On Mon, Nov 27, 2023 at 10:40 PM Daniel Gustafsson <dan...@yesql.se> wrote: > > > On 27 Nov 2023, at 14:06, Masahiko Sawada <sawada.m...@gmail.com> wrote: > > > Is it true that we can modify the timeout after creating > > BackgroundPsql object? If so, it seems we don't need to introduce the > > new timeout argument. But how? > > I can't remember if that's leftovers that incorrectly remains from an earlier > version of the BackgroundPsql work, or if it's a very bad explanation of > ->set_query_timer_restart(). The timeout will use the timeout_default value > and that cannot be overridden, it can only be reset per query.
Thank you for confirming this. I see there is the same problem also in
interactive_psql(). So I've attached the 0001 patch to fix these
documentation issues. Which could be backpatched.
> With your patch the timeout still cannot be changed, but at least set during
> start which seems good enough until there are tests warranting more
> complexity.
> The docs should be corrected to reflect this in your patch.
I've incorporated the comments except for the following one and
attached updated version of the rest patches:
On Fri, Sep 29, 2023 at 7:20 PM vignesh C <vignes...@gmail.com> wrote:
> Few comments:
> 1) Should we have some validation for the inputs given:
> +PG_FUNCTION_INFO_V1(consume_xids_until);
> +Datum
> +consume_xids_until(PG_FUNCTION_ARGS)
> +{
> + FullTransactionId targetxid =
> FullTransactionIdFromU64((uint64) PG_GETARG_INT64(0));
> + FullTransactionId lastxid;
> +
> + if (!FullTransactionIdIsNormal(targetxid))
> + elog(ERROR, "targetxid %llu is not normal", (unsigned
> long long) U64FromFullTransactionId(targetxid));
>
> If not it will take inputs like -1 and 999999999999999.
> Also the notice messages might confuse for the above values, as it
> will show a different untilxid value like the below:
> postgres=# SELECT consume_xids_until(999999999999999);
> NOTICE: consumed up to 0:10000809 / 232830:2764472319
The full transaction ids shown in the notice messages are separated
into epoch and xid so it's not a different value. This epoch-and-xid
style is used also in pg_controldata output and makes sense to me to
show the progress of xid consumption.
Once the new test gets committed, I'll prepare a new buildfarm animal
for that if possible.
Regards,
--
Masahiko Sawada
Amazon Web Services: https://aws.amazon.com
v6-0001-fix-wrong-description-of-BackgroundPsql-s-timeout.patch
Description: Binary data
v6-0003-Add-tests-for-XID-wraparound.patch
Description: Binary data
v6-0002-Add-option-to-specify-timeout-seconds-to-Backgrou.patch
Description: Binary data
