Magnus Hagander wrote:
> On Thu, Aug 6, 2009 at 19:04, Peter Eisentraut wrote:
> > On Thursday 06 August 2009 17:33:40 Tom Lane wrote:
> >> I don't think there'd be much logical difficulty in having an output
> >> field (ie, CSV column or log_line_prefix escape) that represents a
> >> classificatio
On Thu, Aug 6, 2009 at 19:04, Peter Eisentraut wrote:
> On Thursday 06 August 2009 17:33:40 Tom Lane wrote:
>> I don't think there'd be much logical difficulty in having an output
>> field (ie, CSV column or log_line_prefix escape) that represents a
>> classification of the PID, say as "postmaster,
On Thursday 06 August 2009 17:33:40 Tom Lane wrote:
> I don't think there'd be much logical difficulty in having an output
> field (ie, CSV column or log_line_prefix escape) that represents a
> classification of the PID, say as "postmaster, backend, AV worker,
> AV launcher, bgwriter, ...". It wou
Magnus Hagander writes:
> On Thu, Aug 6, 2009 at 16:33, Tom Lane wrote:
>> I don't think there'd be much logical difficulty in having an output
>> field (ie, CSV column or log_line_prefix escape) that represents a
>> classification of the PID, say as "postmaster, backend, AV worker,
>> AV launcher
On Thu, Aug 6, 2009 at 16:33, Tom Lane wrote:
> Magnus Hagander writes:
>> On Thu, Aug 6, 2009 at 16:20, Tom Lane wrote:
>>> Well, it seems like you could get 90% of the way there just by filtering
>>> on the PID --- watching the bgwriter, walwriter, and archiver should
>>> cover this use-case rea
Magnus Hagander writes:
> On Thu, Aug 6, 2009 at 16:20, Tom Lane wrote:
>> Well, it seems like you could get 90% of the way there just by filtering
>> on the PID --- watching the bgwriter, walwriter, and archiver should
>> cover this use-case reasonably well.
> Right. But that's pretty hard to do
On Thu, Aug 6, 2009 at 16:20, Tom Lane wrote:
> Magnus Hagander writes:
>> On Wed, Aug 5, 2009 at 16:11, Heikki
>> Linnakangas wrote:
>>> Would you like to propose a concrete list sources that we would have?
>>> The implementation effort depends a lot on the categorization.
>
>> Well, the only one
Magnus Hagander writes:
> On Wed, Aug 5, 2009 at 16:11, Heikki
> Linnakangas wrote:
>> Would you like to propose a concrete list sources that we would have?
>> The implementation effort depends a lot on the categorization.
> Well, the only one I have a direct usecase for is the one that is "I
> w
On Wed, Aug 5, 2009 at 16:11, Heikki
Linnakangas wrote:
> Magnus Hagander wrote:
>> As for the source, I think we'd just "decorate" the error messages
>> with errsource(ERRSOURCE_USER) or something like that at places where
>> needed, and have it default to "internal" - so we don't have to touch
>>
On Wednesday 05 August 2009 17:45:46 Pavel Stehule wrote:
> SQLCODE could carry enough information about user or system exception.
> There are reserved space for custom codes. Maybe for administration
> should be interesting, if error is system error or application error -
> but this should be desc
2009/8/5 Magnus Hagander :
> Since Alvaro is talking about error messages in another thread, I
> figured I should post this idea now as well.
>
> Something that keeps annoying me a lot when trying to look through
> what comes out of PostgreSQL logs is that errors generated by the user
> (syntax err
Magnus Hagander wrote:
> Something that keeps annoying me a lot when trying to look through
> what comes out of PostgreSQL logs is that errors generated by the user
> (syntax errors in queries, warnings due to incorrect string escaping,
> statements terminated due to timeout etc etc) are intermixed
Magnus Hagander writes:
> I'd like to add another field to messages called "source" (not wedded
> to the name). Initially, this could just be "user" and "internal", but
> I can see a use-case in the future for it to differ between for
> example "archiver" and "bgwriter" (it's certainly not unheard
Since Alvaro is talking about error messages in another thread, I
figured I should post this idea now as well.
Something that keeps annoying me a lot when trying to look through
what comes out of PostgreSQL logs is that errors generated by the user
(syntax errors in queries, warnings due to incorr
14 matches
Mail list logo
