Re: [PATCHES] SIGPIPE handling, take two.

2003-11-11 Thread Gaetano Mendola
Bruce Momjian wrote: I think this is the patch I like. It does the auto-detect handling as I hoped. I will just do the doc updates to mention it. My only issue is that this is per-connection, while I think you have to create a global variable that defaults to false, and on first connect, check, a

Re: [PATCHES] SIGPIPE handling, take two.

2003-11-11 Thread Gaetano Mendola
Gaetano Mendola wrote: Bruce Momjian wrote: I think this is the patch I like. It does the auto-detect handling as I hoped. I will just do the doc updates to mention it. My only issue is that this is per-connection, while I think you have to create a global variable that defaults to false, and o

[PATCHES] cancel <3FB0B7CB.2070602@bigfoot.com>

2003-11-11 Thread mendola
This message was cancelled from within Mozilla. ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the maili

[PATCHES] cancel <3FB0C0CE.6050007@bigfoot.com>

2003-11-11 Thread mendola
This message was cancelled from within Mozilla. ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])

Re: [PATCHES] SIGPIPE handling, take two.

2003-11-11 Thread Tom Lane
Bruce Momjian <[EMAIL PROTECTED]> writes: > I think this is the patch I like. The #if coding is messy and unnecessary. You could do the test as per the non-POSIX variant using two calls of pqsignal(), and not have any system dependence here, nor a need for . regards, tom

Re: [PATCHES] SIGPIPE handling, take two.

2003-11-11 Thread Tom Lane
Oh, forgot to mention ... Bruce Momjian <[EMAIL PROTECTED]> writes: > My only issue is that this is per-connection, while I think you have to > create a global variable that defaults to false, and on first connect, > check, and not after. No, because this patch does not have any global effect on

Re: [PATCHES] SIGPIPE handling, take two.

2003-11-11 Thread Manfred Spraul
Tom Lane wrote: Bruce Momjian <[EMAIL PROTECTED]> writes: I think this is the patch I like. The #if coding is messy and unnecessary. You could do the test as per the non-POSIX variant using two calls of pqsignal(), and not have any system dependence here, nor a need for . What about mu

Re: [PATCHES] SIGPIPE handling, take two.

2003-11-11 Thread Tom Lane
Manfred Spraul <[EMAIL PROTECTED]> writes: > What about multithreaded apps? > old = pgsignal(SIPEPIPE, SIG_IGN); > ** another thread calls sigaction(SIGPIPE,,); > pgsignal(SIGPIPE, old); > And the signal state is corrupted. If other threads are changing the signal state mid-flight, we are

Re: [PATCHES] SIGPIPE handling, take two.

2003-11-11 Thread Manfred Spraul
Tom Lane wrote: I don't think we need to complicate pqsignal's API for this. Instead we'd better document that SIGPIPE handling has to be set up and kept stable before doing any libpq operations in a multithread app. Not reliable. An app could install it's own signal handler and block SIGPIPE

Re: [PATCHES] [HACKERS] Proposal: psql force prompting on notty

2003-11-11 Thread Michael Mauger
You can send it to me to test. I've duplicated the reported behavior here so I can test the fix. (Ideally, send me a url to downloaded it from rather than attaching it.) Just a thought, a corresponding option of --batch/-B could be added to do the opposite of the --interactive/-I option. Having

Re: [PATCHES] SIGPIPE handling, take two.

2003-11-11 Thread Tom Lane
Manfred Spraul <[EMAIL PROTECTED]> writes: > ... But the SIG_IGN/restore > sequence affects the whole app - PQconnectdb calls would result in > randomly dropped SIGPIPE signals. Good point. AFAICS we lose anyway if we don't have sigaction() available, but hopefully any multithreaded platform ha

Re: [PATCHES] psql: \dg and groups for \du

2003-11-11 Thread Bruce Momjian
I will write the psql.sgml changes. Your patch has been added to the PostgreSQL unapplied patches list at: http://momjian.postgresql.org/cgi-bin/pgpatches I will try to apply it within the next 48 hours. --- Mark

Re: [PATCHES] Two very minor win32 patches

