Re: Concurrent connections in psql - Mailing list pgsql-hackers

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@enterprisedb.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