Stephen Frost sfr...@snowman.net writes:
* Tom Lane (t...@sss.pgh.pa.us) wrote:
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.
Sure, I can add the ferror() check. Patch
* Tom Lane (t...@sss.pgh.pa.us) wrote:
If you're combining this with the FETCH_COUNT logic then it seems like
it'd be sufficient to check ferror(fout) once per fetch chunk, and just
fall out of that loop then. I don't want psql issuing query cancels
on its own authority, either.
Attached is
Stephen Frost sfr...@snowman.net writes:
* Tom Lane (t...@sss.pgh.pa.us) wrote:
If you're combining this with the FETCH_COUNT logic then it seems like
it'd be sufficient to check ferror(fout) once per fetch chunk, and just
fall out of that loop then. I don't want psql issuing query cancels
* Tom Lane (t...@sss.pgh.pa.us) wrote:
Stephen Frost sfr...@snowman.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
* Tom Lane (t...@sss.pgh.pa.us) wrote:
A saner
approach, which would also help for other corner cases such as
out-of-disk-space, would be to check for write failures on the output
file and abandon the query if any occur.
I had considered this, but I'm not sure we really need to catch *every*
Stephen Frost sfr...@snowman.net writes:
* Tom Lane (t...@sss.pgh.pa.us) wrote:
A saner
approach, which would also help for other corner cases such as
out-of-disk-space, would be to check for write failures on the output
file and abandon the query if any occur.
I had considered this, but
On Fri, May 14, 2010 at 04:24:43PM -0400, Bruce Momjian wrote:
Stephen Frost wrote:
-- Start of PGP signed section.
Greetings,
Toying around with FETCH_COUNT today, I discovered that it didn't do
the #1 thing I really wanted to use it for- query large tables without
having to
On Sat, May 15, 2010 at 7:46 PM, David Fetter da...@fetter.org wrote:
Anyway, this makes FETCH_COUNT alot more useful, and, in my view, the
current behaviour of completely ignoring $PAGER exiting is a bug.
Plesae add this to the next commit-fest:
Robert Haas robertmh...@gmail.com writes:
On Sat, May 15, 2010 at 7:46 PM, David Fetter da...@fetter.org wrote:
Wouldn't this count as a bug fix?
Possibly, but changes to signal handlers are pretty global and can
sometimes have surprising side effects. I'm all in favor of someone
reviewing
Tom Lane wrote:
Robert Haas robertmh...@gmail.com writes:
On Sat, May 15, 2010 at 7:46 PM, David Fetter da...@fetter.org wrote:
Wouldn't this count as a bug fix?
Possibly, but changes to signal handlers are pretty global and can
sometimes have surprising side effects. I'm all in favor
Greetings,
Toying around with FETCH_COUNT today, I discovered that it didn't do
the #1 thing I really wanted to use it for- query large tables without
having to worry about LIMIT to see the first couple hundred records.
The reason is simple- psql ignores $PAGER exiting, which means that
Stephen Frost wrote:
-- Start of PGP signed section.
Greetings,
Toying around with FETCH_COUNT today, I discovered that it didn't do
the #1 thing I really wanted to use it for- query large tables without
having to worry about LIMIT to see the first couple hundred records.
The reason
12 matches
Mail list logo
