Re: Patch to implement pg_current_logfile() function

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Patch to implement pg_current_logfile() function
Дата
Msg-id 31597.1478052412@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Patch to implement pg_current_logfile() function  (Vik Fearing <vik@2ndquadrant.fr>)
Список pgsql-hackers
Vik Fearing <vik@2ndquadrant.fr> writes:
> I'm really late to this discussion, and I apologize for that; but I'm
> wondering why we're doing all this through some random file on disk.

Well, the log collector is intentionally not connected to very much.

> Why not just use the stats collector and have everything we'd want in a
> pg_stat_logger view just like we have for pg_stat_archiver and others?

This would, at minimum, require the log collector process to not start
until after the stats collector (so that it could be connected to the
stats collector's input socket).  But perhaps more to the point, it
establishes the stats collector as infrastructure for the log collector,
which seems pretty backwards.  It's not totally out of the question that
that could result in a deadlock --- stats collector trying to write to
the log while log collector is trying to write to the stats socket,
and both getting blocked.  Also, this doesn't seem like the sort of
info that people would be okay with having the stats collector drop
under load.

I have to agree that the intermediate disk file is kind of ugly.
But passing this info through the stats collector is not better.
        regards, tom lane



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: Hash Indexes
Следующее
От: David Rowley
Дата:
Сообщение: Re: Performance improvement for joins where outer side is unique