Re: ALTER TABLE lock strength reduction patch is unsafe

Поиск
Список
Период
Сортировка
От Kevin Grittner
Тема Re: ALTER TABLE lock strength reduction patch is unsafe
Дата
Msg-id 4F02F79C0200002500044296@gw.wicourts.gov
обсуждение исходный текст
Ответ на Re: ALTER TABLE lock strength reduction patch is unsafe  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: ALTER TABLE lock strength reduction patch is unsafe  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
Robert Haas <robertmhaas@gmail.com> wrote:
> Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Um ... you're supposing that only DDL uses SnapshotNow, which is
>> wrong.  I refer you to the parser, the planner, execution
>> functions for arrays, records, enums, any sort of relcache
>> reload, etc etc etc.  Yes, some of that is masked by
>> backend-internal caching, some of the time, but it's folly to
>> just assume that there are no SnapshotNow scans during normal
>> queries.
> 
> Hmm.  That's unfortunate, because it seems difficult to construct
> a test case that will exercise every feature in the system.
Would the result of IsMVCCSnapshot() change for these snapshots?  If
so, it might require work in the SSI code to avoid a performance hit
there.  In early profiling and stepping through execution I noticed
that we had overhead in serializable transactions for the planner
checks for the actual values at the beginning or end of an index. 
This went away when we avoided SSI work for reads using a non-MVCC
snapshot.  If we're going to start using MVCC snapshots for such
things, we need some other way to avoid unnecessary work in this
area (and possibly others).
At a minimum, some comparative benchmarks at the serializable
isolation level would be in order when considering a patch like
this.
-Kevin


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

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: ALTER TABLE lock strength reduction patch is unsafe
Следующее
От: Tom Lane
Дата:
Сообщение: Re: ALTER TABLE lock strength reduction patch is unsafe