Re: Concurrent psql API

"Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:

> Alvaro Herrera <alvherre(at)commandprompt(dot)com> writes:
>> Tom Lane wrote:
>>> It strikes me that with these semantics, \cwait is a lot like a thread
>>> join operation, so we could call it \join or \j.
>
>> FWIW on POSIX shell there's something similar called "wait".
>> http://www.opengroup.org/onlinepubs/009695399/utilities/wait.html
>> Perhaps we should define the operator after these semantics -- these
>> guys have probably hashed up a good interface. Basically it means we
>> would have a "\cwait [n ...]" command meaning "wait for the connection
>> 'n' to return".
>
> I was thinking about this some more while out running an errand, and
> came to the same conclusion that "\cwait connID" would be a good thing
> to have.

I threw out cwait because it seemed to me that to write any kind of reliable
regression test you would end up having to put a cwait with a timeout on every
connection switch.

Consider a simple regression test to test that update locks out concurrent
updaters:

1 begin;
1 update t where i=1
UPDATE 1
<switch to connection 2>
2 begin;
2 update t where i=1
<switch to connection 2>
2 commit;
COMMIT
<switch to connection 1>
UPDATE 1

So here what you really want to test is that the second update blocks. If we
don't wait at all we might very well miss the UPDATE message because we just
flew past it too fast. In fact IIRC that's exactly what I saw.

> While there's still a possible use for \D (disconnect) in this
> scheme, I'm not sure how interesting it is. In any case disconnecting
> the active session is a bogus behavior; you should only be able
> to disconnect a non-active, idle one.

Unless you're specifically trying to test that things get cleaned up properly
when the session rolls back... But yeah, I only put it in for the sake of
completeness at the time.

--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
Get trained by Bruce Momjian - ask me about EnterpriseDB's PostgreSQL training!