|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|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
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
Thanks. I am marking those as ready for committer, you are providing the
set patch patch which offer the most consistent experience.
|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|
|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|