Re: Virtual generated columns

On 15.01.25 20:37, Peter Eisentraut wrote:
> On 15.01.25 15:12, Dean Rasheed wrote:
>> On Tue, 14 Jan 2025 at 13:37, Peter Eisentraut <peter(at)eisentraut(dot)org>
>> wrote:
>>>
>>> Here is a new patch with that fixed and also a few
>>> tweaks suggested by Jian.
>>>
>>
>> I'm hoping to push my RETURNING OLD/NEW patch [1] soon, so I thought
>> that I would check how it works together with this patch. The good
>> news is that AFAICS everything just works, and it's possible to return
>> old/new virtual generated columns in DML queries as expected.
>>
>> It did require a minor update, because my patch adds a new
>> "result_relation" argument to ReplaceVarsFromTargetList() -- needed in
>> DML queries because, when propagating a Var's old/new
>> varreturningtype, replacement Vars need to be handled differently
>> depending on whether or not they refer to the result relation. So that
>> affects expand_generated_columns_internal(), when called from
>> fireRIRrules(). OTOH, from expand_generated_columns_in_expr() it's OK
>> to just pass 0 as the result relation index, because there won't be
>> any old/new Vars in an expression that's not part of a DML query.
>>
>> Attached is the delta patch I used to handle this, along with a couple
>> of simple test cases. It doesn't really matter which feature makes it
>> in first, but the one that comes second will need to do something like
>> this.
>
> Ok, I'll wait if you want to go ahead with yours soon.

Here is an updated patch that integrates the above changes and also
makes some adjustments now that the logical replication configuration
questions are resolved. I think this is complete now.

But I'm seeing mysterious CI failures that have me stumped. For example:

https://cirrus-ci.com/task/5924251028422656

I have seen this particular pgbench test failure sporadically but
several times, and I have not seen it anywhere without this patch, and
never locally. The macOS task on the cfbot CI is very flaky right now,
so it's hard to get a good baseline. Also, it seems to me that this
failing test could not possibly be further away from the code that the
patch changes, so I'm thinking timing problems, but it only happens on
the macOS task. Really weird.