Concurrent psql v4 [WIP]
От | stark |
---|---|
Тема | Concurrent psql v4 [WIP] |
Дата | |
Msg-id | 87vegmd4ys.fsf@oxford.xeocode.com обсуждение исходный текст |
Ответы |
Re: Concurrent psql v4 [WIP]
Re: Concurrent psql v4 [WIP] |
Список | pgsql-patches |
This is just an update against CVS. The interface is still as described at this URL: http://community.enterprisedb.com/concurrent/index.html It's true there isn't any documentation in the patch but I'm not sure we're actually settled on the interface. I think our experience here is that the \cwait command was a mistake. You never need it in intractive use, and you need to use it *religiously* when writing regression tests. If you miss one your regression test will fail randomly depending on the timing. Instead we should just have a psql setting that makes it automatically wait before every connection switch. That ensures you catch any bugs where a command fails to block when it should, and also ensures you catch the output of an unblocked command as soon as you switch connections to it. The other issue is the cursor behaviour. Currently it looks like below and it starts a new pager for each block. I'm not sure this is really all that bad myself but I have a feeling others will disagree. I'm not exactly sure what the right behaviour is though, if this is an asynchronous command issued with \cnowait then it would strange to suddenly start executing synchronously once the first bit of data arrives. postgres[2]=# select * from generate_series(1,4); generate_series ----------------- 1 2 3 4 (10 rows) postgres[2]=# \set FETCH_COUNT 1 postgres[2]=# select * from generate_series(1,10); generate_series ----------------- 1 (1 row) generate_series ----------------- 2 (1 row) generate_series ----------------- 3 (1 row) generate_series ----------------- 4 (1 row) generate_series ----------------- (0 rows) -- Gregory Stark EnterpriseDB http://www.enterprisedb.com
Вложения
В списке pgsql-patches по дате отправления: