Re: BUG #14941: Vacuum crashes - Mailing list pgsql-hackers

From Bossart, Nathan
Subject Re: BUG #14941: Vacuum crashes
Date
Msg-id CBEE19BB-6C70-424C-95E5-F8ABC7AA2185@amazon.com
Whole thread Raw
In response to Re: BUG #14941: Vacuum crashes  (Michael Paquier <michael.paquier@gmail.com>)
Responses Re: BUG #14941: Vacuum crashes
Re: BUG #14941: Vacuum crashes
List pgsql-hackers
On 1/9/18, 8:54 PM, "Michael Paquier" <michael.paquier@gmail.com> wrote:
> Backpedalling a bit on this point and coming back to this message from
> Tom (https://www.postgresql.org/message-id/28748.1507071576%40sss.pgh.pa.us)
> which you just cited. Why do we actually need to issue any WARNING
> messages for unlisted relations? Contrary to what Sawada-san complained
> upthread, it looks sane to me to not log anything if a relation is not
> explicitely listed. So you should not get any warnings for a
> database-wide VACUUM if a relation is dropped while the thing is
> running, and what you proposed initially in
> https://www.postgresql.org/message-id/D3FC73E2-9B1A-4DB4-8180-55F57D116B4E@amazon.com
> is more simple, does not need to worry about any kind of timing issues,
> and is consistent with autovacuum.

Right.  I don't have a terribly strong opinion either way.  I think the
counter-argument is that logging skipped relations might provide
valuable feedback to users.  If I ran a database-wide VACUUM and a
relation was skipped due to lock contention, it might be nice to know
that so I can handle the relation individually.

Perhaps any logging changes for VACOPT_NOWAIT could be handled in a
separate thread.  For now, I've updated 0003 to remove the logging
changes.

Nathan


Attachment

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: let's make the list of reportable GUCs configurable (was Re: Add %r substitution for psql prompts to show recovery status)
Next
From: "Joshua D. Drake"
Date:
Subject: Re: let's make the list of reportable GUCs configurable (was Re: Add%r substitution for psql prompts to show recovery status)