Re: Sketch of a fix for that truncation data corruption issue
От | Alvaro Herrera |
---|---|
Тема | Re: Sketch of a fix for that truncation data corruption issue |
Дата | |
Msg-id | 20230403103428.lgglnfn2qstrrbox@alvherre.pgsql обсуждение исходный текст |
Ответ на | Re: Sketch of a fix for that truncation data corruption issue (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Sketch of a fix for that truncation data corruption issue
|
Список | pgsql-hackers |
On 2018-Dec-11, Tom Lane wrote: > Robert Haas <robertmhaas@gmail.com> writes: > > On Tue, Dec 11, 2018 at 3:06 PM Tom Lane <tgl@sss.pgh.pa.us> wrote: > >> Anyway, if your assumption is that WAL replay must yield bit-for-bit > >> the same state of the not-truncated pages that the master would have, > >> then I doubt we can make this work. In that case we're back to the > >> type of solution you rejected eight years ago, where we have to write > >> out pages before truncating them away. > > > How much have you considered the possibility that my rejection of that > > approach was a stupid and wrong-headed idea? I'm not sure I still > > believe that not writing those buffers would have a meaningful > > performance cost. > > Well, if *you're* willing to entertain that possiblity, I'm on board. > That would certainly lead to a much simpler, and probably back-patchable, > fix. Hello, Has this problem been fixed? I was under the impression that it had been, but I spent some 20 minutes now looking for code, commits, or patches in the archives, and I can't find anything relevant. Maybe it was fixed in some different way that's not so obviously connected? Thanks, -- Álvaro Herrera 48°01'N 7°57'E — https://www.EnterpriseDB.com/
В списке pgsql-hackers по дате отправления: