From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Thomas Munro <thomas(dot)munro(at)gmail(dot)com> |
Cc: | Andrey Borodin <amborodin86(at)gmail(dot)com>, Justin Pryzby <pryzby(at)telsasoft(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org, Michael Paquier <michael(at)paquier(dot)xyz> |
Subject: | Re: Something is wrong with wal_compression |
Date: | 2023-01-26 23:04:42 |
Message-ID: | 3223666.1674774282@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Thomas Munro <thomas(dot)munro(at)gmail(dot)com> writes:
> On Fri, Jan 27, 2023 at 11:14 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> If any tuples made by that transaction had reached disk,
>> we'd have a problem.
> The problem is that the WAL wasn't flushed, allowing the same xid to
> be allocated again after crash recovery. But for any data pages to
> hit the disk, we'd have to flush WAL first, so then it couldn't
> happen, no?
Ah, now I get the point: the "committed xact" seen after restart
isn't the same one as we saw before the crash, but a new one that
was given the same XID because nothing about the old one had made
it to disk yet.
> FWIW I also re-complained about the dangers of anyone
> relying on pg_xact_status() for its stated purpose after seeing
> tanager's failure[1].
Indeed, it seems like this behavior makes pg_xact_status() basically
useless as things stand.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Jeff Davis | 2023-01-26 23:29:30 | Re: GUCs to control abbreviated sort keys |
Previous Message | Jelte Fennema | 2023-01-26 22:54:41 | Re: run pgindent on a regular basis / scripted manner |