Re: Concurrent psql v4 [WIP] - Mailing list pgsql-patches

From Bruce Momjian
Subject Re: Concurrent psql v4 [WIP]
Date
Msg-id 200704022013.l32KDNb07071@momjian.us
Whole thread Raw
In response to Concurrent psql v4 [WIP]  (stark <stark@enterprisedb.com>)
List pgsql-patches
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. +

pgsql-patches by date:

Previous
From: David Fetter
Date:
Subject: Re: [HACKERS] Arrays of Complex Types
Next
From: Tom Lane
Date:
Subject: Re: Current enums patch