Re: pgsql: postgres_fdw: Inherit the local transaction's access/deferrable
От | Etsuro Fujita |
---|---|
Тема | Re: pgsql: postgres_fdw: Inherit the local transaction's access/deferrable |
Дата | |
Msg-id | CAPmGK16yRFfMr4cKuL2ioqrhuLo0VrwrhwFre-x4cp2DzhPyqg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: pgsql: postgres_fdw: Inherit the local transaction's access/deferrable (Robert Haas <robertmhaas@gmail.com>) |
Список | pgsql-hackers |
On Thu, Jun 5, 2025 at 3:39 AM Robert Haas <robertmhaas@gmail.com> wrote: > On Tue, Jun 3, 2025 at 6:45 AM Etsuro Fujita <etsuro.fujita@gmail.com> wrote: > > No, this is a fix, not a feature, as discussed in the thread; as > > mentioned in the commit message, the previous version of postgres_fdw > > could cause surprising behaviors that would never happen in normal > > cases where a read-only and/or deferrable transaction only > > accesses/modifies data on the local server, so this commit fixes those > > behaviors. But yes, it makes a behavior change, so I think it’s a > > good idea to add a note about that to the v18 release notes, as > > proposed by Fujii-san. > > Sometimes, people can have different opinions about whether something > is a bug fix or a behavior change. So far, I don't think you've > convinced a single person either on the original thread or on this one > that this is a bug fix, so I believe that, at present, the consensus > is that this is a new feature. Although you may not agree with that > consensus, and you may even be right, we all have to do what most > people agree is right rather than what we ourselves prefer. A consensus we reached on the original thread is that if the previous behavior is considered problematic, we should fix it; otherwise, we should not. I proposed to fix it for the reason mentioned above, and went ahead, as there were no objections about that. But seeing the comments on this thread, I have to agree that this is a feature rather than a fix. > For what it's worth, I agree with others that this is not just a bug > fix: it's a behavior change that should be subject to the feature > freeze. I personally think that it's probably a desirable behavior > change, and that it's small enough that we could consider leaving it > in v18 if that meets with general approval. We have had cases like > this, where something feels too disruptive to back-patch, but is still > on some level a fix or correction of behavior, in the past, and we > have sometimes decided to handle those by allowing them to be added to > the major release after the feature freeze deadline, but not > back-patching them. So in my mind that is a possibility here. > > However, that would require a pretty unanimous agreement that this > change is an improvement, and it appears to me that we don't have > that. I read Fujii Masao's comments to indicate that he doesn't > necessarily agree with the change and wants it reverted, and I read > Michael Paquier's comments the same way. Unless I'm misunderstanding > their position, this needs to be reverted. Agreed. I will revert this in a few days. And I will re-propose it as an improvement for v19. Thanks for the discussion! Best regards, Etsuro Fujita
В списке pgsql-hackers по дате отправления: