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

Yes, yes.  I would like to have used it when testing the MyProc->xmin
improvements.  The only thing that has held it back from being applied
was that there was no documentation/examples of how it would be used.

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

Gregory Stark wrote:
> 
> 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
> 
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 5: don't forget to increase your free space map settings

--  Bruce Momjian  <bruce@momjian.us>          http://momjian.us EnterpriseDB
http://www.enterprisedb.com
 + If your life is a hard drive, Christ can be your backup. +