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" <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> http://momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---------------------------(end of broadcast)--------------------------- TIP 5: don't forget to increase your free space map settings
