Re: BRIN autosummarization lacking a snapshot
| От | Álvaro Herrera |
|---|---|
| Тема | Re: BRIN autosummarization lacking a snapshot |
| Дата | |
| Msg-id | 202511041719.wi27m4fjjveo@alvherre.pgsql обсуждение исходный текст |
| Ответ на | Re: BRIN autosummarization lacking a snapshot (Álvaro Herrera <alvherre@kurilemu.de>) |
| Ответы |
Re: BRIN autosummarization lacking a snapshot
|
| Список | pgsql-hackers |
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 ShareUpdateExclusiveLockon 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/
В списке pgsql-hackers по дате отправления: