Re: Question about InvalidatePossiblyObsoleteSlot()
| От | Bertrand Drouvot | 
|---|---|
| Тема | Re: Question about InvalidatePossiblyObsoleteSlot() | 
| Дата | |
| Msg-id | aQHWnOQNSS4zy105@ip-10-97-1-34.eu-west-3.compute.internal обсуждение исходный текст  | 
		
| Ответ на | Re: Question about InvalidatePossiblyObsoleteSlot() (Masahiko Sawada <sawada.mshk@gmail.com>) | 
| Ответы | 
                	
            		Re: Question about InvalidatePossiblyObsoleteSlot()
            		
            		 | 
		
| Список | pgsql-hackers | 
Hi, On Tue, Oct 28, 2025 at 11:53:26AM -0700, Masahiko Sawada wrote: > On Tue, Oct 28, 2025 at 1:58 AM Bertrand Drouvot > <bertranddrouvot.pg@gmail.com> wrote: > > > > Hi, > > > > On Mon, Oct 27, 2025 at 10:22:32AM -0700, Masahiko Sawada wrote: > > > On Thu, Oct 23, 2025 at 3:07 AM Bertrand Drouvot > > > > > seems no longer match what this > > > block of codes do. > > > > Agree. > > > > > It needs to be updated or moved to a more > > > appropriate place. > > > > What about moving it after? > > > > " > > * If the slot can be acquired, do so and mark it invalidated > > * immediately. Otherwise we'll signal the owning process, below, and > > * retry." > > > > That looks like a good place to me. > > +1 Done that way in v3 attached. Please note that v3 does not take into account the XLogRecPtrIsInvalid() remark as this will be part of a global effort and it's not directly linked to what we want to achieve here. > > > > > but I think > > > we might want to do something to deal with the inconsistency that we > > > originally wanted to address. > > > > I see, you mean that the tests are stable now (thanks to 105b2cb3361) but > > that we should still do something for "production" cases? (i.e not making use > > of injection points). > > Yes. While it seems we might want to review the past discussion, if > we've concluded such behavior is problematic behavior and could > confuse users, we can do something like improving the > invalidation/termination reports. Or we can do nothing if the current > reporting is fine. That's the test instability that triggered 818fefd8fd4 and not any report from the field. I think that pre-818fefd8fd4 behavior has been there for a while and that hitting the inconsistency is a pathological case. I'd vote for do nothing unless we get complaints from the field. Regards, -- Bertrand Drouvot PostgreSQL Contributors Team RDS Open Source Databases Amazon Web Services: https://aws.amazon.com
Вложения
В списке pgsql-hackers по дате отправления: