Re: BUG #14941: Vacuum crashes

From: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
To: "Bossart, Nathan" <bossartn(at)amazon(dot)com>
Cc: Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Lyes Ameddah <lyes(dot)amd(at)gmail(dot)com>, Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>, "pgsql-bugs(at)postgresql(dot)org" <pgsql-bugs(at)postgresql(dot)org>
Subject: Re: BUG #14941: Vacuum crashes
Date: 2018-01-10 23:14:42
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-bugs pgsql-hackers

On Wed, Jan 10, 2018 at 05:26:43PM +0000, Bossart, Nathan wrote:
> 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.

Or users may not care about getting information they don't care
about. When running a database-wide VACUUM or ANALYZE you don't know
what is exactly the list of relations this is working on. Getting
information about things you don't know beforehand can be considered as

Perhaps others have different opinions. Sawada-san?

> 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.

Thanks. I am marking those as ready for committer, you are providing the
set patch patch which offer the most consistent experience.

In response to


Browse pgsql-bugs by date

  From Date Subject
Next Message Masahiko Sawada 2018-01-11 02:17:29 Re: BUG #14941: Vacuum crashes
Previous Message Bruce Momjian 2018-01-10 20:53:48 Re: [BUGS] BUG #14860: pg_read_all_stats and pg_stat_replication

Browse pgsql-hackers by date

  From Date Subject
Next Message Edmund Horner 2018-01-10 23:31:58 Re: [HACKERS] PATCH: psql tab completion for SELECT
Previous Message Nikita Glukhov 2018-01-10 23:04:06 SQL/JSON: JSON_TABLE