Horton

Re: ALTER TABLE lock strength reduction patch is unsafe

Tom Lane <tgl@sss.pgh.pa.us>

View thread
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Simon Riggs <simon@2ndquadrant.com>, pgsql-hackers@postgresql.org
Date: 2011-06-17T21:36:22Z
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> writes:
> I have been thinking for a while now that it would be sensible to make
> vacuum use a different lock type, much as we do for relation
> extension.

Hmm.  I had just been toying with the idea of introducing a new
user-visible locking level to allow separation of anti-vacuum locks from
anti-schema-alteration locks.  But I think you're probably right that it
could be done as a specialized LockTag.  That would make it not easily
user-accessible, but it's hard to think of reasons for users to lock out
vacuum anyway, unless they want to lock out everything via
AccessExclusiveLock.

> ... In particular, it's currently not
> possible to lock a table against SELECT without also locking it
> against VACUUM

Well, it still wouldn't be, since AccessExclusiveLock certainly had
better lock out vacuum.  As said above, I think the important thing
is to distinguish vacuum from schema changes.

> But that's not something I want to do in 9.1,

Definitely.

			regards, tom lane