Thread: OID conflicts
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 :( Any advice?
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/ > From each according to his ability. To each according to his ability to litigate.
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 :) > > Have a nice day,
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
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/ > From each according to his ability. To each according to his ability to litigate.
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
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 hopethat 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