Concurrent psql v4 [WIP]

Your patch has been added to the PostgreSQL unapplied patches list at:

http://momjian.postgresql.org/cgi-bin/pgpatches

It will be applied as soon as one of the PostgreSQL committers reviews
and approves it.

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

stark wrote:

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)

[ Attachment, skipping... ]

--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com

---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly

--
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. +

Please remove \cwait and supply an updated version with documentation.

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

stark wrote:

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)

[ Attachment, skipping... ]

--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com

---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly

--
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. +