Re: BitmapHeapScan streaming read user and prelim refactoring
От | Heikki Linnakangas |
---|---|
Тема | Re: BitmapHeapScan streaming read user and prelim refactoring |
Дата | |
Msg-id | 7ffe3d58-ec85-41f0-93af-37cfb60331c2@iki.fi обсуждение исходный текст |
Ответ на | Re: BitmapHeapScan streaming read user and prelim refactoring (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: BitmapHeapScan streaming read user and prelim refactoring
|
Список | pgsql-hackers |
On 14/03/2024 14:34, Robert Haas wrote: > On Thu, Mar 14, 2024 at 6:37 AM Heikki Linnakangas <hlinnaka@iki.fi> wrote: >> If es_snapshot was different from the active snapshot, things would get >> weird, even without parallel query. The scans would use es_snapshot for >> the visibility checks, but any functions you execute in quals would use >> the active snapshot. > > Hmm, that's an interesting point. > > The case where the query is suspended and resumed - i.e. cursors are > used - probably needs more analysis. In that case, perhaps there's > more room for the snapshots to diverge. The portal code is pretty explicit about it, the ExecutorRun() call in PortalRunSelect() looks like this: PushActiveSnapshot(queryDesc->snapshot); ExecutorRun(queryDesc, direction, (uint64) count, portal->run_once); nprocessed = queryDesc->estate->es_processed; PopActiveSnapshot(); I looked at all the callers of ExecutorRun(), and they all have the active snapshot equal to queryDesc->snapshot, either because they called CreateQueryDesc() with the active snapshot before ExecutorRun(), or they set the active snapshot like above. -- Heikki Linnakangas Neon (https://neon.tech)
В списке pgsql-hackers по дате отправления: