"Kevin Grittner" writes:
> Tom Lane wrote:
>> "Kevin Grittner" writes:
>>> That "F0" class looks suspicious; are those really defined by
>>> standard or did we encroach on standard naming space with
>>> PostgreSQL-specific values?
>> I think we screwed up on that :-(. So we ought to renumber t
Tom Lane wrote:
> "Kevin Grittner" writes:
>> That "F0" class looks suspicious; are those really defined by
>> standard or did we encroach on standard naming space with
>> PostgreSQL-specific values?
>
> I think we screwed up on that :-(. So we ought to renumber those
> codes anyway. Perhaps u
"Kevin Grittner" writes:
> That "F0" class looks suspicious; are those really defined by standard or
> did we encroach on standard naming space with PostgreSQL-specific
> values?
I think we screwed up on that :-(. So we ought to renumber those
codes anyway. Perhaps use "PF" instead of "F0"?
Tom Lane wrote:
> My guess is that all the ones defined in the SQL standard are
> "expected" errors, more or less by definition, and thus not
> interesting according to Peter G's criteria.
On a scan through the list, I didn't see any exceptions to that,
except for the "F0" class. To restate w
Peter Eisentraut writes:
> On tis, 2012-05-01 at 20:13 -0400, Tom Lane wrote:
>> I don't deny that we probably need to reclassify a few error cases,
>> and fix some elogs that should be ereports, before this approach would
>> be really workable. My point is that it's *close*, whereas "let's
>> in
On tis, 2012-05-01 at 20:13 -0400, Tom Lane wrote:
> I don't deny that we probably need to reclassify a few error cases,
> and fix some elogs that should be ereports, before this approach would
> be really workable. My point is that it's *close*, whereas "let's
> invent some new error severities"
2012/5/2 Robert Haas :
> On Tue, May 1, 2012 at 4:09 PM, Tom Lane wrote:
>> I continue to maintain that the SQLSTATE is a much better basis for
>> solving this problem. Its categories are already pretty close to
>> what Peter needs: basically, IIUC, he wants to know about classes
>> 53, 58, maybe
On 2 May 2012 01:13, Tom Lane wrote:
> I don't deny that we probably need to reclassify a few error cases, and
> fix some elogs that should be ereports, before this approach would be
> really workable. My point is that it's *close*, whereas "let's invent
> some new error severities" is not close
On May 1, 2012, at 20:05, Robert Haas wrote:
> On Tue, May 1, 2012 at 4:09 PM, Tom Lane wrote:
>> I continue to maintain that the SQLSTATE is a much better basis for
>> solving this problem. Its categories are already pretty close to
>> what Peter needs: basically, IIUC, he wants to know about
Robert Haas writes:
> On Tue, May 1, 2012 at 4:09 PM, Tom Lane wrote:
>> I continue to maintain that the SQLSTATE is a much better basis for
>> solving this problem. Its categories are already pretty close to
>> what Peter needs: basically, IIUC, he wants to know about classes
>> 53, 58, maybe F
On Tue, May 1, 2012 at 4:09 PM, Tom Lane wrote:
> I continue to maintain that the SQLSTATE is a much better basis for
> solving this problem. Its categories are already pretty close to
> what Peter needs: basically, IIUC, he wants to know about classes
> 53, 58, maybe F0, and XX.
This is really
Peter Geoghegan writes:
> There is another advantage to doing this within the core system that I
> have not touched upon, which is that in this way we can expose another
> useful GUC to reduce log noise, beyond log_min_messages.
Yeah, that one is actually a pretty compelling argument. A *lot* of
On 1 May 2012 22:09, Kevin Grittner wrote:
> That doesn't seem necessary or desirable. The thing to do is to
> somewhere define a list of what is "severe". It seems likely that
> different shops may have different opinions on what constitutes a
> "severe" problem, or may have more than a "severe
> -Original Message-
> From: pgsql-hackers-ow...@postgresql.org [mailto:pgsql-hackers-
> ow...@postgresql.org] On Behalf Of Peter Geoghegan
> Sent: Tuesday, May 01, 2012 4:37 PM
> To: Tom Lane
> Cc: Pavel Stehule; PostgreSQL Hackers
> Subject: Re: [HACKERS] propo
Peter Geoghegan wrote:
> The argument could be made that what I've characterised as severe
> (which is, as I've said, not entirely clear-cut) could be deduced
> from SQLSTATE if we were to formalise the "can't happen errors are
> only allowed to use elog()" convention into a hard rule.
That do
On 1 May 2012 21:14, Tom Lane wrote:
> Peter Geoghegan writes:
>> Maybe no one is convinced by any of this, but the fact is that the
>> SQLSTATE argument falls down when one considers that we aren't using
>> it in many cases of errors that clearly are severe.
>
> The reason that argument isn't co
Peter Geoghegan writes:
> Maybe no one is convinced by any of this, but the fact is that the
> SQLSTATE argument falls down when one considers that we aren't using
> it in many cases of errors that clearly are severe.
The reason that argument isn't convincing is that we *are* using a
SQLSTATE for
On 1 May 2012 20:36, Noah Misch wrote:
> I agree that some means to mechanically distinguish these cases would
> constitute a significant boon for admin monitoring. Note, however, that the
> same split appears at other severity levels:
>
> FATAL, routine: terminating connection due to conflict wi
Noah Misch writes:
> I agree that some means to mechanically distinguish these cases would
> constitute a significant boon for admin monitoring. Note, however, that the
> same split appears at other severity levels:
> FATAL, routine: terminating connection due to conflict with recovery
> FATAL,
Excerpts from Noah Misch's message of mar may 01 15:36:22 -0400 2012:
> On Tue, May 01, 2012 at 02:19:16PM +0100, Peter Geoghegan wrote:
> > The first category of error is something that the DBA will often see
> > very frequently. The latter 3 are situations which I'd like to be
> > woken up in t
On Tue, May 01, 2012 at 02:19:16PM +0100, Peter Geoghegan wrote:
> Currently the following informal categories of error are bunched
> together at ERROR severity:
>
> * Integrity constraint violations
> * Very serious situations, like running out of disk space
> * Serious disasters that often relat
On 1 May 2012 17:22, Robert Haas wrote:
> Yeah. I also noticed in my benchmarking that sprintf() seemed to be
> very slow, to the point where I wondered whether we ought to have our
> own minimal version of sprintf() just for error strings.
Which sprintf()? You're probably aware that we already
>
> Yeah. I also noticed in my benchmarking that sprintf() seemed to be
> very slow, to the point where I wondered whether we ought to have our
> own minimal version of sprintf() just for error strings.
>
> Another idea would be to pass a flag indicating whether the context
> that's going to recei
On Tue, May 1, 2012 at 12:02 PM, Pavel Stehule wrote:
>> I have some concerns about the performance cost of this. Now, you may
>> think that this is a dumb thing to be concerned about, but some
>> testing I've done seems to indicate that MOST of the cost of rolling
>> back a subtransaction is the
2012/5/1 Robert Haas :
> On Tue, May 1, 2012 at 8:21 AM, Pavel Stehule wrote:
>> I have to goals for 9.3. First goal is plpgsql_check_function, second
>> goal is enhancing ErrorData and error management to support new
>> fields: COLUMN_NAME, CONSTRAINT_NAME, CONSTRAINT_SCHEMA, SCHEMA_NAME,
>> TABL
On 1 May 2012 14:55, Tom Lane wrote:
> The last time you complained about this I suggested that looking at
> SQLSTATE would resolve most of your concern. Have you pursued that
> angle?
Sure, I did consider that at the time.
I think that a new severity level (equivalent to ERROR in all but
name)
On Tue, May 1, 2012 at 8:21 AM, Pavel Stehule wrote:
> I have to goals for 9.3. First goal is plpgsql_check_function, second
> goal is enhancing ErrorData and error management to support new
> fields: COLUMN_NAME, CONSTRAINT_NAME, CONSTRAINT_SCHEMA, SCHEMA_NAME,
> TABLE_NAME, ROUTINE_NAME, ROUTINE
Peter Geoghegan wrote:
> Currently the following informal categories of error are bunched
> together at ERROR severity:
>
> * Integrity constraint violations
> * Very serious situations, like running out of disk space
> * Serious disasters that often relate to hardware failure, like
> "xlog flu
Peter Geoghegan writes:
> Currently the following informal categories of error are bunched
> together at ERROR severity:
> * Integrity constraint violations
> * Very serious situations, like running out of disk space
> * Serious disasters that often relate to hardware failure, like "xlog
> flush
On 1 May 2012 14:01, Pavel Stehule wrote:
> What I'd also like to see, which is
>> something that I've agitated about in the past without much luck, is
>> for a new severity level, along the lines of a "severe error". The
>> idea of this is to make a representation that the error in question is
>
2012/5/1 Peter Geoghegan :
> On 1 May 2012 13:21, Pavel Stehule wrote:
>> COLUMN_NAME - contains missing or inaccessible column name or empty string
>> CONSTRAINT_NAME - a name of constraint caused error
>> CONSTRAINT_SCHEMA - a name of schema where constraint is defined -
>> usually same as table
On 1 May 2012 13:21, Pavel Stehule wrote:
> COLUMN_NAME - contains missing or inaccessible column name or empty string
> CONSTRAINT_NAME - a name of constraint caused error
> CONSTRAINT_SCHEMA - a name of schema where constraint is defined -
> usually same as table schema in PostgreSQL
> SCHEMA_NA
Hello
I have to goals for 9.3. First goal is plpgsql_check_function, second
goal is enhancing ErrorData and error management to support new
fields: COLUMN_NAME, CONSTRAINT_NAME, CONSTRAINT_SCHEMA, SCHEMA_NAME,
TABLE_NAME, ROUTINE_NAME, ROUTINE_SCHEMA, TRIGGER_NAME and
TRIGGER_SCHEMA
previous disc
33 matches
Mail list logo
