From: | Sergei Kornilov <sk(at)zsrv(dot)org> |
---|---|
To: | Stephen Frost <sfrost(at)snowman(dot)net>, Andres Freund <andres(at)anarazel(dot)de> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "pgsql-hackers(at)lists(dot)postgresql(dot)org" <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Sketch of a fix for that truncation data corruption issue |
Date: | 2019-12-05 13:39:43 |
Message-ID: | 652931575553183@myt6-636ea6dfd460.qloud-c.yandex.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hello
>> > Also, I'm not entirely sure whether there's anything in our various
>> > replication logic that's dependent on vacuum truncation taking AEL.
>> > Offhand I'd expect the reduced use of AEL to be a plus, but maybe
>> > I'm missing something.
>>
>> It'd be a *MAJOR* plus. One of the biggest operational headaches for
>> using a HS node for querying is that there'll often be conflicts due to
>> vacuum truncating relations (which logs an AEL), even if
>> hot_standby_feedback is used. There's been multiple proposals to
>> allow disabling truncations just because of that.
>
> Huge +1 from me here, we've seen this too. Getting rid of the conflict
> when using a HS node for querying would be fantastic.
One small ping... This topic has been inactive for a long time. But that would be a great improvement for any future release. I observe such problems from time to time... (so far, we have at least a workaround with the vacuum_trunk option)
regards, Sergei
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2019-12-05 13:44:52 | Re: Minor comment fixes for instrumentation.h |
Previous Message | Tomas Vondra | 2019-12-05 13:38:36 | Re: logical decoding bug: segfault in ReorderBufferToastReplace() |