Re: Something is wrong with wal_compression
От | Laurenz Albe |
---|---|
Тема | Re: Something is wrong with wal_compression |
Дата | |
Msg-id | 2673184ea95b7c4698e5b206b902424768a396b0.camel@cybertec.at обсуждение исходный текст |
Ответ на | Re: Something is wrong with wal_compression (Thomas Munro <thomas.munro@gmail.com>) |
Ответы |
Re: Something is wrong with wal_compression
|
Список | pgsql-hackers |
On Fri, 2023-01-27 at 16:15 +1300, Thomas Munro wrote: > On Fri, Jan 27, 2023 at 3:04 PM Tom Lane <tgl@sss.pgh.pa.us> wrote: > > Thomas Munro <thomas.munro@gmail.com> writes: > > > On Fri, Jan 27, 2023 at 1:30 PM Michael Paquier <michael@paquier.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. > > There is no > doubt that the current situation is unacceptable, though, so maybe we > really should just do it and make a faster one later. Anyone else > want to vote on this? I wasn't aware of the existence of pg_xact_status, so I suspect that it is not a widely known and used feature. After reading the documentation, I'd say that anybody who uses it will want it to give a reliable answer. So I'd agree that it is better to make it more expensive, but live up to its promise. Yours, Laurenz Albe
В списке pgsql-hackers по дате отправления: