Re: WHERE CURRENT OF with RLS quals that are ctid conditions

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: WHERE CURRENT OF with RLS quals that are ctid conditions
Date: 2024-05-07 14:05:16
Message-ID: 4057734.1715090716@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Mon, May 6, 2024 at 7:31 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> So maybe this is not really worth fixing. Thoughts?

> Hmm, I thought the RLS condition needed to accept the old and new
> TIDs, but not (InvalidBlockNumber,0). I might well have misunderstood,
> though.

If you leave the (InvalidBlockNumber,0) alternative out of the RLS
condition, my patch's test case fails because the row "doesn't
satisfy the RLS condition" (I forget the exact error message, but
it was more or less that).

> As to whether this is worth fixing, I think it is, but it might not be
> worth back-patching the fix. Also, I'd really like to get disable_cost
> out of the picture here. That would require more code reorganization
> than you've done here, but I think it would be worthwhile. I suppose
> that could also be done as a separate patch, but I wonder if that
> doesn't just amount to changing approximately the same code twice.

No, because the disable_cost stuff is nowhere near here. In any case,
what we were talking about was suppressing creation of competing
non-TIDScan paths. It's still going to be incumbent on tidpath.c to
create a correct path, and as things stand it won't for this case.

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2024-05-07 14:16:51 Re: WHERE CURRENT OF with RLS quals that are ctid conditions
Previous Message Robert Haas 2024-05-07 14:05:02 Re: WHERE CURRENT OF with RLS quals that are ctid conditions