Date: Fri, 9 Apr 2021 16:47:28 -0700
From: Andres Freund <andres@anarazel.de>
To: Alvaro Herrera <alvherre@alvh.no-ip.org>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Zhihong Yu <zyu@yugabyte.com>,
	PostgreSQL Developers <pgsql-hackers@lists.postgresql.org>
Subject: Re: pgsql: autovacuum: handle analyze for partitioned tables
Message-ID: <20210409234728.4zibyifpytgrh2fu@alap3.anarazel.de>
References: <2027895.1617969225@sss.pgh.pa.us>
 <20210409155430.GA9512@alvherre.pgsql>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20210409155430.GA9512@alvherre.pgsql>
Archived-At: 
 <https://www.postgresql.org/message-id/20210409234728.4zibyifpytgrh2fu%40alap3.anarazel.de>
Precedence: bulk

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