Re: Declarative partitioning

0003-... patch does not apply cleanly. It has some conflicts in pg_dump.c.
I have tried fixing the conflict in attached patch.

On Mon, May 23, 2016 at 3:35 PM, Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp
> wrote:

>
> 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.
>
> Thanks,
> Amit
>
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
>
>

--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company