Re: BUG #8629: Strange resultset when using CTE or a subselect

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: bricklen <bricklen(at)gmail(dot)com>
Cc: "jonathan(dot)camile" <jonathan(dot)camile(at)gmail(dot)com>, pgsql-bugs(at)postgresql(dot)org
Subject: Re: BUG #8629: Strange resultset when using CTE or a subselect
Date: 2013-11-26 17:22:08
Message-ID: 9529.1385486528@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

bricklen <bricklen(at)gmail(dot)com> writes:
> On Tue, Nov 26, 2013 at 1:50 AM, jonathan.camile
> <jonathan(dot)camile(at)gmail(dot)com>wrote:
>> I always have the same last result regardless of the offset or the limit I
>> use.

> I cannot reproduce your problem in 9.2.5 nor 9.3.1. Rerunning the query
> with different OFFSET values gives me different results each time.

I do reproduce the behavior, at least when offset+limit is small enough
that the executor will use a top-N heapsort. As already stated, it's
not a bug; the ordering is underdetermined so any set of the correct
number of rows with status = 5 is a valid output. As for what's actually
happening: the row that always shows up seems to be the physically first
one with status = 5. I think that's starting out as the top of the top-N
heap, and it just stays there because there's nothing that can displace
it.

regards, tom lane

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Peter Eisentraut 2013-11-26 19:54:11 Re: Re: [BUGS] BUG #7873: pg_restore --clean tries to drop tables that don't exist
Previous Message bricklen 2013-11-26 16:52:04 Re: BUG #8629: Strange resultset when using CTE or a subselect