On 2013-01-18 17:26:00 +0100, Andres Freund wrote: > On 2013-01-18 11:16:15 -0500, Tom Lane wrote: > > Andres Freund <and...@2ndquadrant.com> writes: > > > I am still stupefied nobody noticed that locking in HS (where just about > > > all locks are going to be fast path locks) was completely broken for > > > nearly two years. > > > > IIUC it would only be broken for cases where activity was going on > > concurrently in two different databases, which maybe isn't all that > > common out in the field. And for sure it isn't something we test much. > > I think effectively it only was broken in Hot Standby. At least I don't > immediately can think of a scenario where a strong lock is being acquired on a > non-shared object in a different database.
Hrmpf, should have mentioned that the problem in HS is that the startup process is doing exactly that, which is why it is broke there. It acquires the exclusive locks shipped via WAL so the following non-concurrency safe actions can be applied. And obviously its not connected to any database while doing it... I would have guessed its not that infrequent to run an ALTER TABLE or somesuch while the standby is still running some longrunning query... Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
