Re: ALTER TABLE lock strength reduction patch is unsafe - Mailing list pgsql-hackers

From Kevin Grittner
Subject Re: ALTER TABLE lock strength reduction patch is unsafe
Date
Msg-id 4F02F79C0200002500044296@gw.wicourts.gov
Whole thread Raw
In response to Re: ALTER TABLE lock strength reduction patch is unsafe  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: ALTER TABLE lock strength reduction patch is unsafe  (Robert Haas <robertmhaas@gmail.com>)
List 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 by date:

Previous
From: Robert Haas
Date:
Subject: Re: ALTER TABLE lock strength reduction patch is unsafe
Next
From: Tom Lane
Date:
Subject: Re: ALTER TABLE lock strength reduction patch is unsafe