Обсуждение: pg_dump and BINARY mode COPY
Is there a reason why pg_dump avoids using BINARY mode COPY? (Or am I missing something?) Unless there is a specific reason not to we could/should allow an option on the dump. -- Simon Riggs 2ndQuadrant http://www.2ndQuadrant.com
On Thu, Dec 06, 2007 at 05:30:02PM +0000, Simon Riggs wrote: > Is there a reason why pg_dump avoids using BINARY mode COPY? > (Or am I missing something?) > > Unless there is a specific reason not to we could/should allow an option > on the dump. Probably because BINARY dumps arn't portable. Just guessing... Have a nice day, -- Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/ > Those who make peaceful revolution impossible will make violent revolution inevitable. > -- John F Kennedy
Simon Riggs <simon@2ndquadrant.com> writes:
> Is there a reason why pg_dump avoids using BINARY mode COPY?
To preserve platform and version independence of the dump.
> Unless there is a specific reason not to we could/should allow an option
> on the dump.
Is there any evidence to show that there'd be enough benefit to warrant
taking such a risk with your dumps?
regards, tom lane
On Thu, 2007-12-06 at 12:43 -0500, Tom Lane wrote: > Simon Riggs <simon@2ndquadrant.com> writes: > > Is there a reason why pg_dump avoids using BINARY mode COPY? > > To preserve platform and version independence of the dump. OK, thats what I guessed. > > Unless there is a specific reason not to we could/should allow an option > > on the dump. > > Is there any evidence to show that there'd be enough benefit to warrant > taking such a risk with your dumps? Only if there is a risk. Since a common route to upgrade is a dump/restore back onto same box it seems worth having an option to do this. -- Simon Riggs 2ndQuadrant http://www.2ndQuadrant.com
Simon Riggs <simon@2ndquadrant.com> writes:
> On Thu, 2007-12-06 at 12:43 -0500, Tom Lane wrote:
>> To preserve platform and version independence of the dump.
> Only if there is a risk. Since a common route to upgrade is a
> dump/restore back onto same box it seems worth having an option to do
> this.
I think you missed the point about version independence. That would be
exactly the scenario where a version-to-version change in binary format
--- for instance, "money" widening to 64 bits in 8.3 --- would burn you.
Furthermore, this doesn't seem like a scenario where performance ought
to be the primary concern. How often do you do major version upgrades?
regards, tom lane
On Thu, 2007-12-06 at 13:22 -0500, Tom Lane wrote: > Simon Riggs <simon@2ndquadrant.com> writes: > > On Thu, 2007-12-06 at 12:43 -0500, Tom Lane wrote: > >> To preserve platform and version independence of the dump. > > > Only if there is a risk. Since a common route to upgrade is a > > dump/restore back onto same box it seems worth having an option to do > > this. > > I think you missed the point about version independence. That would be > exactly the scenario where a version-to-version change in binary format > --- for instance, "money" widening to 64 bits in 8.3 --- would burn you. OK > Furthermore, this doesn't seem like a scenario where performance ought > to be the primary concern. How often do you do major version upgrades? Not often enough. If it was faster, we would rely on more people actually doing it. -- Simon Riggs 2ndQuadrant http://www.2ndQuadrant.com
I use often pgdump... and we have many bytea on our database...<br /> Without binary COPY, backup is very slow and takes4x more space on the network wire...<br /><br /> It would be great to have an option (--binary) with eventually a WARNINGmessage (that your backup could be not portable across architecture...)<br /> but i think that 99% of the time wedon't change between x86 or ppc....<br /><br /> please think for users...<br /> Hubert<br /><br /> Le jeudi 06 décembre2007 à 18:32 +0000, Simon Riggs a écrit : <blockquote type="CITE"><pre> <font color="#000000">On Thu, 2007-12-06 at 13:22 -0500, Tom Lane wrote:</font> <font color="#000000">> Simon Riggs <<a href="mailto:simon@2ndquadrant.com">simon@2ndquadrant.com</a>> writes:</font> <font color="#000000">> > On Thu, 2007-12-06 at 12:43 -0500, Tom Lane wrote:</font> <font color="#000000">> >> To preserve platform and version independence of the dump.</font> <font color="#000000">> </font> <font color="#000000">> > Only if there is a risk. Since a common route to upgrade is a</font> <font color="#000000">> > dump/restore back onto same box it seems worth having an option to do</font> <font color="#000000">> > this.</font> <font color="#000000">> </font> <font color="#000000">> I think you missed the point about version independence. That would be</font> <font color="#000000">> exactly the scenario where a version-to-version change in binary format</font> <font color="#000000">> --- for instance, "money" widening to 64 bits in 8.3 --- would burn you.</font> <font color="#000000">OK</font> <font color="#000000">> Furthermore, this doesn't seem like a scenario where performance ought</font> <font color="#000000">> to be the primary concern. How often do you do major version upgrades?</font> <font color="#000000">Not often enough.</font> <font color="#000000">If it was faster, we would rely on more people actually doing it.</font> </pre></blockquote><br /> _________________________________________________ <br /> Ce message et les éventuels documentsjoints peuvent contenir des informations confidentielles. Au cas où il ne vous serait pas destiné, nous vous remercionsde bien vouloir le supprimer et en aviser immédiatement l'expéditeur. Toute utilisation de ce message non conformeà sa destination, toute diffusion ou publication, totale ou partielle et quel qu'en soit le moyen est formellementinterdite. Les communications sur internet n'étant pas sécurisées, l'intégrité de ce message n'est pas assuréeet la société émettrice ne peut être tenue pour responsable de son contenu.