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 |
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 |