Re: [HACKERS] Restrict concurrent update/delete with UPDATE ofpartition key - Mailing list pgsql-hackers

From Robert Haas
Subject Re: [HACKERS] Restrict concurrent update/delete with UPDATE ofpartition key
Date
Msg-id CA+TgmoYY98AEjh7RDtuzaLC--_0smCozXRu6bFmZTaX5Ne=B5Q@mail.gmail.com
Whole thread Raw
In response to [HACKERS] Restrict concurrent update/delete with UPDATE of partition key  (amul sul <sulamul@gmail.com>)
Responses Re: [HACKERS] Restrict concurrent update/delete with UPDATE ofpartition key  (amul sul <sulamul@gmail.com>)
List pgsql-hackers
On Wed, Sep 27, 2017 at 7:07 AM, amul sul <sulamul@gmail.com> wrote:
> Attaching POC patch that throws an error in the case of a concurrent update
> to an already deleted tuple due to UPDATE of partition key[1].
>
> In a normal update new tuple is linked to the old one via ctid forming
> a chain of tuple versions but UPDATE of partition key[1] move tuple
> from one partition to an another partition table which breaks that chain.

This patch needs a rebase.  It has one whitespace-only hunk that
should possibly be excluded.

I think the basic idea of this is sound.  Either you or Amit need to
document the behavior in the user-facing documentation, and it needs
tests that hit every single one of the new error checks you've added
(obviously, the tests will only work in combination with Amit's
patch).  The isolation should be sufficient to write such tests.

It needs some more extensive comments as well.  The fact that we're
assigning a meaning to ip_blkid -> InvalidBlockNumber is a big deal,
and should at least be documented in itemptr.h in the comments for the
ItemPointerData structure.

I suspect ExecOnConflictUpdate needs an update for the
HeapTupleUpdated case similar to what you've done elsewhere.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: [HACKERS] parallelize queries containing initplans
Next
From: Peter Eisentraut
Date:
Subject: Re: [HACKERS] LDAP URI decoding bugs