OID conflicts

On Mon, Sep 18, 2006 at 04:02:56PM +0200, Gevik Babakhani wrote:

I was wondering how one can avoid OID conflicts?
I was testing the uuid patch on a new download from the CVS and
I noticed that some of the OIDs I thought to be free are used by someone
else :(

Not really. At the point of committing it should get sorted out. Did
you use the scripts to find free numbers?

Have a nice day,
--
Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/

On Mon, 2006-09-18 at 16:32 +0200, Martijn van Oosterhout wrote:

On Mon, Sep 18, 2006 at 04:02:56PM +0200, Gevik Babakhani wrote:

I was wondering how one can avoid OID conflicts?
I was testing the uuid patch on a new download from the CVS and
I noticed that some of the OIDs I thought to be free are used by someone
else :(

Not really. At the point of committing it should get sorted out. Did
you use the scripts to find free numbers?

Yes. I did :)

Martijn van Oosterhout wrote:

On Mon, Sep 18, 2006 at 04:02:56PM +0200, Gevik Babakhani wrote:

I was wondering how one can avoid OID conflicts?
I was testing the uuid patch on a new download from the CVS and
I noticed that some of the OIDs I thought to be free are used by someone
else :(

Not really. At the point of committing it should get sorted out. Did
you use the scripts to find free numbers?

Actually, it would be nice to be able to reserve some. It would help
stop patch bitrot. I know Tom Dunstan wanted to do just that while he
was working on the enums patch.

cheers

andrew

On Mon, 2006-09-18 at 10:43 -0400, Andrew Dunstan wrote:

Martijn van Oosterhout wrote:

On Mon, Sep 18, 2006 at 04:02:56PM +0200, Gevik Babakhani wrote:

I was wondering how one can avoid OID conflicts?
I was testing the uuid patch on a new download from the CVS and
I noticed that some of the OIDs I thought to be free are used by someone
else :(

Not really. At the point of committing it should get sorted out. Did
you use the scripts to find free numbers?

Actually, it would be nice to be able to reserve some. It would help
stop patch bitrot. I know Tom Dunstan wanted to do just that while he
was working on the enums patch.

Yes it would be very. If Tom Dunstan decided not to do that I would like
build such a thing.

Gevik Babakhani wrote:

Actually, it would be nice to be able to reserve some. It would help
stop patch bitrot. I know Tom Dunstan wanted to do just that while he
was working on the enums patch.

Yes it would be very. If Tom Dunstan decided not to do that I would like
build such a thing.

You misunderstood me. I meant he wanted to make use of such a facility,
not that he wanted to build it.

By all means float ideas on this - the problem seems to me to be
ensuring that reservations are time limited, but no doubt Tom Lane and
Bruce will have opinions ...

cheers

andrew

Andrew Dunstan wrote:

You misunderstood me. I meant he wanted to make use of such a facility,
not that he wanted to build it.

Yeah, I had enough things on my plate just getting enums to work :)

By all means float ideas on this - the problem seems to me to be
ensuring that reservations are time limited, but no doubt Tom Lane and
Bruce will have opinions ...

OK, one way for such a scheme to work (ie so that patch authors wouldn't
have to worry about OIDs disappearing out from under them) would be to
be able to specify OIDs in a slightly more symbolic form. All the OIDs
allocated for a given patch are likely to be in a block, so you could do
something like (FEATURE_NAME+0), (FEATURENAME+1) or something like that,
rather than hardcoding 2989 or whatever, and hope that the precompiler
could sort it all out. Then you could just have some featureoid.h file
which would define the starting points, and you could just update that
file when someone allocates some oids to point to the latest free one.

I'm don't know whether there are enough patches which allocate OIDs for
it to be worth building such infrastructure, though. It wouldn't just be
the first line in catalog entries, it would have to be all over the
place, e.g. pg_proc has a column whose value in the catalog file is a
string with the oid numbers of the parameters that the function takes. I
suspect, reluctantly, that the pain of patch authors maintaining these
is likely to be less than the pain of hacking the catalog generation
stuff to support something smarter. I'd love to be proven wrong, though.

Hmm. A simpler way lessen the pain might be to have a script which could
update OIDs in your catalog files. You'd have to run it BEFORE doing a
merge. Ie, suppose I've allocated 2978-2991 in my patch, but since then
OIDs have been allocated up to and including 2980. The way to tell that
this is the case would be to do a clean checkout and run the unused_oids
script. Then you could feed the numbers 2978, 2991 and 2980 into the
magical update_oids script which could do a fairly simple sed type of
job on the catalog files. Then you could CVS update and look on in
happiness when duplicate_oids returns nothing and unused_oids show no
gaps. Obviously, being the good patch author that you are, you would
then run your extensive regression tests to make sure that everything is
sweet. :)

If there's interest in such a thing, I might have a go at it. If it
works as described above, would it have a fighting chance of inclusion?
I'd probably use perl rather than pure bourne shell / sed.

Cheers

Tom

On Mon, Sep 18, 2006 at 10:09:52PM +0100, Tom Dunstan wrote:

Hmm. A simpler way lessen the pain might be to have a script which could
update OIDs in your catalog files. You'd have to run it BEFORE doing a
merge. Ie, suppose I've allocated 2978-2991 in my patch, but since then
OIDs have been allocated up to and including 2980. The way to tell that

<snip>

Seems awfully complicated. The numbers don't mean anything, they don't
have to be contiguous. If you want to reduce the chance of conflict,
find a nice big block in unused_oids, add a random number between 0 and
100 and use that. Or squeeze yourself into a block that exactly fits
what you need. There's simply not that many patches that need numbers
to worry about anything complicated.

When I needed a few dozen OIDs for an (unapplied) patch I simply picked
2900 and went up from there. That was a while ago and there's no
conflict yet.

Have anice day,
--
Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/

Martijn van Oosterhout wrote:

Seems awfully complicated. The numbers don't mean anything, they don't
have to be contiguous. If you want to reduce the chance of conflict,
find a nice big block in unused_oids, add a random number between 0 and
100 and use that. Or squeeze yourself into a block that exactly fits
what you need. There's simply not that many patches that need numbers
to worry about anything complicated.

When I needed a few dozen OIDs for an (unapplied) patch I simply picked
2900 and went up from there. That was a while ago and there's no
conflict yet.

Well, since there were no gaps for a significant way up to the last used
OID (I forget where the last gap was), I figured that there was a no-gap
policy. If that's not the case, then indeed, writing a script might be
overkill.

OTOH, I would think that the last allocated OID will continue to rise,
and eventually your patch will have a conflict. Or alternately it'll get
applied before then, and someone else will have to worry about whether
the gap between the end of the contiguous OIDs and where your patch
starts allocating them is enough for their needs, or whether they should
stake out some other part of the reserved OID space for themselves. And
of course, someone else might submit a patch in the meantime that uses
OIDs in the gap or stakes out the same space. Any of the above cases,
having a tool to remap the OIDs might be useful.

I suppose the main point is that given the hardcoded nature of OIDs used
in the catalogs, allocating them is not a process that lends itself to
parallel development. An easy way to remap OIDs in a patch sidesteps a
bunch of issues.

Cheers

Tom