Re: ALTER TABLE lock strength reduction patch is unsafe

Поиск
Список
Период
Сортировка
От Simon Riggs
Тема Re: ALTER TABLE lock strength reduction patch is unsafe
Дата
Msg-id CA+U5nMLpfx-NpC8fD6-7EEV5LxKLmM7YjZKLGicV91U3Rg+kaA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: ALTER TABLE lock strength reduction patch is unsafe  (Noah Misch <noah@leadboat.com>)
Ответы Re: ALTER TABLE lock strength reduction patch is unsafe  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
On Tue, Jan 3, 2012 at 4:40 AM, Noah Misch <noah@leadboat.com> wrote:
> On Tue, Jan 03, 2012 at 01:18:41AM +0000, Simon Riggs wrote:
>> Just for the record, yes we do run multiple catalog scans in some
>> parts of the code.
>>
>> So I can see how we might trigger 4 nested scans, using cache
>> replacement while scanning, so best assume more, with no guarantee of
>> them being neatly stacked for pop/push type access.
>
> Yeah, I wouldn't want to commit to a nesting limit.

Agreed

> However, I _would_ have
> expected that a stack would suffice; PushActiveSnapshot()/PopActiveSnapshot()
> is adequate for a great deal of the backend, after all.  In what sort of
> situation do catalog scans not strictly nest?

It's possible. Making assumptions about what is possible bit me
before, as you showed.

I've seen code where we are explicitly running two concurrent scans.

I don't want to put unnecessary and subtle assumptions into catalog
scan code so I'm working on the assumption that endscan may not be
called in strict FIFO order. The difference is fairly minor and
doesn't restrict us in other ways.

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


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

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: spinlocks on powerpc
Следующее
От: "Albe Laurenz"
Дата:
Сообщение: Re: review: CHECK FUNCTION statement