Re: Patch to implement pg_current_logfile() function - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Patch to implement pg_current_logfile() function
Date
Msg-id 31597.1478052412@sss.pgh.pa.us
Whole thread Raw
In response to Re: Patch to implement pg_current_logfile() function  (Vik Fearing <vik@2ndquadrant.fr>)
List 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 by date:

Previous
From: Robert Haas
Date:
Subject: Re: Hash Indexes
Next
From: David Rowley
Date:
Subject: Re: Performance improvement for joins where outer side is unique