Re: Why don't we have a small reserved OID range for patch revisions?
От | Peter Eisentraut |
---|---|
Тема | Re: Why don't we have a small reserved OID range for patch revisions? |
Дата | |
Msg-id | a9681fca-51d7-2692-84af-69fb505f0c6e@2ndquadrant.com обсуждение исходный текст |
Ответ на | Re: Why don't we have a small reserved OID range for patch revisions? (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Why don't we have a small reserved OID range for patch revisions?
Re: Why don't we have a small reserved OID range for patch revisions? |
Список | pgsql-hackers |
On 2019-02-27 22:27, Tom Lane wrote: >> OID collision doesn't seem to be a significant problem (for me). > > Um, I beg to differ. It's not at all unusual for pending patches to > bit-rot for no reason other than suddenly getting an OID conflict. > I don't have to look far for a current example: I'm not saying it doesn't happen, but that it's not a significant problem overall. The changes of a patch (a) allocating a new OID, (b) a second patch allocating a new OID, (c) both being in flight at the same time, (d) actually picking the same OID, are small. I guess the overall time lost to this issue is perhaps 2 hours per year. On the other hand, with about 2000 commits to master per year, if this renumbering business only adds 2 seconds of overhead to committing, we're coming out behind. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
В списке pgsql-hackers по дате отправления: