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

Re: pg_dump's checkSeek() seems inadequate

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: pg_dump's checkSeek() seems inadequate
Date: 2010-06-28 00:42:43
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On Sun, Jun 27, 2010 at 6:19 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> On Sun, Jun 27, 2010 at 1:42 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>> If I change the test to be
>>>        fseeko(fp, 0, SEEK_SET)
>>> then it does the right thing.
>> Well, I guess it depends on what you think the chances are that the
>> revised test will fail on some other obscure platform.
> To believe that, you'd have to believe that fseeko(fp, 0, SEEK_SET)
> will fail but fseeko(fp, something-not-zero, SEEK_SET) will succeed.
> 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
> I believe that (at least on most Unixen) doing fseeko(fp, 0, SEEK_SET)
> would result in overwriting the custom header, where it would not have
> been overwritten before.  However the usefulness of the above is at
> best far-fetched; and I'm not very sure that it works today anyway,
> since pg_dump/pg_restore seem to assume that manual byte counting should
> match the results of ftell().

That doesn't actually sound all that far-fetched.

Robert Haas
The Enterprise Postgres Company

In response to


pgsql-hackers by date

Next:From: Robert HaasDate: 2010-06-28 00:54:40
Subject: suppress automatic recovery after back crash
Previous:From: Tom LaneDate: 2010-06-27 23:41:06
Subject: Re: Why are these modules built without respecting my LDFLAGS?

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