Re: danger of stats_temp_directory = /dev/shm - Mailing list pgsql-hackers

From Tom Lane
Subject Re: danger of stats_temp_directory = /dev/shm
Date
Msg-id 28615.1376943157@sss.pgh.pa.us
Whole thread Raw
In response to Re: danger of stats_temp_directory = /dev/shm  (Andres Freund <andres@2ndquadrant.com>)
List pgsql-hackers
Andres Freund <andres@2ndquadrant.com> writes:
> On 2013-08-19 15:51:16 -0400, Tom Lane wrote:
>> Yeah, the stats temp directory will act pretty much the same way: there
>> will be an interval where backends might not get the most up-to-date data,
>> but it's not clear that it's worth the trouble to get it to be more nearly
>> synchronous.

> Won't it possibly cause stats being entirely lost?

How would that happen?  The directory is write-only as far as the stats
collector is concerned, no?

Admittedly it might take a long time for it to write out the data again
for some database that wasn't getting any updates.  Possibly it'd be worth
teaching the SIGHUP code segment in the stats collector to check for a
change in the value of stats_temp_directory and schedule write-out for all
databases if that happens.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Andrew Gierth
Date:
Subject: Re: UNNEST with multiple args, and TABLE with multiple funcs
Next
From: Christophe Pettus
Date:
Subject: ereport documentation patch