From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
Cc: | Zdenek Kotala <Zdenek(dot)Kotala(at)Sun(dot)COM>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: COPY does not work with regproc and aclitem |
Date: | 2006-10-23 20:57:32 |
Message-ID: | 28514.1161637052@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-patches |
Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
> Zdenek Kotala wrote:
>> I'm not sure if it is important, but I think that preserve OID is
>> important and SQL level does not allow set OID.
> Does it matter in any case other than where it refers to an on-disk
> object? And does that need anything other than a fixup to
> pg_class::relfilenode?
The only things pg_upgrade should be trying to preserve OIDs for are
large objects. I don't even see a need to worry about relfilenode:
you've got to link the physical files into the new directory tree
anyway, you can perfectly well link them in under whatever new
relfilenode identity happens to be assigned during the dump-reload step.
This was all worked out years ago.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Mark Kirkwood | 2006-10-23 21:10:40 | Re: New CRC algorithm: Slicing by 8 |
Previous Message | richard-pgodbc | 2006-10-23 20:48:36 | Re: Tsearch2 index size |
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2006-10-23 20:59:22 | Re: BUG #2712: could not fsync segment: Permission |
Previous Message | Thomas H. | 2006-10-23 20:49:37 | Re: BUG #2712: could not fsync segment: Permission |