On 1/26/22 19:14, Alvaro Herrera wrote:
On 2022-Jan-26, Robert Haas wrote:
On Tue, Jan 25, 2022 at 10:12 PM Tomas Vondra
wrote:
2) brin_summarize_range()
Now, the issue I think is more serious, more likely to happen, and
harder to fix. When summarizing a range, we write two WAL records:
On 2022-Jan-26, Robert Haas wrote:
> On Tue, Jan 25, 2022 at 10:12 PM Tomas Vondra
> wrote:
> > 2) brin_summarize_range()
> >
> > Now, the issue I think is more serious, more likely to happen, and
> > harder to fix. When summarizing a range, we write two WAL records:
> >
> > INSERT heapBlk 2 pag
On Tue, Jan 25, 2022 at 10:12 PM Tomas Vondra
wrote:
> 1) brin_desummarize_range()
>
> But if the cluster/VM/... crashes right after you ran the function (and
> it completed just fine, possibly even in an explicit transaciton), that
> change will get lost. Not really a serious data corruption/loss
Hi,
In a thread about sequences and sync replication [1], I've explained
that the issue we're observing is due to not waiting for WAL at commit
if the transaction only did nextval(). In which case we don't flush WAL
in RecordTransactionCommit, we don't wait for sync replica, etc. The WAL
may
