Re: vacuum_truncate configuration parameter and isset_offset - Mailing list pgsql-hackers
From | Robert Haas |
---|---|
Subject | Re: vacuum_truncate configuration parameter and isset_offset |
Date | |
Msg-id | CA+TgmoaSKpN--opAwuqrawhzgQKnFJxZT0f-hqun9a2nkQS-PA@mail.gmail.com Whole thread Raw |
In response to | Re: vacuum_truncate configuration parameter and isset_offset ("David G. Johnston" <david.g.johnston@gmail.com>) |
Responses |
Re: vacuum_truncate configuration parameter and isset_offset
Re: vacuum_truncate configuration parameter and isset_offset Re: vacuum_truncate configuration parameter and isset_offset |
List | pgsql-hackers |
On Wed, Mar 26, 2025 at 11:10 AM David G. Johnston <david.g.johnston@gmail.com> wrote: > I'm willing to say "I don't know why this is so very important to Nikolay, but I trust him that it is, and since my opinionisn't that strong and this isn't a big deal, so I will accommodate the person screaming that adding this will maketheir life miserable in a real way." Maybe others need more evidence of what that misery looks like? What I'm upset about is that it feels to me like Nikolay is trying to win the argument by yelling. I don't want that to be the way we do things around here. I admit that sometimes it is, and I think that is bad, no matter who the yeller is and who is getting yelled at. People get upset, including me, and that is life, but whether people are upset should never be the determinant of what goes into the tree. I fear that this argument will make Nathan - or other committers - more cautious in committing routine patches for no real reason, and I think that would be bad for the project. Committing patches frequently results in a bunch of people getting annoyed at you because of some oversight, and it's one of the reasons why it takes so long to get a patch committed around here -- people are risk-averse and afraid of doing something wrong, so they do nothing. I don't really know how we can solve that problem, but I definitely do not want to see us start getting upset with people when they didn't even do anything wrong. And that's how I see this case. Somebody could have chosen to solve this problem in a few ways, Nathan picked one of the reasonable ones, and now we're spending dozens of email messages arguing about whether Nathan is a terrible person for doing something that looks totally normal. In my mind, that is absolutely clear. Nathan is not a terrible person for that, and I feel rather strongly that saying otherwise is harmful to the development community and to the project as a whole. I have no problem with a rational discussion of what the best option is here, but I am absolutely not OK with vitriolic rhetoric about how things are awful when, AFAICS, nothing has happened here beyond the totally routine. In a certain sense, the damage here has already been done. Nathan has already had to spend a significant amount of time engaging with this thread over what I think should be a complete non-event, and will probably have to spend more, and all that takes away from time that could, for example, be spent reviewing and committing other patches. And for what? If it ever happens that the design decision that this patch made caused a real problem, some future patch could have reverted it and substituted something else and probably nobody would have cared. Even now, if some committer other than Nathan cares enough to change something here, I doubt that Nathan will really care. But I cannot see any world in which pinning Nathan beyond a barrel and demanding action is a win for the project overall. If we argued this much about every design detail of my patches, I would have quit working on this project long ago. -- Robert Haas EDB: http://www.enterprisedb.com
pgsql-hackers by date: