Re: abi-compliance-check failure due to recent changes to pg_{clear,restore}_{attribute,relation}_stats()
| От | Nathan Bossart | 
|---|---|
| Тема | Re: abi-compliance-check failure due to recent changes to pg_{clear,restore}_{attribute,relation}_stats() | 
| Дата | |
| Msg-id | aQOEpG_AI-z2dmJx@nathan обсуждение исходный текст  | 
		
| Ответ на | Re: abi-compliance-check failure due to recent changes to pg_{clear,restore}_{attribute,relation}_stats() (Tom Lane <tgl@sss.pgh.pa.us>) | 
| Список | pgsql-hackers | 
On Wed, Oct 29, 2025 at 10:49:24PM -0400, Tom Lane wrote: > No; my proposal was "don't run the ABI check unless the branch has > a .abi-compliance-history file". master would normally not contain > such a file, thus no check. As I was just discussing with Bruce, > we could put one there for awhile if we wanted to run ABI checks in > advance of forking a stable branch. > > The reason I'm so allergic to having any of these decisions made on > the buildfarm-client side is years of herding cats^W^W trying to get > buildfarm owners to update their script versions and/or config files. > It's close to hopeless. Thus, your proposal a message or three back > to add another BF client config setting to control this sounds like > the worst of all possible worlds. If we needed a change in the > setting, getting the farm to converge to that would take months if not > years. The idea that we could transiently enable checks between beta1 > and branch fork on the basis of that approach is downright risible. > On the other hand, if the decisions are driven purely by what is in > our git tree, a change is the work of moments. I agree with Tom. The lack of an .abi-compliance-history file should be taken to mean that we're not interested in maintaining ABI compatibility across commits for that branch, and the buildfarm check should be skipped. -- nathan
В списке pgsql-hackers по дате отправления: