S1: rhaas=# create table foo (a int); CREATE TABLE rhaas=# begin; BEGIN rhaas=# lock foo; LOCK TABLE
S2: rhaas=# grant all on foo to public; GRANT rhaas=# revoke all on foo from public; REVOKE This seems quite obviously silly, given the amount of time and energy we've spent worrying about ALTER TABLE lock levels. Note that GRANT/REVOKE on a table do a not-in-place update of the pg_class row; with anything less than an AccessExclusiveLock, the usual SnapshotNow hazards exist: another session can fail to find the pg_class row altogether. [ Credit: Noah Misch helped me trace down the problem that led me to this report. ] -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
