Eric Comeau writes:
> Okay - I'm starting to see other stmts other than just commits taking
> longer than 5 secs sometimes as well now - stress test has been running
> for 3 days now...some commits 17 and 15 secs ouch...
If it's not just commits then some of the stranger theories go away.
I thi
On 10-10-18 11:02 AM, Tom Lane wrote:
Mladen Gogala writes:
Tom Lane wrote:
My guess would be overstressed disk subsystem. A COMMIT doesn't require
much except fsync'ing the commit WAL record down to disk ...
Doesn't the "commit" statement also release all the locks held by the
transaction
Mladen Gogala writes:
> Tom Lane wrote:
>> My guess would be overstressed disk subsystem. A COMMIT doesn't require
>> much except fsync'ing the commit WAL record down to disk ...
> Doesn't the "commit" statement also release all the locks held by the
> transaction?
Yeah, and there's a nontriv
Tom Lane wrote:
My guess would be overstressed disk subsystem. A COMMIT doesn't require
much except fsync'ing the commit WAL record down to disk ...
Doesn't the "commit" statement also release all the locks held by the
transaction?
--
Mladen Gogala
Sr. Oracle DBA
1500 Broadway
New York, N
Eric Comeau writes:
> 2010-10-16 05:55:52 EDT [6334]: [1-1] LOG: duration: 5572.517 ms
> statement: EXECUTE [PREPARE: COMMIT]
> 2010-10-16 06:06:24 EDT [26856]: [1-1] LOG: duration: 5617.866 ms
> statement: EXECUTE [PREPARE: COMMIT]
> 2010-10-16 06:06:24 EDT [20740]: [13-1] LOG: duratio
We currently have
log_min_duration_statement = 5000
and are seeing statements like the following logged
2010-10-16 05:55:52 EDT [6334]: [1-1] LOG: duration: 5572.517 ms
statement: EXECUTE [PREPARE: COMMIT]
2010-10-16 06:06:24 EDT [26856]: [1-1] LOG: duration: 5617.866 ms
statement: EXE
