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
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 |