Re: Honor inherited ownership when finishing prepared transactions

From: Kirill Reshke <reshkekirill(at)gmail(dot)com>
To: Andrey Borodin <x4mmm(at)yandex-team(dot)ru>
Cc: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Honor inherited ownership when finishing prepared transactions
Date: 2026-11-09 11:33:27
Message-ID: CALdSSPiaUqhhcC5CckLTrSEkHuSydjDk5WdR89s6QXjYa4E3bQ@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, 9 Nov 2026 at 15:30, Andrey Borodin <x4mmm(at)yandex-team(dot)ru> wrote:
>
> Hi Kirill,
>
> On November 2, 2026, Kirill Reshke wrote:
> > So, can we use same in 2pc (prepared) tx?
>
> I agree that prepared transactions should follow the same inherited
> ownership rules as other objects. has_privs_of_role() seems the right
> check, including INHERIT TRUE, SET FALSE.
>
> In the roles discussion you linked, Tom explicitly suggested retaining
> this check. I think it is worth revisiting that decision.

Sure. Maybe it was some sort of safety measure back then - but I don't
get the exact vulnerability.

> One implementation detail. LockGXact() currently checks ownership while
> holding TwoPhaseStateLock. Membership expansion can read pg_auth_members
> and acquire a relation lock on a cache miss. Could we reserve the GXACT,
> release the LWLock, then check permission, using the existing abort
> cleanup if permission is denied?
>
> Could you post the patch?
>
> Thank you!
>
>
> Best regards, Andrey Borodin.
>

PFA

--
Best regards,
Kirill Reshke

Attachment Content-Type Size
v1-0001-Honor-inherited-ownership-when-finishing-prepared.patch application/octet-stream 21.4 KB

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Zhijie Hou 2026-11-09 11:34:41 Re: Avoid using raw xmin of frozen tuples in logicalrep conflict detection
Previous Message Tomas Vondra 2026-11-09 11:33:17 Re: A gap in preventing bogus parameterizations in a798660ebe3