Re: [PATCHES] [HACKERS] Point in Time Recovery
On Wed, 21 Jul 2004, Tom Lane wrote: Hi Tom, Simon doesn't mean the recovery part. Instead he means the normal startup of the server. It has to be absolutely clear (in the logfile!) if the server was started in archive mode or not. Otherwise you always have to guess. On server startup there should to be a message like LOG: Database started in archive mode or LOG: Archive mode is DISABLED To get the users attention. Greetings, Klaus Simon Riggs [EMAIL PROTECTED] writes: A more important omission is the deletion of a message to indicate that the server is acting in archive_modeso there's no visual clue in the log to warn an admin that its been turned off now or incorrectly specified (by somebody else, of course). (At least using the default log mode). Hmm, we are apparently not reading the same code. My copy shows LOG: starting archive recovery LOG: restore_command = cp /home/postgres/testversion/archive/%f %p ... blah blah ... LOG: archive recovery complete Which part of this is insufficiently clear? regards, tom lane -- Full Name : Klaus Naumann | (http://www.mgnet.de/) (Germany) Phone / FAX : ++49/177/7862964 | E-Mail: ([EMAIL PROTECTED]) ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [PATCHES] logfile subprocess and Fancy File Functions
Bruce Momjian wrote:
Andreas Pflug wrote:
OK, new idea. Forget about modifying pg_dir_ls(). Instead add
pg_file_stat the returns the file size, times. You can then easily use
that for file size and times. Also, if you want, add an is_dir boolean
so people can write functions that walk the directory tree.
I now replaced pg_logfile_length, instead pg_logfile_stat(text) will
return a record (len int8, ctime timestamp, atime timestamp, mtime
timestamp, isdir bool).
For convenience, I'd like to have the function
CREATE FUNCTION pg_file_length(text) RETURNS int8
AS
$BODY$
SELECT len
FROM pg_file_stat($1) AS stat
(len int8, ctime timestamp,
atime timestamp, mtime timestamp, isdir bool)
$BODY$ LANGUAGE SQL STRICT;
Where is the right place to put it?
Also, I wonder how to join pg_file_stat and pg_dir_ls to get a ls -l
like listing. Apparently I can't do that, unless I don't code pg_dir_ls
as returning records too, right?
I noticed we had a big logging discussion during 7.4 beta about logging
and log rotation. This patch is clearly superior to the ideas we had at
that time.
Currently, the discussion circles around file functions, not logging. If
you think that part is clean, how about committing it separately so it
can be tested/used (no problem if pg_logfile_rotate() isn't available
right from the start). I'll supply docs RSN.
Regards,
Andreas
Index: src/backend/catalog/system_views.sql
===
RCS file: /projects/cvsroot/pgsql-server/src/backend/catalog/system_views.sql,v
retrieving revision 1.6
diff -u -r1.6 system_views.sql
--- src/backend/catalog/system_views.sql 26 Apr 2004 15:24:41 - 1.6
+++ src/backend/catalog/system_views.sql 21 Jul 2004 09:49:22 -
@@ -273,3 +273,8 @@
DO INSTEAD NOTHING;
GRANT SELECT, UPDATE ON pg_settings TO PUBLIC;
+
+CREATE VIEW pg_logdir_ls AS
+ SELECT *
+ FROM pg_logdir_ls() AS A
+ (filetime timestamp, pid int4, filename text);
Index: src/backend/postmaster/Makefile
===
RCS file: /projects/cvsroot/pgsql-server/src/backend/postmaster/Makefile,v
retrieving revision 1.16
diff -u -r1.16 Makefile
--- src/backend/postmaster/Makefile 19 Jul 2004 02:47:08 - 1.16
+++ src/backend/postmaster/Makefile 21 Jul 2004 09:49:23 -
@@ -12,7 +12,7 @@
top_builddir = ../../..
include $(top_builddir)/src/Makefile.global
-OBJS = postmaster.o bgwriter.o pgstat.o pgarch.o
+OBJS = postmaster.o bgwriter.o pgstat.o pgarch.o syslogger.o
all: SUBSYS.o
Index: src/backend/postmaster/postmaster.c
===
RCS file: /projects/cvsroot/pgsql-server/src/backend/postmaster/postmaster.c,v
retrieving revision 1.412
diff -u -r1.412 postmaster.c
--- src/backend/postmaster/postmaster.c 19 Jul 2004 02:47:08 - 1.412
+++ src/backend/postmaster/postmaster.c 21 Jul 2004 09:49:29 -
@@ -118,7 +118,7 @@
#include utils/ps_status.h
#include bootstrap/bootstrap.h
#include pgstat.h
-
+#include postmaster/syslogger.h
/*
* List of active backends (or child processes anyway; we don't actually
@@ -201,6 +201,7 @@
BgWriterPID = 0,
PgArchPID = 0,
PgStatPID = 0;
+pid_t SysLoggerPID = 0;
/* Startup/shutdown state */
#define NoShutdown 0
@@ -852,6 +853,12 @@
#endif
/*
+ * start logging to file
+ */
+
+SysLoggerPID = SysLogger_Start();
+
+ /*
* Reset whereToSendOutput from Debug (its starting state) to None.
* This prevents ereport from sending log messages to stderr unless
* the syslog/stderr switch permits. We don't do this until the
@@ -1230,6 +1237,11 @@
StartupPID == 0 !FatalError Shutdown == NoShutdown)
PgStatPID = pgstat_start();
+ /* If we have lost the system logger, try to start a new one */
+ if (SysLoggerPID == 0
+ StartupPID == 0 !FatalError Shutdown == NoShutdown)
+ SysLoggerPID = SysLogger_Start();
+
/*
* Touch the socket and lock file at least every ten minutes, to ensure
* that they are not removed by overzealous /tmp-cleaning tasks.
@@ -1770,6 +1782,9 @@
kill(BgWriterPID, SIGHUP);
if (PgArchPID != 0)
kill(PgArchPID, SIGHUP);
+ if (SysLoggerPID != 0)
+ kill(SysLoggerPID, SIGHUP);
+
/* PgStatPID does not currently need SIGHUP */
load_hba();
load_ident();
@@ -1835,7 +1850,6 @@
if (PgStatPID != 0)
kill(PgStatPID, SIGQUIT);
break;
-
case SIGINT:
/*
* Fast Shutdown:
@@ -1902,6 +1916,7 @@
kill(PgStatPID, SIGQUIT);
if (DLGetHead(BackendList))
SignalChildren(SIGQUIT);
+
ExitPostmaster(0);
break;
}
@@ -2059,6 +2074,15 @@
continue;
}
+ /* was it the system logger, try to start a new one */
+ if (SysLoggerPID != 0 pid == SysLoggerPID)
+ {
+ if (exitstatus != 0)
+LogChildExit(LOG, gettext(system logger process),
+ pid, exitstatus);
+ SysLoggerPID = SysLogger_Start();
+ continue;
+ }
/*
* Else do
Re: [PATCHES] win32 readline
FYI: I've been using a CVS pull from the middle of May with readline under Win32 without any problems. Firing up the database and doing a 'show all' shows all lc_* vars set to English_United Kingdom.1252. This was compiled using MingW-3.1.0-1 and MSYS-1.0.10, running under Windows XP Pro. The only issues I have found with testing are that the history is not maintained between psql sessions, and completion doesn't work with \i when using a backslash (\) as a separator or when including a drive specifier. Hope this helps, Mark. --- Mark Cave-Ayland Webbased Ltd. Tamar Science Park Derriford Plymouth PL6 8BX England Tel: +44 (0)1752 764445 Fax: +44 (0)1752 764446 This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Magnus Hagander Sent: 21 July 2004 09:13 To: Mark Kirkwood; Peter Eisentraut Cc: [EMAIL PROTECTED] Subject: Re: [PATCHES] win32 readline Hmm. And this is a cvs pull that was before Bruce actually disabled readline? What locale are you in? Peter - what OS are you on, and what mingw version? And what locale? I've done my tests on Win XP, and it elcearly does not work (locale = Swedish). I've also talked to Merlin, and he had the same problems (backslash worked bceauase his locale didn't require Alt-Gr for it, but other Alt keysequences didn't) //Magnus -Original Message- From: Mark Kirkwood [mailto:[EMAIL PROTECTED] To add to the confusion it works for me as well - Windows 2003 with Mingw 3.1.0 Peter Eisentraut wrote: Magnus Hagander wrote: Readline is pretty badly broken under mingw. Basically, it disables the alt-gr key, which renders psql almost useless on most locales (no way to type backslash, and a whole lot of other characters, for example). I can't reproduce that. It works perfectly fine here. ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED]) ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [PATCHES] win32 readline
The locale that's interesting is the Windows locale, not the pg one. And I assume you are on english locale? Then you don't need Alt-Gr for backslash at least, but you're saying other Alt-Gr-key based combinations did work? (I've also had reports of history problems, which in at least one case has been fixed by the disabling of readline) //Magnus -Original Message- From: Mark Cave-Ayland [mailto:[EMAIL PROTECTED] Sent: Wednesday, July 21, 2004 12:38 PM To: Magnus Hagander; 'Mark Kirkwood'; 'Peter Eisentraut' Cc: [EMAIL PROTECTED] Subject: RE: [PATCHES] win32 readline FYI: I've been using a CVS pull from the middle of May with readline under Win32 without any problems. Firing up the database and doing a 'show all' shows all lc_* vars set to English_United Kingdom.1252. This was compiled using MingW-3.1.0-1 and MSYS-1.0.10, running under Windows XP Pro. The only issues I have found with testing are that the history is not maintained between psql sessions, and completion doesn't work with \i when using a backslash (\) as a separator or when including a drive specifier. Hope this helps, Mark. --- Mark Cave-Ayland Webbased Ltd. Tamar Science Park Derriford Plymouth PL6 8BX England Tel: +44 (0)1752 764445 Fax: +44 (0)1752 764446 This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Magnus Hagander Sent: 21 July 2004 09:13 To: Mark Kirkwood; Peter Eisentraut Cc: [EMAIL PROTECTED] Subject: Re: [PATCHES] win32 readline Hmm. And this is a cvs pull that was before Bruce actually disabled readline? What locale are you in? Peter - what OS are you on, and what mingw version? And what locale? I've done my tests on Win XP, and it elcearly does not work (locale = Swedish). I've also talked to Merlin, and he had the same problems (backslash worked bceauase his locale didn't require Alt-Gr for it, but other Alt keysequences didn't) //Magnus -Original Message- From: Mark Kirkwood [mailto:[EMAIL PROTECTED] To add to the confusion it works for me as well - Windows 2003 with Mingw 3.1.0 Peter Eisentraut wrote: Magnus Hagander wrote: Readline is pretty badly broken under mingw. Basically, it disables the alt-gr key, which renders psql almost useless on most locales (no way to type backslash, and a whole lot of other characters, for example). I can't reproduce that. It works perfectly fine here. ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED]) ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [PATCHES] win32 readline
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Magnus Hagander Sent: 21 July 2004 11:49 To: Mark Cave-Ayland Cc: [EMAIL PROTECTED] Subject: Re: [PATCHES] win32 readline The locale that's interesting is the Windows locale, not the pg one. And I assume you are on english locale? Then you don't need Alt-Gr for backslash at least, but you're saying other Alt-Gr-key based combinations did work? (I've also had reports of history problems, which in at least one case has been fixed by the disabling of readline) //Magnus Ah sorry, I misunderstood that you needed the Windows locale. Assuming that the locale is the one that's set in Control Panel, Regional Options then on my PC it's set to English (United Kingdom). As you suggest, I don't need to use Alt-Gr for a backslash, but I can happily write all sorts of strange characters (particularly lots of DOS characters) by holding down Alt-Gr and tapping other keys on the keyboard. I can even include these strange characters in SELECT queries, plus they display correctly when cycling through the history. Note this is running psql from cmd.exe instead of through the MSYS terminal - for some reason psql.exe hangs when I try and run it from the MSYS terminal at the moment Kind regards, Mark. --- Mark Cave-Ayland Webbased Ltd. Tamar Science Park Derriford Plymouth PL6 8BX England Tel: +44 (0)1752 764445 Fax: +44 (0)1752 764446 This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [PATCHES] Patch for pg_dump: Multiple -t options and new -T
Hi, This is a response to several messages: 1) Copyright notice: I have no problem having this removed, although it would be nice to credit me somewhere in a comment. 2) I put most of the code in a separate file so that if the patch is rejected, it's easy for me to maintain a forked copy. If the patch is accepted, obviously it can be integrated into an existing file. 3) Multiple -n options: We need to figure out how this would work, and make it non-surprising. Some ideas: pg_dump -t t1 -n s2 -t t2 -t t3 -n s4 -t t5 What does that do? My guess is: - Dump table t1 in any schema - Dump tables t2 and t3 in schema s2 - Dump table t5 in schema s4 So now the position of the options matters! That might surprise people, because: pg_dump -s s1 -t t2 is no longer the same as: pg_dump -t t2 -n s1 What about: pg_dump -t t1 -n s2 Should that dump table t1 in any schema, and any table in schema s2? If we can nail down the semantics, I can implement the patch. The code is very simple. 4) The -T option (and, one assumes, a corresponding -N option) If the -T option is considered unknown/risky and would prevent the patch from going in, we can drop it for now. Regards, David. ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [PATCHES] Patch for pg_dump: Multiple -t options and new -T option
David F. Skoll wrote: Hi, This is a response to several messages: 1) Copyright notice: I have no problem having this removed, although it would be nice to credit me somewhere in a comment. We credit in the commit message, and in the release notes so it will always be seen. 2) I put most of the code in a separate file so that if the patch is rejected, it's easy for me to maintain a forked copy. If the patch is accepted, obviously it can be integrated into an existing file. OK. Makes sense. 3) Multiple -n options: We need to figure out how this would work, and make it non-surprising. Some ideas: pg_dump -t t1 -n s2 -t t2 -t t3 -n s4 -t t5 What does that do? My guess is: - Dump table t1 in any schema - Dump tables t2 and t3 in schema s2 - Dump table t5 in schema s4 So now the position of the options matters! That might surprise people, because: pg_dump -s s1 -t t2 is no longer the same as: pg_dump -t t2 -n s1 What about: pg_dump -t t1 -n s2 Should that dump table t1 in any schema, and any table in schema s2? If we can nail down the semantics, I can implement the patch. The code is very simple. Even though I suggested it, I am afraid this is just too confusing an API. And I can't think of another one. :-( -- 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 7: don't forget to increase your free space map settings
Re: [PATCHES] Patch for pg_dump: Multiple -t options and new -T
On Wed, 21 Jul 2004, Bruce Momjian wrote: Even though I suggested it, I am afraid this is just too confusing an API. How about this: pg_dump -t t1 -- Dump table t1 in any schema pg_dump -n s1 -- Dump all of schema s1 pg_dump -t t1 -n s1-- Dump t1 in s1 pg_dump -t t1 -t t2 -n s1 -- Dump s1.t1 and s1.t2 pg_dump -t t1 -t t2 -n s1 -n s2-- Dump s1.t1, s1.t2, s2.t1 and s2.t2 Basically, no -t option means dump all tables. No -n option means dump all schemas. If any -t or -n options are present, then we only dump the specified tables/schemas. We also probably should not warn about missing tables, because it's likely that the full cartesian product of schemas and tables won't exist. And we nuke the -T and -N options. Regards, David. ---(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: [PATCHES] logfile subprocess and Fancy File Functions
Andreas Pflug wrote: Bruce Momjian wrote: Andreas Pflug wrote: OK, new idea. Forget about modifying pg_dir_ls(). Instead add pg_file_stat the returns the file size, times. You can then easily use that for file size and times. Also, if you want, add an is_dir boolean so people can write functions that walk the directory tree. I now replaced pg_logfile_length, instead pg_logfile_stat(text) will return a record (len int8, ctime timestamp, atime timestamp, mtime timestamp, isdir bool). You mean pg_file_stat(text), right? That's what I see in your code. For convenience, I'd like to have the function CREATE FUNCTION pg_file_length(text) RETURNS int8 AS $BODY$ SELECT len FROM pg_file_stat($1) AS stat (len int8, ctime timestamp, atime timestamp, mtime timestamp, isdir bool) $BODY$ LANGUAGE SQL STRICT; Where is the right place to put it? Take a look at obj_description in include/catalog/pg_proc.h. That should be a good example. Also, I wonder how to join pg_file_stat and pg_dir_ls to get a ls -l like listing. Apparently I can't do that, unless I don't code pg_dir_ls as returning records too, right? Ideally you want: select filename, pg_file_stat(filename) from pg_dir_ls() or something like that. However, I don't think you can have a function call returning multiple values in the target list, and I can't figure out how to pass an argument to the function if it is in the target list. Ideas? I noticed we had a big logging discussion during 7.4 beta about logging and log rotation. This patch is clearly superior to the ideas we had at that time. Currently, the discussion circles around file functions, not logging. If you think that part is clean, how about committing it separately so it can be tested/used (no problem if pg_logfile_rotate() isn't available right from the start). I'll supply docs RSN. Is pg_logfile_rotate() not working? You mean pg_file_length(). Seems we should get this stat() idea working first. Adjusting catalog entries once they are in CVS means a catalog bump for every catalog change. -- 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 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [PATCHES] Patch for pg_dump: Multiple -t options and new -T option
David F. Skoll [EMAIL PROTECTED] writes: How about this: pg_dump -t t1 -- Dump table t1 in any schema pg_dump -n s1 -- Dump all of schema s1 pg_dump -t t1 -n s1-- Dump t1 in s1 pg_dump -t t1 -t t2 -n s1 -- Dump s1.t1 and s1.t2 pg_dump -t t1 -t t2 -n s1 -n s2-- Dump s1.t1, s1.t2, s2.t1 and s2.t2 Why not pg_dump -t t1 -- Dump table t1 in any schema pg_dump -n s1 -- Dump all of schema s1 pg_dump -t s1.t1 -- Dump t1 in s1 pg_dump -t s1.t1 -t s2.t2 -- Dump s1.t1 and s2.t2 pg_dump -t t1 -t t2 -n s1 -n s2-- Dump s1.t1, s1.t2, s2.t1 and s2.t2 That is, the rules are: - if any -t switches appear, only tables matching (any one of) those switches are dumped - if any -n switches appear, only objects in (any one of) those schemas are dumped - a -t switch can be name only or schema.name The cross-product semantics you're proposing can't implement my fourth example. I really dislike the idea of switch ordering making a difference... We also probably should not warn about missing tables, because it's likely that the full cartesian product of schemas and tables won't exist. Agreed. If any -t or -n switches appear, then warn only if *no* objects get selected. regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [PATCHES] Patch for pg_dump: Multiple -t options and new -T
On Wed, 21 Jul 2004, Tom Lane wrote: pg_dump -t s1.t1 -t s2.t2 -- Dump s1.t1 and s2.t2 That's a good idea, but then it's questionable whether we need the -n switch at all. It might be simpler to extend the -t switch to accept: pg-dump -t 's1.*' rather than using a -n switch. Of course, that breaks backward-compatibility. Regards, David. ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [PATCHES] [HACKERS] Point in Time Recovery
Klaus Naumann [EMAIL PROTECTED] writes: Simon doesn't mean the recovery part. Instead he means the normal startup of the server. It has to be absolutely clear (in the logfile!) if the server was started in archive mode or not. Otherwise you always have to guess. Why would you guess? SHOW archive_command will tell you, without question, at any time. I don't see the point of placing such a message in the postmaster log --- in normal circumstances the postmaster will still be running long after its starting messages have been discarded due to log rotation. Also, the current implementation allows you to stop and start archiving on-the-fly, so a start-time message would be an unreliable guide to what the postmaster is actually doing at the moment. regards, tom lane ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [PATCHES] Patch for pg_dump: Multiple -t options and new -T option
David F. Skoll [EMAIL PROTECTED] writes: On Wed, 21 Jul 2004, Tom Lane wrote: pg_dump -t s1.t1 -t s2.t2 -- Dump s1.t1 and s2.t2 That's a good idea, but then it's questionable whether we need the -n switch at all. Sure we do --- for backwards compatibility if nothing else. It might be simpler to extend the -t switch to accept: pg-dump -t 's1.*' That would not be the same thing --- that would mean to dump *only tables* from s1, rather than objects of all types. Anyway, I think it's a bit late in this cycle to be proposing to implement wild-card matching. Maybe for next time someone can do that, but for 7.5 I think we should limit ourselves to cleaning up any design flaws of the already-submitted patch. regards, tom lane ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [PATCHES] Show tablespace name in pg_tables and pg_indexes
Patch applied and catalog version updated. We now have: test= select * from pg_tables; schemaname |tablename| tablespace | tableowner | hasindexes | hasrules | hastriggers +-++++--+- information_schema | sql_packages|| postgres | f | f| f information_schema | sql_sizing || postgres | f | f| f information_schema | sql_sizing_profiles || postgres | f | f| f information_schema | sql_features|| postgres | f | f| f information_schema | sql_implementation_info || postgres | f | f| f information_schema | sql_languages || postgres | f | f| f pg_catalog | pg_shadow | pg_global | postgres | t | f| t pg_catalog | pg_opclass || postgres | t | f| f These columns are individually selectable so if people don't want the column they can just skip it. --- Klaus Naumann wrote: On Mon, 12 Jul 2004, Klaus Naumann wrote: Hi, sorry, the last patch is buggy which didn't show up in the tests :( Two LEFTs were missing - new patch is attached. Greetings, Klaus Hi, the attached patch shows the new column tablespace in the mentioned views. Apply with ~/pgsql$ patch -p1 03_showtblspc.diff Greetings, Klaus -- Full Name : Klaus Naumann | (http://www.mgnet.de/) (Germany) Phone / FAX : ++49/177/7862964 | E-Mail: ([EMAIL PROTECTED]) Content-Description: [ Attachment, skipping... ] ---(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 -- 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 6: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] pg_config
There are a couple of things that need adjustment: 1. typo in the makefile - ((X) should be $(X) 2. these cases need to be fixed: else if (strcmp(argv[i],--includedir-server) ==0) get_pkginclude_path(mypath,otherpath); else if (strcmp(argv[i],--libdir) == 0) get_include_path(mypath,otherpath); We might actually need one or two functions in port/path.c to handle them. cheers andrew Bruce Momjian wrote: Your patch has been added to the PostgreSQL unapplied patches list at: http://momjian.postgresql.org/cgi-bin/pgpatches It will be applied as soon as one of the PostgreSQL committers reviews and approves it. ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [PATCHES] [HACKERS] Point in Time Recovery
On Wed, 2004-07-21 at 15:53, Tom Lane wrote: Klaus Naumann [EMAIL PROTECTED] writes: Simon doesn't mean the recovery part. Instead he means the normal startup of the server. It has to be absolutely clear (in the logfile!) if the server was started in archive mode or not. Otherwise you always have to guess. Why would you guess? SHOW archive_command will tell you, without question, at any time. I don't see the point of placing such a message in the postmaster log --- in normal circumstances the postmaster will still be running long after its starting messages have been discarded due to log rotation. Also, the current implementation allows you to stop and start archiving on-the-fly, so a start-time message would be an unreliable guide to what the postmaster is actually doing at the moment. Overall, this is a small point and I think we should leave Tom alone, to focus on the bigger issues that we care about. Tom has done an amazingly good job in the last few days of refactoring some reasonably ugly code on my part, all without a murmur. I relent on this to allow everything to be finished in time. The PITR journey has just begun, so there will be further opportunity to discuss and agree what constitutes real issues and then correct them. This may not be on that list later. Best Regards, Simon Riggs ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [PATCHES] autovacuum integration attempt #3
I am having problem applying this. I don't think we can just move pg_autovacuum.[ch] right into the backend code. There are issues with include files and there is no definition for autovacuum_vacuum_base and other variables, and there is no AutoVacMain(). I can try guessing on those but I think I need a more complete patch or more complete instructions to get this applied. Also, it uses the gcc-ism __attribute__ that isn't portable to other compilers. --- Matthew T. O'Connor wrote: Ok, here is a new patch for to integrate pg_autovacuum into the backend. This patch adds the following to that last patch: * updated to latest CVS * changed GUC vars from autovac_* to autovacuum_* * changed autovac_enabled GUC variable to autovacuum * changed autovacuum GUC variable default to false * improved autovacuum failure when row level stats aren't enabled As before, this patch requires pg_autovacuum.c and .h get moved from contrib to src/backend/postmaster and src/include/postmaster respectively. In addition, the attached pg_autovacuum.h file must be put in src/include/catelog/ for the new pg_autovacuum system table. Please apply to CVS or tell me what I need to change to get it applied. -- 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: [PATCHES] Docs for PL/Perl
Patch applied. Thanks. --- David Fetter wrote: Kind people, Please find enclosed a patch that matches the PL/Perl documentation (fairly closely, I hope) to the current PL/Perl implementation. Cheers, D -- David Fetter [EMAIL PROTECTED] http://fetter.org/ phone: +1 510 893 6100 mobile: +1 415 235 3778 Remember to vote! [ Attachment, skipping... ] ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings -- 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 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [PATCHES] win32 readline
Sorry - I have done it too: Windows Locale is : English (New Zealand) Mark Kirkwood wrote: - CVS HEAD from approx 19 Jul - locale is 'English_New Zealand.1252' Magnus Hagander wrote: Hmm. And this is a cvs pull that was before Bruce actually disabled readline? What locale are you in? ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [PATCHES] autovacuum integration attempt #3
Sorry, perhaps my initial instructions weren't clear. You have to move the pg_autovacuum.[ch] files then apply the patch. The patch alters them considerably. Should I submit the patch in a different way? Thanks, Matthew I am having problem applying this. I don't think we can just move pg_autovacuum.[ch] right into the backend code. There are issues with include files and there is no definition for autovacuum_vacuum_base and other variables, and there is no AutoVacMain(). I can try guessing on those but I think I need a more complete patch or more complete instructions to get this applied. Also, it uses the gcc-ism __attribute__ that isn't portable to other compilers. --- Matthew T. O'Connor wrote: Ok, here is a new patch for to integrate pg_autovacuum into the backend. This patch adds the following to that last patch: * updated to latest CVS * changed GUC vars from autovac_* to autovacuum_* * changed autovac_enabled GUC variable to autovacuum * changed autovacuum GUC variable default to false * improved autovacuum failure when row level stats aren't enabled As before, this patch requires pg_autovacuum.c and .h get moved from contrib to src/backend/postmaster and src/include/postmaster respectively. In addition, the attached pg_autovacuum.h file must be put in src/include/catelog/ for the new pg_autovacuum system table. Please apply to CVS or tell me what I need to change to get it applied. -- 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: [PATCHES] autovacuum integration attempt #3
Ack! I sent the wrong patch... Sorry I will resend it tonight. Matthew T. O'Connor wrote: Sorry, perhaps my initial instructions weren't clear. You have to move the pg_autovacuum.[ch] files then apply the patch. The patch alters them considerably. Should I submit the patch in a different way? I don't see any modifications to pg_autovacuum.[ch] in the patch in the patches queue: http://momjian.postgresql.org/cgi-bin/pgpatches -- 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 8: explain analyze is your friend
Re: [PATCHES] autovacuum integration attempt #3
Patch withdrawn by author. Will resubmit. --- Matthew T. O'Connor wrote: Ok, here is a new patch for to integrate pg_autovacuum into the backend. This patch adds the following to that last patch: * updated to latest CVS * changed GUC vars from autovac_* to autovacuum_* * changed autovac_enabled GUC variable to autovacuum * changed autovacuum GUC variable default to false * improved autovacuum failure when row level stats aren't enabled As before, this patch requires pg_autovacuum.c and .h get moved from contrib to src/backend/postmaster and src/include/postmaster respectively. In addition, the attached pg_autovacuum.h file must be put in src/include/catelog/ for the new pg_autovacuum system table. Please apply to CVS or tell me what I need to change to get it applied. Matthew [ Attachment, skipping... ] [ Attachment, skipping... ] ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster -- 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 4: Don't 'kill -9' the postmaster
Re: [PATCHES] logfile subprocess and Fancy File Functions
Andreas Pflug wrote:
or something like that. However, I don't think you can have a function
call returning multiple values in the target list, and I can't figure
out how to pass an argument to the function if it is in the target list.
Ideas?
I thought of
SELECT filename, len, ctime
FROM pg_dir_ls('/etc') AS d (filename text...)
JOIN pg_file_stat(filename) AS s(len int8, )
WHERE filename like 's%'
but that wouldn't work either.
Hm, is it really worth thinking about this further. We won't contribute
a Konqueror plugin to browse a file server through a pgsql connection, I
believe...
Here is what you can do:
SELECT filename,
(SELECT file_len FROM pg_file_stat(filename)),
(SELECT file_ctime FROM pg_file_stat(filename)),
(SELECT file_mtime FROM pg_file_stat(filename)),
(SELECT file_atime FROM pg_file_stat(filename))
FROM pg_dir_ls('/etc') AS d (filename text...)
WHERE filename like 's%'
I don't think you can have a subquery in the target list that returns
more the one column so you have to do multiple SELECT calls.
Currently, the discussion circles around file functions, not logging. If
you think that part is clean, how about committing it separately so it
can be tested/used (no problem if pg_logfile_rotate() isn't available
right from the start). I'll supply docs RSN.
Is pg_logfile_rotate() not working? You mean pg_file_length().
pg_logfile_rotate() *is* working, it's just buried in a bunch of generic
file functions in adt/misc.c. My suggestion was to commit without
pg_proc.h, builtins.h and misc.c. For automatic logfile rotation, no
function is needed.
I now separated the generic file functions in a separate file
misc/adt/genfile.c. syslogger.c/h are still unchanged, appended for
convenience.
No. We will have enough time for testing. Let's get this right first.
If we leave it for later we will forget.
Are we done? Seems pg_file_stat() works fine. Do we need other
adjustments?
--
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: [PATCHES] win32 readline
Magnus Hagander wrote: Hmm. And this is a cvs pull that was before Bruce actually disabled readline? What locale are you in? Actually, I just just typed away in the bash shell, which uses readline as well. Peter - what OS are you on, and what mingw version? And what locale? Windows XP Pro, MinGW 2.0.0, MSys 1.0.8, locale German (Germany) -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
