Re: libpq debug log

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: libpq debug log
Дата
Msg-id CA+TgmobviA3E6JH4ohq50FvvL8Lo1=jGKR3t2L196J3CjVeQJg@mail.gmail.com
обсуждение исходный текст
Ответ на RE: libpq debug log  ("Iwata, Aya" <iwata.aya@jp.fujitsu.com>)
Ответы Re: libpq debug log  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
On Thu, Feb 21, 2019 at 7:52 PM Iwata, Aya <iwata.aya@jp.fujitsu.com> wrote:
> > I'm not really sure that I like the design of this patch in any way.
> Aside from problems with my current documentation which I will fix,
> could you explain more detail about the problem of the design?
> I would like to improve my current implementation based from feedback.

Well, I believe that what you've got here is something that could,
perhaps, be occasionally useful.  However, I don't think it would be
useful to very many people very often, and we'd still have to maintain
the code, so that's not a great situation.

We already have a PQtrace() facility that could be improved, and it
has been previously suggested that you work on improving this facility
rather than inventing something new.  I still think that's a good
idea.  Instead you've created a second way of producing similar
information, and then coupled it to very specific ideas about how that
information should be logged: it is triggered by new libpq parameters,
there is log rotation logic, etc.  Those might not be right for
everyone, and there's no flexibility in the mechanism.

I am not sure that it's a good idea to have facilities that write to
the local filesystem that can be triggered by libpq parameters.  Seems
like that might have possible security consequences, or at least annoy
people who want to accept connection strings from users without having
to sanitize them for these sorts of options.

I do sometimes want to know  what's going on at the protocol level.
Sometimes it's possible to use wireshark for that (as mentioned
upthread) and when it isn't, the thing I'd really like is for the
command-line clients that already exist have an option to enable
PQtrace without me having to hack the C code.  We could go through and
add a long-form command-line option, --libpq-trace, to every
command-line tool we ship, for example.  Then we could, as a separate
patch, improve the format of that tracing output.  For me that would
be more useful than this.

I don't necessarily think there's anything deeply wrong with this
approach.  It's not like your patch will bring about the end of
civilization or anything like that.  It just doesn't excite me very
much.  And since I agree that we have a problem in this area, I would
ideally like to have a solution to that problem that I feel excited
about.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


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

Предыдущее
От: Alvaro Herrera
Дата:
Сообщение: Re: partitioned tables referenced by FKs
Следующее
От: "Ideriha, Takeshi"
Дата:
Сообщение: RE: Protect syscache from bloating with negative cache entries