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

Re: [PATCH] Add SIGCHLD catch to psql

From: Stephen Frost <sfrost(at)snowman(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, David Fetter <david(at)fetter(dot)org>,Bruce Momjian <bruce(at)momjian(dot)us>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: [PATCH] Add SIGCHLD catch to psql
Date: 2010-05-17 16:49:27
Message-ID: (view raw or whole thread)
Lists: pgsql-hackers
* Tom Lane (tgl(at)sss(dot)pgh(dot)pa(dot)us) wrote:
> Stephen Frost <sfrost(at)snowman(dot)net> writes:
> > Attached is a patch that just checks the result from the existing
> > fflush() inside the FETCH_COUNT loop and drops out of that loop if we
> > get an error from it.
> I thought it might be about that simple once you went at it the right
> way ;-).  However, I'd suggest checking ferror(pset.queryFout) as well
> as the fflush result.  It's not clear to me whether fflush should be
> counted on to report an error that actually occurred in a previous
> fwrite.  (It's also unclear why fflush isn't documented to set the stream
> error indicator on failure, but it isn't.)

Sure, I can add the ferror() check.  Patch attached.

My man page (Debian/Linux) has this to say about fflush():

       The function fflush() forces a write of all user-space buffered
	   data for the given output or update stream via the stream’s
	   underlying write function.  The open status of the stream
       is unaffected.

       If the stream argument is NULL, fflush() flushes all open output

       For a non-locking counterpart, see unlocked_stdio(3).

       Upon successful completion 0 is returned.  Otherwise, EOF is
	   returned and the global variable errno is set to indicate the

       EBADF  Stream is not an open stream, or is not open for writing.

       The function fflush() may also fail and set errno for any of the
	   errors specified for the routine write(2).

       C89, C99.



In response to


pgsql-hackers by date

Next:From: Jim NasbyDate: 2010-05-17 17:45:14
Subject: Re: Partitioning/inherited tables vs FKs
Previous:From: Andrew DunstanDate: 2010-05-17 16:36:47
Subject: Re: release notes

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