Re: Better way of dealing with pgstat wait timeout during buildfarm runs?

From: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Andres Freund <andres(at)2ndquadrant(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Better way of dealing with pgstat wait timeout during buildfarm runs?
Date: 2014-12-26 22:16:13
Message-ID: 20141226221613.GJ1645@alvh.no-ip.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Tom Lane wrote:

> The argument that autovac workers need fresher stats than anything else
> seems pretty dubious to start with. Why shouldn't we simplify that down
> to "they use PGSTAT_STAT_INTERVAL like everybody else"?

The point of wanting fresher stats than that, eons ago, was to avoid a
worker vacuuming a table that some other worker vacuumed more recently
than PGSTAT_STAT_INTERVAL. I realize now that the semantics we really
want was something like "stats no older than XYZ" where the given value
is the timestamp at which we start checking; if we get anything newer
than that it would be okay, but we currently reject it because of lack
of a more appropriate API. (If it takes more than PGSTAT_STAT_INTERVAL
to get the stats back, a regular backend would ask for fresher stats,
but to an autovac worker they would be good enough as long as they are
newer than its recheck start time.)

Nowadays we can probably disregard the whole issue, since starting a new
vacuum just after the prior one finished should not cause much stress to
the system thanks to the visibility map.

--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Geoghegan 2014-12-27 00:22:55 Re: INSERT ... ON CONFLICT {UPDATE | IGNORE}
Previous Message Tom Lane 2014-12-26 21:56:36 Re: Better way of dealing with pgstat wait timeout during buildfarm runs?