pg.ddx.io pgsql-hackers@postgresql.org mailing list archive
help / color / mirror / Atom feed From: Andres Freund <andres@anarazel.de>
To: Amit Kapila <amit.kapila16@gmail.com>
Cc: amul sul <sulamul@gmail.com>
Cc: Stephen Frost <sfrost@snowman.net>
Cc: Robert Haas <robertmhaas@gmail.com>
Cc: PostgreSQL-development <pgsql-hackers@postgresql.org>
Subject: Re: [HACKERS] Restrict concurrent update/delete with UPDATE of partition key
Date: Tue, 3 Apr 2018 16:01:50 -0700
Message-ID: <20180403230150.b564ihenfuktt7cp@alap3.anarazel.de> (raw )
In-Reply-To: <CAA4eK1KFfm4PBbshNSikdru3Qpt8hUoKQWtBYjdVE2R7U9f6iA@mail.gmail.com >
References: <CAAJ_b95R4i-+4VevSYEg1HdT+Zq6v5BuZ1zD14-yzpxe+kioqg@mail.gmail.com >
<CAA4eK1LrOf+ZGkjMbiL7GjvFXoQ_O+XPyXHTL-L5yhd+WU4NWQ@mail.gmail.com >
<CAAJ_b97w_GGV-k4ErxWTpz5sAgFJ4aUYMx0khfySvANmWRzsag@mail.gmail.com >
<CAA4eK1Kn7EgUdnFnp0d+Jk7Chf88qsyzNBDfJ8OJsMGpKuX4mA@mail.gmail.com >
<CAAJ_b94_29wiUA83W8LQjtfjv9XNV=+PT8+ioWRPjnnFHe3eqw@mail.gmail.com >
<CAAJ_b94rtTW+J-_NH0V_q13SXLyMt0d1NSj+SAh439j3c-wPmA@mail.gmail.com >
<CAA4eK1KtsTqsGDggDCrz2O9Jgo7ma-Co-B8+v3L2zWMA2NHm6A@mail.gmail.com >
<CAAJ_b95GpE7Qh+17zY-d5p5xPfqcTSY5ppEiYyeGTmoPaw=zXQ@mail.gmail.com >
<20180305232353.gpue7jldnm4bjf4i@alap3.anarazel.de >
<CAA4eK1KFfm4PBbshNSikdru3Qpt8hUoKQWtBYjdVE2R7U9f6iA@mail.gmail.com >
On 2018-03-06 19:57:03 +0530, Amit Kapila wrote:
> On Tue, Mar 6, 2018 at 4:53 AM, Andres Freund <andres@anarazel.de> wrote:
> > Hi,
> >
> >> diff --git a/src/backend/executor/nodeLockRows.c b/src/backend/executor/nodeLockRows.c
> >> index 7961b4be6a..b07b7092de 100644
> >> --- a/src/backend/executor/nodeLockRows.c
> >> +++ b/src/backend/executor/nodeLockRows.c
> >> @@ -218,6 +218,11 @@ lnext:
> >> ereport(ERROR,
> >> (errcode(ERRCODE_T_R_SERIALIZATION_FAILURE),
> >> errmsg("could not serialize access due to concurrent update")));
> >> + if (!BlockNumberIsValid(BlockIdGetBlockNumber(&((hufd.ctid).ip_blkid))))
> >> + ereport(ERROR,
> >> + (errcode(ERRCODE_OBJECT_NOT_IN_PREREQUISITE_STATE),
> >> + errmsg("tuple to be locked was already moved to another partition due to concurrent update")));
> >> +
> >
> > Why are we using ERRCODE_OBJECT_NOT_IN_PREREQUISITE_STATE rather than
> > ERRCODE_T_R_SERIALIZATION_FAILURE? A lot of frameworks have builtin
> > logic to retry serialization failures, and this kind of thing is going
> > to resolved by retrying, no?
> >
>
> I think it depends, in some cases retry can help in deleting the
> required tuple, but in other cases like when the user tries to perform
> delete on a particular partition table, it won't be successful as the
> tuple would have been moved.
So? In that case the retry will not find the tuple, which'll also
resolve the issue. Preventing frameworks from dealing with this seems
like a way worse issue than that.
Greetings,
Andres Freund
view thread (84+ messages) latest in thread
Message-ID: <20180403230150.b564ihenfuktt7cp@alap3.anarazel.de>
Permalink: ../20180403230150.b564ihenfuktt7cp@alap3.anarazel.de/
Also on: postgresql.org/message-id/20180403230150.b564ihenfuktt7cp@alap3.anarazel.de
copy link · copy postgr.es
reply Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: andres@anarazel.de, amit.kapila16@gmail.com, sulamul@gmail.com, sfrost@snowman.net, robertmhaas@gmail.com
Subject: Re: [HACKERS] Restrict concurrent update/delete with UPDATE of partition key
In-Reply-To: <20180403230150.b564ihenfuktt7cp@alap3.anarazel.de>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox