From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Vik Fearing <vik(at)2ndquadrant(dot)fr> |
Cc: | Gilles Darold <gilles(dot)darold(at)dalibo(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Patch to implement pg_current_logfile() function |
Date: | 2016-11-02 02:06:52 |
Message-ID: | 31597.1478052412@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Vik Fearing <vik(at)2ndquadrant(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | David Rowley | 2016-11-02 02:21:28 | Re: Performance improvement for joins where outer side is unique |
Previous Message | Robert Haas | 2016-11-02 01:09:18 | Re: Hash Indexes |