Unix Technical Forum

Re: Concurrent psql v4 [WIP]

This is a discussion on Re: Concurrent psql v4 [WIP] within the Pgsql Patches forums, part of the PostgreSQL category; --> 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 ...


Go Back   Unix Technical Forum > Database Server Software > PostgreSQL > Pgsql Patches

Register FAQ Members List Calendar Search Today's Posts Mark Forums Read
  #1 (permalink)  
Old 04-18-2008, 09:50 AM
Bruce Momjian
 
Posts: n/a
Default Re: 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. +

---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

Digg this Post!Add Post to del.icio.usBookmark Post in TechnoratiFurl this Post!
Reply With Quote
Reply


Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are On
Forum Jump


All times are GMT. The time now is 11:56 PM.


Powered by vBulletin® Version 3.6.5
Copyright ©2000 - 2008, Jelsoft Enterprises Ltd.
SEO by vBSEO 3.2.0
www.UnixAdminTalk.com