Re: [HACKERS] [PATCHES] log_line_info
On Tue, 09 Mar 2004 10:02:14 -0500, Andrew Dunstan [EMAIL PROTECTED] wrote: After this is applied (fingers crossed) and everyone is happy, I will submit a patch to remove log_timestamp, log_pid and (if we are agreed on it) log_source_port. Is there agreement on removing these 3 config vars? Please don't. Declare them obsolete for 7.5 and remove them in a later release. Servus Manfred ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] [PATCHES] log_line_info
Please don't. Declare them obsolete for 7.5 and remove them in a later release. Nah, just remove them. We've removed, added and changed so many config options and no-one's ever complained... Chris ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] [PATCHES] log_line_info
Christopher Kings-Lynne [EMAIL PROTECTED] writes: Please don't. Declare them obsolete for 7.5 and remove them in a later release. Nah, just remove them. We've removed, added and changed so many config options and no-one's ever complained... I agree with Chris; this would be taking compatibility concerns a bit far. None of these variables are likely to be touched except through postgresql.conf (I don't think we even allow them to be SET interactively). And you can never simply take your old .conf file and plop it down into a new release. regards, tom lane ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] [PATCHES] log_line_info
Tom Lane wrote: I agree with Chris; this would be taking compatibility concerns a bit far. None of these variables are likely to be touched except through postgresql.conf (I don't think we even allow them to be SET interactively). And you can never simply take your old .conf file and plop it down into a new release. Also, I selfishly want to get this out of my hair and move on :-) The docs already state that log_source_port is useless. patch forthcoming soon. cheers andrew ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] [PATCHES] log_line_info
Tom Lane wrote: Christopher Kings-Lynne [EMAIL PROTECTED] writes: Please don't. Declare them obsolete for 7.5 and remove them in a later release. Nah, just remove them. We've removed, added and changed so many config options and no-one's ever complained... I agree with Chris; this would be taking compatibility concerns a bit far. None of these variables are likely to be touched except through postgresql.conf (I don't think we even allow them to be SET interactively). And you can never simply take your old .conf file and plop it down into a new release. And the other reason to remove them is that if you don't, you will get all sorts of confusion about people asking, Which one should I use for pid logging? Looks like both work. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] [PATCHES] log_line_info
Bruce Momjian wrote: Andrew Dunstan wrote: After this is applied (fingers crossed) and everyone is happy, I will submit a patch to remove log_timestamp, log_pid and (if we are agreed on it) log_source_port. I have applied this patch. It will be a great addition to PostgreSQL. Is there agreement on removing these 3 config vars? cheers andrew ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] [PATCHES] log_line_info
Andrew Dunstan [EMAIL PROTECTED] writes: After this is applied (fingers crossed) and everyone is happy, I will submit a patch to remove log_timestamp, log_pid and (if we are agreed on it) log_source_port. Is there agreement on removing these 3 config vars? Now that I look at it, log_source_port does look pretty useless. While you are at it, please clean up the confusion about whether port-remote_host contains the port number or not (IMHO it should never do so; BackendInit() is doing things in the wrong order). regards, tom lane ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] [PATCHES] log_line_info
After this is applied (fingers crossed) and everyone is happy, I will submit a patch to remove log_timestamp, log_pid and (if we are agreed on it) log_source_port. Is there agreement on removing these 3 config vars? There is from me. ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] [PATCHES] log_line_info
Andrew Dunstan wrote: Nice. Only two comments --- does this mean we should remove log_pid? Seems it is now duplicate functionality. Is that the only duplication? Also, I don't see any documention changes in the patch, but I assume you will work on that before final. I will do docs. We could sensibly get rid of log_pid and log_timestamp with my latest patch. I would also suggest getting rid of log_source_port, since there really isn't any reason *not* to log the source port. Do you want me to make those changes in my patch? Or I can leave them for now and we can get rid of them when everyone is happy. I agree, but let's make it a separate patch. Oh, I think we still need log_timestamp for postmaster-generated lines, no? What does log_line_info output for postmaster-generated logs? Also, should we call the option just log_line? Is that clearer, or log_line_prefix? -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] [PATCHES] log_line_info
Bruce Momjian wrote:
Andrew Dunstan wrote:
Nice. Only two comments --- does this mean we should remove log_pid?
Seems it is now duplicate functionality. Is that the only duplication?
Also, I don't see any documention changes in the patch, but I assume you
will work on that before final.
I will do docs. We could sensibly get rid of log_pid and log_timestamp
with my latest patch. I would also suggest getting rid of
log_source_port, since there really isn't any reason *not* to log the
source port. Do you want me to make those changes in my patch? Or I can
leave them for now and we can get rid of them when everyone is happy.
I agree, but let's make it a separate patch.
Oh, I think we still need log_timestamp for postmaster-generated lines,
no? What does log_line_info output for postmaster-generated logs?
I have fixed the postmaster lines issue. There is a new escape %X that
says postmaster and friends stop here.
Example, with log_timestamp = false and log_pid = false and
log_line_info = '%T [%P] %X [EMAIL PROTECTED](%C:%S) %R %I line:%L ' :
2004-02-28 20:24:49 [11154] LOG: database system was shut down at
2004-02-28 20:24:20 EST
2004-02-28 20:24:49 [11154] LOG: checkpoint record is at 0/9D1874
2004-02-28 20:24:49 [11154] LOG: redo record is at 0/9D1874; undo
record is at 0/0; shutdown TRUE
2004-02-28 20:24:49 [11154] LOG: next transaction ID: 467; next OID: 17145
2004-02-28 20:24:49 [11154] LOG: database system is ready
2004-02-28 20:25:30 [11158]
[EMAIL PROTECTED](40413f8a.2b96:2004-02-28 20:25:30) line:1 LOG:
connection received: host=alphonso port=45621
2004-02-28 20:25:30 [11158] [EMAIL PROTECTED](40413f8a.2b96:2004-02-28
20:25:30) alphonso:45621 authentication line:2 LOG: connection
authorized: user=andrew database=blurflx
2004-02-28 20:25:34 [11158] [EMAIL PROTECTED](40413f8a.2b96:2004-02-28
20:25:30) alphonso:45621 idle line:3 LOG: statement: SELECT n.nspname
as Schema,
c.relname as Name,
CASE c.relkind WHEN 'r' THEN 'table' WHEN 'v' THEN 'view' WHEN
'i' THEN 'index' WHEN 'S' THEN 'sequence' WHEN 's' THEN 'special' END as
Type,
u.usename as Owner,
c2.relname as Table
FROM pg_catalog.pg_class c
JOIN pg_catalog.pg_index i ON i.indexrelid = c.oid
JOIN pg_catalog.pg_class c2 ON i.indrelid = c2.oid
LEFT JOIN pg_catalog.pg_user u ON u.usesysid = c.relowner
LEFT JOIN pg_catalog.pg_namespace n ON n.oid = c.relnamespace
WHERE c.relkind IN ('i','')
AND n.nspname NOT IN ('pg_catalog', 'pg_toast')
AND pg_catalog.pg_table_is_visible(c.oid)
ORDER BY 1,2;
2004-02-28 20:25:38 [11158] [EMAIL PROTECTED](40413f8a.2b96:2004-02-28
20:25:30) alphonso:45621 idle line:4 LOG: disconnection: session time:
0:00:08.50 user=andrew database=blurflx host=alphonso:45621
2004-02-28 20:25:44 [11149] LOG: received smart shutdown request
2004-02-28 20:25:44 [11170] LOG: shutting down
2004-02-28 20:25:46 [11170] LOG: database system is shut down
Also, should we call the option just log_line? Is that clearer, or
log_line_prefix?
I floated the name log_line_info a while back and noone objected. I
don't think log_line is any clearer - quite the contrary IMNSHO.
cheers
andrew
---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings
