Re: ALTER TABLE lock strength reduction patch is unsafe

Simon Riggs wrote:
> > This costs no performance; if anything it should be faster than now,
> > because we'll be replacing expensive transaction state probes with
> > relatively-cheap searches of an XID array that should almost always
> > be quite short.
> >
> > With this approach, we would have no serialization anomalies from single
> > transactions committing while a scan is in progress. ?There could be
> > anomalies resulting from considering an earlier XID to be in-progress
> > while a later XID is considered committed (because we didn't observe
> > it until later). ?So far as I can see offhand, the impact of that would
> > be that there might be multiple versions of a tuple that are considered
> > good, but never that there would be no version considered good (so long
> > as the other XIDs simply updated the tuple and didn't delete it). ?I
> > think this would be all right, since the scan would just seize on the
> > first good version it finds. ?As you argue above, if that's not good
> > enough for our purposes then the updater(s) should have taken a stronger
> > lock.
> 
> I liked this idea, so began to prototype the code. My rough hack is
> attached, for the record.
> 
> One thing that occurs to me about this is that SnapshotNow with or
> without these changes returns the latest committed row and ignores
> in-progress changes.
> 
> Accepting an older version of the definition will always be
> potentially dangerous. I can't see a way of doing this that doesn't
> require locking - for changes such as new constraints we need to wait
> until in progress changes are complete.
> 
> So maybe this idea is worth doing, but I don't think it helps us much
> reduce lock levels for DDL.

Just confirming we decided not to persue this.

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com
 + It's impossible for everything to be true. +