Thread: Last builtin OID?

Last builtin OID?

From
Philip Warner
Date:
pg_dump uses the OID of template1 as the last builtin OID, but this now
seems broken in CVS (it returns 1). Should this work? If not, what is the
recommended way to find the last built-in OID?


----------------------------------------------------------------
Philip Warner                    |     __---_____
Albatross Consulting Pty. Ltd.   |----/       -  \
(A.B.N. 75 008 659 498)          |          /(@)   ______---_
Tel: (+61) 0500 83 82 81         |                 _________  \
Fax: (+61) 0500 83 82 82         |                 ___________ |
Http://www.rhyme.com.au          |                /           \|                                |    --________--
PGP key available upon request,  |  /
and from pgp5.ai.mit.edu:11371   |/


Re: Last builtin OID?

From
Peter Eisentraut
Date:
Philip Warner writes:

> pg_dump uses the OID of template1 as the last builtin OID, but this now
> seems broken in CVS (it returns 1). Should this work? If not, what is the
> recommended way to find the last built-in OID?

If you define the last builtin oid as the highest oid in existence after
initdb then it has always been whatever the load of pg_description at then
end leaves you with.

Perhaps you could move the CREATE TRIGGER pg_sync_pg_pwd (or something
else) to the very end to get a more predictable starting point.

-- 
Peter Eisentraut      peter_e@gmx.net       http://yi.org/peter-e/



Re: Last builtin OID?

From
Philip Warner
Date:
At 16:00 21/10/00 +0200, Peter Eisentraut wrote:
>
>Perhaps you could move the CREATE TRIGGER pg_sync_pg_pwd (or something
>else) to the very end to get a more predictable starting point.
>

Unfortunately, this is the sort of thing that caused the current problem
(ie. assuming that a certain item of metadata will remain 'at the end').

What pg_dump needs is 'the oid of that the first thing created in a new DB
will have'. Would there be a simple way of adding a
variable/attribute/whatever to template1? Or adding something to the code
for 'Create Database' that sets a global variable that pg_dump can retreieve?


----------------------------------------------------------------
Philip Warner                    |     __---_____
Albatross Consulting Pty. Ltd.   |----/       -  \
(A.B.N. 75 008 659 498)          |          /(@)   ______---_
Tel: (+61) 0500 83 82 81         |                 _________  \
Fax: (+61) 0500 83 82 82         |                 ___________ |
Http://www.rhyme.com.au          |                /           \|                                |    --________--
PGP key available upon request,  |  /
and from pgp5.ai.mit.edu:11371   |/


Re: Last builtin OID?

From
Larry Rosenman
Date:
Could we set a starting OID for user stuff like (0x4000000) or some
other round number?

LER


* Philip Warner <pjw@rhyme.com.au> [001021 19:52]:
> At 16:00 21/10/00 +0200, Peter Eisentraut wrote:
> >
> >Perhaps you could move the CREATE TRIGGER pg_sync_pg_pwd (or something
> >else) to the very end to get a more predictable starting point.
> >
> 
> Unfortunately, this is the sort of thing that caused the current problem
> (ie. assuming that a certain item of metadata will remain 'at the end').
> 
> What pg_dump needs is 'the oid of that the first thing created in a new DB
> will have'. Would there be a simple way of adding a
> variable/attribute/whatever to template1? Or adding something to the code
> for 'Create Database' that sets a global variable that pg_dump can retreieve?
> 
> 
> ----------------------------------------------------------------
> Philip Warner                    |     __---_____
> Albatross Consulting Pty. Ltd.   |----/       -  \
> (A.B.N. 75 008 659 498)          |          /(@)   ______---_
> Tel: (+61) 0500 83 82 81         |                 _________  \
> Fax: (+61) 0500 83 82 82         |                 ___________ |
> Http://www.rhyme.com.au          |                /           \|
>                                  |    --________--
> PGP key available upon request,  |  /
> and from pgp5.ai.mit.edu:11371   |/
-- 
Larry Rosenman                      http://www.lerctr.org/~ler
Phone: +1 972-414-9812 (voice) Internet: ler@lerctr.org
US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749


