Re: [PATCHES] DOC: Wal update
Zdenek Kotala wrote: > Bruce Momjian wrote: > > Zdenek Kotala wrote: > >> I add few sentences how to write cache works on Solaris platform. > > > > I have updated our documentation with the attached patch. I was able to > > verify all the information in this change. > > Thanks. > > > I changed your original wording because the statement that UFS turns off > > write cache seemed unclear because the file system seems independent of > > the disk write cache. (What happens if you have UFS and ZFS on the same > > drive?) > > You are right UFS does not modify (write) cache setting and it is usually > disabled by default on most disks. If ZFS and UFS are on same disk, than ZFS > don't enable disk cache. It is a reason why put ZFS on separate disk is > better. See > http://www.solarisinternals.com/wiki/index.php/ZFS_Best_Practices_Guide#Storage_Pools > > > Anyway I think the attached wording is fine. > > Yes, it is. > > Zdenek > > PS: There are some articles about ZFS. > > http://www.solarisinternals.com/wiki/index.php/ZFS_Best_Practices_Guide > http://www.solarisinternals.com/wiki/index.php/ZFS_Evil_Tuning_Guide > http://www.solarisinternals.com/wiki/index.php/ZFS_for_Databases > > ---(end of broadcast)--- > TIP 3: Have you checked our extensive FAQ? > >http://www.postgresql.org/docs/faq -- Bruce Momjian <[EMAIL PROTECTED]>http://momjian.us EnterpriseDB http://postgres.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [PATCHES] Revised patch for fixing archiver shutdown behavior
I wrote: > One point needing discussion is that the postmaster is currently > coded not to send SIGUSR1 to the archiver if a fast-mode shutdown > is under way. I duplicated that in the added SIGUSR1 signal here, > but I wonder whether it is sane or not. Comments? After chewing on that for awhile, I decided it was bogus. If we are going to have a policy that the archiver gets a chance to archive everything, that shouldn't depend on fast vs. smart shutdown; those alternatives determine whether we kick clients out ungracefully, not whether we take extra risks with committed data. I think we should allow the archiver to finish out its tasks fully in all non-crash cases except one: if we got SIGTERM from init. In that case there's a very great risk of being SIGKILL'd before we can finish archiving. The postmaster cannot easily tell whether its SIGTERM came from init or not, but we can drive this off the archiver itself getting SIGTERM'd. I propose that if the archiver receives SIGTERM, it should cease to issue any new archive commands, but just wait till it sees the postmaster exit. (It can't exit right away, since there's a race condition: the postmaster might not have been SIGTERM'd yet, and might therefore spawn a new archiver, which would have no idea it's unsafe to do anything more.) There's an obvious failure mode in that, which is that a randomly issued SIGTERM to the archiver would shut down archiving indefinitely. We can guard against that with a timeout: the archiver should exit a minute or two after being SIGTERM'd, even if the postmaster is still there. That should certainly be enough delay to avoid the race condition, and if in fact everything is still hunky-dory the postmaster will immediately spawn a new archiver. Hence, attached revised patch ... regards, tom lane binN52EbkMKOk.bin Description: archiver-shutdown-2.patch ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] Revised patch for fixing archiver shutdown behavior
Alvaro Herrera <[EMAIL PROTECTED]> writes: > Hmm, so the postmaster is gone during the last archiving cycle? What > about syslogger? Is the archiver able to log stuff in the last cycle? The logger is no problem --- it quits when it sees EOF on its input pipe, which means that all upstream processes are gone. > The comment in line 2180 seems a bit bogus ...? Yeah, that could use a bit more work I guess, since "normal children" sounds like it would refer to more than just backends. regards, tom lane ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [PATCHES] Revised patch for fixing archiver shutdown behavior
Tom Lane wrote: > The attached patch fixes archiver shutdown in what seems to me to be > a sane way. With the patch, we send SIGQUIT to the archiver only for > panic-stop situations (backend crash or immediate-mode shutdown). > This is important because the postmaster is coded to send SIGQUIT > to the entire process group, meaning we'd also ungracefully terminate > any currently-running archive command, which does not seem like a good > idea for normal exit. Instead, the shutdown protocol is that *after* > the bgwriter has quit, we send SIGUSR1 (ie, the normal archiver wakeup > signal) to the archiver. This ensures that it will do a normal > archiving cycle after the last possible creation of WAL entries. Hmm, so the postmaster is gone during the last archiving cycle? What about syslogger? Is the archiver able to log stuff in the last cycle? The comment in line 2180 seems a bit bogus ...? -- Alvaro Herrerahttp://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
[PATCHES] Revised patch for fixing archiver shutdown behavior
The attached patch fixes archiver shutdown in what seems to me to be a sane way. With the patch, we send SIGQUIT to the archiver only for panic-stop situations (backend crash or immediate-mode shutdown). This is important because the postmaster is coded to send SIGQUIT to the entire process group, meaning we'd also ungracefully terminate any currently-running archive command, which does not seem like a good idea for normal exit. Instead, the shutdown protocol is that *after* the bgwriter has quit, we send SIGUSR1 (ie, the normal archiver wakeup signal) to the archiver. This ensures that it will do a normal archiving cycle after the last possible creation of WAL entries. The archiver is also modified to fall out of its wait loop more quickly when the postmaster has died (this is the same as Simon's previous one-liner patch), and to not exit until it has completed a full archive cycle since the postmaster died. The latter eliminates a race condition that existed before --- depending on timing, the CVS-HEAD archiver might or might not do a final archiving cycle. I also tweaked the postmaster so that the stats collector isn't told to quit until after the bgwriter finishes; this ensures that any stats reported from the bgwriter will be collected. One point needing discussion is that the postmaster is currently coded not to send SIGUSR1 to the archiver if a fast-mode shutdown is under way. I duplicated that in the added SIGUSR1 signal here, but I wonder whether it is sane or not. Comments? regards, tom lane binEUCN9e9ool.bin Description: archiver-shutdown.patch ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [PATCHES] [HACKERS] OUTER JOIN performance regression remains in 8.3beta4
"Alvaro Herrera" <[EMAIL PROTECTED]> writes: > Tom Lane wrote: > >> Comparing the behavior of this to my patch for HEAD, I am coming to the >> conclusion that this is actually a *better* planning method than >> removing the redundant join conditions, even when they're truly >> rendundant! The reason emerges as soon as you look at cases involving >> more than a single join. If we strip the join condition from just one >> of the joins, then we find that the planner insists on doing that join >> last, whether it's a good idea or not, because clauseful joins are >> always preferred to clauseless joins in the join search logic. > > Would it be a good idea to keep removing redundant clauses and rethink > the preference for clauseful joins, going forward? I don't understand what's going on here. The planner is choosing one join order over another because one join has more join clauses than the other? Even though some of those joins are entirely redundant and have no selectivity? That seems like a fortuitous choice made on entirely meaningless data. Is there some other source of data we could use to make this decision instead of the number of clauses? I would suggest the selectivity but from the sound of it that's not going to help at all. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's RemoteDBA services! ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] [HACKERS] Archiver behavior at shutdown
On Wed, 2008-01-09 at 10:15 -0500, Tom Lane wrote: > Simon Riggs <[EMAIL PROTECTED]> writes: > > Not sure why this hasn't being applied yet for 8.3 > > Because it doesn't fix the problem ... which is that the postmaster > kills the archiver (and the stats collector too) at what is now the > wrong point in the shutdown sequence. The original bug report states the problem as being that the archiver stays for a noticeable period after postmaster shutdown. My patch fixes that very safely. It doesn't fix your request for redesign, which I accept is still pending and I've explained why. I don't see any reason to leave the original problem hanging just because the fix isn't as wide as we might really like. -- Simon Riggs 2ndQuadrant http://www.2ndQuadrant.com ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [PATCHES] [HACKERS] Archiver behavior at shutdown
Simon Riggs <[EMAIL PROTECTED]> writes: > Not sure why this hasn't being applied yet for 8.3 Because it doesn't fix the problem ... which is that the postmaster kills the archiver (and the stats collector too) at what is now the wrong point in the shutdown sequence. regards, tom lane ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [PATCHES] DOC: Wal update
Bruce Momjian wrote: Zdenek Kotala wrote: I add few sentences how to write cache works on Solaris platform. I have updated our documentation with the attached patch. I was able to verify all the information in this change. Thanks. I changed your original wording because the statement that UFS turns off write cache seemed unclear because the file system seems independent of the disk write cache. (What happens if you have UFS and ZFS on the same drive?) You are right UFS does not modify (write) cache setting and it is usually disabled by default on most disks. If ZFS and UFS are on same disk, than ZFS don't enable disk cache. It is a reason why put ZFS on separate disk is better. See http://www.solarisinternals.com/wiki/index.php/ZFS_Best_Practices_Guide#Storage_Pools Anyway I think the attached wording is fine. Yes, it is. Zdenek PS: There are some articles about ZFS. http://www.solarisinternals.com/wiki/index.php/ZFS_Best_Practices_Guide http://www.solarisinternals.com/wiki/index.php/ZFS_Evil_Tuning_Guide http://www.solarisinternals.com/wiki/index.php/ZFS_for_Databases ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [PATCHES] [HACKERS] Archiver behavior at shutdown
On Sat, 2008-01-05 at 12:09 +, Simon Riggs wrote: > On Fri, 2008-01-04 at 17:28 +0900, Fujii Masao wrote: > > Simon Riggs wrote: > > > > > My original one line change described on bug 3843 seems like the best > > > solution for 8.3. > > > > > > > +1 > > Is this change in time for RC1? > > Patch attached. Not sure why this hasn't being applied yet for 8.3 We have a small problem, a fix and a user voting for the fix. Can we discuss, briefly? -- Simon Riggs 2ndQuadrant http://www.2ndQuadrant.com ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] win32.mak patch
On Wed, Jan 09, 2008 at 02:40:42PM +0900, Hiroshi Saito wrote: > Hi Magnus. > > From: "Magnus Hagander" <[EMAIL PROTECTED]> > > > >I see the problem now. In my dev kit, there is no error for using > >_USE_32BIT_TIME_T on Win64. That's why I got caught up in your patch being > >wrong. > > Umm,... It is very strange.?_? > C:\Program Files\Microsoft Visual Studio 8\VC\include\crtdefs.h(493) as > below... > -- > #ifdef _USE_32BIT_TIME_T > #ifdef _WIN64 > #error You cannot use 32-bit time_t (_USE_32BIT_TIME_T) with _WIN64 > #undef _USE_32BIT_TIME_T > #endif > #else > #if _INTEGRAL_MAX_BITS < 64 > #define _USE_32BIT_TIME_T > #endif > #endif > -- Yes, it's strange - I don't have that. Different versions, I guess. > >A question there though - do we care about the length of time_t on client > >platforms, or should we instead just disable the whole check for the > >client? AFAICS we don't expose time_t at all on the client, so why should > >we force libpq *clients* to build with 32-bit time_t? Shouldn't we go with > >the attached patch instead? > > > >It makes the win64 compile pass for me, but the linker step fails badly > >with: > >libpqdll.def : error LNK2001: unresolved external symbol PQbackendPID > >libpqdll.def : error LNK2001: unresolved external symbol PQbinaryTuples > >libpqdll.def : error LNK2001: unresolved external symbol PQcancel > >libpqdll.def : error LNK2001: unresolved external symbol PQclear > > > >for every export we have. Hiroshi, do you see that as well, or is > >something broken > >in my win64 environment? I'm running "nmake /f win32.mak CPU=AMD64" to > >build per our documentation, is that correct? > > Ah yes, however, the 64-bit build environment is created by the command > which Microsoft offers. > As for it, CPU=AMD64 is already defined. Then, I look at a good result > after your patch. > http://winpg.jp/~saito/pg83/WIN32MAK_AMD64_PATCH.txt Ok. My build env is probably broken then for 64-bit. I'll go ahead and apply this patch then. //Magnus ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [PATCHES] win32.mak patch
On 08/01/2008, Magnus Hagander <[EMAIL PROTECTED]> wrote: > On Thu, Dec 20, 2007 at 10:02:24AM +0900, Hiroshi Saito wrote: > A question there though - do we care about the length of time_t on client > platforms, or should we instead just disable the whole check for the > client? AFAICS we don't expose time_t at all on the client, so why should > we force libpq *clients* to build with 32-bit time_t? Shouldn't we go with > the attached patch instead? That makes sense to me - why dictate to client apps when we don't need to. We can always change the check in the future in the unlikely event that we do expose time_t - which I can't imagine being in anything other than a major release. /D ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [PATCHES] Fix for _outAgg()
On Tue, 2008-01-08 at 23:08 -0500, Tom Lane wrote: > Hmm, I think that must be my fault, but I'm not sure how it got by me > ... I'm usually pretty careful about adding outfuncs support when I add > a node field. Patch looks good, please apply. Applied to HEAD. -Neil ---(end of broadcast)--- TIP 6: explain analyze is your friend
