Lists: | pgsql-sql |
---|
From: | Rob Sargent <robjsargent(at)gmail(dot)com> |
---|---|
To: | pgsql-sql(at)postgresql(dot)org |
Subject: | Order of operations in ascii vs archive format (moderately urgent) |
Date: | 2009-07-21 16:27:38 |
Message-ID: | 4A65EC7A.8010003@gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-sql |
Is there a difference in the order of execution between an ascii dump
and one using the "custom" format? Or any difference in the general
operation?
I need to know if I can rely on the ascii version to tell me what the
custom format might have done.
From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Rob Sargent <robjsargent(at)gmail(dot)com> |
Cc: | pgsql-sql(at)postgresql(dot)org |
Subject: | Re: Order of operations in ascii vs archive format (moderately urgent) |
Date: | 2009-07-21 16:49:52 |
Message-ID: | 15027.1248194992@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-sql |
Rob Sargent <robjsargent(at)gmail(dot)com> writes:
> Is there a difference in the order of execution between an ascii dump
> and one using the "custom" format? Or any difference in the general
> operation?
There's not supposed to be. One standard test on the pg_dump code is
pg_dump >textfile
pg_dump -Fc >dumpfile
pg_restore dumpfile >textfile2
diff textfile textfile2
If these don't produce the same results something is broken.
regards, tom lane
From: | Rob Sargent <robjsargent(at)gmail(dot)com> |
---|---|
To: | pgsql-sql(at)postgresql(dot)org |
Subject: | Re: Order of operations in ascii vs archive format (moderately urgent) |
Date: | 2009-07-21 16:54:47 |
Message-ID: | 4A65F2D7.8000901@gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-sql |
Wonderful news.
I just ran dump and restore against same production server. Constraints
and the absence of drop <object> calls appears to have saved my butt.
Tom Lane wrote:
> Rob Sargent <robjsargent(at)gmail(dot)com> writes:
>
>> Is there a difference in the order of execution between an ascii dump
>> and one using the "custom" format? Or any difference in the general
>> operation?
>>
>
> There's not supposed to be. One standard test on the pg_dump code is
> pg_dump >textfile
> pg_dump -Fc >dumpfile
> pg_restore dumpfile >textfile2
> diff textfile textfile2
> If these don't produce the same results something is broken.
>
> regards, tom lane
>
From: | Rob Sargent <robjsargent(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-sql(at)postgresql(dot)org |
Subject: | Re: Order of operations in ascii vs archive format (moderately urgent) |
Date: | 2009-07-21 17:24:27 |
Message-ID: | 4A65F9CB.2050000@gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-sql |
The ascii dump has serveral CREATE FUNCTION gbtreeN_{in,out} but I don't
see them in the current (source) database using '\df gbtree*'. Using
'\df gbt*' I get 111 functions for which all the names begin 'gbt_'.
Have I lost them? The gbtreekeyN types are still there.
Tom Lane wrote:
> Rob Sargent <robjsargent(at)gmail(dot)com> writes:
>
>> Is there a difference in the order of execution between an ascii dump
>> and one using the "custom" format? Or any difference in the general
>> operation?
>>
>
> There's not supposed to be. One standard test on the pg_dump code is
> pg_dump >textfile
> pg_dump -Fc >dumpfile
> pg_restore dumpfile >textfile2
> diff textfile textfile2
> If these don't produce the same results something is broken.
>
> regards, tom lane
>
From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Rob Sargent <robjsargent(at)gmail(dot)com> |
Cc: | pgsql-sql(at)postgresql(dot)org |
Subject: | Re: Order of operations in ascii vs archive format (moderately urgent) |
Date: | 2009-07-21 17:29:43 |
Message-ID: | 15783.1248197383@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-sql |
Rob Sargent <robjsargent(at)gmail(dot)com> writes:
> The ascii dump has serveral CREATE FUNCTION gbtreeN_{in,out} but I don't
> see them in the current (source) database using '\df gbtree*'.
Which ones? Pre-8.4 \df will deliberately suppress I/O functions
(or functions that it thinks are I/O functions, anyway).
regards, tom lane