Re: Last builtin OID?

From
Tom Lane
Date:
Peter Eisentraut <peter_e@gmx.net> writes:
> Philip Warner writes:
>> pg_dump uses the OID of template1 as the last builtin OID, but this now
>> seems broken in CVS (it returns 1). Should this work? If not, what is the
>> recommended way to find the last built-in OID?

> If you define the last builtin oid as the highest oid in existence after
> initdb then it has always been whatever the load of pg_description at then
> end leaves you with.

"select max(oid) from pg_description" won't do, unfortunately, since the
user might add more comments after creating objects of his own.  Ugh.

> Perhaps you could move the CREATE TRIGGER pg_sync_pg_pwd (or something
> else) to the very end to get a more predictable starting point.

This seems pretty fragile; I'd rather not rely on the assumption that
some specific item is the last one created by initdb.

The reason this isn't simple is that we have a bunch of rows with
hard-wired OIDs (all the ones specifically called out in
include/catalog) plus a bunch more with non-hard-wired OIDs (if they
don't need to be well-known, why keep track of them?).  We initialize
the OID counter to 16384, above the last hard-wired OID, so that the
non-hard-wired OIDs start there.  But there's no way to be sure where
the non-hard-wired system OIDs stop and user OIDs begin.

What if we specify a definite range for these "soft system OIDs"?
Say, 1-16383 are for hardwired OIDs as now, 16384-32767 for soft OIDs,
and user OIDs start at 32768.  Then pg_dump's task is easy; it just
uses the latter constant from some include file.  We could implement
this by initializing the OID counter at 16384 as now, and then rewriting
it to 32768 at the end of initdb.

Comments?

BTW, this raises a point I'd never thought hard about: if the dbadmin
adds some site-local objects to template1, then makes databases that
copy these objects, a pg_dumpall and restore will do the Wrong Thing.
pg_dump isn't smart about excluding objects inherited from template1
from dumps of other databases.  Is there any reasonable way to fix
that?
        regards, tom lane


Re: Last builtin OID?

From
Philip Warner
Date:
At 21:40 21/10/00 -0400, Tom Lane wrote:
>We could implement
>this by initializing the OID counter at 16384 as now, and then rewriting
>it to 32768 at the end of initdb.
...
>BTW, this raises a point I'd never thought hard about: if the dbadmin
>adds some site-local objects to template1, then makes databases that
>copy these objects, a pg_dumpall and restore will do the Wrong Thing.

Some kind of forced value would be good, although I would prefer the
'CREATE DATABASE' code to set a value in a table somewhere to the last OID
used when the DB was created. This would deal with the 'extended template1'
scenario (which, incidentally, I am already a victim of). Could a new
attribute be added to pg_database?


----------------------------------------------------------------
Philip Warner                    |     __---_____
Albatross Consulting Pty. Ltd.   |----/       -  \
(A.B.N. 75 008 659 498)          |          /(@)   ______---_
Tel: (+61) 0500 83 82 81         |                 _________  \
Fax: (+61) 0500 83 82 82         |                 ___________ |
Http://www.rhyme.com.au          |                /           \|                                |    --________--
PGP key available upon request,  |  /
and from pgp5.ai.mit.edu:11371   |/


Re: Last builtin OID?

From
Tom Lane
Date:
Philip Warner <pjw@rhyme.com.au> writes:
> ... I would prefer the
> 'CREATE DATABASE' code to set a value in a table somewhere to the last OID
> used when the DB was created. This would deal with the 'extended template1'
> scenario (which, incidentally, I am already a victim of). Could a new
> attribute be added to pg_database?

Hm.  Offhand I don't see a hole in that idea, but it's too simple and
beautiful to be right ;-) ...
        regards, tom lane