Re: pgsql: autovacuum: handle analyze for partitioned tables

On 2021-Apr-08, Tom Lane wrote:

> BTW, another thing that looks like a race condition is the
> extract_autovac_opts() call that is done a little bit earlier,
> also without lock.  I think this is actually safe, but it's ONLY
> safe because we resisted the calls by certain people to add a
> toast table to pg_class.  Otherwise, fetching reloptions could
> have involved a toast pointer dereference, and it would then be
> racy whether the toasted data was still there.  As-is, even if
> the pg_class row we're looking at has been deleted, we can safely
> disassemble its reloptions.  I think this matter is deserving
> of a comment at least.

True.  I added a comment there.

Thanks,

-- 
Álvaro Herrera       Valdivia, Chile
"I am amazed at [the pgsql-sql] mailing list for the wonderful support, and
lack of hesitasion in answering a lost soul's question, I just wished the rest
of the mailing list could be like this."                               (Fotis)
               (http://archives.postgresql.org/pgsql-sql/2006-06/msg00265.php)