Re: pg_dump's checkSeek() seems inadequate
От | Robert Haas |
---|---|
Тема | Re: pg_dump's checkSeek() seems inadequate |
Дата | |
Msg-id | AANLkTinfAT40PNuyiOPdjcgRWzgqO0nDmOSoukf-CxcE@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: pg_dump's checkSeek() seems inadequate (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: pg_dump's checkSeek() seems inadequate
|
Список | pgsql-hackers |
On Sun, Jun 27, 2010 at 6:19 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Robert Haas <robertmhaas@gmail.com> writes: >> On Sun, Jun 27, 2010 at 1:42 PM, Tom Lane <tgl@sss.pgh.pa.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 EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company
В списке pgsql-hackers по дате отправления: