Re: [HACKERS] Online index builds
On Sat, 2006-07-15 at 21:10 -0400, Greg Stark wrote: Hannu Krosing [EMAIL PROTECTED] writes: Another related thing - throttling -- Did you do any work on using vacuum_cost_* GUC vars to throttle the build process if desired ? Actually no. While there is consensus that will be necessary I'm not sure I can do it with this patch. The problem is that most of the real heavy lifting here is done inside tuplesort. Even aside from that most of what's left is inside bulkdelete(*) and the code that handles regular index builds. So I think we'll need some global thinking about what options Postgres needs to control throttling in general. And probably someone needs to write a separate patch that adds all the hooks to the various places in a single go. Trying to throttle just one operation at a time when a lot of the code that implements these operations is shared will have us running in circles. (*) Hm. Come to think of it I wonder if the vacuum_cost parameters are already kicking in for this phase. That would be a bit strange since it's the fastest of the three scans. Separate patches sounds more sensible. Using statement_cost_* in many places sounds useful to me and not too hard to get into 8.2 -- Simon Riggs EnterpriseDB http://www.enterprisedb.com ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] Forcing wal rotation
Ühel kenal päeval, L, 2006-07-15 kell 22:24, kirjutas Tom Lane: Hannu Krosing [EMAIL PROTECTED] writes: And by any chance, do you plan to backport the standby WAL playback mode patches to 8.0 and 8.1 series ? That's not happening ... we do not put new features in stable branches. Not even the part that is obviously a bugfix ? I mean the fact that currently checkpoints are not done while doing playback and any failure during playback causes one to do the whole playback again from the start, which means among oyher things that you must keep all your WAL files on the destination machine. regards, tom lane -- Hannu Krosing Database Architect Skype Technologies OÜ Akadeemia tee 21 F, Tallinn, 12618, Estonia Skype me: callto:hkrosing Get Skype for free: http://www.skype.com ---(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: [HACKERS] Online index builds
Ühel kenal päeval, L, 2006-07-15 kell 21:10, kirjutas Greg Stark: Hannu Krosing [EMAIL PROTECTED] writes: Maybe we can show progress indicators in status line (either pg_stat_activity.current_query or commandline shown in ps), like WAITING TO START PHASE 1 - WAITING FOR TRANSACTION XXX TO COMPLETE or INSERTING INDEX ENTRY N OF M changing every few seconds. Hm. That would be very interesting. I'll say that one of the things that impressed me very much with Postgres moving from Oracle was the focus on usability. Progress indicators would be excellent for a lot of operations. That said I'm not sure how much I can do here. For a substantial index we should expect most of the time will be spent in the tuplesort. If index is substantially bigger than shared memory/available RAM then tuple by tuple index insertion part can also be quite slow and i/o consuming even if the number of entries to insert is low compared to total index size. That is where INSERTING INDEX ENTRY N OF M would be a thing which helps the DBA to estimate time to completion. It's hard to see how to get any sort of progress indicator out of there and as long as we can't it's hard to see the point of getting one during the heap scan or any of the other i/o operations. It would be useful to know, in what step we are in general , that is are we doing some useful work or just waiting for something. -- Hannu Krosing Database Architect Skype Technologies OÜ Akadeemia tee 21 F, Tallinn, 12618, Estonia Skype me: callto:hkrosing Get Skype for free: http://www.skype.com ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
[HACKERS] Windows buildfarm support, or lack of it
What's wrong with this picture? http://www.pgbuildfarm.org/cgi-bin/show_status.pl Notice how all the red is at the bottom of the report? That's because all the Windows machines are at the bottom, indicating that they haven't reported recently. AFAICT, snake is the only Windows machine that actually runs the buildfarm on a regular schedule, and even it is just running once a day. So, while the timescale for finding out if a commit breaks or fixes other platforms is just a couple hours, we generally need a full day to find out about Windows. For a platform that requires as much special-case care and feeding as the Windows code does, that's not very acceptable. For a platform that's as ubiquitous as Windows allegedly is, that's pretty surprising. You'd think we could find a couple of people willing to run buildfarm tests every four hours or so, as many of the Unix buildfarm members do. (Yeah, I'm a bit ticked off after waiting overnight to find out if yesterday's commits fixed Windows, and getting up to find no new data.) regards, tom lane ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Windows buildfarm support, or lack of it
On Sun, 16 Jul 2006, Tom Lane wrote: [windows buildfarm machines run irregularly] For my part the difficulty is scheduling. As a primarily unix user I understand cron, but have no idea what the windows equivalent is. For my cygwin buildfarm member I setup cron, but the make step failed for every build for unknown reasons while succeeding if not run from cron. That further demotivated me from scheduling mingw builds. Perhaps snake's maintainer could share his configuration? Kris Jurka ---(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: [HACKERS] [PATCHES] Restartable Recovery
Andreas Seltenreich [EMAIL PROTECTED] writes: Simon Riggs [EMAIL PROTECTED] writes: [2. text/x-patch; restartableRecovery.patch] Hmm, wouldn't you have to reboot the resource managers at each checkpoint? I'm afraid otherwise things like postponed page splits could get lost on restart from a later checkpoint. Ouch. That's a bit nasty. You can't just apply a postponed split at checkpoint time, because the WAL record could easily be somewhere after the checkpoint, leading to duplicate insertions. Right offhand I don't see how to make this work :-( regards, tom lane ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Online index builds
On Saturday 15 July 2006 21:37, Joshua D. Drake wrote:
That said I'm not sure how much I can do here. For a substantial index we
should expect most of the time will be spent in the tuplesort. It's hard
to see how to get any sort of progress indicator out of there and as long
as we can't it's hard to see the point of getting one during the heap
scan or any of the other i/o operations.
Well from a DBA perspective, just knowing that something productive is
happening is useful.
When using vacuum I almost always use vacuum verbose, just so I have an
idea of what is going on.
+1
--
Robert Treat
Build A Brighter LAMP :: Linux Apache {middleware} PostgreSQL
---(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: [HACKERS] [PATCHES] Restartable Recovery
On Sun, 2006-07-16 at 10:51 -0400, Tom Lane wrote: Andreas Seltenreich [EMAIL PROTECTED] writes: Simon Riggs [EMAIL PROTECTED] writes: [2. text/x-patch; restartableRecovery.patch] Hmm, wouldn't you have to reboot the resource managers at each checkpoint? I'm afraid otherwise things like postponed page splits could get lost on restart from a later checkpoint. Ouch. That's a bit nasty. You can't just apply a postponed split at checkpoint time, because the WAL record could easily be somewhere after the checkpoint, leading to duplicate insertions. Right offhand I don't see how to make this work :-( Yes, ouch. So much for gung-ho code sprints; thanks Andreas. To do this we would need to have another rmgr specific routine that gets called at a recovery checkpoint. This would then write to disk the current state of the incomplete multi-WAL actions, in some manner. During the startup routines we would check for any pre-existing state files and use those to initialise the incomplete action cache. Cleanup would then discard all state files. That allows us to not-forget actions, but it doesn't help us if there are problems repeating actions twice. We would at least know that we are in a potential double-action zone and could give different kinds of errors or handling. Or we can simply mark any indexes incomplete-needs-rebuild if they had a page split during the overlap time between the last known good recovery checkpoint and the following one. But that does lead to randomly bounded recovery time, which might be better to have started from scratch anyway. Given time available for 8.2, neither one is a quick fix. -- Simon Riggs EnterpriseDB http://www.enterprisedb.com ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] Windows buildfarm support, or lack of it
-Original Message- From: [EMAIL PROTECTED] on behalf of Tom Lane Sent: Sun 7/16/2006 3:29 PM To: pgsql-hackers@postgresql.org Subject: [HACKERS] Windows buildfarm support, or lack of it AFAICT, snake is the only Windows machine that actually runs the buildfarm on a regular schedule, and even it is just running once a day. I can bump that up as high as you'd like within reason. 4? 6 times a day? I have spare licences for most versions of Windows as well, so if Microsoft's virtual server product is not too expensive for us I can probably add a few platform variations to that box. I'll look into it. Regards, Dave. ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Windows buildfarm support, or lack of it
-Original Message- From: Kris Jurka [mailto:[EMAIL PROTECTED] Sent: Sun 7/16/2006 3:44 PM To: Tom Lane Cc: pgsql-hackers@postgreSQL.org; Dave Page Subject: Re: [HACKERS] Windows buildfarm support, or lack of it For my part the difficulty is scheduling. As a primarily unix user I understand cron, but have no idea what the windows equivalent is. For my cygwin buildfarm member I setup cron, but the make step failed for every build for unknown reasons while succeeding if not run from cron. That further demotivated me from scheduling mingw builds. Perhaps snake's maintainer could share his configuration? I run a simple batch script that fires the run off under msys from the Windows Task Scheduler. I'll happily help out anyone who wants to get a build running. Regards, Dave. ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
[HACKERS] Possible explanation for Win32 stats regression test failures
The latest buildfarm report from trout,
http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=troutdt=2006-07-16%2014:36:19
shows a failure mode that we've seen recently on snake, but not for a
long time on any non-Windows machines: the stats test fails with
symptoms suggesting that the stats counters aren't getting incremented.
Dave Page spotted the reason for this during the recent code sprint.
The stats collector is dying with
FATAL: could not read statistics message: A blocking operation was interrupted
by a call to WSACancelBlockingCall.
If you look through the above-mentioned report's postmaster log, you'll
see several occurrences of this, indicating that the stats collector is
being restarted by the postmaster and then dying again.
After a bit of digging in our code, I realized that the above text is
probably the system's translation of WSAEINTR, which we equate EINTR
to, and thus that what's happening is just recv() returned EINTR,
even though the socket had already tested read-ready. I'm not sure
whether that's considered normal behavior on Unixen but it is clearly
possible with our Win32 implementation of recv() --- any pending signal
will make it happen. So it seems an appropriate fix for the stats
collector is
len = recv(pgStatSock, (char *) msg,
sizeof(PgStat_Msg), 0);
if (len 0)
+ {
+ if (errno == EINTR)
+ continue;
ereport(ERROR,
(errcode_for_socket_access(),
errmsg(could not read statistics message: %m)));
+ }
and we had better look around to make sure all other calls of send()
and recv() treat EINTR as expected too.
But ... AFAICS the only signal that could plausibly be arriving at the
stats collector is SIGALRM from its own use of setitimer() to schedule
stats file writes. So it seems that this failure occurs when the alarm
fires between the select() and recv() calls; which is possible but it
seems a mighty narrow window. So I'm not 100% convinced that this is
the correct explanation of the problem --- we've seen snake fail this
way repeatedly, and here we have trout doing it three times within one
regression run. Can anyone think of a reason why the timing might fall
just so with a higher probability than one would expect? Perhaps
pgwin32_select() has got a problem that makes it not dispatch signals
as it seems to be trying to do?
regards, tom lane
---(end of broadcast)---
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
Re: [HACKERS] Windows buildfarm support, or lack of it
Kris Jurka wrote: On Sun, 16 Jul 2006, Tom Lane wrote: [windows buildfarm machines run irregularly] For my part the difficulty is scheduling. As a primarily unix user I understand cron, but have no idea what the windows equivalent is. For my cygwin buildfarm member I setup cron, but the make step failed for every build for unknown reasons while succeeding if not run from cron. That further demotivated me from scheduling mingw builds. Perhaps snake's maintainer could share his configuration? There is job schedulers for Windows. I have no idea how good or bad they are. Joshua D. Drake Kris Jurka ---(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 -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutions since 1997 http://www.commandprompt.com/ ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] [PATCHES] Restartable Recovery
Simon Riggs [EMAIL PROTECTED] writes: On Sun, 2006-07-16 at 10:51 -0400, Tom Lane wrote: Ouch. That's a bit nasty. You can't just apply a postponed split at checkpoint time, because the WAL record could easily be somewhere after the checkpoint, leading to duplicate insertions. To do this we would need to have another rmgr specific routine that gets called at a recovery checkpoint. This would then write to disk the current state of the incomplete multi-WAL actions, in some manner. During the startup routines we would check for any pre-existing state files and use those to initialise the incomplete action cache. Cleanup would then discard all state files. I thought about that too, but it seems very messy, eg you'd have to actually fsync the state files to be sure they were safely down to disk. Another problem is that WAL records between the checkpoint's REDO point and the physical checkpoint location could get replayed twice, leading to duplicate entries in the rmgr's state. Consider a split start WAL entry located in that range, with the split completion entry after the checkpoint --- on restart, we'd load a pending-split entry from the state file and then create another one on seeing the split-start record again. A compromise that might be good enough is to add an rmgr routine defined as bool is_idle(void) that tests whether the rmgr has any open state to worry about. Then, recovery checkpoints are done only if all rmgrs say they are idle. That is, we only checkpoint if there is not a need for any state files. At least for btree's usage, this should be all right since the split pending state is short-lived and so most of the time we'd not need to skip checkpoints. I'm not totally sure about GIST or GIN though (Teodor?). regards, tom lane ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Windows buildfarm support, or lack of it
Dave Page wrote: I have spare licences for most versions of Windows as well, so if Microsoft's virtual server product is not too expensive for us I can probably add a few platform variations to that box. I'll look into it. In fact MS released Virtual PC 2004 for free a couple days ago (http://www.microsoft.com/windows/virtualpc/default.mspx) -- Regards Petr Jelinek (PJMODOS) ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Windows buildfarm support, or lack of it
Dave Page wrote: -Original Message- From: [EMAIL PROTECTED] on behalf of Tom Lane Sent: Sun 7/16/2006 3:29 PM To: pgsql-hackers@postgresql.org Subject: [HACKERS] Windows buildfarm support, or lack of it AFAICT, snake is the only Windows machine that actually runs the buildfarm on a regular schedule, and even it is just running once a day. I can bump that up as high as you'd like within reason. 4? 6 times a day? Let's go for 6, at least for HEAD. Under normal use buildfarm doesn't actually do anything unless it detects a change in the source, and it makes sure there isn't a collision by using a lockfile. That means it is safe to schedule builds fairly frequently. cheers andrew ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Windows buildfarm support, or lack of it
Andrew Dunstan [EMAIL PROTECTED] writes: Dave Page wrote: I can bump that up as high as you'd like within reason. 4? 6 times a day? Let's go for 6, at least for HEAD. There's probably no need to check the back branches oftener than once a day, but if you can do HEAD every 4 hours that'd be great ... 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: [HACKERS] Windows buildfarm support, or lack of it
-Original Message- From: Petr Jelinek [EMAIL PROTECTED] To: Dave Page dpage@vale-housing.co.uk Cc: PostgreSQL-development pgsql-hackers@postgresql.org Sent: 16/07/06 18:05 Subject: Re: Windows buildfarm support, or lack of it In fact MS released Virtual PC 2004 for free a couple days ago (http://www.microsoft.com/windows/virtualpc/default.mspx) Yeah - I have licences for it, but it's more of an interactive emulator. I think I'll need the server version to run fully unattended. /D ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] Windows buildfarm support, or lack of it
Andrew, Tom: I'm putting a solicitation in this week's PWN for more Windows buildfarm members. With 250,000 Windows+PostgreSQL users out there, you'd think a few people would step up. Dave, I think you may need to give Andrew Windows buildfarm instructions to put up at www.pgbuildfarm.org. -- Josh Berkus PostgreSQL @ Sun San Francisco ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] Windows buildfarm support, or lack of it
Tom Lane wrote: Andrew Dunstan [EMAIL PROTECTED] writes: Dave Page wrote: I can bump that up as high as you'd like within reason. 4? 6 times a day? Let's go for 6, at least for HEAD. There's probably no need to check the back branches oftener than once a day, but if you can do HEAD every 4 hours that'd be great ... I will have seahorse doing Windows builds at the same rate then ... Stefan ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
[HACKERS] SPI Elections and mailing list
Folks, Hopefully by now a bunch of you have joined as Software in the Public Interest Contributing members per my earlier e-mail and are aware that the SPI annual board election has started. If you are a registered contributing member with SPI, elections are at: http://members.spi-inc.org/vote/ and candidate statements are at: http://www.spi-inc.org/secretary/votes/vote5/ Voting closes July 28th. If you did not already register as an SPI contributing member, it is too late for this year. Please also note that the current volume of e-mail on the spi-private mailing list is due entirely to the election and is not at all typical of the list. -- Josh Berkus PostgreSQL @ Sun San Francisco ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] Windows buildfarm support, or lack of it
-Original Message- From: Tom Lane [mailto:[EMAIL PROTECTED] Sent: 16 July 2006 18:47 To: Andrew Dunstan Cc: Dave Page; pgsql-hackers@postgresql.org Subject: Re: [HACKERS] Windows buildfarm support, or lack of it Andrew Dunstan [EMAIL PROTECTED] writes: Dave Page wrote: I can bump that up as high as you'd like within reason. 4? 6 times a day? Let's go for 6, at least for HEAD. There's probably no need to check the back branches oftener than once a day, but if you can do HEAD every 4 hours that'd be great ... NP - next run is at 2200BST. Regards, Dave. ---(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: [HACKERS] Windows buildfarm support, or lack of it
-Original Message- From: Stefan Kaltenbrunner [mailto:[EMAIL PROTECTED] Sent: 16 July 2006 18:17 To: Dave Page Subject: Re: [HACKERS] Windows buildfarm support, or lack of it care to share that script ? I set up seahorse on friday but as a unix-sysadmin I have not yet managed to get it to do automatic builds ... Sure. It's pretty simply. I run one for each branch (used to do one for all runs, but a problem in an early run can prevent later ones running at all then Regards, Dave. @echo off echo == \msys\1.0\local\build-farm\run-head.log \msys\1.0\bin\date \msys\1.0\local\build-farm\run-head.log echo Starting HEAD run... \msys\1.0\local\build-farm\run-head.log \msys\1.0\bin\sh --login -c cd /usr/local/build-farm; ./run_build.pl --verbose HEAD \msys\1.0\local\build-farm\run-head.log echo Finished. \msys\1.0\local\build-farm\run-head.log \msys\1.0\bin\date \msys\1.0\local\build-farm\run-head.log echo == \msys\1.0\local\build-farm\run-head.log echo. \msys\1.0\local\build-farm\run-head.log ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Windows buildfarm support, or lack of it
-Original Message- From: Josh Berkus [mailto:[EMAIL PROTECTED] Sent: 16 July 2006 19:04 To: pgsql-hackers@postgresql.org Cc: Tom Lane; Andrew Dunstan; Dave Page Subject: Re: [HACKERS] Windows buildfarm support, or lack of it Andrew, Tom: I'm putting a solicitation in this week's PWN for more Windows buildfarm members. With 250,000 Windows+PostgreSQL users out there, you'd think a few people would step up. Dave, I think you may need to give Andrew Windows buildfarm instructions to put up at www.pgbuildfarm.org. grinIt was Andrew that gave me instructions! I'll see if I can write up the important points though. /D ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Possible explanation for Win32 stats regression test failures
I wrote: But ... AFAICS the only signal that could plausibly be arriving at the stats collector is SIGALRM from its own use of setitimer() to schedule stats file writes. So it seems that this failure occurs when the alarm fires between the select() and recv() calls; which is possible but it seems a mighty narrow window. So I'm not 100% convinced that this is the correct explanation of the problem --- we've seen snake fail this way repeatedly, and here we have trout doing it three times within one regression run. Can anyone think of a reason why the timing might fall just so with a higher probability than one would expect? Perhaps pgwin32_select() has got a problem that makes it not dispatch signals as it seems to be trying to do? Ah-hah, I see it. pgwin32_select() uses WaitForMultipleObjectsEx() with an event for the socket read-ready plus an event for signal arrival. It returns EINTR if the return code from WaitForMultipleObjectsEx shows the signal-arrival event as fired. However, WaitForMultipleObjectsEx is defined to return the number of the *first* event in the list that is fired. This means that if the socket comes read-ready at the same time the SIGALRM arrives, pgwin32_select() will ignore the signal, and it'll be processed by the subsequent pgwin32_recv(). Now I don't know anything about the Windows scheduler, but I suppose it gives processes time quantums like everybody else does. So at the same time really means within the same scheduler clock tick, which is not so unlikely after all. In short, before the just-committed patch, the Windows stats collector would fail if a stats message arrived during the same clock tick that its SIGALRM timeout expired. I think this explains not only the intermittent stats regression failures, but the reports we've heard from Merlin and others about the stats collector being unstable under load on Windows. The heavier the load of stats messages, the more likely one is to arrive during the tick when the timeout expires. regards, tom lane ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] [PATCHES] Restartable Recovery
On Sun, 2006-07-16 at 12:40 -0400, Tom Lane wrote: A compromise that might be good enough is to add an rmgr routine defined as bool is_idle(void) that tests whether the rmgr has any open state to worry about. Then, recovery checkpoints are done only if all rmgrs say they are idle. Like it. That is, we only checkpoint if there is not a need for any state files. At least for btree's usage, this should be all right since the split pending state is short-lived and so most of the time we'd not need to skip checkpoints. I'm not totally sure about GIST or GIN though (Teodor?). Considering how infrequently we wanted to do recovery checkpoints, this is unlikely to cause any issue. But in any case, this is the best we can give people, rather than a compromise. Perhaps that should be extended to say whether there are any non-idempotent changes made in the last checkpoint period. That might cover a wider set of potential actions. If index splits in GIST or GIN are *not* short lived, then I would imagine we'd have some serious contention problems to clear up since an inconsistent index is unusable and would require portions of it to be locked throughout such operations to ensure their atomicity. -- Simon Riggs EnterpriseDB http://www.enterprisedb.com ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Windows buildfarm support, or lack of it
Dave Page dpage@vale-housing.co.uk writes: In fact MS released Virtual PC 2004 for free a couple days ago (http://www.microsoft.com/windows/virtualpc/default.mspx) Yeah - I have licences for it, but it's more of an interactive emulator. I think I'll need the server version to run fully unattended. Surely we can dredge up enough Windows users that Dave need not futz with putting multiple versions onto his one machine ... 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: [HACKERS] [PATCHES] Restartable Recovery
Simon Riggs [EMAIL PROTECTED] writes: On Sun, 2006-07-16 at 12:40 -0400, Tom Lane wrote: A compromise that might be good enough is to add an rmgr routine defined as bool is_idle(void) that tests whether the rmgr has any open state to worry about. Then, recovery checkpoints are done only if all rmgrs say they are idle. Perhaps that should be extended to say whether there are any non-idempotent changes made in the last checkpoint period. That might cover a wider set of potential actions. Perhaps best to call it safe_to_checkpoint(), and not pre-judge what reasons the rmgr might have for not wanting to restart here. If we are only going to do a recovery checkpoint at every Nth checkpoint record, then occasionally having to skip one seems no big problem --- just do it at the first subsequent record that is safe. regards, tom lane ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] [PATCHES] Restartable Recovery
On Sun, 2006-07-16 at 15:33 -0400, Tom Lane wrote: Simon Riggs [EMAIL PROTECTED] writes: On Sun, 2006-07-16 at 12:40 -0400, Tom Lane wrote: A compromise that might be good enough is to add an rmgr routine defined as bool is_idle(void) that tests whether the rmgr has any open state to worry about. Then, recovery checkpoints are done only if all rmgrs say they are idle. Perhaps that should be extended to say whether there are any non-idempotent changes made in the last checkpoint period. That might cover a wider set of potential actions. Perhaps best to call it safe_to_checkpoint(), and not pre-judge what reasons the rmgr might have for not wanting to restart here. You read my mind. If we are only going to do a recovery checkpoint at every Nth checkpoint record, then occasionally having to skip one seems no big problem --- just do it at the first subsequent record that is safe. Got it. -- Simon Riggs EnterpriseDB http://www.enterprisedb.com ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Windows buildfarm support, or lack of it
Kris Jurka wrote: For my cygwin buildfarm member I setup cron, but the make step failed for every build for unknown reasons while succeeding if not run from cron. Is this still happening? We should try to get to the bottom of it. cheers andrew ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] automatic system info tool?
-Original Message- From: Andrew Dunstan [EMAIL PROTECTED] To: Peter Eisentraut [EMAIL PROTECTED] Cc: pgsql-hackers@postgresql.org pgsql-hackers@postgresql.org Sent: 16/07/06 23:50 Subject: Re: [HACKERS] automatic system info tool? We also classify buildfarm machines by os, os_version, compiler, compiler_version and config.guess doesn't give us that, unfortunately. It also won't work on Win32 without msys (or SFU/Interix). /D ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
[HACKERS] plPHP and plRuby
Hello, We were going to submit plPHP to core for inclusion but it is not ready yet. Namely it requires the apache SAPI which could introduce some portability issues. The other issues it has (such as some array parsing problems) are minor and could probably be fixed easily within the beta period but the SAPI is a show stopper. As some of you know, we have also procured permission to relicense plRuby so that the project can include it in core. I have a version that works with -HEAD. However plRuby is even a stranger beast as it uses an entirely ruby build system. I am also fairly confident that it does not meat the PostgreSQL style guidelines. Is there enough interest in plRuby to get it where it needs to be for possible inclusion into core? Sincerely, Joshua D. Drake -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutions since 1997 http://www.commandprompt.com/ ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] plPHP and plRuby
On Sun, 16 Jul 2006, Joshua D. Drake wrote: Hello, However plRuby is even a stranger beast as it uses an entirely ruby build system. I am also fairly confident that it does not meat the PostgreSQL style guidelines. Well... JDBC used its own. Is there enough interest in plRuby to get it where it needs to be for possible inclusion into core? I'd like to see it ship with the core distribution. Thanks, Gavin ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Windows buildfarm support, or lack of it
On 7/16/06, Joshua D. Drake [EMAIL PROTECTED] wrote: Kris Jurka wrote: On Sun, 16 Jul 2006, Tom Lane wrote: [windows buildfarm machines run irregularly] For my part the difficulty is scheduling.As a primarily unix user I understand cron, but have no idea what the windows equivalent is.For my cygwin buildfarm member I setup cron, but the make step failed for every build for unknown reasons while succeeding if not run from cron. That further demotivated me from scheduling mingw builds.Perhaps snake's maintainer could share his configuration?There is job schedulers for Windows. I have no idea how good or bad theyare. This might help: http://support.microsoft.com/default.aspx?scid=kb;en-us;308569sd=tech The windows scheduler is ok. I think Dave is doing it the best way. NathanJoshua D. Drake Kris Jurka ---(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 --=== The PostgreSQL Company: Command Prompt, Inc. ===Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240Providing the most comprehensivePostgreSQL solutions since 1997 http://www.commandprompt.com/---(end of broadcast)---TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] SPI Elections and mailing list
Sorry- perhaps I misunderstand the purpose of your group, but how can you claim to be making decisions on software in the public interest on a private, paid-member mailing list? -M On Jul 16, 2006, at 2:10 PM, Josh Berkus wrote: Folks, Hopefully by now a bunch of you have joined as Software in the Public Interest Contributing members per my earlier e-mail and are aware that the SPI annual board election has started. If you are a registered contributing member with SPI, elections are at: http://members.spi-inc.org/vote/ and candidate statements are at: http://www.spi-inc.org/secretary/votes/vote5/ Voting closes July 28th. If you did not already register as an SPI contributing member, it is too late for this year. Please also note that the current volume of e-mail on the spi-private mailing list is due entirely to the election and is not at all typical of the list. ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ AgentM [EMAIL PROTECTED] ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] SPI Elections and mailing list
Agent M wrote: Sorry- perhaps I misunderstand the purpose of your group, but how can you claim to be making decisions on software in the public interest on a private, paid-member mailing list? Well it isn't paid-member mailing (I don't think) but you do need to be a contributing member (ahh that is where it comes from). When they say contributing, they are talking about people who are recognized within the FOSS community for their contributions. The SPI is a non-profit that is designed to help support other FOSS projects. In our case PostgreSQL. The PostgreSQL Fundraising Group (of which I am apart) is using the SPI non-profit status to allow for tax deductible donations to the PostgreSQL project. Sincerely, Joshua D. Drake -M On Jul 16, 2006, at 2:10 PM, Josh Berkus wrote: Folks, Hopefully by now a bunch of you have joined as Software in the Public Interest Contributing members per my earlier e-mail and are aware that the SPI annual board election has started. If you are a registered contributing member with SPI, elections are at: http://members.spi-inc.org/vote/ and candidate statements are at: http://www.spi-inc.org/secretary/votes/vote5/ Voting closes July 28th. If you did not already register as an SPI contributing member, it is too late for this year. Please also note that the current volume of e-mail on the spi-private mailing list is due entirely to the election and is not at all typical of the list. ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ AgentM [EMAIL PROTECTED] ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutions since 1997 http://www.commandprompt.com/ ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
[HACKERS]
Hi, when searching the TODO list (http://www.postgresql.org/docs/faqs.TODO.html). i found this on the Monitoring section: o Allow protocol-level BIND parameter values to be logged http://archives.postgresql.org/pgsql-hackers/2006-02/msg00165.php But i don't understand why that thread is related to the TODO item, i'm missing something? -- Atentamente, Jaime Casanova Programming today is a race between software engineers striving to build bigger and better idiot-proof programs and the universe trying to produce bigger and better idiots. So far, the universe is winning. Richard Cook ---(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
[HACKERS] url for TODO item, is it right?
Sorry, i'm resending because i forgot the subject On 7/17/06, Jaime Casanova [EMAIL PROTECTED] wrote: Hi, when searching the TODO list (http://www.postgresql.org/docs/faqs.TODO.html). i found this on the Monitoring section: o Allow protocol-level BIND parameter values to be logged http://archives.postgresql.org/pgsql-hackers/2006-02/msg00165.php But i don't understand why that thread is related to the TODO item, i'm missing something? -- Atentamente, Jaime Casanova Programming today is a race between software engineers striving to build bigger and better idiot-proof programs and the universe trying to produce bigger and better idiots. So far, the universe is winning. Richard Cook -- Atentamente, Jaime Casanova Programming today is a race between software engineers striving to build bigger and better idiot-proof programs and the universe trying to produce bigger and better idiots. So far, the universe is winning. Richard Cook ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] url for TODO item, is it right?
On Mon, Jul 17, 2006 at 12:25:09AM -0500, Jaime Casanova wrote: when searching the TODO list (http://www.postgresql.org/docs/faqs.TODO.html). i found this on the Monitoring section: o Allow protocol-level BIND parameter values to be logged http://archives.postgresql.org/pgsql-hackers/2006-02/msg00165.php But i don't understand why that thread is related to the TODO item, i'm missing something? Possibly the message renumbering that Tom griped about: http://archives.postgresql.org/pgsql-www/2006-07/msg00061.php -- Michael Fuhr ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
