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