pg.ddx.io  pgsql-bugs@postgresql.org mailing list archive  

help / color / mirror / Atom feed
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andres Freund <andres@anarazel.de>
Cc: Laetitia Avrot <laetitia.avrot@gmail.com>
Cc: Peter Eisentraut <peter@eisentraut.org>
Cc: Japin Li <japinli@hotmail.com>
Cc: David G. Johnston <david.g.johnston@gmail.com>
Cc: John Naylor <john.naylor@enterprisedb.com>
Cc: PostgreSQL mailing lists <pgsql-bugs@lists.postgresql.org>
Subject: Re: Statistics updates is delayed when using `commit and chain`
Date: Mon, 01 Aug 2022 13:22:35 -0400
Message-ID: <1856493.1659374555@sss.pgh.pa.us> (raw)
In-Reply-To: <20220801171051.vxnit2t6soddaquh@awork3.anarazel.de>
References: <CAKFQuwaTDMYW0v2cv+CxLfnyJ_OAh=Pc0YKvD8f3xc3DtB_LHQ@mail.gmail.com>
	<CAKFQuwZSi6vWEUtZKQhqzHj8FeWtgon=HJ-BGLfpRwjErpwKGw@mail.gmail.com>
	<MEYP282MB16691F2B962B05BB1AC5C151B6139@MEYP282MB1669.AUSP282.PROD.OUTLOOK.COM>
	<CAB_COdjhzA+9URWOekr3s=J-+kMsUQDcjae2rF00Z5X-jDKzuA@mail.gmail.com>
	<MEYP282MB16691A6E80DF769F04BF9EB0B6E99@MEYP282MB1669.AUSP282.PROD.OUTLOOK.COM>
	<CAB_COdiHgHsUb7qxftTe9S-fagXr3Xv+Grw5rcdjwvu2pYy1uA@mail.gmail.com>
	<20220801161256.ogcacmw6txiecvfb@awork3.anarazel.de>
	<1839632.1659371158@sss.pgh.pa.us>
	<20220801164004.kybukw4j3svgcv54@awork3.anarazel.de>
	<1845220.1659372203@sss.pgh.pa.us>
	<20220801171051.vxnit2t6soddaquh@awork3.anarazel.de>

Andres Freund <andres@anarazel.de> writes:
> On 2022-08-01 12:43:23 -0400, Tom Lane wrote:
>> Yeah.  I think we'd need to get rid of the "bool force" argument
>> of pgstat_report_stat, and instead have it manage things internally
>> based on understanding whether the current process uses a reporting
>> timeout timer or not (if not, always send the report right away).

> It's not as simple as looking at the backend type, I think. We'd not want to
> enable a timer in the commit-and-chain context, even in a normal backend -
> there's no chance we'll go idle.

No, but that's not the point.  During CommitTransaction we should check
to see if it's more than X amount of time since our last stats report,
and if so send a new one.  No timer interaction involved there.  When
we go idle, if not inside a transaction and a report needs to be sent,
then compute the wait time till it should be sent and set a timer for
that.

> I wonder if it was the wrong call to use timers for IdleSessionTimeout,
> IdleInTransactionSessionTimeout and pgstats. We always use nonblocking socket
> IO these days, so perhaps we should instead just compute a relevant timeout
> for the WaitEventSetWait() call?

Meh.  I think that that would end up with duplicative logic and
duplicative gettimeofday calls, unless your idea is to get rid of
the timeout.c facilities altogether.

			regards, tom lane





view thread (29+ messages)  latest in thread

Message-ID: <1856493.1659374555@sss.pgh.pa.us>
Permalink:  ../1856493.1659374555@sss.pgh.pa.us/
Also on:    postgresql.org/message-id/1856493.1659374555@sss.pgh.pa.us

 · 

reply
Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-bugs@postgresql.org
  Cc: tgl@sss.pgh.pa.us, andres@anarazel.de, laetitia.avrot@gmail.com, peter@eisentraut.org, japinli@hotmail.com, david.g.johnston@gmail.com, john.naylor@enterprisedb.com, pgsql-bugs@lists.postgresql.org
  Subject: Re: Statistics updates is delayed when using `commit and chain`
  In-Reply-To: <1856493.1659374555@sss.pgh.pa.us>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox