agora inbox for [email protected]help / color / mirror / Atom feed
Re: Confirmation on concurrent SELECT FOR UPDATE with ON CONFLICT DO NOTHING 3+ messages / 3 participants [nested] [flat]
* Re: Confirmation on concurrent SELECT FOR UPDATE with ON CONFLICT DO NOTHING @ 2026-04-30 04:32 Adrian Klaver <[email protected]> 0 siblings, 0 replies; 3+ messages in thread From: Adrian Klaver @ 2026-04-30 04:32 UTC (permalink / raw) To: Matt Magoffin <[email protected]>; +Cc: [email protected] On 4/29/26 7:48 PM, Matt Magoffin wrote: > >> On 30 Apr 2026, at 11:37 AM, Adrian Klaver <[email protected]> >> wrote: >> >> So in your first case the INSERT is never done and there is no lock >> for the INSERT in any case. > > Thanks for the info, Adrian. And so for my 2nd case, where the INSERT is > blocked by the DELETE statement, I see the docs say > > The FOR UPDATE lock mode is also acquired by any DELETE on a row… > > But I am not finding the info that talks about why the INSERT … ON > CONFLICT DO NOTHING does block until the DELETE finishes. I guess in my > mind the SELECT … FOR UPDATE and DELETE were acquiring the same kind of > row lock, so the behaviour of the INSERT would be the same across both > cases. This is beginning to get outside my level of understanding. As I see it in the first case the below applies: "SELECT FOR UPDATE will wait for a concurrent transaction that has run any of those commands on the same row, and will then lock and return the updated row (or no row, if the row was deleted). ..." where other commands are "UPDATE, DELETE, SELECT FOR UPDATE, SELECT FOR NO KEY UPDATE, SELECT FOR SHARE or SELECT FOR KEY SHARE". In your case you where doing an INSERT and the ON CONFLICT DO NOTHING meant a DELETE would not reached. In the second case you locked with an explicit DELETE in the first session which prevented the second session from determining whether the ON CONFLICT DO NOTHING actually applied until the first session committed. > > I suppose what I’d be keen to confirm is that the blocking behaviour I > get with the DELETE is expected behaviour, that I can count on. Do you > know if that is true? > > Cheers, > Matt -- Adrian Klaver [email protected] ^ permalink raw reply [nested|flat] 3+ messages in thread
* Pre-PG18 parallel scan estimation: accessing planned worker count from amestimateparallelscan() @ 2026-06-25 01:46 Sivaprasad <[email protected]> 2026-06-25 05:42 ` Re: Pre-PG18 parallel scan estimation: accessing planned worker count from amestimateparallelscan() Peter Geoghegan <[email protected]> 0 siblings, 1 reply; 3+ messages in thread From: Sivaprasad @ 2026-06-25 01:46 UTC (permalink / raw) To: [email protected] Hello, While adding parallel scan support to the Biscuit <https://github.com/CrystallineCore/Biscuit; index access method, I ran into a question about the pre-PG18 parallel scan API. Biscuit partitions scan work into a fixed number of segments at estimation time and assigns those segments to parallel participants via a shared-memory descriptor in the DSM segment. Because the segment layout depends on the number of participants, we need the planned worker count during amestimateparallelscan() — the only callback that both sizes the DSM allocation and runs in the same process immediately before aminitparallelscan(). The callback signatures across versions are: - - PG16: Size (*)(void) - PG17: Size (*)(int nkeys, int norderbys) - PG18+: Size (*)(Relation, int *nworkers*, int nchunks) In PG18+, nworkers is available directly. In PG16 and PG17 it is not. My question: prior to PG18, was there any supported mechanism by which an index AM could determine the planner's intended parallel worker count during scan estimation? Thanks, Sivaprasad Murali Biscuit index access method ^ permalink raw reply [nested|flat] 3+ messages in thread
* Re: Pre-PG18 parallel scan estimation: accessing planned worker count from amestimateparallelscan() 2026-06-25 01:46 Pre-PG18 parallel scan estimation: accessing planned worker count from amestimateparallelscan() Sivaprasad <[email protected]> @ 2026-06-25 05:42 ` Peter Geoghegan <[email protected]> 0 siblings, 0 replies; 3+ messages in thread From: Peter Geoghegan @ 2026-06-25 05:42 UTC (permalink / raw) To: Sivaprasad <[email protected]>; +Cc: [email protected] On Wed, Jun 24, 2026 at 9:46 PM Sivaprasad <[email protected]> wrote: > My question: prior to PG18, was there any supported mechanism by which an index AM could determine the planner's intended parallel worker count during scan estimation? No. -- Peter Geoghegan ^ permalink raw reply [nested|flat] 3+ messages in thread
end of thread, other threads:[~2026-06-25 05:42 UTC | newest] Thread overview: 3+ messages (download: mbox mbox.gz follow: Atom feed) -- links below jump to the message on this page -- 2026-04-30 04:32 Re: Confirmation on concurrent SELECT FOR UPDATE with ON CONFLICT DO NOTHING Adrian Klaver <[email protected]> 2026-06-25 01:46 Pre-PG18 parallel scan estimation: accessing planned worker count from amestimateparallelscan() Sivaprasad <[email protected]> 2026-06-25 05:42 ` Re: Pre-PG18 parallel scan estimation: accessing planned worker count from amestimateparallelscan() Peter Geoghegan <[email protected]>
This inbox is served by agora; see mirroring instructions for how to clone and mirror all data and code used for this inbox