Re: pg_dump's checkSeek() seems inadequate

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Andrew Dunstan <andrew(at)dunslane(dot)net>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: pg_dump's checkSeek() seems inadequate
Date: 2010-06-28 02:24:21
Message-ID: 6345.1277691861@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
> Tom Lane wrote:
>> A somewhat more plausible scenario is that somebody might hope that
>> they could do something like this:
>>
>> echo 'some custom header' >pg.dump
>> pg_dump -Fc >>pg.dump

> What would anyone hope to achieve by such a manoeuvre, even if it
> worked, which I am close the dead sure it would not?

It looks to me like it probably would actually work, so far as pg_dump
is concerned, but _discoverArchiveFormat() would break it because that
tries to do an unconditional fseeko(fp, 0, SEEK_SET) (and the position
counting is screwed up even if the fseeko fails). That could probably
be fixed if anyone thought this scenario was interesting enough to
justify work directed specifically at it. I did the ftello/fseeko dance
in checkSeek() just now because it seems sensible to me to have
checkSeek() actually verify functionality of both of those calls,
not because I think it's real likely that the position won't be 0.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2010-06-28 05:03:23 Re: Why are these modules built without respecting my LDFLAGS?
Previous Message Andrew Dunstan 2010-06-28 01:25:18 Re: pg_dump's checkSeek() seems inadequate