Fix corruption in gapfill plan

[erimatnor]

This change fixes a bug with gapfill that caused certain query plans
to fail with the error "could not find pathkey item to sort". This was
caused by a corruption in the query plan which happened as a result of
removing the last two arguments to the time_bucket_gapfill function
expression during query planning. Since the function expression was
modified via a reference to the original query plan tree, it affected
also the expression in the target list. When the planner couldn't
match the target list with the corresponding equivalence member (which
still included the two removed arguments), the error was generated.

The original reason for removing the two arguments was to avoid
passing them on to time_bucket, which is called internally by
time_bucket_gapfill. However, the last to arguments aren't passed on
anyway, so it isn't necessary to modify the original argument list.

Fixes #2232

[codecov]

Codecov Report

Merging #2868 (b047264) into master (87a190a) will increase coverage by 0.13%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master    #2868      +/-   ##
==========================================
+ Coverage   90.09%   90.22%   +0.13%     
==========================================
  Files         212      212              
  Lines       34769    34718      -51     
==========================================
  Hits        31324    31324              
+ Misses       3445     3394      -51     

Impacted Files	Coverage Δ
tsl/src/nodes/gapfill/planner.c	96.89% <ø> (-0.02%)	⬇️
src/loader/bgw_message_queue.c	87.74% <0.00%> (+0.64%)	⬆️
src/import/planner.c	70.30% <0.00%> (+11.12%)	⬆️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 87a190a...b047264. Read the comment docs.

[k-rus]

It looks good to me, but I cannot verify the example.
Can you run a query showing the actual data in the range (or absence of the data)?
For example:

SELECT time
FROM metrics_tstz
WHERE time >= '2017-01-01' AND time < '2018-01-01'

[erimatnor]

It looks good to me, but I cannot verify the example.
Can you run a query showing the actual data in the range (or absence of the data)?
For example:

SELECT time
FROM metrics_tstz
WHERE time >= '2017-01-01' AND time < '2018-01-01'

Added improved queries, although the fix is for an error that occurred before, not correctness (which should also be covered by existing queries/tests in my understanding). Also, shouldn't the comparison query be time_bucket without gapfill? (Not sure what the value is of showing the raw, non-grouped data, for this bug fix)

[k-rus]

Added improved queries, although the fix is for an error that occurred before, not correctness (which should also be covered by existing queries/tests in my understanding). Also, shouldn't the comparison query be time_bucket without gapfill? (Not sure what the value is of showing the raw, non-grouped data, for this bug fix)

@erimatnor I think you missed my point. If I see the data in table for the same range as the test query, I can judge if the test query result is reasonable or not. Thus I suggested to run the query:

SELECT time
FROM metrics_tstz
WHERE time >= '2017-01-01' AND time < '2018-01-01'

Since the query was failing before the fix, the code path wasn't tested and thus it is not strange to pay attention to the correctness of the test result.

[svenklemm]

Having those extra arguments in EXPLAIN looks a bit weird

[erimatnor]

Having those extra arguments in EXPLAIN looks a bit weird

IMO, it was more weird before when the arguments were given in the query but disappeared in the plan.