On Wed, May 13, 2020 at 1:20 AM Laurenz Albe <laurenz.a...@cybertec.at> wrote:
>
> On Tue, 2020-05-12 at 11:50 -0400, Tom Lane wrote:
> > Laurenz Albe <laurenz.a...@cybertec.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.a...@cybertec.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.
>
- /*
- * Close the relation. If reading, we can release the AccessShareLock we
- * got; if writing, we should hold the lock until end of transaction to
- * ensure that updates will be committed before lock is released.
- */
- if (rel != NULL)
- table_close(rel, (is_from ? NoLock : AccessShareLock));
+ table_close(rel, NoLock);
I wonder why you have removed (rel != NULL) check? It can be NULL
when we use a query instead of a relation. Refer below code:
DoCopy()
{
..
..
{
Assert(stmt->query);
query = makeNode(RawStmt);
query->stmt = stmt->query;
query->stmt_location = stmt_location;
query->stmt_len = stmt_len;
relid = InvalidOid;
rel = NULL;
}
..
}
--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
