On lör, 2011-07-16 at 21:55 +0300, Heikki Linnakangas wrote:
> I think I would prefer something like this:
>
> ERROR: could not serialize access due to read/write dependencies
> among
> transactions
> DETAIL: Reason code: %s
> HINT: The transaction might succeed if retried.
I've done it this
Alvaro Herrera writes:
> Excerpts from Peter Eisentraut's message of vie jul 29 14:46:20 -0400 2011:
>> On lör, 2011-07-16 at 21:55 +0300, Heikki Linnakangas wrote:
>> Do you have an idea how to address this case:
> Call sprintf to expand the %u before ereport()?
That sounds like way too much w
Excerpts from Peter Eisentraut's message of vie jul 29 14:46:20 -0400 2011:
> On lör, 2011-07-16 at 21:55 +0300, Heikki Linnakangas wrote:
> > I think I would prefer something like this:
> >
> > ERROR: could not serialize access due to read/write dependencies
> > among
> > transactions
> > DETAI
On lör, 2011-07-16 at 21:55 +0300, Heikki Linnakangas wrote:
> I think I would prefer something like this:
>
> ERROR: could not serialize access due to read/write dependencies
> among
> transactions
> DETAIL: Reason code: %s
> HINT: The transaction might succeed if retried.
>
> Where %s gets t
Excerpts from Peter Eisentraut's message of mié jul 27 16:19:22 -0400 2011:
> On lör, 2011-07-16 at 15:01 -0400, Tom Lane wrote:
> > Well, as I mentioned in the commit message, I've thought for some time
> > that there were use cases for errdetail_internal. Whether these
> > particular places in p
On lör, 2011-07-16 at 21:55 +0300, Heikki Linnakangas wrote:
> I find it strange to simply leave those strings untranslated. It's
> going
> to look wrong, like someone just forgot to translate them. However, I
> agree it's perhaps a bit too much detail to translate all of those
> messages, and t
On lör, 2011-07-16 at 15:01 -0400, Tom Lane wrote:
> Well, as I mentioned in the commit message, I've thought for some time
> that there were use cases for errdetail_internal. Whether these
> particular places in predicate.c use it or not doesn't affect that.
Looking at commit 1af37ec96d97722aeb5
Heikki Linnakangas writes:
> I think I would prefer something like this:
> ERROR: could not serialize access due to read/write dependencies among
> transactions
> DETAIL: Reason code: %s
> HINT: The transaction might succeed if retried.
> That's my 2c, anyway. I see you committed this already
On 16.07.2011 03:14, Tom Lane wrote:
"Kevin Grittner" writes:
OK, after getting distracted by test failures caused by an unrelated
commit, I've confirmed that this passes my usual tests. I don't
know anything about the tools used for extracting the text for the
translators, so if that needs an
"Kevin Grittner" writes:
> Tom Lane wrote:
>> You did miss some places that ought to be updated (mumble
>> sources.sgml mumble)
> Sorry I missed that; sources.sgml covered with the attached.
Oh, I'd already fixed that locally, but thanks. Patch is committed now.
regar
Tom Lane wrote:
> "Kevin Grittner" writes:
>> OK, after getting distracted by test failures caused by an
>> unrelated commit, I've confirmed that this passes my usual tests.
>> I don't know anything about the tools used for extracting the text
>> for the translators, so if that needs any correspo
"Kevin Grittner" writes:
> OK, after getting distracted by test failures caused by an unrelated
> commit, I've confirmed that this passes my usual tests. I don't
> know anything about the tools used for extracting the text for the
> translators, so if that needs any corresponding adjustment, some
"Kevin Grittner" wrote:
> Alvaro Herrera wrote:
>> Excerpts from Tom Lane's message:
>>
>>> I think that Peter's real concern is whether these are worth
>>> translating, and I share that doubt. Perhaps we should invent
>>> an errdetail_internal, parallel to errmsg_internal, that works
>>> like
Alvaro Herrera wrote:
> Excerpts from Tom Lane's message:
>
>> I think that Peter's real concern is whether these are worth
>> translating, and I share that doubt. Perhaps we should invent an
>> errdetail_internal, parallel to errmsg_internal, that works like
>> errdetail but doesn't treat the m
Excerpts from Tom Lane's message of vie jul 15 14:33:34 -0400 2011:
> I think that Peter's real concern is whether these are worth
> translating, and I share that doubt. Perhaps we should invent an
> errdetail_internal, parallel to errmsg_internal, that works like
> errdetail but doesn't treat th
Robert Haas writes:
> On Jul 15, 2011, at 12:06 PM, "Kevin Grittner"
> wrote:
>> I have a suspicion that we might sometimes find the information
>> conveyed by the detail useful when responding to users with
>> questions; but the language as it stands seems confusing for users.
> I think removi
On Jul 15, 2011, at 12:06 PM, "Kevin Grittner"
wrote:
> I have a suspicion that we might sometimes find the information
> conveyed by the detail useful when responding to users with
> questions; but the language as it stands seems confusing for users.
I think removing info here or making it hard
Peter Eisentraut wrote:
> Some of these new error messages from the SSI code are a mouthful:
>
> not enough elements in RWConflictPool to record a rw-conflict
> not enough elements in RWConflictPool to record a potential
> rw-conflict
>
> These are basically "out of shared memory"
Some of these new error messages from the SSI code are a mouthful:
not enough elements in RWConflictPool to record a rw-conflict
not enough elements in RWConflictPool to record a potential rw-conflict
These are basically "out of shared memory" conditions that could be
moved to a DETAIL me
19 matches
Mail list logo
