From: | David Rowley <david(dot)rowley(at)2ndquadrant(dot)com> |
---|---|
To: | Andres Freund <andres(at)anarazel(dot)de> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Michael Paquier <michael(at)paquier(dot)xyz>, Postgres hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Custom table AMs need to include heapam.h because of BulkInsertState |
Date: | 2019-06-13 01:42:11 |
Message-ID: | CAKJS1f8C6MDRg7sGNtPC35Dw0GAF85KE+wfTgwQq=8-cqu59ww@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, 10 Jun 2019 at 11:45, David Rowley <david(dot)rowley(at)2ndquadrant(dot)com> wrote:
>
> On Sat, 8 Jun 2019 at 04:51, Andres Freund <andres(at)anarazel(dot)de> wrote:
> > David, any opinions on how to best fix this? It's not extremely obvious
> > how to do so best in the current setup of the partition actually being
> > hidden somewhere a few calls away (i.e. the table_open happening in
> > ExecInitPartitionInfo()).
>
> That's been overlooked. I agree it's not a bug with heap, since
> heapam_finish_bulk_insert() only does anything there when we're
> skipping WAL, which we don't do in copy.c for partitioned tables.
> However, who knows what other AMs will need, so we'd better fix that.
>
> My proposed patch is attached.
>
> I ended up moving the call to CopyMultiInsertInfoCleanup() down to
> after we call table_finish_bulk_insert for the main table. This might
> not be required but I lack imagination right now to what AMs might put
> in the finish_bulk_insert call, so doing this seems safer.
Andres, do you want to look at this before I look again?
Do you see any issue with calling table_finish_bulk_insert() when the
partition's CopyMultiInsertBuffer is evicted from the
CopyMultiInsertInfo rather than at the end of the copy? It can mean
that we call the function multiple times per partition. I assume the
function is only really intended to flush bulk inserted tuple to the
storage, so calling it more than once would just mean an inefficiency
rather than a bug.
Let me know your thoughts.
--
David Rowley http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2019-06-13 02:29:34 | Re: PG 12 draft release notes |
Previous Message | Peter Geoghegan | 2019-06-13 01:34:27 | Re: PG 12 draft release notes |