Skip site navigation (1) Skip section navigation (2)

Re: Concurrent psql patch

From: Gregory Stark <stark(at)enterprisedb(dot)com>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "David Fetter" <david(at)fetter(dot)org>, "Jim Nasby" <decibel(at)decibel(dot)org>, "pgsql-patches" <pgsql-patches(at)postgresql(dot)org>
Subject: Re: Concurrent psql patch
Date: 2007-05-14 11:51:39
Message-ID: 87r6pjd3n8.fsf@oxford.xeocode.com (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-patches
"Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:

> Gregory Stark <stark(at)enterprisedb(dot)com> writes:
>> So would you prefer \g& as Jim Nasby suggested? I hadn't even considered that
>> previously since I'm not accustomed to using \g but it does seem kind of
>> pretty. I normally use ; but I suppose there's nothing wrong with just
>> declaring that asynchronous commands must be issued using \g& rather than use
>> the semicolon to fire them off.
>
> It makes sense to me... but what is the state of the session afterward?
> Should this be combined with switching to another connection?

It's an interesting idea since you'll inevitably have to switch connections.
If you issue a second query it'll forces the session to wait for the results.
(It doesn't seem like there's any point in keeping a queue of pending queries
per session.)

However we do still need a command to switch back anyways so there doesn't
seem to be any advantage in combining the two.

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


In response to

Responses

pgsql-hackers by date

Next:From: Andrew DunstanDate: 2007-05-14 12:09:31
Subject: Re: What is happening on buildfarm member baiji?
Previous:From: Dave PageDate: 2007-05-14 11:46:45
Subject: Re: What is happening on buildfarm member baiji?

pgsql-patches by date

Next:From: Andrew DunstanDate: 2007-05-14 12:04:22
Subject: Re: [PATCHES] OS/X startup scripts
Previous:From: Gregory StarkDate: 2007-05-14 11:36:14
Subject: Re: [PATCHES] OS/X startup scripts

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group