Re: pgsql: autovacuum: handle analyze for partitioned tables

Hi,

On 2021-04-09 11:54:30 -0400, Alvaro Herrera wrote:
> On 2021-Apr-09, Tom Lane wrote:
>
> > Could we get this pushed sooner rather than later?  The buildfarm
> > is showing a wide variety of intermittent failures on HEAD, and it's
> > hard to tell how many of them trace to this one bug.
>
> Pushed now, thanks.

I assume this is also the likely explanation for / fix for:
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=skink&dt=2021-04-08%2016%3A03%3A03

==3500389== VALGRINDERROR-BEGIN
==3500389== Invalid read of size 8
==3500389==    at 0x4EC4B8: relation_needs_vacanalyze (autovacuum.c:3237)
==3500389==    by 0x4EE0AF: do_autovacuum (autovacuum.c:2168)
==3500389==    by 0x4EEEA8: AutoVacWorkerMain (autovacuum.c:1715)
==3500389==    by 0x4EEF7F: StartAutoVacWorker (autovacuum.c:1500)
==3500389==    by 0x4FD2E4: StartAutovacuumWorker (postmaster.c:5539)
==3500389==    by 0x4FE50A: sigusr1_handler (postmaster.c:5243)
==3500389==    by 0x4A6513F: ??? (in /usr/lib/x86_64-linux-gnu/libpthread-2.31.so)
==3500389==    by 0x4DCA865: select (select.c:41)
==3500389==    by 0x4FEB75: ServerLoop (postmaster.c:1701)
==3500389==    by 0x4FFE52: PostmasterMain (postmaster.c:1409)
==3500389==    by 0x442563: main (main.c:209)
==3500389==  Address 0x10 is not stack'd, malloc'd or (recently) free'd
==3500389==
==3500389== VALGRINDERROR-END
==3500389==
==3500389== Process terminating with default action of signal 11 (SIGSEGV): dumping core
==3500389==  Access not within mapped region at address 0x10
==3500389==    at 0x4EC4B8: relation_needs_vacanalyze (autovacuum.c:3237)
==3500389==    by 0x4EE0AF: do_autovacuum (autovacuum.c:2168)
==3500389==    by 0x4EEEA8: AutoVacWorkerMain (autovacuum.c:1715)
==3500389==    by 0x4EEF7F: StartAutoVacWorker (autovacuum.c:1500)
==3500389==    by 0x4FD2E4: StartAutovacuumWorker (postmaster.c:5539)
==3500389==    by 0x4FE50A: sigusr1_handler (postmaster.c:5243)
==3500389==    by 0x4A6513F: ??? (in /usr/lib/x86_64-linux-gnu/libpthread-2.31.so)
==3500389==    by 0x4DCA865: select (select.c:41)
==3500389==    by 0x4FEB75: ServerLoop (postmaster.c:1701)
==3500389==    by 0x4FFE52: PostmasterMain (postmaster.c:1409)
==3500389==    by 0x442563: main (main.c:209)
==3500389==  If you believe this happened as a result of a stack
==3500389==  overflow in your program's main thread (unlikely but
==3500389==  possible), you can try to increase the size of the
==3500389==  main thread stack using the --main-stacksize= flag.
==3500389==  The main thread stack size used in this run was 8388608.


Greetings,

Andres Freund