| From: | Michael Paquier <michael(at)paquier(dot)xyz> |
|---|---|
| To: | Bruce Momjian <bruce(at)momjian(dot)us> |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Robert Haas <robertmhaas(at)gmail(dot)com>, Hamid Akhtar <hamid(dot)akhtar(at)gmail(dot)com>, Craig Ringer <craig(at)2ndquadrant(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Thomas Kellerer <shammat(at)gmx(dot)net> |
| Subject: | Re: Do we need to handle orphaned prepared transactions in the server? |
| Date: | 2020-04-21 04:52:46 |
| Message-ID: | 20200421045246.GB6436@paquier.xyz |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Mon, Apr 20, 2020 at 10:35:15PM -0400, Bruce Momjian wrote:
> On Thu, Apr 16, 2020 at 03:11:51PM -0400, Tom Lane wrote:
>> If we were going to go down the path of periodically logging warnings
>> about old prepared transactions, some single-instance background task
>> like the checkpointer would be a better place to do the work in. But
>> I'm not really recommending that, because I agree with Robert that
>> we just plain don't want this functionality.
>
> I thought we would just emit a warning at boot time.
That's more tricky than boot time (did you mean postmaster context?),
especially if you are starting a cluster from a base backup as you
have no guarantee that the 2PC information is consistent by just
looking at what's on disk (some of the 2PC files may still be in WAL
records to-be-replayed), so a natural candidate to gather the
information wanted here would be RecoverPreparedTransactions() for a
primary, and StandbyRecoverPreparedTransactions() for a standby.
--
Michael
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Michael Paquier | 2020-04-21 04:57:39 | Re: [BUG] non archived WAL removed during production crash recovery |
| Previous Message | Amit Kapila | 2020-04-21 04:50:01 | Re: design for parallel backup |