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

From: "jonathan(dot)camile" <jonathan(dot)camile(at)gmail(dot)com>
To: pgsql-bugs(at)postgresql(dot)org
Subject: Re: BUG #8629: Strange resultset when using CTE or a subselect
Date: 2013-11-26 09:50:15
Message-ID: 1385459415878-5780294.post@n5.nabble.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Hi David,

Thanks for your reply.

Here a query to create table with which I can reproduce this behavior :

CREATE TABLE public.testme AS SELECT generate_series(134800, 348008) as id,
trunc(random() * 9 + 1) as status;

Then if you play with the following query, you will reproduce it.

WITH filtred_test AS (
SELECT c.id
FROM public.testme c
WHERE c.status = ANY ('{5}')
)
SELECT mytest.id, mytest.status
FROM public.testme mytest
WHERE mytest.id IN (SELECT filtred_test.id FROM filtred_test)
ORDER BY mytest.status DESC
OFFSET 35
LIMIT 10

I always have the same last result regardless of the offset or the limit I
use.
If you have any clue about what's wrong I'll be very glad.

By advance, thanks.

David Johnston wrote
>
> jonathan.camile wrote
>> The following bug has been logged on the website:
>>
>> Bug reference: 8629
>> Logged by: Jonathan Camile
>> Email address:

>> jonathan.camile@

>> PostgreSQL version: 9.2.4
>> Operating system: Ubuntu 10.04.4 LTS
>> Description:
>>
>> Hey folks!
>>
>>
>> I have a bit of an issue with a query and I don't understand why.
>> It might be not very elegant but here it is, when I use the following
>> query
>> the last result will always be the same whatsoever the values of LIMIT
>> and
>> OFFSET.
> When debugging ORDER BY/LIMIT it is good practice to output the columns
> being ordered, and others if applicable, and omit the LIMIT (or makes it
> considerably larger than needed) to see what raw table data the LIMIT
> clause is seeing. At minimum you need; "SELECT my_table.id,
> my_table.hdata->'field' FROM ..." for the output and either remove the
> limit or show at least 30 records initially.
>
>
> The small subset of the data you have provided is insufficient to
> determine whether you are making bad assumptions about your data or
> whether there is actually a problem. The fact that it is not
> self-contained makes debugging difficult as well.
>
> Note that LIMIT and OFFSET can appear in either order. While there are
> some parts of a select statement for which the syntax dictates an order
> these do not appear to be in the group. If they could not then LIMIT 5
> OFFSET 100 would make no sense...

David Johnston wrote
>
> jonathan.camile wrote
>> The following bug has been logged on the website:
>>
>> Bug reference: 8629
>> Logged by: Jonathan Camile
>> Email address:

>> jonathan.camile@

>> PostgreSQL version: 9.2.4
>> Operating system: Ubuntu 10.04.4 LTS
>> Description:
>>
>> Hey folks!
>>
>>
>> I have a bit of an issue with a query and I don't understand why.
>> It might be not very elegant but here it is, when I use the following
>> query
>> the last result will always be the same whatsoever the values of LIMIT
>> and
>> OFFSET.
> When debugging ORDER BY/LIMIT it is good practice to output the columns
> being ordered, and others if applicable, and omit the LIMIT (or makes it
> considerably larger than needed) to see what raw table data the LIMIT
> clause is seeing. At minimum you need; "SELECT my_table.id,
> my_table.hdata->'field' FROM ..." for the output and either remove the
> limit or show at least 30 records initially.
>
>
> The small subset of the data you have provided is insufficient to
> determine whether you are making bad assumptions about your data or
> whether there is actually a problem. The fact that it is not
> self-contained makes debugging difficult as well.
>
> Note that LIMIT and OFFSET can appear in either order. While there are
> some parts of a select statement for which the syntax dictates an order
> these do not appear to be in the group. If they could not then LIMIT 5
> OFFSET 100 would make no sense...

David Johnston wrote
>
> jonathan.camile wrote
>> The following bug has been logged on the website:
>>
>> Bug reference: 8629
>> Logged by: Jonathan Camile
>> Email address:

>> jonathan.camile@

>> PostgreSQL version: 9.2.4
>> Operating system: Ubuntu 10.04.4 LTS
>> Description:
>>
>> Hey folks!
>>
>>
>> I have a bit of an issue with a query and I don't understand why.
>> It might be not very elegant but here it is, when I use the following
>> query
>> the last result will always be the same whatsoever the values of LIMIT
>> and
>> OFFSET.
> When debugging ORDER BY/LIMIT it is good practice to output the columns
> being ordered, and others if applicable, and omit the LIMIT (or makes it
> considerably larger than needed) to see what raw table data the LIMIT
> clause is seeing. At minimum you need; "SELECT my_table.id,
> my_table.hdata->'field' FROM ..." for the output and either remove the
> limit or show at least 30 records initially.
>
>
> The small subset of the data you have provided is insufficient to
> determine whether you are making bad assumptions about your data or
> whether there is actually a problem. The fact that it is not
> self-contained makes debugging difficult as well.
>
> Note that LIMIT and OFFSET can appear in either order. While there are
> some parts of a select statement for which the syntax dictates an order
> these do not appear to be in the group. If they could not then LIMIT 5
> OFFSET 100 would make no sense...

--
View this message in context: http://postgresql.1045698.n5.nabble.com/BUG-8629-Strange-resultset-when-using-CTE-or-a-subselect-tp5780187p5780294.html
Sent from the PostgreSQL - bugs mailing list archive at Nabble.com.

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message strahinjak 2013-11-26 13:01:52 BUG #8632: file "pg_subtrans/CEC0" doesn't exist, reading as zeroes
Previous Message Francisco Olarte 2013-11-26 08:57:29 Re: BUG #8628: md5 security hole