Re: Concurrent connections in psql

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Gregory Stark <stark(at)enterprisedb(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Concurrent connections in psql
Date: 2007-01-20 22:11:25
Message-ID: 200701202211.l0KMBPD02436@momjian.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


What are people's opinions on this patch? (It is at the URL below.)

I like the capability, and am impressed it allowed testing that found
some concurrency bugs in our server, but it is a large patch to psql.

---------------------------------------------------------------------------

Gregory Stark wrote:
>
> 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

--
Bruce Momjian bruce(at)momjian(dot)us
EnterpriseDB http://www.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2007-01-21 01:39:13 Re: Function execution costs 'n all that
Previous Message Tom Lane 2007-01-20 21:54:32 Re: XML regression test failure