We'd love this feature as it would really help us write better test cases !
[W] (650) 242-3503
[C] (650) 804-6585
[mailto:pgsql-hackers-owner(at)postgresql(dot)org] On Behalf Of Gregory Stark
Sent: Tuesday, March 27, 2007 6:39 AM
Subject: Re: [HACKERS] Concurrent connections in psql
Would people be interested in this feature? There was some positive reaction
from users but I'm not sure how excited developers are about complicating
logic in psql (which is already pretty tangled).
This code bitrotted severely when Tom added the cursor support to psql. I
don't mind redoing it if people want it though. I already did a first pass
doing so but it wasn't clear to me how best to integrate it with that cursor
support change. I elected to treat each chunk of results from the cursor as
separate result set which makes it possible to switch connections between
chunks. That's nice but probably not really acceptable judging by how much
effort Tom went through in the cursor code to avoid having the chunks appear
as separate result sets. Probably I'll have to do more work in that area.
Are people interested in having this? The reason I think it's particularly
interesting is writing regression tests -- especially to test HOT cases.
"Gregory Stark" <stark(at)enterprisedb(dot)com> writes:
> I mentioned this a while back, now that 8.2 is out perhaps others will be
> interested in new code.
> Currently Postgres regression tests only test functionality within a
> session. There are no regression tests that test the transaction semantics
> locking behaviour across multiple transactions.
> I modified psql to allow you to open multiple connections and switch
> them with a sort of csh job control style interface. It actually works out
> pretty well. It's fairly easy to write regression tests for basic 2-client
> 3-client cases.
> The actual user interface may need some discussion though. I didn't want
> play the name game so I just prefixed all my commands with "c" and figured
> can always rename them later.
> And experience with actually writing the tests shows that the explicit
> command which was needed to eliminate (in practice if not in theory) race
> conditions in regression tests turns out to be more flexibility than
> necessary. Since you end up having to insert one in precisely predictable
> locations -- namely after every asynchronous command and after every
> connection switch -- perhaps it would be simpler to just have a "\pset
> command that automatically introduces timeouts in precisely those places.
> A brief explanation including an example regression test (the SAVEPOINT
> locking bug discovered recently) and the patch here:
> Gregory Stark
> EnterpriseDB http://www.enterprisedb.com
> ---------------------------(end of broadcast)---------------------------
> TIP 5: don't forget to increase your free space map settings
---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings
In response to
pgsql-hackers by date
|Next:||From: Sailesh Krishnamurthy||Date: 2007-03-27 18:01:13|
|Subject: Re: Concurrent connections in psql|
|Previous:||From: Bruce Momjian||Date: 2007-03-27 17:40:37|
|Subject: Re: Log levels for checkpoint/bgwriter monitoring|