Re: HS locking broken in HEAD
Andres Freund <andres@2ndquadrant.com>
From: Andres Freund <andres@2ndquadrant.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Robert Haas <robertmhaas@gmail.com>, pgsql-hackers@postgresql.org
Date: 2013-01-18T16:26:00Z
Lists: pgsql-hackers
On 2013-01-18 11:16:15 -0500, Tom Lane wrote: > Andres Freund <andres@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. > I wonder if it'd be practical to, say, run all the contrib regression > tests concurrently in different databases of one installation. I think it would be a good idea, but I don't immediately have an idea how to implement it. It seems to me we would need to put the logic for it into pg_regress? Otherwise the lifetime management of the shared postmaster seems to get complicated. What I would really like is to have some basic replication test scenario in the regression tests. That seems like a dramatically undertested, but pretty damn essential, part of the code. The first handwavy guess I have of doing it is something like connecting a second postmaster to the primary one at the start of the main regression tests (requires changing the wal level again, yuck) and fuzzyly comparing a pg_dump of the database remnants in both clusters at the end of the regression tests. Better ideas? Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
Commits
-
Put back AcceptInvalidationMessages calls in heap_openrv(_extended).
- 96cc18eef648 9.3.0 cited