From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Thomas Munro <thomas(dot)munro(at)gmail(dot)com> |
Cc: | Michael Paquier <michael(at)paquier(dot)xyz>, Andrey Borodin <amborodin86(at)gmail(dot)com>, Justin Pryzby <pryzby(at)telsasoft(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: Something is wrong with wal_compression |
Date: | 2023-01-27 02:04:04 |
Message-ID: | 3248602.1674785044@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 1:30 PM Michael Paquier <michael(at)paquier(dot)xyz> wrote:
>> My opinion would be to make this function more reliable, FWIW, even if
>> that involves a performance impact when called in a close loop by
>> forcing more WAL flushes to ensure its report durability and
>> consistency.
> Yeah, the other thread has a patch for that. But it would hurt some
> workloads.
I think we need to get the thing correct first and worry about
performance later. What's wrong with simply making pg_xact_status
write and flush a record of the XID's existence before returning it?
Yeah, it will cost you if you use that function, but not if you don't.
> A better patch would do some kind of amortisation
> (reserving N xids at a time or some such scheme, while being careful
> to make sure the right CLOG pages etc exist if you crash and skip a
> bunch of xids on recovery) but be more complicated.
Maybe that would be appropriate for HEAD, but I'd be wary of adding
anything complicated to the back branches. This is clearly a very
under-tested area.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2023-01-27 02:37:43 | Re: New strategies for freezing, advancing relfrozenxid early |
Previous Message | Amit Langote | 2023-01-27 01:39:42 | Re: wrong Append/MergeAppend elision? |