Re: [PATCH] Better logging of COPY queries if log_statement='all' - Mailing list pgsql-hackers

From Stephen Frost
Subject Re: [PATCH] Better logging of COPY queries if log_statement='all'
Date
Msg-id 20161017152452.GW13284@tamriel.snowman.net
Whole thread Raw
In response to Re: [PATCH] Better logging of COPY queries if log_statement='all'  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: [PATCH] Better logging of COPY queries if log_statement='all'  (Aleksander Alekseev <a.alekseev@postgrespro.ru>)
List 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 by date:

Previous
From: Tom Lane
Date:
Subject: Re: [COMMITTERS] pgsql: Replace PostmasterRandom() with a stronger way of generating ran
Next
From: Magnus Hagander
Date:
Subject: Re: [COMMITTERS] pgsql: Replace PostmasterRandom() with a stronger way of generating ran