On Wed, 5 May 2021 at 23:15, Craig Ringer wrote:
> Which was fine as far as it went, but I failed to account for the xid
> assignment not necessarily being durable when the client calls
> txid_status().
Ahem, I meant "when the client calls txid_current()"
--
Craig Ringer htt
On Tue, 9 Feb 2021 at 05:52, Andres Freund wrote:
>
> Craig, it kind of looks to me like you assumed it'd be guaranteed that
> the xid at this point would show in-progress?
>
At the time I wrote that code, I don't think I understood that xid
assignment wasn't necessarily durable until either (a)
On Wed, 10 Feb 2021 at 04:28, Robert Haas wrote:
> On Mon, Feb 8, 2021 at 4:52 PM Andres Freund wrote:
> > The 011_crash_recovery.pl test test starts a transaction, creates a
> > table, fetches the transaction's xid. Then shuts down the server in
> > immediate mode. It then asserts that after cr
On Mon, Feb 8, 2021 at 4:52 PM Andres Freund wrote:
> The 011_crash_recovery.pl test test starts a transaction, creates a
> table, fetches the transaction's xid. Then shuts down the server in
> immediate mode. It then asserts that after crash recovery the previously
> assigned xid is shown as abor
Hi Craig, Robert,
The 011_crash_recovery.pl test test starts a transaction, creates a
table, fetches the transaction's xid. Then shuts down the server in
immediate mode. It then asserts that after crash recovery the previously
assigned xid is shown as aborted, and that new xids are assigned after
