On Sat, Aug 22, 2015 at 2:23 AM, Noah Misch <n...@leadboat.com> wrote: >> > Can you get away with only looking at tuples though? For example, >> > what about advisory locks? Table locks? >> >> Well, that's an interesting question. Can we get away with regarding >> those things as non-conflicting, as between the parent and child >> transactions? > > For system lock types, no. While one could define advisory locks to work > differently, we should assume that today's advisory lockers have expectations > like those of system lockers. An autonomous transaction should not bypass any > lock that a transaction of another backend could not bypass.
Why? Suppose you do this: BEGIN; DECLARE CURSOR foo FOR SELECT * FROM foo; BEGIN AUTONOMOUS TRANSACTION; ALTER TABLE foo ALTER bar TYPE int; This has got to fail for safety reasons, but CheckTableNotInUse() is on it. Suppose you do this: BEGIN; LOCK foo; BEGIN AUTONOMOUS TRANSACTION; INSERT INTO foo VALUES ('spelunk'); How will making this fail improve anything? -- 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