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

Re: pg_dump's checkSeek() seems inadequate

From: Andrew Dunstan <andrew(at)dunslane(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
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 11:32:17
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers

Tom Lane wrote:
> 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.  

IIRC pg_restore expects the archive to begin with the header and TOC 
produced by pg_dump. Maybe I'm being dense, but I'm not able to see how 
prefixing that with something else could possibly do something useful or 



In response to


pgsql-hackers by date

Next:From: Robert HaasDate: 2010-06-28 12:09:21
Subject: Re: suppress automatic recovery after back crash
Previous:From: KaiGai KoheiDate: 2010-06-28 09:21:28
Subject: Re: get_whatever_oid, part 1: object types with unqualifed names

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