Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lKJz3-0004SD-Hh for pgsql-bugs@arkaria.postgresql.org; Thu, 11 Mar 2021 12:00:05 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1lKJz2-0003DI-9y for pgsql-bugs@arkaria.postgresql.org; Thu, 11 Mar 2021 12:00:04 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lKJz1-0003D9-T0 for pgsql-bugs@lists.postgresql.org; Thu, 11 Mar 2021 12:00:03 +0000 Received: from mail-pf1-x42f.google.com ([2607:f8b0:4864:20::42f]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1lKJyv-000556-9l for pgsql-bugs@lists.postgresql.org; Thu, 11 Mar 2021 12:00:02 +0000 Received: by mail-pf1-x42f.google.com with SMTP id y13so10889426pfr.0 for ; Thu, 11 Mar 2021 03:59:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=+Mh52dL2r12OceDBDnmnAbH/rtlHY9p9BPkB5DWLhpY=; b=gPJiSee/boUYeqN3gQBasFbk2Q3NxC9tDGoUINEEGkpPm+tiSa9rVbc+kHxGJHQkiy 6qNKX01nr99dRzJCCDRZwcjBV2WoFz5jEdb4V3Xy+lrVuXpuMDCCegcoogz5/r+WMBlE yphmqNwoXdg1Nj8XihkVPBgTdE4FjBqhdGdqXO4NZkt2KyR4cP4WpBCSC/tg0yWd368Z VP/WHC6RORUMQmeyYdOOdJHHdzRZg7HtBCfxEG46J6/iNuhzJK/TGwHLrQGdXUV2ucO3 W1iMCcvZT+7g9cv1pVMKdHkChXSUs5cfXDGiCOGh6smGecbre0huB9g9etvz1sO2Y/2t 301g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=+Mh52dL2r12OceDBDnmnAbH/rtlHY9p9BPkB5DWLhpY=; b=aCxjNJvSsqI8XT+vh/5yk2bBlRB5GR5tcxKDt+Bm+jGm1K0B73kXdEfp9MNR9K9b+5 jJr8aiM5NlbhnQuL9mmHqPFEBT9R2cGcIrjz2/9AC5OIy1JS4WQI9lT7PHUUTnA2zBBh mpo0iCWWazg0oYggVkORb/HPgbesUETSsbAIokbfliIEuZsmACQut4J3diTVyByitnye neuBKtSTVOJ5QbS6q9AhtoQ8p/BhjI/z+huyYo21wZfAIigyijUurp5KI67cX60gVX8B HZaW0ZX/71MGPd925qRLX+EtEdVRG5DwF5KN6NAJhQKXwVExNnTupGLgwqFVPoMr/JLf Sugg== X-Gm-Message-State: AOAM531jCrswei2bH7VETmgKrewaZnFIxdLDNQVPu4HgiqCre0S4CwRp WKvUGzuNmp7g0EVm9YCJC2Q= X-Google-Smtp-Source: ABdhPJx36+4IpGUkZKMQlxavcXP8nNX/9cS+x5eDn6y2F3OnIrTW7DQgRlQ64z8cJFnh/qiV6jiTzA== X-Received: by 2002:a63:f055:: with SMTP id s21mr7109379pgj.293.1615463995959; Thu, 11 Mar 2021 03:59:55 -0800 (PST) Received: from nol (2001-b011-0008-97ef-7556-9f0a-3bbb-1260.dynamic-ip6.hinet.net. [2001:b011:8:97ef:7556:9f0a:3bbb:1260]) by smtp.gmail.com with ESMTPSA id v2sm2201275pjg.34.2021.03.11.03.59.54 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 11 Mar 2021 03:59:55 -0800 (PST) Date: Thu, 11 Mar 2021 20:00:26 +0800 From: Julien Rouhaud To: Alex Cc: pgsql-bugs@lists.postgresql.org Subject: Re: Invalid idle_in_transaction_session_timeout data type Message-ID: <20210311120026.lf3cs332xvhm7qna@nol> References: <11783b8644ae5.7f3aa1e3b18b4.ref@yahoo.com> <11783b8644ae5.7f3aa1e3b18b4@yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <11783b8644ae5.7f3aa1e3b18b4@yahoo.com> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Thu, Mar 11, 2021 at 10:48:21AM +0000, Alex wrote: > Documentation https://www.postgresql.org/docs/13/runtime-config-client.html > shows that > `idle_in_transaction_session_timeout` is integer, bug you can set text > values '30s' and `show idle_in_transaction_session_timeout` returns `30s` > not an integer. > Documentation should be updated to include this data field format. The documentation is correct. This parameter has a unit and you can therefore use that unit for a better readability. There's a mention of that on the setting documentation: If this value is specified without units, it is taken as milliseconds. A value of zero (the default) disables the timeout. If you want to get the stored value, without unit, you can use SELECT setting FROM pg_settings WHERE name = 'guc_name'; For more details on how unit for GUC works, see the documentation at https://www.postgresql.org/docs/current/config-setting.html: Numeric with Unit: Some numeric parameters have an implicit unit, because they describe quantities of memory or time. The unit might be bytes, kilobytes, blocks (typically eight kilobytes), milliseconds, seconds, or minutes. An unadorned numeric value for one of these settings will use the setting's default unit, which can be learned from pg_settings.unit. For convenience, settings can be given with a unit specified explicitly, for example '120 ms' for a time value, and they will be converted to whatever the parameter's actual unit is. Note that the value must be written as a string (with quotes) to use this feature.