Re: [HACKERS] [Proposal] Allow users to specify multiple tables inVACUUM commands
От | Michael Paquier |
---|---|
Тема | Re: [HACKERS] [Proposal] Allow users to specify multiple tables inVACUUM commands |
Дата | |
Msg-id | CAB7nPqTP4i1YTg5o=N_0QicZua7wLU6Hki5uYGkWhARVmqma-g@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] [Proposal] Allow users to specify multiple tables in VACUUM commands (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: [HACKERS] [Proposal] Allow users to specify multiple tables inVACUUM commands
|
Список | pgsql-hackers |
On Thu, Sep 21, 2017 at 9:51 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Michael Paquier <michael.paquier@gmail.com> writes: >> On Thu, Sep 21, 2017 at 9:08 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote: >>> Um ... so? With Nathan's proposed behavior, there are two cases depending >>> on just when the unexpected schema change happens: >>> 1. *None* of the work gets done. >>> 2. The work before the troublesome relation gets done, and the work after >>> doesn't. > >> You may be missing one which is closer to what autovacuum does: >> 3) Issue a warning for the troublesome relation, and get the work done >> a maximum. > > Well, we could certainly discuss whether the behavior on detecting a > conflict ought to be "error" or "warning and continue". But I do not buy > the value of "it might be one or the other depending on timing". I definitely agree with that, and I don't want this point to be a blocker for the proposed patch either. So if you feel that for now the focus should be on simplicity rather than reliability (my word may be incorrect here, I mean having a consistent and continuous flow), let's do so then. We could always change the implemented behavior later on. -- Michael -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
В списке pgsql-hackers по дате отправления: