elog cleanup

----- Original Message -----
From: "Bruce Momjian" <pgman@candle.pha.pa.us>
Sent: Tuesday, February 19, 2002 12:16 AM

...

! elog(CRASH, "heap_delete_%sdo: no block", (redo) ? "re" : "un");
! elog(CRASH, "heap_delete_%sdo: uninitialized page", (redo) ? "re" : "un");

...

This type of "dynamically constructed" messages is kinda bad for translators,
because the parts one's replacing in the original message could be
translated differently entirely and may not suit in the translations as they do in the originals.
Even if they do, "re" and "un" will never make into the message catalogs, for example.

Maybe it's not so crucial for these specific messages, but for sure won't
work for general type of messages.

Bruce Momjian wrote:

This patch fixes several issues with our elog() handling:

Oh, I forgot to mention that this patch also renumbers the elog values
so they are in increasing order; seemed to make sense.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Serguei Mokhov wrote:

----- Original Message -----
From: "Bruce Momjian" <pgman@candle.pha.pa.us>
Sent: Tuesday, February 19, 2002 12:16 AM

...

! elog(CRASH, "heap_delete_%sdo: no block", (redo) ? "re" : "un");
! elog(CRASH, "heap_delete_%sdo: uninitialized page", (redo) ? "re" : "un");

...

This type of "dynamically constructed" messages is kinda bad for translators,
because the parts one's replacing in the original message could be
translated differently entirely and may not suit in the translations as they do in the originals.
Even if they do, "re" and "un" will never make into the message catalogs, for example.

Maybe it's not so crucial for these specific messages, but for sure won't
work for general type of messages.

This is a good point. I am not too concerned about this case because it
is attempting to match an actual function name. I hope we don't do this
for more general messages. My guess is that we don't, because if we
did, some translator would have complained. :-)

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Bruce Momjian <pgman@candle.pha.pa.us> writes:

[ 100K+ patch ]

If you're going to hit every file in the backend in pursuit of this
idea, *puh-leeze* get it right the FIRST time, rather than subjecting
us all to multiple rounds of break-everyone-else's-patches-in-progress.

Things you did not get right include: where's the PG_ prefix?
And what happened to merging the debug-level mechanism with the
error level codes?

o Add INFO level that prints only to the client
o Add LOG level to print messages only to the server log

I still object strongly to this worldview. The code should not have
a hard-wired concept of which messages are for the client and which
are for the log.

regards, tom lane

Tom Lane wrote:

Bruce Momjian <pgman@candle.pha.pa.us> writes:

[ 100K+ patch ]

If you're going to hit every file in the backend in pursuit of this
idea, *puh-leeze* get it right the FIRST time, rather than subjecting
us all to multiple rounds of break-everyone-else's-patches-in-progress.

Things you did not get right include: where's the PG_ prefix?
And what happened to merging the debug-level mechanism with the
error level codes?

Wow, what encouragement! :-<

See later posting. I didn't want a mammoth patch that no one could
review. I will do the rename at the same time I apply the patch, if
everyone agrees.

o Add INFO level that prints only to the client
o Add LOG level to print messages only to the server log

I still object strongly to this worldview. The code should not have
a hard-wired concept of which messages are for the client and which
are for the log.

OK, I can't come up with a clean solution without hardwiring it. If we
are warning someone about a sequence creation as part of SERIAL, it
makes no sense to send it to the server log, it is informational. The
same goes with database startup messages and checkpoint log file
rotation, which go only to the server logs. I don't see the value in
adding complexity when it isn't needed.

If you want a clean heiarchy, I guess you could put INFO below LOG, and
default the server level to LOG and the client level to INFO. However,
the client is never going to see most LOG message, but it does have the
desired effect that INFO only goes to the client and LOG goes only to
the server (usually). Seems less logical to me because LOG can't go to
the client, but it has the same effect if people prefer that. Actually,
now that I think of it, several LOG message would go to the client. The
old way was to make LOG == DEBUG, but if you do that, then the server
would see all the INFO message because LOG has to be less than INFO; it
gets to be a mess.

Considering the number of people doing elog(), I think saying "Use LOG
for server-only, INFO for client-only, and NOTICE for both" is pretty
clear.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Bruce Momjian <pgman@candle.pha.pa.us> writes:

Wow, what encouragement! :-<

Well, I assumed that you generated this patch with the intention of
applying it promptly. If it was only a basis for discussion, why'd
you go to the effort of creating a 100K+ patch that will be stale in
a few days? It's certainly not useful to aid the discussion: a ten-line
statement of what you wanted to do would've been more helpful. Who's
going to wade through a 100K patch?

In any case, the correct approach would've been to put up a proposal
on pghackers before doing the work. You *know* this is going to be
controversial. More, if it's not highlighted on pghackers then a
lot of people will fail to get the word and we'll be having trouble
with broken patches for a long time to come.

regards, tom lane

Tom Lane wrote:

Bruce Momjian <pgman@candle.pha.pa.us> writes:

Wow, what encouragement! :-<

Well, I assumed that you generated this patch with the intention of
applying it promptly. If it was only a basis for discussion, why'd
you go to the effort of creating a 100K+ patch that will be stale in
a few days? It's certainly not useful to aid the discussion: a ten-line
statement of what you wanted to do would've been more helpful. Who's
going to wade through a 100K patch?

Well, I am making decisions that certain messages to only to the client.
I need people to see those changes.

In any case, the correct approach would've been to put up a proposal
on pghackers before doing the work. You *know* this is going to be
controversial. More, if it's not highlighted on pghackers then a
lot of people will fail to get the word and we'll be having trouble
with broken patches for a long time to come.

I just sent the summary to hackers. Haven't seen any comments either
way so far.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026