Re: deferred writing of two-phase state files adds fragility

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: deferred writing of two-phase state files adds fragility
Date: 2024-12-04 17:58:43
Message-ID: 2372479.1733335123@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Wed, Dec 4, 2024 at 12:19 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Could we fix it so ROLLBACK TRANSACTION removes the GID from the
>> list of prepared xacts that need to be written out? Then we'd
>> no longer have a pending requirement to read the broken WAL record.

> That would be nice, but I'm not sure that it's possible. As currently
> implemented, FinishPreparedTransaction() always reads the two-phase
> state data either from the two-phase file or the WAL, whether it's
> committing or rolling back.

I'm not following. FinishPreparedTransaction is not what's preventing
checkpoints or holding back the VACUUM horizon. What is doing that
is the in-memory fake PGPROC representing the prepared transaction
(I forget the exact terminology). I'm suggesting that we could have
some way to nuke one of those without properly cleaning up the
prepared xact. Maybe it'd need to be invoked via a different command
than ROLLBACK TRANSACTION.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2024-12-04 18:01:42 Re: deferred writing of two-phase state files adds fragility
Previous Message Robert Haas 2024-12-04 17:44:05 Re: deferred writing of two-phase state files adds fragility