Re: ALTER TABLE lock strength reduction patch is unsafe

Поиск
Список
Период
Сортировка
От Simon Riggs
Тема Re: ALTER TABLE lock strength reduction patch is unsafe
Дата
Msg-id BANLkTi=YxA4oY5KQkURpTtfGNgzfCV8PmA@mail.gmail.com
обсуждение исходный текст
Ответ на ALTER TABLE lock strength reduction patch is unsafe  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: ALTER TABLE lock strength reduction patch is unsafe  (Simon Riggs <simon@2ndQuadrant.com>)
Список pgsql-hackers
On Thu, Jun 16, 2011 at 11:54 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:

> 2. In response, some other backend starts to reload its relcache entry
> for pgbench_accounts when it begins its next command.  It does an
> indexscan with SnapshotNow on pg_class to find the updated pg_class row.
>
> 3. Meanwhile, some third backend commits another ALTER TABLE, updating
> the pg_class row another time.  Since we have removed the
> AccessExclusiveLock that all variants of ALTER TABLE used to take, this
> commit can happen while backend #2 is in process of scanning pg_class.

This part is the core of the problem:

We must not be able to update the catalog entry while a relcache
rebuild scan is in place.

So I'm prototyping something that allows
LockRelationDefinitionOid(targetRelId, ShareLock);



--
 Simon Riggs                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services


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

Предыдущее
От: Shigeru Hanada
Дата:
Сообщение: Re: deadlock_timeout at < PGC_SIGHUP?
Следующее
От: Florian Pflug
Дата:
Сообщение: Re: Boolean operators without commutators vs. ALL/ANY