Re: danger of stats_temp_directory = /dev/shm

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Andres Freund <andres(at)2ndquadrant(dot)com>
Cc: Josh Berkus <josh(at)agliodbs(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: danger of stats_temp_directory = /dev/shm
Date: 2013-08-19 20:12:37
Message-ID: 28615.1376943157@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Andres Freund <andres(at)2ndquadrant(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Christophe Pettus 2013-08-19 20:40:06 ereport documentation patch
Previous Message Andrew Gierth 2013-08-19 20:04:27 Re: UNNEST with multiple args, and TABLE with multiple funcs