Re: Concurrent connections in psql

+++

We'd love this feature as it would really help us write better test cases !

Regards
Sailesh

--
Sailesh Krishnamurthy
Amalgamated Insight
[W] (650) 242-3503
[C] (650) 804-6585

-----Original Message-----
From: pgsql-hackers-owner(at)postgresql(dot)org
[mailto:pgsql-hackers-owner(at)postgresql(dot)org] On Behalf Of Gregory Stark
Sent: Tuesday, March 27, 2007 6:39 AM
To: pgsql-hackers(at)postgresql(dot)org
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
the
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
at
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
a
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
> more
> interested in new code.
>
> Currently Postgres regression tests only test functionality within a
> single
> session. There are no regression tests that test the transaction semantics
> or
> locking behaviour across multiple transactions.
>
> I modified psql to allow you to open multiple connections and switch
> between
> 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
> or
> 3-client cases.
>
> The actual user interface may need some discussion though. I didn't want
> to
> play the name game so I just prefixed all my commands with "c" and figured
> we
> can always rename them later.
>
> And experience with actually writing the tests shows that the explicit
> \cwait
> 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
> cwait"
> 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:
>
> http://community.enterprisedb.com/concurrent/index.html
>
> --
> Gregory Stark
> EnterpriseDB http://www.enterprisedb.com
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 5: don't forget to increase your free space map settings

--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com

---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings