Re: Concurrent psql v4 [WIP]

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: stark <stark(at)enterprisedb(dot)com>
Cc: pgsql-patches <pgsql-patches(at)postgresql(dot)org>
Subject: Re: Concurrent psql v4 [WIP]
Date: 2007-04-02 20:13:23
Message-ID: 200704022013.l32KDNb07071@momjian.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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(at)postgresql(dot)org so that your
> message can get through to the mailing list cleanly

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://www.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

In response to

Browse pgsql-patches by date

  From Date Subject
Next Message Tom Lane 2007-04-02 20:23:28 Re: Current enums patch
Previous Message David Fetter 2007-04-02 20:10:05 Re: [HACKERS] Arrays of Complex Types