Re: Storing pg_stat_statements query texts externally, pg_stat_statements in core
От | Peter Geoghegan |
---|---|
Тема | Re: Storing pg_stat_statements query texts externally, pg_stat_statements in core |
Дата | |
Msg-id | CAM3SWZStk01Aa5noBea15XrOihRKp0tZOdVwCcZC+wuDQq9zjg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Storing pg_stat_statements query texts externally, pg_stat_statements in core (Peter Geoghegan <pg@heroku.com>) |
Список | pgsql-hackers |
On Tue, Jan 21, 2014 at 8:01 PM, Peter Geoghegan <pg@heroku.com> wrote: >> BTW shouldn't there be an fflush() in qtext_store? > > I don't think so, no. Whenever qtext_store() callers don't fflush() > before releasing their exclusive lock, they FreeFile() before doing so > instead. In the case of pgss_shmem_startup() there is no lock held > anyway, because it doesn't matter, for the same reason it doesn't > matter that we're modifying shmem structures in a way that ordinarily > necessitates an exclusive lock. Why fflush() every qtext_store() call > if there is expected to be more than one, as is the case for several > callers? Having said all that, it occurs to me now that I could have been smarter about where I fflush(). I'm pretty sure pgss_store() should have two fflush() calls. The first can occur with just a shared LWLock held, before the lock strength promotion interim (you probably noticed that I no longer generate a normalized query text in that interim, for reasons that are obvious). The second fflush() may occur only in the very unlikely event of a garbage collection necessitating a new qtext_store() call with an exclusive lock held, a few lines after the first fflush(). No need to fflush() with the exclusive lock the vast majority of the time. -- Peter Geoghegan
В списке pgsql-hackers по дате отправления: