From: | Stephen Frost <sfrost(at)snowman(dot)net> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Aleksander Alekseev <a(dot)alekseev(at)postgrespro(dot)ru> |
Cc: | Andrew Dunstan <andrew(at)dunslane(dot)net>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [PATCH] Better logging of COPY queries if log_statement='all' |
Date: | 2016-10-17 15:24:52 |
Message-ID: | 20161017152452.GW13284@tamriel.snowman.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
* Tom Lane (tgl(at)sss(dot)pgh(dot)pa(dot)us) wrote:
> Andrew Dunstan <andrew(at)dunslane(dot)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(dot)alekseev(at)postgrespro(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Magnus Hagander | 2016-10-17 15:33:50 | Re: [COMMITTERS] pgsql: Replace PostmasterRandom() with a stronger way of generating ran |
Previous Message | Tom Lane | 2016-10-17 15:21:03 | Re: [COMMITTERS] pgsql: Replace PostmasterRandom() with a stronger way of generating ran |