Re: COPY, lock release and MVCC

From: Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: COPY, lock release and MVCC
Date: 2020-05-12 19:50:40
Message-ID: 9f043b1dac1347a757236fd84eed8d67d8eeec6b.camel@cybertec.at
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, 2020-05-12 at 11:50 -0400, Tom Lane wrote:
> Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at> writes:
> > On Mon, 2020-05-11 at 15:43 -0400, Robert Haas wrote:
> > > On Fri, May 8, 2020 at 4:58 AM Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at> wrote:
> > > > I happened to notice that COPY TO releases the ACCESS SHARE lock
> > > > on the table right when the command ends rather than holding it
> > > > until the end of the transaction:
> > > That seems inconsistent with what an INSERT statement would do, and thus bad.
> > Well, should we fix the code or the documentation?
>
> I'd agree with fixing the code. Early lock release is something we do on
> system catalog accesses, and while it hasn't bitten us yet, I've been
> kind of expecting that someday it will. We should not do it on SQL-driven
> accesses to user tables.
>
> Having said that, I'd vote for just changing it in HEAD, not
> back-patching. It's not clear that there are consequences bad enough
> to merit a back-patched behavior change.

Agreed.

Here is a patch.

Yours,
Laurenz Albe

Attachment Content-Type Size
0001-Make-COPY-TO-keep-locks-until-transaction-end.patch text/x-patch 1.6 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2020-05-12 20:00:46 Re: Our naming of wait events is a disaster.
Previous Message Tom Lane 2020-05-12 19:50:35 Inefficiency in SLRU stats collection