From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Peter Geoghegan <pg(at)bowt(dot)ie> |
Cc: | Justin Pryzby <pryzby(at)telsasoft(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: Reducing the WAL overhead of freezing in VACUUM by deduplicating per-tuple freeze plans |
Date: | 2023-01-09 21:43:08 |
Message-ID: | 20230109214308.icz26oqvt3k2274c@awork3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Mark Dilger | 2023-01-09 21:55:02 | Re: BUG: Postgres 14 + vacuum_defer_cleanup_age + FOR UPDATE + UPDATE |
Previous Message | Tom Lane | 2023-01-09 21:41:05 | Re: ATTACH PARTITION seems to ignore column generation status |