Hi Ildar, On 2016/05/21 0:29, Ildar Musin wrote: > On 20.05.2016 11:37, Amit Langote wrote: >> Moreover, instead of pruning partitions in planner prep phase, might it >> not be better to do that when considering paths for the (partitioned) rel? >> IOW, instead of looking at parse->jointree, we should rather be working >> with rel->baserestrictinfo. Although, that would require some revisions >> to how append_rel_list, simple_rel_list, etc. are constructed and >> manipulated in a given planner invocation. Maybe it's time for that... >> Again, you may have already considered these things. >> > Yes, you're right, this is how we did it in pg_pathman extension. But for > this patch it requires further consideration and I'll do it in future!
OK, sure. >> Could you try with the attached updated set of patches? I changed >> partition descriptor relcache code to eliminate excessive copying in >> previous versions.
[...] > However I've encountered a problem which is that postgres crashes > occasionally while creating partitions. Here is function that reproduces > this behaviour: > > CREATE OR REPLACE FUNCTION fail() > RETURNS void > LANGUAGE plpgsql > AS $$ > BEGIN > DROP TABLE IF EXISTS abc CASCADE; > CREATE TABLE abc (id SERIAL NOT NULL, a INT, dt TIMESTAMP) PARTITION BY > RANGE (a); > CREATE INDEX ON abc (a); > CREATE TABLE abc_0 PARTITION OF abc FOR VALUES START (0) END (1000); > CREATE TABLE abc_1 PARTITION OF abc FOR VALUES START (1000) END (2000); > END > $$; > > SELECT fail(); > > It happens not every time but quite often. It doesn't happen if I execute > this commands one by one in psql. Backtrace: > > #0 range_overlaps_existing_partition (key=0x7f1097504410, > range_spec=0x1d0f400, pdesc=0x1d32200, with=0x7ffe437ead00) at > partition.c:747
[...]
I made a mistake in the last version of the patch which caused a relcache field to be pfree'd unexpectedly. Attached updated patches.