Re: possible bug

On 2022-Oct-21, Tom Lane wrote: > "David G. Johnston" writes: > > On Fri, Oct 21, 2022 at 4:52 PM Ravi Krishna wrote: > >> on a diff note, is the word memoize inspired from Perl Module memoize > >> which use to do the same thing. > > > It is a general functional programming concept - not sure o

Re: possible bug

On Fri, Oct 21, 2022 at 6:09 PM Tom Lane wrote: > "David G. Johnston" writes: > > On Fri, Oct 21, 2022 at 4:52 PM Ravi Krishna > wrote: > >> on a diff note, is the word memoize inspired from Perl Module memoize > >> which use to do the same thing. > > > It is a general functional programming co

Re: possible bug

"David G. Johnston" writes: > On Fri, Oct 21, 2022 at 4:52 PM Ravi Krishna wrote: >> on a diff note, is the word memoize inspired from Perl Module memoize >> which use to do the same thing. > It is a general functional programming concept - not sure on the history > but probably academic and thu

Re: possible bug

On Fri, Oct 21, 2022 at 4:52 PM Ravi Krishna wrote: > on a diff note, is the word memoize inspired from Perl Module memoize > which use to > do the same thing. > It is a general functional programming concept - not sure on the history but probably academic and thus Perl and others picked it up "

Re: possible bug

on a diff note, is the word memoize inspired from Perl Module memoize which use todo the same thing.

Re: possible bug

Les writes: > As always, you hit the nail on the head. set enable_memoize = on fixes the > problem! > Version is PostgreSQL 14.1, time to upgrade... Yup, very likely fixed by c2dc7b9e1 then. > I'm sorry that I wasted your time. No need to apologize, it was an actual bug.

Re: possible bug

> Which PG version is this exactly? Given the Memoize node shown > in your plan, I suppose 14.something, but is it up to date? > There were Memoize-related bug fixes in 14.2 and 14.4, and the > one in 14.2 looks particularly likely to be relevant. > > If you are on the current minor release, does

Re: possible bug

Les writes: > We had a support request today, and we have narrowed down the problem to a > query that behaves very strangely. The actual query was much more > complicated, but I came up with this minimal example. Which PG version is this exactly? Given the Memoize node shown in your plan, I supp

Re: possible bug

> > > > So what happens if query the table directly?: > > select * from wf.workflow where head_table_id::float8::int8 = 25408438504; > > vs > > select * from wf.workflow where head_table_id = 25408438504; > > Both return lots of rows. The same number of rows. select count(*) from wf.workflow wh

Re: possible bug

