Re: Reducing the WAL overhead of freezing in VACUUM by deduplicating per-tuple freeze plans - Mailing list pgsql-hackers

From Andres Freund
Subject Re: Reducing the WAL overhead of freezing in VACUUM by deduplicating per-tuple freeze plans
Date
Msg-id 20230109214308.icz26oqvt3k2274c@awork3.anarazel.de
Whole thread Raw
In response to Re: Reducing the WAL overhead of freezing in VACUUM by deduplicating per-tuple freeze plans  (Peter Geoghegan <pg@bowt.ie>)
Responses Re: Reducing the WAL overhead of freezing in VACUUM by deduplicating per-tuple freeze plans
List pgsql-hackers
Hi,

On 2022-11-15 10:26:05 -0800, Peter Geoghegan wrote:
> Pushed something like this earlier today, though without any changes
> to VISIBLE records.

While updating a patch to log various offsets in pg_waldump, I noticed a few
minor issues in this patch:

ISTM that some of the page level freezing functions are misnamed. In heapam.c
the heap_xlog* routines are for replay, afaict. However
heap_xlog_freeze_plan() is used to WAL log the freeze
plan. heap_xlog_freeze_page() is used to replay that WAL record. Probably your
brain is too used to nbtree/ :).

I think s/heap_xlog_freeze/heap_log_freeze/ would mostly do the trick, except
that heap_xlog_new_freeze_plan() doesn't quite fit in the scheme.

The routines then also should be moved a bit up, because right now they're
inbetween other routines doing WAL replay, adding to the confusion.


The memcpy in heap_xlog_freeze_page() seems a tad odd. I assume that the
alignment guarantees for xl_heap_freeze_plan are too weak? But imo it's
failure prone (and I'm not sure strictly speaking legal from an undefined
behaviour POV) to form a pointer to a misaligned array. Even if we then later
just memcpy() from those pointers.

Greetings,

Andres Freund



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: ATTACH PARTITION seems to ignore column generation status
Next
From: Mark Dilger
Date:
Subject: Re: BUG: Postgres 14 + vacuum_defer_cleanup_age + FOR UPDATE + UPDATE