| From: | Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Peter Geoghegan <pg(at)bowt(dot)ie>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Why don't we have a small reserved OID range for patch revisions? |
| Date: | 2019-02-27 22:38:58 |
| Message-ID: | a9681fca-51d7-2692-84af-69fb505f0c6e@2ndquadrant.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | 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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Peter Eisentraut | 2019-02-27 22:44:30 | Re: Why don't we have a small reserved OID range for patch revisions? |
| Previous Message | Tom Lane | 2019-02-27 22:09:42 | Re: Why don't we have a small reserved OID range for patch revisions? |