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 Tue, Feb 25, 2014 at 1:03 PM, Rajeev rastogi
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 phrase
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
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
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 h
On Mon, Feb 3, 2014 at 8:53 PM, Christian Kruse
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 reques
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
On 3 February 2014 10:06, Christian Kruse 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
>> >> message s
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 Sat, Feb 1, 2014 at 7:41 PM, Christian Kruse
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 ...]
>> L
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
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
>> "errdetail_log_plural".
>> > Plea
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 re
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 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, le
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 b/src/backend/stora
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_plur
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
Christian Kruse 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
> errorcontext(nge
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 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
> > nge
Alvaro Herrera 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 break the compiler's
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,
> (
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: B
On 22 January 2014 04:42, Rajeev rastogi 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 (show_pids_in_lock_log.p
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):
>
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
(
On 30 December 2013 19:52, Christian Kruse 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 Development, 24x7 Support, Train
27 matches
Mail list logo