stats_temp_directory conflicts

From: Noah Misch <noah(at)leadboat(dot)com>
To: Andrew Dunstan <andrew(dot)dunstan(at)2ndquadrant(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org
Subject: stats_temp_directory conflicts
Date: 2018-12-31 00:28:15
Message-ID: 20181231002815.GB187973@gust.leadboat.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sun, Dec 30, 2018 at 10:32:31AM -0500, Andrew Dunstan wrote:
> On 12/30/18 12:53 AM, Noah Misch wrote:
> > stats_temp_directory = '/cygdrive/w/lorikeet/HEAD'

> > 2. stats_temp_directory is incompatible with TAP suites that start more than
> > one node simultaneously.

> > It's already a problem for "make -j check-world".

> lorikeet is putting the stats_temp directory on a ramdisk. This is worth
> testing in any case, but in lorikeet's case was done to help speed up
> the tests. When I had a Raspberry Pi instance I did something similar,
> for the same reason.

I, too, value the ability to override stats_temp_directory for test runs. (I
get stats.sql failures at high load, even on a high-performance machine.
Using stats_temp_directory may fix that.)

> The obvious quick fix would be to have PostgresNode.pm set this to the
> default after inserting the TEMP_CONFIG file.

True.

> There are a couple of problems here that bear further consideration.
> First, that the stats_temp_directory has to exist, and second that there
> is no convenient way to make it unique. It would be nice if a) the
> directory could be created if it didn't exist and b) some place-holder
> in the name could be replaced by a unique identifier such as the node
> id. If there is interest I'll work on these. One problem I foresee is
> that it might lead to a plethora of stats temp directories being left
> around. Still thinking about how we should deal with that. In the
> buildfarm client I'd be tempted to create a directory to hold all the
> run's stats_temp_directories and then clean it up at the end of the run.

I'm thinking the server should manage this; during startup, create
$stats_temp_directory/PostgreSQL.$postmaster_pid and store each stats file
therein. Just before creating that directory, scan $stats_temp_directory and
delete subdirectories that no longer correspond to live PIDs. Subdirectories
would not build up over time, even if one deletes a test data directory while
its subdirectory of stats_temp_directory still exists. For non-test
applications, this makes stats_temp_directory safer to use. Today, we don't
detect two clusters using the same stats_temp_directory. We don't even
document that it's unacceptable. This makes it acceptable.

Thanks,
nm

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2018-12-31 00:47:05 Re: stats_temp_directory conflicts
Previous Message Peter Eisentraut 2018-12-30 21:25:56 Re: [PATCH] Change "checkpoint starting" message to use "wal"