Re: [PATCHES] set_ps_display during recovery
On Sat, 2007-09-29 at 14:34 -0400, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
Small patch to set ps display during recovery, so we can see the current
WAL file being processed in both crash and archive recovery.
Hmm, not right there, because we don't know that the file actually
exists yet. Applied with modifications ...
Double hmmm, that means when we are waiting for file X in pg_standby the
ps display will still show recovering X-1. I'd prefer to set ps before
the call to RestoreArchivedFile(), since that is where the wait occurs.
I got that wrong myself.
Perhaps we could add these lines?
Index: src/backend/access/transam/xlog.c
===
RCS file: /projects/cvsroot/pgsql/src/backend/access/transam/xlog.c,v
retrieving revision 1.282
diff -c -r1.282 xlog.c
*** src/backend/access/transam/xlog.c 26 Sep 2007 22:36:30 -
1.282
--- src/backend/access/transam/xlog.c 30 Sep 2007 07:39:43 -
***
*** 2299,2304
--- 2299,2309
if (InArchiveRecovery)
{
XLogFileName(xlogfname, tli, log, seg);
+ /* Report recovery progress in PS display */
+ strcpy(activitymsg, restoring );
+ XLogFileName(activitymsg + 11, tli, log, seg);
+ set_ps_display(activitymsg, false);
+
restoredFromArchive = RestoreArchivedFile(path,
xlogfname,
RECOVERYXLOG,
XLogSegSize);
--
Simon Riggs
2ndQuadrant http://www.2ndQuadrant.com
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
Re: [PATCHES] ecpg thead-safe memory management + cleanup
On Fri, Sep 28, 2007 at 03:00:54PM +0900, ITAGAKI Takahiro wrote: Here is a patch to get memory management to thread-safe. The auto_allocs global variable is split into per-thread variables and accessed separately in each thread. Thanks. Committed to CVS HEAD. * Release all prepared statements on disconnection to avoid memory leaks even if users forget to DEALLOCATE their statements before disconnection. Oops, should have noticed this. Michael -- Michael Meskes Email: Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: [EMAIL PROTECTED] Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL! ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [PATCHES] set_ps_display during recovery
Simon Riggs [EMAIL PROTECTED] writes: On Sat, 2007-09-29 at 14:34 -0400, Tom Lane wrote: Hmm, not right there, because we don't know that the file actually exists yet. Applied with modifications ... Double hmmm, that means when we are waiting for file X in pg_standby the ps display will still show recovering X-1. I'd prefer to set ps before the call to RestoreArchivedFile(), since that is where the wait occurs. I got that wrong myself. Well, if you think that's an important time component --- which it could be in archive situations, I guess --- there should be a separate PS display state for it. Perhaps fetching XXX vs restoring XXX? regards, tom lane ---(end of broadcast)--- TIP 1: 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] set_ps_display during recovery
On Sun, 2007-09-30 at 10:28 -0400, Tom Lane wrote: Simon Riggs [EMAIL PROTECTED] writes: On Sat, 2007-09-29 at 14:34 -0400, Tom Lane wrote: Hmm, not right there, because we don't know that the file actually exists yet. Applied with modifications ... Double hmmm, that means when we are waiting for file X in pg_standby the ps display will still show recovering X-1. I'd prefer to set ps before the call to RestoreArchivedFile(), since that is where the wait occurs. I got that wrong myself. Well, if you think that's an important time component --- which it could be in archive situations, I guess --- there should be a separate PS display state for it. Agreed. I think it will save time answering questions on -admin later. Perhaps fetching XXX vs restoring XXX? Restoring is the right term, I think. -- Simon Riggs 2ndQuadrant http://www.2ndQuadrant.com ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] set_ps_display during recovery
On Sun, 2007-09-30 at 10:28 -0400, Tom Lane wrote: Perhaps fetching XXX vs restoring XXX? Not sure if I read you right, so one more time for clarity: IMHO wording should be restoring X before we send to archive to get file (archive only) recovering X once we have the file (archive or not) -- Simon Riggs 2ndQuadrant http://www.2ndQuadrant.com ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [PATCHES] set_ps_display during recovery
Simon Riggs [EMAIL PROTECTED] writes: On Sun, 2007-09-30 at 10:28 -0400, Tom Lane wrote: Perhaps fetching XXX vs restoring XXX? Not sure if I read you right, so one more time for clarity: IMHO wording should be restoring X before we send to archive to get file (archive only) recovering X once we have the file (archive or not) Those two words seem close enough in meaning that most admins wouldn't be clear on the difference. I like fetching or retrieving for the activity of getting a WAL segment from an archive, because in cases where the activity takes long enough to be noticeable, it's probably because you are physically getting the file from someplace else. In the specific context of a warm standby machine, waiting for would be the bon mot, but that would probably be inappropriate for other contexts. As for the second-phase activity, recovering is fine, or maybe processing? regards, tom lane ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] set_ps_display during recovery
On Sun, 2007-09-30 at 11:16 -0400, Tom Lane wrote: Simon Riggs [EMAIL PROTECTED] writes: On Sun, 2007-09-30 at 10:28 -0400, Tom Lane wrote: Perhaps fetching XXX vs restoring XXX? Not sure if I read you right, so one more time for clarity: IMHO wording should be restoring X before we send to archive to get file (archive only) recovering X once we have the file (archive or not) Those two words seem close enough in meaning that most admins wouldn't be clear on the difference. OK, I see that. I like fetching or retrieving for the activity of getting a WAL segment from an archive, because in cases where the activity takes long enough to be noticeable, it's probably because you are physically getting the file from someplace else. In the specific context of a warm standby machine, waiting for would be the bon mot, but that would probably be inappropriate for other contexts. Waiting for sounds best I think. It might be waiting for a manual tape mount for example, not just a warm standby. If the wait isn't very long it won't hardly notice anyway. As for the second-phase activity, recovering is fine, or maybe processing? Yes, Recovering is fine. -- Simon Riggs 2ndQuadrant http://www.2ndQuadrant.com ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [PATCHES] set_ps_display during recovery
Simon Riggs [EMAIL PROTECTED] writes: On Sun, 2007-09-30 at 11:16 -0400, Tom Lane wrote: I like fetching or retrieving for the activity of getting a WAL segment from an archive, because in cases where the activity takes long enough to be noticeable, it's probably because you are physically getting the file from someplace else. Waiting for sounds best I think. It might be waiting for a manual tape mount for example, not just a warm standby. If the wait isn't very long it won't hardly notice anyway. Hmm ... I guess that's OK, because after all we *are* waiting for the restore_command to do something. Will make it so. regards, tom lane ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] [HACKERS] Add function for quote_qualified_identifier?
On 9/29/07, Bruce Momjian [EMAIL PROTECTED] wrote: I think we need more than one person's request to add this function. Well, I don't expect it would get requested. Most DBAs would likely look for the function in the docs, see it's not there and then just implement it themselves. Obviously it's not critical. But anticipating those little requirements and providing for them is one of the things that makes a piece of software a pleasure to use. Batteries included and all that. Anyway, I seem to be flogging a horse which, if not dead, is surely mortally wounded. If quote_qualified_ident isn't desired, perhaps you can still use the regression test I included for quote_ident in the patch. The test is functional as a standalone item, and seems to fill a gap. Thanks for your time, BJ ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
