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)