Alexander Kukushkin writes:
> On Wed, 28 Aug 2019 at 04:51, Michael Paquier wrote:
>> note that your patch had a warning as "result" is not needed in
>> run_simple_command().
> Ohh, sorry about that. I compiled the whole source tree and the
> warning was buried down among other output :(
"make
Hi,
Thank you, Michael, for committing it!
On Wed, 28 Aug 2019 at 04:51, Michael Paquier wrote:
> note that your patch had a warning as "result" is not needed in
> run_simple_command().
Ohh, sorry about that. I compiled the whole source tree and the
warning was buried down among other output :(
On Tue, Aug 27, 2019 at 10:45:27AM +0200, Alexander Kukushkin wrote:
> Done, please see the next version attached.
I have made the new error message consistent with run_simple_query to
avoid more work to translators and because it is possible to know
immediately the code path involved thanks to th
On Tue, 27 Aug 2019 at 08:36, Michael Paquier wrote:
> I'd rather be on the safe side and as we are looking at this at this
> area.. Who knows if this logic is going to change in the future and
> how it will change.
Agree.
> Oops, I misread this part. What about a simple wrapper
> run_simple_
On Mon, Aug 26, 2019 at 03:42:46PM +0200, Alexander Kukushkin wrote:
> Well, I was thinking about it and came to the conclusion that we are
> neither taking heavy locks nor explicitly opening a transaction and
> therefore we can avoid changing them.
> But maybe you are right, having them set to the
Hi,
On Mon, 26 Aug 2019 at 06:28, Michael Paquier wrote:
> Alexander, it seems to me that we should also consider lock_timeout
> and idle_in_transaction_session_timeout (new as of 9.6), no? We could
Well, I was thinking about it and came to the conclusion that we are
neither taking heavy locks
On Sun, Aug 25, 2019 at 10:34:29PM +0200, David Fetter wrote:
> I meant to ask whether, in addition to pg_dump and pg_rewind, there
> are other things that should ignore statement_timeout settings.
Sure. Please note that I am not sure if it is worth bothering about
all the code paths which emit S
On Sun, Aug 25, 2019 at 04:30:38PM -0400, Tom Lane wrote:
> David Fetter writes:
> > Is pg_rewind the only thing that this hits?
>
> pg_dump has forced statement_timeout to 0 for ages. If pg_rewind
> is also likely to have a long-running transaction, I don't see any
> good reason for it not to d
David Fetter writes:
> Is pg_rewind the only thing that this hits?
pg_dump has forced statement_timeout to 0 for ages. If pg_rewind
is also likely to have a long-running transaction, I don't see any
good reason for it not to do likewise.
regards, tom lane
On Fri, Aug 23, 2019 at 10:05:02AM +0200, Alexander Kukushkin wrote:
> Hi,
>
> It is quite common to set a global statement_timeout to a few seconds
> (or minutes) in postgresql.conf in order to avoid hitting a production
> server with slow/bad queries.
True!
Is pg_rewind the only thing that thi
Hi,
It is quite common to set a global statement_timeout to a few seconds
(or minutes) in postgresql.conf in order to avoid hitting a production
server with slow/bad queries.
This value is applied to all connections in the system unless it is
redefined per database, user, or explicitly changed in
11 matches
Mail list logo
