Horton

Re: ALTER TABLE lock strength reduction patch is unsafe

Kevin Grittner <kevin.grittner@wicourts.gov>

View thread
From: "Kevin Grittner" <Kevin.Grittner@wicourts.gov>
To: "Robert Haas" <robertmhaas@gmail.com>, "Tom Lane" <tgl@sss.pgh.pa.us>
Cc: "Simon Riggs" <simon@2ndquadrant.com>, "Noah Misch" <noah@leadboat.com>, "Bruce Momjian" <bruce@momjian.us>, "pgsql-hackers" <pgsql-hackers@postgresql.org>
Date: 2012-01-03T18:42:04Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Add bytea_agg, parallel to string_agg.

  2. Fix ALTER TABLE ONLY .. DROP CONSTRAINT.

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