John Naylor writes:
> On Tue, Mar 12, 2019 at 5:36 AM Tom Lane wrote:
>> This seems committable from my end --- any further comments?
> I gave it a read and it looks good to me, but I haven't tried to run it.
Thanks for checking. I've pushed both patches now.
I noticed while looking at the
On Tue, Mar 12, 2019 at 5:36 AM Tom Lane wrote:
> This seems committable from my end --- any further comments?
I gave it a read and it looks good to me, but I haven't tried to run it.
--
John Naylorhttps://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA,
I wrote:
> I've successfully done check-world after renumbering every OID above
> 4000 to somewhere else. I also tried renumbering everything below
> 4000, which unsurprisingly blew up because there are various catalog
> columns we haven't fixed to use symbolic OIDs. (The one that initdb
>
John Naylor writes:
> Now it looks like:
> perl renumber_oids.pl --first-mapped-oid 8000 --last-mapped-oid 8999
> --first-target-oid 2000 *.dat
> To prevent a maintenance headache, I didn't copy any of the formatting
> logic over. You'll also have to run reformat_dat_files.pl afterwards
> to
On Sat, Mar 9, 2019 at 1:14 AM Tom Lane wrote:
> I took a quick look at this. I went ahead and pushed the parts that
> were just code cleanup in reformat_dat_file.pl, since that seemed
> pretty uncontroversial. As far as the rest of it goes:
Okay, thanks.
> * I'm really not terribly happy
John Naylor writes:
>> On 2/8/19, Tom Lane wrote:
>>> A script such as you suggest might be a good way to reduce the temptation
>>> to get lazy at the last minute. Now that the catalog data is pretty
>>> machine-readable, I suspect it wouldn't be very hard --- though I'm
>>> not volunteering
Peter Geoghegan writes:
> On Fri, Mar 1, 2019 at 11:56 AM Robert Haas wrote:
>> It would be neat if there were a tool you could run to somehow tell
>> you whether catversion needs to be changed for a given patch.
> That seems infeasible because of stored rules. A lot of things bleed
> into
On Fri, Mar 1, 2019 at 11:56 AM Robert Haas wrote:
> It would be neat if there were a tool you could run to somehow tell
> you whether catversion needs to be changed for a given patch.
That seems infeasible because of stored rules. A lot of things bleed
into that. We could certainly do better at
On Thu, Feb 28, 2019 at 5:36 PM Peter Geoghegan wrote:
> I have attempted to institute some general guidelines for what the
> thicket of rules are by creating the "committing checklist" page. This
> is necessarily imperfect, because the rules are in many cases open to
> interpretation, often for
On Thu, Feb 28, 2019 at 6:40 PM Tom Lane wrote:
> 1. Encourage people to develop new patches using chosen-at-random
> high OIDs, in the 7K-9K range. They do this already, it'd just
> be encouraged instead of discouraged.
>
> 2. Commit patches as received.
>
> 3. Once each devel cycle, after
On Thu, Feb 28, 2019 at 3:40 PM Tom Lane wrote:
> Robert Haas writes:
> >>> just as a thought, what if we stopped assigning manual OIDs for new
> >>> catalog entries altogether, except for once at the end of each release
> >>> cycle?
>
> Actually ... that leads to an idea that wouldn't add any
On 3/1/19 12:41 AM, Peter Geoghegan wrote:
> On Thu, Feb 28, 2019 at 3:09 PM Tom Lane wrote:
>> The only thing that's really clear is that some senior committers don't
>> want to be bothered because they don't think there's a problem here that
>> justifies any additional expenditure of their
On Thu, Feb 28, 2019 at 3:09 PM Tom Lane wrote:
> The only thing that's really clear is that some senior committers don't
> want to be bothered because they don't think there's a problem here that
> justifies any additional expenditure of their time. Perhaps they are
> right, because I'd
Robert Haas writes:
>>> just as a thought, what if we stopped assigning manual OIDs for new
>>> catalog entries altogether, except for once at the end of each release
>>> cycle?
Actually ... that leads to an idea that wouldn't add any per-commit
overhead, or really much change at all to existing
Peter Geoghegan writes:
> On Thu, Feb 28, 2019 at 7:59 AM Robert Haas wrote:
>> OK. Well, I think that doing nothing is superior to this proposal,
>> for reasons similar to what Peter Eisentraut has already articulated.
>> And I think rather than blasting forward with your own preferred
>>
On Thu, Feb 28, 2019 at 7:59 AM Robert Haas wrote:
> I don't think this is the worst proposal ever. However, I also think
> that it's not unreasonable to raise the issue that writing OR
> reviewing OR committing a patch already involves adhering to a thicket
> of undocumented rules. When
On Thu, Feb 28, 2019 at 10:27 AM Tom Lane wrote:
> Robert Haas writes:
> > This seems like a big piece of new mechanism being invented
> > to solve an occasional annoyance. Your statistics are not convincing
> > at all: you're arguing that this is a big problem because 2-3% of
> > pending
Robert Haas writes:
> This seems like a big piece of new mechanism being invented
> to solve an occasional annoyance. Your statistics are not convincing
> at all: you're arguing that this is a big problem because 2-3% of
> pending patches current have an issue here, and some others have in
> the
On Wed, Feb 27, 2019 at 10:41 PM Tom Lane wrote:
> In short, this situation may look fine from the perspective of a committer
> with a relatively short timeline to commit, but it's pretty darn awful for
> everybody else. The only way to avoid a ~ 50% failure rate is to choose
> OIDs above 6K,
Peter Eisentraut writes:
> 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
Peter Geoghegan writes:
> On Wed, Feb 27, 2019 at 2:44 PM Peter Eisentraut
> wrote:
>> If this is the problem (although I think we'd find that OID collisions
>> are rather rare compared to other gratuitous cfbot failures), why not
>> have the cfbot build with a flag that ignores OID collisions?
On Wed, Feb 27, 2019 at 2:44 PM Peter Eisentraut
wrote:
> If this is the problem (although I think we'd find that OID collisions
> are rather rare compared to other gratuitous cfbot failures), why not
> have the cfbot build with a flag that ignores OID collisions?
How would that work?
--
Peter
On 2019-02-27 22:50, Peter Geoghegan wrote:
> However, the continuous
> integration stuff has created an expectation that your patch shouldn't
> be left to bitrot for long. Silly mechanical bitrot now seems like a
> much bigger problem than it was before these developments. It unfairly
> puts
On Wed, Feb 27, 2019 at 2:39 PM Peter Eisentraut
wrote:
> 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.
But...they are. Most patches don't create new system
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:
Peter Geoghegan writes:
> On Wed, Feb 27, 2019 at 1:27 PM 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
I wrote:
> We do need a couple of pieces of new infrastructure to make this idea
> conveniently workable. One is a tool to allow automatic OID renumbering
> instead of having to do it by hand; Naylor has a draft for that upthread.
Oh: arguably, something else we'd need to do to ensure that OID
On Wed, Feb 27, 2019 at 1:27 PM 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
Peter Eisentraut writes:
> On 2019-02-08 19:14, Tom Lane wrote:
>> Quite a few people have used OIDs up around 8000 or 9000 for this purpose;
>> I doubt we need a formally reserved range for it. The main problem with
>> doing it is the hazard that the patch'll get committed just like that,
>>
On 2019-02-08 19:14, Tom Lane wrote:
> Quite a few people have used OIDs up around 8000 or 9000 for this purpose;
> I doubt we need a formally reserved range for it. The main problem with
> doing it is the hazard that the patch'll get committed just like that,
> suddenly breaking things for
I wrote:
> Along those lines, here's a draft patch to do just that. It handles
> array type oids as well. Run it like this:
>
> perl reformat_dat_file.pl --map-from 9000 --map-to 2000 *.dat
>
> There is some attempt at documentation. So far it doesn't map by
> default, but that could be
I wrote:
> On 2/8/19, Tom Lane wrote:
>> A script such as you suggest might be a good way to reduce the temptation
>> to get lazy at the last minute. Now that the catalog data is pretty
>> machine-readable, I suspect it wouldn't be very hard --- though I'm
>> not volunteering either. I'm
On 2/8/19, Tom Lane wrote:
> A script such as you suggest might be a good way to reduce the temptation
> to get lazy at the last minute. Now that the catalog data is pretty
> machine-readable, I suspect it wouldn't be very hard --- though I'm
> not volunteering either. I'm envisioning something
On Fri, Feb 8, 2019 at 11:59 PM Tom Lane wrote:
> To the extent that this works at all, OIDs in the 9000 range ought
> to be enough of a flag already, I think.
A "flag" that isn't documented anywhere outside of a mailing list
discussion and that isn't checked by any code anywhere is not much of
On Fri, Feb 8, 2019 at 10:29 AM Tom Lane wrote:
> Um. That would not be just an add-on script but something that
> genbki.pl would have to accept. I'm not excited about that; it would
> complicate what's already complex, and if it works enough for test
> purposes then it wouldn't really stop a
Peter Geoghegan writes:
> On Fri, Feb 8, 2019 at 10:14 AM Tom Lane wrote:
>> A script such as you suggest might be a good way to reduce the temptation
>> to get lazy at the last minute. Now that the catalog data is pretty
>> machine-readable, I suspect it wouldn't be very hard --- though I'm
>>
On Fri, Feb 8, 2019 at 10:14 AM Tom Lane wrote:
> A script such as you suggest might be a good way to reduce the temptation
> to get lazy at the last minute. Now that the catalog data is pretty
> machine-readable, I suspect it wouldn't be very hard --- though I'm
> not volunteering either. I'm
Peter Geoghegan writes:
> Why don't we provide a small reserved OID range that can be used by
> patch authors temporarily, with the expectation that they'll be
> replaced by "real" OIDs at the point the patch gets committed? This
> would be similar the situation with catversion bumps -- we don't
Why don't we provide a small reserved OID range that can be used by
patch authors temporarily, with the expectation that they'll be
replaced by "real" OIDs at the point the patch gets committed? This
would be similar the situation with catversion bumps -- we don't
expect patches that will
39 matches
Mail list logo
