Amit Langote wrote: > Since this bug also exists in the released PG 10 branch, I also created a > patch for that. It's slightly different than the one for PG 11dev, > because there were some changes recently to how the memory context is > manipulated in RelationBuildPartitionKey. That's > v1-PG10-0001-Fix-a-memory-context-bug-in-RelationBuildPartitio.patch.
Here's a repro for pg10, which doesn't have hash partitioning: create function my_int4_sort(int4,int4) returns int language sql as $$ select case when $1 = $2 then 0 when $1 > $2 then 1 else -1 end; $$; create operator class test_int4_ops for type int4 using btree as operator 1 < (int4,int4), operator 2 <= (int4,int4), operator 3 = (int4,int4), operator 4 >= (int4,int4), operator 5 > (int4,int4), function 1 my_int4_sort(int4,int4); create table t (a int4) partition by range (a test_int4_ops); create table t1 partition of t for values from (0) to (1000); insert into t values (100); insert into t values (200); -- *boom* I'm dealing with this now -- will push shortly. The sane thing to do is backpatch my previous memcxt fixes, since your patch introduces a problem that we discussed with that other patch, namely that you would leak the whole memory context if there is a problem while running the function. I also noticed here that copy_partition_key is doing memcpy() on the fmgr_info, which is bogus -- it should be using fmgr_info_copy. Rather than patching that one piece it seems better to replace it wholesale, since I bet this won't be the last time we'll hear about this routine, and I would prefer not to deal with differently broken code in the older branch. -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
