On 08/18/2015 07:11 AM, Tom Lane wrote:
> Adrian Klaver <adrian.klaver@aklaver.com> writes:
>> On 08/18/2015 06:44 AM, Tom Lane wrote:
>>> Adrian Klaver <adrian.klaver@aklaver.com> writes:
>>>> The only thing I can think to do is load pg_stat_statements:
>>>> http://www.postgresql.org/docs/9.4/interactive/pgstatstatements.html
>
>>> That won't help after-the-fact either.
>
>> Well at some point the query will leave the view, but by default
>> pg_stat_statements tracks the last 5000 distinct statements, so you have
>> some time > 0 to find it.
>
> No, you don't have any time to find it, because pg_stat_statements can
> only track operations in backends that it's already been loaded into.
I was not clear enough. The intent was for the OP to load
pg_stat_statements into the remote server and just leave it running. At
that point you have something that replicates(to a degree) log_statement
= 'all' in postgresql.conf without having to remember to turn it on or
off. It imposes an overhead, but that is the case for anything that
tracks history. It up to the user to decide whether the benefit is worth
the cost.
> What's more, it requires shared memory that can only be allocated at
> postmaster start, so that there's really no way to load it without a
> postmaster restart.
>
> regards, tom lane
>
--
Adrian Klaver
adrian.klaver@aklaver.com