2003-11-11 Thread Bruce Momjian
Claudio Natoli wrote: > For src/backend/postmaster/postmaster.c and src/include/c.h > (Note: should ioctlsocket_ret be initialized to 1 for BEOS too, and can it > take an unsigned parameter? If so, could simplify.) OK, I have updated this for 7.4 and CVS. Any idea why it has to be initialized to

Re: [PATCHES] Two very minor win32 patches

2003-11-11 Thread Bruce Momjian
Bruce Momjian wrote: > Claudio Natoli wrote: > > For src/backend/postmaster/postmaster.c and src/include/c.h > > (Note: should ioctlsocket_ret be initialized to 1 for BEOS too, and can it > > take an unsigned parameter? If so, could simplify.) > > OK, I have updated this for 7.4 and CVS. Any idea

Re: [PATCHES] Win32 patch for Makefile.shlib

2003-11-11 Thread Bruce Momjian
Of course, this only applied to head, no 7.4. --- Claudio Natoli wrote: > > If this is acceptable, I'll send a similar one for src/backend/Makefile > > Cheers, > Claudio > > > --- > WE HAVE MOVED - PLEASE NOTE OUR NEW C

Re: [PATCHES] Win32 patch for Makefile.shlib

2003-11-11 Thread Bruce Momjian
Your patch has been added to the PostgreSQL unapplied patches list at: http://momjian.postgresql.org/cgi-bin/pgpatches I will try to apply it within the next 48 hours. --- Claudio Natoli wrote: > > If this is acc

Re: [PATCHES] Win32 patch for Makefile.shlib

2003-11-11 Thread Claudio Natoli
> Of course, this only applied to head, no 7.4. Yes, that's correct. (strictly, at the time of creation, I was working off the WIN32_DEV branch...) --- Certain disclaimers and policies apply to all email sent from Memetrics. For the full text of these disclaimers and policies see http://www.m

Re: [PATCHES] Win32 patch for Makefile.shlib

2003-11-11 Thread Bruce Momjian
Claudio Natoli wrote: > > > > Of course, this only applied to head, no 7.4. > > Yes, that's correct. (strictly, at the time of creation, I was working off > the WIN32_DEV branch...) OK. You said you had some backend/Makefile stuff too. Please check CVS head first because I dealt with ln -s an

Re: [PATCHES] equal() perf tweak

2003-11-11 Thread Bruce Momjian
Is there a TODO here? --- Neil Conway wrote: > Tom Lane <[EMAIL PROTECTED]> writes: > > This does suggest that it might be worth making the struct layout be > > > > int NodeTag; > > int length; > > foo *head; > >

Re: [PATCHES] equal() perf tweak

2003-11-11 Thread Neil Conway
Bruce Momjian <[EMAIL PROTECTED]> writes: > Is there a TODO here? I've been short on time recently, so I haven't had a chance to make the suggested changes to the List patch. I'll send in an updated version of the List changes, and if there aren't any gripes, I'll begin making the changes to the L

Re: [PATCHES] ALTER TABLE modifications

2003-11-11 Thread Bruce Momjian
Is this to be applied to CVS HEAD? --- Rod Taylor wrote: > A general re-organization of Alter Table. Node wise, it is a > AlterTableStmt with a list of AlterTableCmds. The Cmds are the > individual actions to be completed (

Re: [PATCHES] Small Doc Patch

2003-11-11 Thread Bruce Momjian
Patch applied to HEAD and 7.4CVS. Thanks. --- Stephan Szabo wrote: > Here's a patch that adds some text mentioning that > RESTRICT is not deferrable to the create table reference > page. Content-Description: [ Attachmen

Re: [PATCHES] "make check" improvement for cygwin

2003-11-11 Thread Bruce Momjian
Patch applied to CVS HEAD and 7.4CVS. Thanks. --- Christopher Kings-Lynne wrote: > Here's some improvements. I just ended up referring people to Jason's > website for install as service, because it's a quite a long and c

Re: [PATCHES] ALTER TABLE modifications

2003-11-11 Thread Tom Lane
Bruce Momjian <[EMAIL PROTECTED]> writes: > Is this to be applied to CVS HEAD? It sounded like large portions were still at the request-for-comment stage... regards, tom lane ---(end of broadcast)--- TIP 8: explain analyze i