On 10/21/22 10:57 AM, Les wrote: One of my colleagues pointed out, that they query returns a different result, if I cast the head_table_id condition to float8 and then back to int8. SELECT c.id ,     tt.code,     c.regno,     (         select count(*)         FROM kap.course_

Re: possible bug

Not that I know of. I just tried this: reindex table kap.course; reindex table kap.course_user; reindex table wf.workflow; reindex table kap.training_type; But it is still wrong. Adrian Klaver ezt írta (időpont: 2022. okt. 21., P, 19:57): > On 10/21/22 10:50 AM, Les wrote: > > Hello, > > >

Re: possible bug

One of my colleagues pointed out, that they query returns a different result, if I cast the head_table_id condition to float8 and then back to int8. SELECT c.id, tt.code, c.regno, ( select count(*) FROM kap.course_user cu JOIN wf.workflow w_1 ON w_1.rec_id =

Re: possible bug

On 10/21/22 10:50 AM, Les wrote: Hello, We had a support request today, and we have narrowed down the problem to a query that behaves very strangely. The actual query was much more complicated, but I came up with this minimal example. This is what we have seen inside our application: select

possible bug

Hello, We had a support request today, and we have narrowed down the problem to a query that behaves very strangely. The actual query was much more complicated, but I came up with this minimal example. This is what we have seen inside our application: select * from test where id in (26643094740,

Re: Possible bug: SQL function parameter in window frame definition

Andrew Gierth writes: > "Tom" == Tom Lane writes: > Tom> Hmm. I think this is a reasonable direction to go in, but > Tom> what about groupingSets and rowMarks? > groupingSets ultimately contains nothing but numbers which are > meaningless without reference to the matching groupClause list. So

Re: Possible bug: SQL function parameter in window frame definition

> "Tom" == Tom Lane writes: >> Here is a draft patch along those lines; the intent of this one is >> that no existing walker or mutator should need to change (the change >> to the dependency code is basically cosmetic I believe, just avoids >> walking some things twice). Tom> Hmm. I th

Re: Possible bug: SQL function parameter in window frame definition

Andrew Gierth writes: > "Andrew" == Andrew Gierth writes: > Andrew> We could minimize the chance of breakage in a back-patched fix > Andrew> by having query_tree_walker/mutator iterate the windowClause > Andrew> list itself > Here is a draft patch along those lines; the intent of this one is

Re: Possible bug: SQL function parameter in window frame definition

> "Andrew" == Andrew Gierth writes: Andrew> We could minimize the chance of breakage in a back-patched fix Andrew> by having query_tree_walker/mutator iterate the windowClause Andrew> list itself Here is a draft patch along those lines; the intent of this one is that no existing walker or

Re: Possible bug: SQL function parameter in window frame definition

> "Tom" == Tom Lane writes: Tom> However, we need to fix this in all active branches, and I Tom> definitely agree with minimizing the amount of change to back Tom> branches. The fact that the minimal change breaks (or exposes an Tom> oversight in) assign_collations_walker makes it very pl

Re: Possible bug: SQL function parameter in window frame definition

Andrew Gierth writes: > "Tom" == Tom Lane writes: > Tom> Now probably this is never called on utility statements, and maybe > Tom> there is never a reason for anyone to examine or mutate > Tom> SortGroupClauses, GroupingSets, or RowMarkClauses, but I'm not > Tom> sure it's any business of thi

Re: Possible bug: SQL function parameter in window frame definition

> "Tom" == Tom Lane writes: Tom> It looks to me that the reason is that query_tree_mutator Tom> (likewise query_tree_walker) fails to visit query->windowClause, I noticed this too. I spent some time looking at what might break if that was changed (found two places so far, see attached draf

Re: Possible bug: SQL function parameter in window frame definition

Andrew Gierth writes: > "Alastair" == Alastair McKinley writes: > Alastair> This appears to be a bug to me. > Yes, it's a bug, related to function inlining (the select f(3); is not > inlined and therefore works, but the select * from f(3); is being > inlined, but the original Param is somehow m

Re: Possible bug: SQL function parameter in window frame definition

> "Alastair" == Alastair McKinley writes: Alastair> Hi all, Alastair> I noticed this strange behaviour whilst trying to write a Alastair> function for Postgres 11.5 (PostgreSQL 11.5 on Alastair> x86_64-pc-linux-gnu, compiled by gcc (GCC) 4.8.5 20150623 Alastair> (Red Hat 4.8.5-36), 64-b

Possible bug: SQL function parameter in window frame definition

Hi all, I noticed this strange behaviour whilst trying to write a function for Postgres 11.5 (PostgreSQL 11.5 on x86_64-pc-linux-gnu, compiled by gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-36), 64-bit) and reduced it to this minimal example. Using a function parameter in the window frame definiti

Re: GiST index on INT8, possible bug in query planner?

On Mon, 03 Dec 2018 11:47:17 -0500 Tom Lane wrote: > Jan Behrens writes: > > > However, the GiST index seems not to work as expected by me when > > 64-bit integers are involved. I tried to create a minimal > > proof-of-concept to demonstrate this. Consider the following setup: > > > > CREATE T

Re: GiST index on INT8, possible bug in query planner?

Jan Behrens writes: > However, the GiST index seems not to work as expected by me when > 64-bit integers are involved. I tried to create a minimal > proof-of-concept to demonstrate this. Consider the following setup: > CREATE TABLE test8_gist (id SERIAL4, ctx INT8); > CREATE INDEX ON test8_gist US

GiST index on INT8, possible bug in query planner?

Dear colleagues, I have developed two indices using PostgreSQL's awesome GiST support, one of them available here: http://www.public-software-group.org/pgLatLon (which is a lightweight and MIT-licensed alternative to PostGIS for certain simple tasks involving geographic coordinates on the WGS-84

Re: Possible bug: could not open relation with OID [numbers] SQL State: XX000

I would like to refresh the topic and add another report about the issue that just happened to me.I'm sure it's the toast table that cannot be opened inside the function.I have added following RAISE NOTICE clauses to it and run analyze inside of the function: analyze verbose temp_table;