Exact same code gives different result in server and local host

Question

I have a back end that uses PostGIS to filter points inside a polygon. Backend is in Django, and here is the code that does the filtering:

def get_queryset(self):
    polystr = self.request.query_params.get('poly', None)
    if polystr:
        poly = GEOSGeometry('SRID=4326;' + polystr)
        qs = PropertyPost.objects.filter(location__contained=poly)
        return qs

So using that I would be able to filter the points inside a polygon, like this in local host (Windows):

http://127.0.0.1:8000/prop-posts/?poly=POLYGON((50.844738 28.957921,50.844906 28.959785,50.8433 28.957801,50.844738 28.957921))

the above returns the points inside the polygon. Now I have 3 points inside the polygon that correctly will be returned by above request. However I have uploaded my code in digital ocean server on Linux, and the below code returns only two points:

http://127.137.139.1/prop-posts/?poly=POLYGON((50.844738 28.957921,50.844906 28.959785,50.8433 28.957801,50.844738 28.957921))

I am puzzled that what can cause this. The code is exactly the same. I usually test things locally and push it to server and everything has been pretty similar so far. So it is odd that it is not working.

Both PostgreSQL (Windows and Linux) are 10.6. However PostGIS versions are a bit different (but I doubt this should make such an issue):

POSTGIS="2.4.3 r16312" on Linux server

POSTGIS="2.4.4 r16526" on local host Windows.

Is there some setting that might be different on Windows and Linux?

Answer 1

(Wrote a comment about this and the OP said it was right, so I will put it here for other people to read as a answer)

About the point that causes the different result: is it clearly inside the polygon? Is it right on the border of the polygon? I have had this issue sometimes with points that are right on the border of the polygon.

For some reason, when using different PostGIS versions, you might get different results when dealing with points right on the border of a polygon.