Re: First steps with 8.3 and autovacuum launcher

Поиск
Список
Период
Сортировка
От Alvaro Herrera
Тема Re: First steps with 8.3 and autovacuum launcher
Дата
Msg-id 20071003140228.GC10624@alvh.no-ip.org
обсуждение исходный текст
Ответ на Re: First steps with 8.3 and autovacuum launcher  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: First steps with 8.3 and autovacuum launcher  (Alvaro Herrera <alvherre@commandprompt.com>)
Список pgsql-hackers
Tom Lane escribió:

> >> It might be possible to solve this if we reduce the strength of the lock
> >> used for ALTER TABLE.  We'd have to go through all the commands
> >> potentially issued by a pg_dump script and see if they could all be made
> >> to run concurrently with autovac, which is a bit nervous-making but
> >> might be feasible; and I'm afraid tablecmds.c would need some
> >> restructuring to not use the same lock type for every variant of ALTER.
> >> But it seems like a path worth investigating.

I think this is doable.  We would need to add a phase 0 to ALTER TABLE
processing, which grabs a less strong (than AccessExclusive) lock on the
table, then goes over the list of commands and determine if at least one
of them requires exclusive access to the table (I think the criteria
here is whether table rewriting is needed, in which case AccessExclusive
is enough).  If none of them does, then we press on.

If at least one subcommand needs exclusive lock, then it releases the
first lock and grabs AccessExclusive.  Then it rechecks whether the
table is still OK (not dropped, maybe not renamed)

This is on a new phase 0, and not integrated on phase 1, because this
way we get all the permission checks and, more importantly, inheritance
checks after we have grabbed the correct lock.  (Note: GRANT and REVOKE
do not lock the table itself (only pg_class), so an ALTER TABLE could be
still be running when somebody revokes a needed privilege that was
checked at the start.  Surely this is not a concern for this patch.)

Initially I was proposing RowExclusiveLock for the first lock (because
it's the strongest lock that doesn't conflict with ShareUpdateExclusive
which is what ANALYZE uses).  The problem with this approach is that it
leads to two ALTER TABLE commands being able to run concurrently, which
is a disaster.  To solve that, my idea is to create another lock type,
which conflicts with itself but not with ShareUpdateExclusive.  Not sure
what to call it.

Comments?

-- 
Alvaro Herrera                  http://www.amazon.com/gp/registry/5ZYLFMCVHXC
"Cuando mañana llegue pelearemos segun lo que mañana exija" (Mowgli)


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Magnus Hagander
Дата:
Сообщение: Re: [COMMITTERS] pgsql: Use BIO functions to avoid passing FILE * pointers to OpenSSL
Следующее
От: Alvaro Herrera
Дата:
Сообщение: Re: First steps with 8.3 and autovacuum launcher