Horton

Re: BRIN autosummarization lacking a snapshot

Álvaro Herrera <alvherre@kurilemu.de>

View thread
From: Álvaro Herrera <alvherre@kurilemu.de>
To: Michael Paquier <michael@paquier.xyz>
Cc: Pg Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2025-11-04T17:22:50Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Fix snapshot handling bug in recent BRIN fix

  2. BRIN autosummarization may need a snapshot

On 2025-Nov-04, Álvaro Herrera wrote:

> 2025-11-04 16:44:47.792 CET [2118443][autovacuum worker][108/6:0] ERROR:  canceling autovacuum task
> 2025-11-04 16:44:47.792 CET [2118443][autovacuum worker][108/6:0] CONTEXT:  processing work entry for relation "postgres.public.brin_packdate_idx"
> 2025-11-04 16:44:47.810 CET [2118078][autovacuum worker][103/10:0] LOG:  process 2118078 acquired ShareUpdateExclusiveLock on relation 16436 of database 5 after 1414.103 ms

> ==2118443== VALGRINDERROR-BEGIN
> ==2118443== Invalid read of size 8
> ==2118443==    at 0x4634F39: PopActiveSnapshot (snapmgr.c:777)
> ==2118443==    by 0x43F693F: do_autovacuum (autovacuum.c:2561)
> ==2118443==    by 0x43F6E2B: AutoVacWorkerMain (autovacuum.c:1604)

Ah, the problem is that perform_work_item() pushes an active snapshot
before calling the BRIN function, but because of the error, we
terminate the transaction before returning, so when we try to Pop that
snapshot, it doesn't exist anymore.  Other ways for this to happen would
be an autovacuum worker trying to run an item for a dropped table (the
"goto deleted2" case).  Hmm ...

-- 
Álvaro Herrera         PostgreSQL Developer  —  https://www.EnterpriseDB.com/