Re: Buffer locking is special (hints, checksums, AIO writes)

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: Chao Li <li(dot)evan(dot)chao(at)gmail(dot)com>, Kirill Reshke <reshkekirill(at)gmail(dot)com>, Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, Melanie Plageman <melanieplageman(at)gmail(dot)com>, Matthias van de Meent <boekewurm+postgres(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org, Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, Noah Misch <noah(at)leadboat(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
Subject: Re: Buffer locking is special (hints, checksums, AIO writes)
Date: 2026-01-15 23:19:41
Message-ID: 938362.1768519181@sss.pgh.pa.us
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Andres Freund <andres(at)anarazel(dot)de> writes:
> Can't quite decide between just using always_inline - after all the buffer
> locking really is a rather crucial code path - and just initializing
> wait_event to 0. Either seems better than using a default:.

Yeah, I agree with not using a default: in case we ever extend
the mode enum. I'd be inclined to fix it like this:

case BUFFER_LOCK_UNLOCK:
pg_unreachable();
+ /* silence possible compiler warning: */
+ wait_event = 0;
}

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2026-01-15 23:22:48 Re: Extended Statistics set/restore/clear functions.
Previous Message Andres Freund 2026-01-15 23:16:07 Re: Buffer locking is special (hints, checksums, AIO writes)