Re: HS locking broken in HEAD
От | Andres Freund |
---|---|
Тема | Re: HS locking broken in HEAD |
Дата | |
Msg-id | 20130118162600.GI29501@alap2.anarazel.de обсуждение исходный текст |
Ответ на | Re: HS locking broken in HEAD (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: HS locking broken in HEAD
Re: HS locking broken in HEAD Re: HS locking broken in HEAD |
Список | 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
В списке pgsql-hackers по дате отправления: