"Tom Lane" <[EMAIL PROTECTED]> writes: > Alvaro Herrera <[EMAIL PROTECTED]> 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! -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers