Re: [PATCH] Better logging of COPY queries if log_statement='all'

Поиск
Список
Период
Сортировка
От Stephen Frost
Тема Re: [PATCH] Better logging of COPY queries if log_statement='all'
Дата
Msg-id 20161017152452.GW13284@tamriel.snowman.net
обсуждение исходный текст
Ответ на Re: [PATCH] Better logging of COPY queries if log_statement='all'  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: [PATCH] Better logging of COPY queries if log_statement='all'  (Aleksander Alekseev <a.alekseev@postgrespro.ru>)
Список pgsql-hackers
* Tom Lane (tgl@sss.pgh.pa.us) wrote:
> Andrew Dunstan <andrew@dunslane.net> writes:
> > On 10/17/2016 09:57 AM, Aleksander Alekseev wrote:
> >> Sometimes it's useful to log content of files used in COPY ... TO ... and
> >> COPY ... FROM ... queries. Unfortunately PostgreSQL doesn't allow to do
> >> it, even if log_statement='all'. Suggested patch fixes this.
>
> > I'm not in favor of this, especially if it's not even optional.
>
> I'm not either.  It sounds good when you're looking at toy examples,
> but not when it means repeating gigabytes of COPY data into the log.

This isn't new- I've seen many cases of people happily loading gigabytes
of data via INSERT with log_statement='all' on.  What I don't like is
the idea of springing this change on people.

* Aleksander Alekseev (a.alekseev@postgrespro.ru) wrote:
> I understand your concern. Perhaps we could create and additional
> parameter for enabling/disabling this feature or a new log_statement
> value, or maybe both - i.e. rename log_statement and add a new possible
> value?

Ugh.  Adding more options to log_statement is just an ugly route to go
in, in my view.  We really need a better solution here.

> According to my colleagues it would be very nice to have this feature.
> For instance, if you are trying to optimize PostgreSQL for application
> that uses COPY and you don't have access to or something like this.
> It could also be useful in some other cases.

This use-case doesn't really make much sense to me.  Can you explain it
in more detail?  Is the goal here to replicate all of the statements
that are changing data in the database?

Thanks!

Stephen

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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: [COMMITTERS] pgsql: Replace PostmasterRandom() with a stronger way of generating ran
Следующее
От: Magnus Hagander
Дата:
Сообщение: Re: [COMMITTERS] pgsql: Replace PostmasterRandom() with a stronger way of generating ran