On Tue, Feb 25, 2014 at 1:03 PM, Rajeev rastogi
rajeev.rast...@huawei.com wrote:
On 04 February 2014 14:38, Myself wrote:
On 4th February 2014, Christian kruse Wrote:
On 04/02/14 12:38, Fujii Masao wrote:
ISTM that the phrase Request queue is not used much around the
lock.
Using the
Hi,
On 13/03/14 03:27, Fujii Masao wrote:
Committed!
Thank you very much!
Best regards,
--
Christian Kruse http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training Services
pgpkDoVMmXIL4.pgp
Description: PGP signature
On 04 February 2014 14:38, Myself wrote:
On 4th February 2014, Christian kruse Wrote:
On 04/02/14 12:38, Fujii Masao wrote:
ISTM that the phrase Request queue is not used much around the
lock.
Using the phrase wait queue or Simon's suggestion sound better to
at least me.
Thought?
Hi,
On 04/02/14 12:38, Fujii Masao wrote:
ISTM that the phrase Request queue is not used much around the lock.
Using the phrase wait queue or Simon's suggestion sound better to at least
me.
Thought?
Sounds reasonable to me. Attached patch changes messages to the following:
Process holding
On 4th February 2014, Christian kruse Wrote:
On 04/02/14 12:38, Fujii Masao wrote:
ISTM that the phrase Request queue is not used much around the lock.
Using the phrase wait queue or Simon's suggestion sound better to
at least me.
Thought?
Sounds reasonable to me. Attached patch
On Sat, Feb 1, 2014 at 7:41 PM, Christian Kruse
christ...@2ndquadrant.com wrote:
Hi,
On 01/02/14 02:45, Fujii Masao wrote:
LOG: process 33662 still waiting for ShareLock on transaction
1011 after 1000.184 ms
DETAIL: Process holding the lock: 33660. Request queue: 33662.
[... snip
Hi,
On 03/02/14 17:59, Fujii Masao wrote:
Since you added errdetail_log_plural(), ISTM that you need to update
sources.sgml.
[x] Fixed.
While I'm griping, this message isn't even trying to follow the project's
message style guidelines. Detail or context messages are supposed to be
On 3 February 2014 10:06, Christian Kruse christ...@2ndquadrant.com wrote:
Hi,
On 03/02/14 17:59, Fujii Masao wrote:
Since you added errdetail_log_plural(), ISTM that you need to update
sources.sgml.
[x] Fixed.
While I'm griping, this message isn't even trying to follow the project's
Hi Simon,
On 03/02/14 10:43, Simon Riggs wrote:
Singular:
The following process is holding the lock: A. The request queue
consists of: B.
Plural:
Following processes are holding the lock: A, B. The request queue
consists of: C.
Seems too complex. How about this...
Lock
On Mon, Feb 3, 2014 at 8:53 PM, Christian Kruse
christ...@2ndquadrant.com wrote:
Hi Simon,
On 03/02/14 10:43, Simon Riggs wrote:
Singular:
The following process is holding the lock: A. The request queue
consists of: B.
Plural:
Following processes are holding the lock: A, B. The
Hi,
On 01/02/14 02:45, Fujii Masao wrote:
LOG: process 33662 still waiting for ShareLock on transaction
1011 after 1000.184 ms
DETAIL: Process holding the lock: 33660. Request queue: 33662.
[… snip …]
LOG: process 33665 still waiting for ExclusiveLock on tuple (0,4)
of
On Tue, Jan 28, 2014 at 6:39 PM, Rajeev rastogi
rajeev.rast...@huawei.com wrote:
On 28/01/14, Christian Kruse wrote:
I have checked the revised patch. It looks fine to me except one
minor code formatting issue.
In elog.c, two tabs are missing in the definition of function
Hi,
On 27/01/14 11:44, Rajeev rastogi wrote:
I have checked the revised patch. It looks fine to me except one minor code
formatting issue.
In elog.c, two tabs are missing in the definition of function
errdetail_log_plural.
Please run pgindent tool to check the same.
I did, but this
On 28/01/14, Christian Kruse wrote:
I have checked the revised patch. It looks fine to me except one
minor code formatting issue.
In elog.c, two tabs are missing in the definition of function
errdetail_log_plural.
Please run pgindent tool to check the same.
I did, but this reformats
On 23/01/14, Christian Kruse wrote:
Well, is it context or detail? Those fields have reasonably well
defined meanings IMO.
I find the distinction somewhat blurry and think both would be
appropriate. But since I wasn't sure I changed to detail.
If we need errcontext_plural, let's add
On 23/01/14 14:45, Christian Kruse wrote:
Well, is it context or detail? Those fields have reasonably well
defined meanings IMO.
I find the distinction somewhat blurry and think both would be
appropriate. But since I wasn't sure I changed to detail.
If we need errcontext_plural, let's
Hi,
I think you have attached wrong patch.
Hurm. You are right, attached v3, not v4. Sorry.
Best regards,
--
Christian Kruse http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training Services
diff --git a/src/backend/storage/lmgr/proc.c
On 22 January 2014 04:42, Rajeev rastogi rajeev.rast...@huawei.com wrote:
On 31st December 2013, Christian Kruse Wrote:
Hi there,
I created two patches improving the log messages generated by
log_lock_waits. The first patch shows the process IDs holding a lock we
try to acquire
Hi,
On 22/01/14 12:40, Simon Riggs wrote:
1. I find a issue in following scenario:
session 1 with process id X: BEGIN; LOCK TABLE foo IN SHARE MODE;
session 2 with process id Y: BEGIN; LOCK TABLE foo IN EXCLUSIVE
MODE;
session 3 with process id Z: BEGIN; LOCK
Christian Kruse wrote:
I think this could use some more comments -- for instance at the top of
the while loop, explain what's its purpose.
if (deadlock_state == DS_SOFT_DEADLOCK)
ereport(LOG,
Alvaro Herrera alvhe...@2ndquadrant.com writes:
This ngettext() call is repeated four times in the new code, which is a
bit annoying because it's not trivial. I think you could assign the
ngettext() to a char * at the bottom of the loop, and then in the
ereport() calls use it:
Would that not
Hi,
attached you will find a new version of the patch containing more
comments.
On 22/01/14 12:00, Tom Lane wrote:
Alvaro Herrera alvhe...@2ndquadrant.com writes:
This ngettext() call is repeated four times in the new code, which is a
bit annoying because it's not trivial. I think you
Christian Kruse christ...@2ndquadrant.com writes:
However, the real problem here is that you shouldn't be calling ngettext
manually in an ereport context in the first place. There is
infrastructure in place for that, and this isn't using it.
Fixed in attached patch. I changed it from calling
Hi,
On 22/01/14 14:45, Tom Lane wrote:
Well, is it context or detail? Those fields have reasonably well defined
meanings IMO.
I find the distinction somewhat blurry and think both would be
appropriate. But since I wasn't sure I changed to detail.
If we need errcontext_plural, let's add it,
On 31st December 2013, Christian Kruse Wrote:
Hi there,
I created two patches improving the log messages generated by
log_lock_waits. The first patch shows the process IDs holding a lock we
try to acquire (show_pids_in_lock_log.patch), sample output
(log_lock_waits=on required):
On 30 December 2013 19:52, Christian Kruse christ...@2ndquadrant.com wrote:
I created two patches..
Patches are related but separate, so should be tracked on separate
threads. Please add them to the CF app also.
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL
Hi,
On 31/12/13 08:48, Simon Riggs wrote:
I created two patches..
Patches are related but separate, so should be tracked on separate
threads.
[x] Done (in 20131231091244.gb25...@defunct.ch)
Please add them to the CF app also.
[x] Done. I modified the existing commitfest entry
Hi there,
I created two patches improving the log messages generated by
log_lock_waits. The first patch shows the process IDs holding a lock
we try to acquire (show_pids_in_lock_log.patch), sample output
(log_lock_waits=on required):
session 1: BEGIN; LOCK TABLE foo IN SHARE MODE;
session 2:
28 matches
Mail list logo
