Re: Is NEW.ctid usable as table_tuple_satisfies_snapshot?

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Kaiting Chen <ktchen14(at)gmail(dot)com>
Cc: "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Is NEW.ctid usable as table_tuple_satisfies_snapshot?
Date: 2023-05-26 16:49:11
Message-ID: 2002278.1685119751@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Kaiting Chen <ktchen14(at)gmail(dot)com> writes:
> On Fri, May 26, 2023 at 11:34 AM David G. Johnston <
> david(dot)g(dot)johnston(at)gmail(dot)com> wrote:
>> On Fri, May 26, 2023 at 8:04 AM Kaiting Chen <ktchen14(at)gmail(dot)com> wrote:
>>> 2. If I lookup the row by its ctid, will the visibility map be consulted.

>> No, but that doesn't seem to be material anyway. Your user-space pl/pgsql
>> function shouldn't care about such a purely performance optimization.

It'd be a waste of cycles to consult the map in this usage, since the
tuple of interest is surely not all-visible and thus the page couldn't
be either.

> Just to clarify, there's no way for SELECT FROM foo WHERE ctid = NEW.ctid
> to return a row that ordinary wouldn't be visible right? There's no magic
> going on with the qual on ctid that skips a visibility check right?

No, a ctid test isn't magic in that way; nodeTidscan.c applies the
same snapshot check as any other relation scan.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Geoghegan 2023-05-26 16:56:50 Re: Cleaning up nbtree after logical decoding on standby work
Previous Message Daniel Verite 2023-05-26 16:24:35 Re: Order changes in PG16 since ICU introduction