Re: Concurrent connections in psql

From: "Jim C(dot) Nasby" <jim(at)nasby(dot)net>
To: Bruce Momjian <bruce(at)momjian(dot)us>
Cc: Gregory Stark <stark(at)enterprisedb(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Concurrent connections in psql
Date: 2007-01-21 08:01:30
Message-ID: 20070121080130.GC77382@nasby.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Sounds like good reason to get it in early... :)

It would be nice if there were some tests for this/that used this...
wasn't there a patch for that floating around somewhere?

On Sat, Jan 20, 2007 at 05:11:25PM -0500, Bruce Momjian wrote:
>
> 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. +
>
> ---------------------------(end of broadcast)---------------------------
> TIP 2: Don't 'kill -9' the postmaster
>

--
Jim Nasby jim(at)nasby(dot)net
EnterpriseDB http://enterprisedb.com 512.569.9461 (cell)

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message shaunc 2007-01-21 08:28:37 send password to pg_dump
Previous Message Peter Eisentraut 2007-01-21 07:36:30 Re: XML regression test failure