On Thu, May 24, 2012 at 1:36 PM, Peter Geoghegan <peter@2ndquadrant.com> wrote:
> On 24 May 2012 11:43, Magnus Hagander <magnus@hagander.net> 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_stat_statements is now rather a lot more useful than it used
> to be. That would solve that problem, as well as putting
> pg_stat_statements into the hands of the largest possible number of
> people, which would be a positive development, in my humble and fairly
> predictable opinion.
Well, it would solve the problem for this specific case - but there
will always be yet another extension. Actually, it would only solve
the *ugliness*, and not the actual problem.
(That's not to say tha tI don't agree that moving it into core would
be a good idea, but that's not happening for 9.2 - and the problem
exists in 9.1 as well)
> However, pg_stat_statements will not prevent the database from
> starting if the file is corrupt. It makes some basic attempts to
> detect that within pgss_shmem_startup(), and will simply log the
> problem and unlink the file in the event of detecting corruption.
> Otherwise, I suppose you might get garbage values in
> pg_stat_statements, which, while rather annoying and possibly
> unacceptable, is hardly the end of the world.
Ok. I was worried it might crash on loading the data when it was
corrupt - say a size field that ended up specifying gigabytes that it
then tries to allocate, or something like that.
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?
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
