Horton

Re: BUG #14941: Vacuum crashes

Nathan Bossart <bossartn@amazon.com>

View thread View on postgr.es
From: "Bossart, Nathan" <bossartn@amazon.com>
To: Masahiko Sawada <sawada.mshk@gmail.com>
Cc: Michael Paquier <michael.paquier@gmail.com>, Robert Haas <robertmhaas@gmail.com>, Lyes Ameddah <lyes.amd@gmail.com>, Tomas Vondra <tomas.vondra@2ndquadrant.com>, "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>, "pgsql-bugs@postgresql.org" <pgsql-bugs@postgresql.org>
Date: 2017-12-18T22:18:09Z
Lists: pgsql-bugs, pgsql-hackers 
On 12/18/17, 3:30 PM, "Masahiko Sawada" <sawada.mshk@gmail.com> wrote:
> According to the following old comment, there might be reason why we
> didn't pass the information to vacuum_rel(). But your patch fetches
> the relation
> name even if the "relation" is not provided. I wonder if it can be
> problem in some cases.

Thanks for taking another look.

I've thought through a few edge cases here, but I haven't noticed
anything that I think is a problem.  If an unspecified relation is
renamed prior to get_rel_name(), we'll use the updated name, which
doesn't seem like an issue.  If an unspecified relation is renamed
between get_rel_name() and the log statement, we'll use the old name,
which seems possible in the current logging logic for VACUUM/ANALYZE.
And if an unspecified relation is dropped just prior to
get_rel_name(), the result will be NULL, and the logging will be
skipped (as it already is for concurrently dropped relations that are
not specified in the command).

Nathan

Commits

  1. Add option SKIP_LOCKED to VACUUM and ANALYZE

  2. Rename VACOPT_NOWAIT to VACOPT_SKIP_LOCKED

  3. Add parenthesized options syntax for ANALYZE.

  4. Don't allow VACUUM VERBOSE ANALYZE VERBOSE.

  5. Fix inadequate locking during get_rel_oids().

  6. Avoid having autovacuum workers wait for relation locks.