On 01/29/2016 07:00 AM, Edson Richter wrote:
I've set statement timeout in postgresql.conf to 300s.
Now, I have a schema update procedure at application startup I would
like to run without timeout, or with significant larger timeout (let's
say, 1s).
It is possible to change statement timeout
I've set statement timeout in postgresql.conf to 300s.
Now, I have a schema update procedure at application startup I would
like to run without timeout, or with significant larger timeout (let's
say, 1s).
It is possible to change statement timeout at runtime before issuing the
command (fo
Scott Marlowe wrote:
> On Mon, Jul 14, 2008 at 1:02 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
> > "Scott Marlowe" <[EMAIL PROTECTED]> writes:
> >> I just got hoisted by my own petard when a pg_dump failed due to
> >> statement timeout and I didn't notice because I was running the dump
> >> nohup and
On Mon, Jul 14, 2008 at 1:02 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
> "Scott Marlowe" <[EMAIL PROTECTED]> writes:
>> I just got hoisted by my own petard when a pg_dump failed due to
>> statement timeout and I didn't notice because I was running the dump
>> nohup and didn't read the nohup.out file
"Scott Marlowe" <[EMAIL PROTECTED]> writes:
> I just got hoisted by my own petard when a pg_dump failed due to
> statement timeout and I didn't notice because I was running the dump
> nohup and didn't read the nohup.out file to see the errors. It wasn't
> a big deal, the data wasn't critical opera
I just got hoisted by my own petard when a pg_dump failed due to
statement timeout and I didn't notice because I was running the dump
nohup and didn't read the nohup.out file to see the errors. It wasn't
a big deal, the data wasn't critical operational data or anything.
But it got me to thinking
Brian Wipf writes:
On 12-Dec-06, at 4:30 PM, Tom Lane wrote:
"Brendan O'Shea" <[EMAIL PROTECTED]> writes:
We have discovered a situation where the statement_timeout is not =
honored for broken connections. If a connection is in the process of =
returning results to the client and the connect
"Tom Lane" <[EMAIL PROTECTED]>
"Brendan O'Shea" <[EMAIL PROTECTED]> writes:
We have discovered a situation where the statement_timeout is not =
honored for broken connections. If a connection is in the process of =
returning results to the client and the connection is severed (for =
example, n
On Tue, Dec 12, 2006 at 10:41:19PM -0500, Tom Lane wrote:
> "Brendan O'Shea" <[EMAIL PROTECTED]> writes:
> > Is there no way to specify a timeout for the write() to the socket or some
> > other way to abort?
>
> This is really a question to take up with your TCP stack implementors.
> I think it i
"Brendan O'Shea" <[EMAIL PROTECTED]> writes:
> Is there no way to specify a timeout for the write() to the socket or some
> other way to abort?
This is really a question to take up with your TCP stack implementors.
I think it is fundamentally wrong for Postgres to be second-guessing
the network s
On 12-Dec-06, at 4:30 PM, Tom Lane wrote:
"Brendan O'Shea" <[EMAIL PROTECTED]> writes:
We have discovered a situation where the statement_timeout is not =
honored for broken connections. If a connection is in the process
of =
returning results to the client and the connection is severed (for
"Brendan O'Shea" <[EMAIL PROTECTED]> writes:
> We have discovered a situation where the statement_timeout is not =
> honored for broken connections. If a connection is in the process of =
> returning results to the client and the connection is severed (for =
> example, network cable on client is u
We have discovered a situation where the statement_timeout is not honored for
broken connections. If a connection is in the process of returning results to
the client and the connection is severed (for example, network cable on client
is unplugged) then the query continues to run on the server
13 matches
Mail list logo
