On Friday, January 18, 2013 9:56 PM Andres Freund wrote:
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.
I think this is good idea to start testing for replication. In addition to this, I think to test secondary's
behavior,there should be some kind of controller module which should control SQL commands run on primary and secondary
andmatch the expected behavior. This can be particulary useful to test locking conflicts and do the more specific
tests.
With Regards,
Amit Kapila.