Robert Haas <robertmhaas@gmail.com> writes:
> On Mon, May 6, 2024 at 7:31 PM Tom Lane <tgl@sss.pgh.pa.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
