On Tue, Jan 25, 2022 at 10:12 PM Tomas Vondra
<tomas.vondra@enterprisedb.com> 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, and you
> can simply run it again, but IMHO rather surprising.
I don't have a big problem with inserting an XLogFlush() here, but I
also don't think there's a hard and fast rule that maintenance
operations have to have full transactional behavior. Because that's
violated in various different ways by various different DDL commands.
CREATE INDEX CONCURRENTLY can leave detritus around if it fails. At
least one variant of ALTER TABLE does a non-MVCC-aware rewrite of the
table contents. COPY FREEZE violates MVCC. Concurrent partition attach
and detach aren't fully serializable with concurrent transactions.
Years ago TRUNCATE didn't have MVCC semantics. We often make small
compromises in these areas for implementation simplicity or other
benefits.
> 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 pagesPerRange 2 offnum 2, blkref #0: rel 1663/63 ...
> SAMEPAGE_UPDATE offnum 2, blkref #0: rel 1663/63341/73957 blk 2
>
> So, what happens if we lost the second WAL record, e.g. due to a crash?
Ouch. As you say, XLogFlush() won't fix that. The WAL logging scheme
needs to be redesigned.
--
Robert Haas
EDB: http://www.enterprisedb.com