On Friday, May 25, 2012 05:19:28 PM Tom Lane wrote:
> Andres Freund writes:
> > On Friday, May 25, 2012 04:03:49 PM Peter Geoghegan wrote:
> >> Where do you suggest the file be written to?
> >
> > One could argue stats_temp_directory would be the correct place.
>
> No, that would be exactly the
On Friday, May 25, 2012, Tom Lane wrote:
> Andres Freund > writes:
> > On Friday, May 25, 2012 04:03:49 PM Peter Geoghegan wrote:
> >> Where do you suggest the file be written to?
>
> > One could argue stats_temp_directory would be the correct place.
>
> No, that would be exactly the *wrong* place
On Friday, May 25, 2012, Peter Geoghegan wrote:
> On 25 May 2012 14:13, Magnus Hagander >
> wrote:
> > Here's a patch that does the two easy fixes:
> > 1) writes the file to a temp file and rename()s it over the main file
> > as it writes down. This removes the (small) risk of corruption because
>
> Why would they want that? PSS only writes the tempfile on shutdown and
> reads it on startup. Unlike pgstats which reads and writes it all the
> time.
Ah, ok! Didn't know that.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via pgsql-hackers mailing list (pgsql-hacker
On Fri, May 25, 2012 at 6:49 PM, Josh Berkus wrote:
> On 5/25/12 8:19 AM, Tom Lane wrote:
>> Andres Freund writes:
>>> On Friday, May 25, 2012 04:03:49 PM Peter Geoghegan wrote:
Where do you suggest the file be written to?
>>
>>> One could argue stats_temp_directory would be the correct plac
On 5/25/12 8:19 AM, Tom Lane wrote:
> Andres Freund writes:
>> On Friday, May 25, 2012 04:03:49 PM Peter Geoghegan wrote:
>>> Where do you suggest the file be written to?
>
>> One could argue stats_temp_directory would be the correct place.
>
> No, that would be exactly the *wrong* place, becaus
Andres Freund writes:
> On Friday, May 25, 2012 04:03:49 PM Peter Geoghegan wrote:
>> Where do you suggest the file be written to?
> One could argue stats_temp_directory would be the correct place.
No, that would be exactly the *wrong* place, because that directory can
be on a RAM disk. We need
Magnus Hagander writes:
> On Fri, May 25, 2012 at 4:09 PM, Tom Lane wrote:
>> Given that pgstats keeps its permanent file in global/, I think the
>> argument that pg_stat_statements should not do likewise is pretty thin.
> Fair enough. As long as the file is unlinked after reading (per my
> patc
On Fri, May 25, 2012 at 4:09 PM, Tom Lane wrote:
> Peter Geoghegan writes:
>> On 25 May 2012 14:13, Magnus Hagander wrote:
>>> I still think we should consider the placement of this file to not be
>>> in the global/ directory, but this is a quick (back-patchable) fix...
>
>> Where do you suggest
Peter Geoghegan writes:
> On 25 May 2012 14:13, Magnus Hagander wrote:
>> I still think we should consider the placement of this file to not be
>> in the global/ directory, but this is a quick (back-patchable) fix...
> Where do you suggest the file be written to?
Given that pgstats keeps its pe
On Friday, May 25, 2012 04:03:49 PM Peter Geoghegan wrote:
> > I still think we should consider the placement of this file to not be
> > in the global/ directory, but this is a quick (back-patchable) fix...
>
> Where do you suggest the file be written to?
One could argue stats_temp_directory would
On 25 May 2012 14:13, Magnus Hagander wrote:
> Here's a patch that does the two easy fixes:
> 1) writes the file to a temp file and rename()s it over the main file
> as it writes down. This removes the (small) risk of corruption because
> of a crash during write
>
> 2) unlinks the file after readi
On Thu, May 24, 2012 at 2:19 PM, Magnus Hagander wrote:
> On Thu, May 24, 2012 at 2:16 PM, Peter Geoghegan
> wrote:
>> On 24 May 2012 12:42, Magnus Hagander wrote:
>>> What actually happens if it tries to repalloc() something huge? palloc
>>> will throw an elog(ERROR), and since this happens du
On Thu, May 24, 2012 at 2:16 PM, Peter Geoghegan wrote:
> On 24 May 2012 12:42, Magnus Hagander wrote:
>> What actually happens if it tries to repalloc() something huge? palloc
>> will throw an elog(ERROR), and since this happens during postmaster
>> startup, are you sure it won't prevent the ser
On 24 May 2012 12:42, Magnus Hagander wrote:
> What actually happens if it tries to repalloc() something huge? palloc
> will throw an elog(ERROR), and since this happens during postmaster
> startup, are you sure it won't prevent the server from starting?
Oh, yes, missed that.
/*
On Thu, May 24, 2012 at 1:36 PM, Peter Geoghegan wrote:
> On 24 May 2012 11:43, Magnus Hagander wrote:
>> In general, should a contrib module really store data in the global/
>> directory? Seems pretty ugly to me...
>
> I think the case could be made for moving pg_stat_statements into
> core, as
On 24 May 2012 11:43, Magnus Hagander wrote:
> In general, should a contrib module really store data in the global/
> directory? Seems pretty ugly to me...
I think the case could be made for moving pg_stat_statements into
core, as an optionally enabled view, like pg_stat_user_functions,
since pg_
If pg_stat_statements is set to store it's data across restarts, it
stores it in global/pg_stat_statements.stat. This causes some
interesting things to happen in combination with a base backup -
namely, if you take a base backup *after* you have restarted th
emaster, the slave will get a snapshot o
18 matches
Mail list logo
