On Wed, Jun 23, 2010 at 03:26, Tom Lane t...@sss.pgh.pa.us wrote:
Andrew Dunstan and...@dunslane.net writes:
4. Is there any value in back-porting the Windows FSEEKO support into
8.3 and 8.2? Arguably, not writing the data offsets is a performance
bug. However a back-port won't do anything
On Wed, Jun 23, 2010 at 2:26 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Uh, that doesn't fix anything: if you can't seek, a TOC at the end of
the file is useless. And the cases where the writer can't seek are
likely to be identically the ones where the reader can't seek, viz
pg_dump piped to
I've dug into the problem reported by Igor Neyman:
http://archives.postgresql.org/pgsql-admin/2010-06/msg00148.php
Unlike previous complainants, Igor was kind enough to supply a pg_dump
archive file that triggers the problem. What I find is that his dump
file contains no data offsets, ie,
On Tue, Jun 22, 2010 at 9:07 PM, Tom Lane t...@sss.pgh.pa.us wrote:
3. Perhaps pg_dump ought to emit a warning when it can't seek, instead
of just silently not writing the data offsets. That behavior was okay
before when lack of data offsets didn't really matter that much, but
lack of data
Tom Lane wrote:
In short, parallel pg_restore is guaranteed to fail on any input file
made with a pre-8.4 pg_dump on Windows. It may be that there's some
other mechanism involved in the reports we've gotten of parallel restore
failing only some of the time, but I'm thinking that the
Andrew Dunstan and...@dunslane.net writes:
Tom Lane wrote:
In short, parallel pg_restore is guaranteed to fail on any input file
made with a pre-8.4 pg_dump on Windows.
IIRC, you can reproduce this on Unix too by sending the output of
pg_dump into a pipe. So it's not uniquely a Windows
Tom Lane wrote:
Another possibility is to just remove the inside-the-loop error test
altogether: make it just skip till it finds the desired item, and only
throw an error if it hits EOF without finding it. In the case that
the error test is trying to catch, this would mean significantly more
