I have applied a modified version of this patch, attached. I trimmed
down the description of log_lock_waits to be more concise, and moved the
idea of using this to tune deadlock_timeout to the deadlock_timeout
section of the manual.
I will rework this before application to use LOG level.
Your patch has been added to the PostgreSQL unapplied patches list at:
http://momjian.postgresql.org/cgi-bin/pgpatches
It will be applied as soon as one of the PostgreSQL committers reviews
and approves it.
I am a little concerned about a log_* setting that is INFO. I understand
why you used INFO (for log_min_error_messages), but INFO is inconsistent
with the log* prefix, and by default INFO doesn't appear in the log
file.
So, by default, the INFO is going to go to the user terminal, and not to
the
On Mon, 2007-02-26 at 13:34 -0500, Bruce Momjian wrote:
I am a little concerned about a log_* setting that is INFO. I understand
why you used INFO (for log_min_error_messages), but INFO is inconsistent
with the log* prefix, and by default INFO doesn't appear in the log
file.
Yeh, LOG would
Simon Riggs [EMAIL PROTECTED] writes:
Yeh, LOG would be most appropriate, but thats not possible.
You have not given any good reason for that.
log_min_messages allows only DEBUG5, DEBUG4, DEBUG3, DEBUG2, DEBUG1,
INFO, NOTICE and WARNING for non-error states.
I don't think you understand
On Mon, 2007-02-26 at 14:11 -0500, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
Yeh, LOG would be most appropriate, but thats not possible.
You have not given any good reason for that.
The idea of the patch is that it generates a log message which then
invokes
Simon Riggs [EMAIL PROTECTED] writes:
The idea of the patch is that it generates a log message which then
invokes log_min_error_statement so that the SQL statement is displayed.
LOG is not on the list of options there, otherwise I would use it.
As I said, you don't understand how the logging
On Mon, 2007-02-26 at 14:28 -0500, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
The idea of the patch is that it generates a log message which then
invokes log_min_error_statement so that the SQL statement is displayed.
LOG is not on the list of options there, otherwise I would use
Simon Riggs [EMAIL PROTECTED] writes:
On Mon, 2007-02-26 at 14:28 -0500, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
The idea of the patch is that it generates a log message which then
invokes log_min_error_statement so that the SQL statement is displayed.
LOG is not on the list of
On Mon, 2007-02-26 at 14:52 -0500, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
On Mon, 2007-02-26 at 14:28 -0500, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
The idea of the patch is that it generates a log message which then
invokes log_min_error_statement so that the
Simon Riggs wrote:
On Mon, 2007-02-26 at 13:34 -0500, Bruce Momjian wrote:
I am a little concerned about a log_* setting that is INFO. I understand
why you used INFO (for log_min_error_messages), but INFO is inconsistent
with the log* prefix, and by default INFO doesn't appear in the log
Bruce Momjian [EMAIL PROTECTED] writes:
This is not the first GUC that has needed this.
Exactly. I think that we simply made a mistake in the initial
implementation of log_min_error_statement: we failed to think about
whether it should use client or server priority ordering, and the
On Tue, 2007-02-13 at 22:19 -0500, Bruce Momjian wrote:
Simon Riggs wrote:
On Thu, 2006-10-26 at 18:45 -0400, Tom Lane wrote:
Chris Campbell [EMAIL PROTECTED] writes:
Is there additional logging information I can turn on to get more
details? I guess I need to see exactly what locks
On Mon, 2007-02-19 at 19:38 +, Simon Riggs wrote:
On Tue, 2007-02-13 at 22:19 -0500, Bruce Momjian wrote:
Simon Riggs wrote:
On Thu, 2006-10-26 at 18:45 -0400, Tom Lane wrote:
Chris Campbell [EMAIL PROTECTED] writes:
Is there additional logging information I can turn on to get
Simon Riggs wrote:
On Thu, 2006-10-26 at 18:45 -0400, Tom Lane wrote:
Chris Campbell [EMAIL PROTECTED] writes:
Is there additional logging information I can turn on to get more
details? I guess I need to see exactly what locks both processes
hold, and what queries they were running
Tom Lane wrote:
Albe Laurenz [EMAIL PROTECTED] writes:
[ Memo to hackers: why is it that log_min_error_statement = error
isn't the default? ]
To avoid spamming the logs with every failed SQL statement?
Certainly there are people who will turn it off, but that's why it's
configurable.
Bruce Momjian [EMAIL PROTECTED] writes:
Are we ready to set 'log_min_error_statement = error' by default for
8.3?
We already did that in 8.2.
regards, tom lane
---(end of broadcast)---
TIP 5: don't forget to increase your
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Are we ready to set 'log_min_error_statement = error' by default for
8.3?
We already did that in 8.2.
Oh, interesting. Oops again.
--
Bruce Momjian [EMAIL PROTECTED] http://momjian.us
EnterpriseDB
On Thu, 2006-10-26 at 18:45 -0400, Tom Lane wrote:
Chris Campbell [EMAIL PROTECTED] writes:
Is there additional logging information I can turn on to get more
details? I guess I need to see exactly what locks both processes
hold, and what queries they were running when the deadlock
[ Memo to hackers: why is it that log_min_error_statement = error
isn't the default? ]
To avoid spamming the logs with every failed SQL statement?
Yours,
Laurenz Albe
---(end of broadcast)---
TIP 4: Have you searched our list archives?
On Fri, 2006-10-27 at 09:23, Albe Laurenz wrote:
[ Memo to hackers: why is it that log_min_error_statement = error
isn't the default? ]
To avoid spamming the logs with every failed SQL statement?
And it would be hurting applications where query failure is taken as a
valid path (as
Csaba Nagy wrote:
On Fri, 2006-10-27 at 09:23, Albe Laurenz wrote:
[ Memo to hackers: why is it that log_min_error_statement = error
isn't the default? ]
To avoid spamming the logs with every failed SQL statement?
And it would be hurting applications where query failure is taken as a
Albe Laurenz [EMAIL PROTECTED] writes:
[ Memo to hackers: why is it that log_min_error_statement = error
isn't the default? ]
To avoid spamming the logs with every failed SQL statement?
Certainly there are people who will turn it off, but that's why it's
configurable. I've had to answer how
We're getting deadlock error messages in the production database logs
during times of inactivity, where the only other thing using the
database (we think) is the every-15-minutes pg_dump process. There
are still database connections up-and-running from unused Hibernate
Java processes, but
Chris Campbell [EMAIL PROTECTED] writes:
ERROR: deadlock detected
DETAIL: Process 1120 waits for ShareLock on transaction 5847116;
blocked by process 1171.
Process 1171 waits for ExclusiveLock on tuple (6549,28) of relation
37637 of database 37574; blocked by process 1120.
Relation
On Oct 26, 2006, at 17:21, Tom Lane wrote:
And what was 1171 doing? I really doubt that either of these could
have
been pg_dump.
I know that process 1120 is a Java client (Hibernate) running an
UPDATE query, but I have no idea what 1171 is. I doubt that 1171 was
pg_dump, but when we
On Thu, Oct 26, 2006 at 06:11:59PM -0400, Chris Campbell wrote:
On Oct 26, 2006, at 17:21, Tom Lane wrote:
And what was 1171 doing? I really doubt that either of these could
have
been pg_dump.
I know that process 1120 is a Java client (Hibernate) running an
UPDATE query, but I have
Chris Campbell [EMAIL PROTECTED] writes:
Is there additional logging information I can turn on to get more
details? I guess I need to see exactly what locks both processes
hold, and what queries they were running when the deadlock occurred?
Is that easily done, without turning on logging
Tom Lane wrote:
[ Memo to hackers: why is it that log_min_error_statement = error
isn't the default? ]
I think it default to panic because it's the way to disable the feature,
which was the easiest sell when the feature was introduced. I'm all for
lowering it to error.
--
Alvaro Herrera
On Oct 26, 2006, at 18:45, Tom Lane wrote:
log_min_error_statement = error would at least get you the statements
reporting the deadlocks, though not what they're conflicting against.
Would it be possible (in 8.3, say) to log the conflicting backend's
current statement (from
30 matches
Mail list logo
