From: | Simon Riggs <simon(at)2ndquadrant(dot)com> |
---|---|
To: | Andres Freund <andres(at)anarazel(dot)de> |
Cc: | Konstantin Knizhnik <k(dot)knizhnik(at)postgrespro(dot)ru>, Michael Paquier <michael(at)paquier(dot)xyz>, Stas Kelvich <s(dot)kelvich(at)postgrespro(dot)ru>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Read-only access to temp tables for 2PC transactions |
Date: | 2019-05-26 08:45:55 |
Message-ID: | CANP8+jJ6of+w3y-2Q6pbguVyvqYSn+Dk5TiXQ_2c8f_r=6gY-Q@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, 24 May 2019 at 18:09, Andres Freund <andres(at)anarazel(dot)de> wrote:
> Hi,
>
> On 2019-05-24 19:37:15 +0300, Konstantin Knizhnik wrote:
> > From my point of view releasing all temporary table locks after
> preparing of
> > 2PC transaction is not technically possible:
> > assume that this transaction has updated some tuples of temporary table
> - them
> > are not visible to other transactions until 2PC is committed,
> > but since lock is removed, other transactions can update the same tuple.
>
> I don't think tuple level actions are the problem? Those doesn't require
> table level locks to be held.
>
> Generally, I fail to see how locks themselves are the problem.
Agreed
> The
> problem are the catalog entries for the temp table, the relation forks,
> and the fact that a session basically couldn't drop (and if created in
> that transaction, use) etc the temp table after the PREPARE.
>
I don't see there is a problem here, but run out of time to explain more,
for a week.
--
Simon Riggs http://www.2ndQuadrant.com/
<http://www.2ndquadrant.com/>
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Tatsuo Ishii | 2019-05-26 12:53:41 | vacuumdb as server application in v12 release note |
Previous Message | didier | 2019-05-26 07:41:23 | Re: [HACKERS] Small fix: avoid passing null pointers to memcpy() |