Re: ALTER TABLE lock strength reduction patch is unsafe

On Fri, Jun 17, 2011 at 8:45 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> Department of second thoughts: I think I see a problem.
>
> Um, yeah, so that doesn't really work any better than my idea.
>
> On further reflection, there's a problem at a higher level than this
> anyway.  Even if we can get a single SnapshotNow scan to produce
> guaranteed-self-consistent results, that doesn't ensure consistency
> between the results of scans occurring serially.  An example here is
> ALTER COLUMN DROP DEFAULT, which is currently imagined to impact only
> writers.  However, suppose that a concurrent relcache load fetches the
> pg_attribute row, notes that it has atthasdef = true, and then the ALTER
> commits before we start to scan pg_attrdef.  The consistency checks in
> AttrDefaultFetch() will complain about a missing pg_attrdef entry, and
> rightly so.  We could lobotomize those checks, but it doesn't feel right
> to do so; and anyway there may be other cases that are harder to kluge up.

Locking the whole definition is at least one way of solving this
problem. My locking fix does that.

> So really we need consistency across *at least* one entire relcache load
> cycle.  We could maybe arrange to take an MVCC snap (or some lighter
> weight version of that) at the start, and use that for all the resulting
> scans, but I think that would be notationally messy.  It's not clear
> that it'd solve everything anyhow.  There are parts of a relcache entry
> that we fetch only on-demand, so they are typically loaded later than
> the core items, and probably couldn't use the same snapshot.  Worse,
> there are lots of places where we assume that use of catcache entries or
> direct examination of the catalogs will yield results consistent with
> the relcache.
>
> I suspect these latter problems will impact Simon's idea as well.

I think you're probably right, or at least, the suspicion is not
something I can address quickly enough to be safe.

I will revert to the AccessExclusiveLocks.

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