Re: [PATCHES] Expose checkpoint start/finish times into SQL.
On Apr 3, 2008, at 10:33 PM, Tom Lane wrote: Theo claimed he had a reason for wanting to know the latest checkpoint time, *without* any intention of time-extended tracking of that; but he didn't say what it was. If there is a credible reason for that then it might justify a patch of this nature, but I don't see that the reasons that have been stated so far in the thread hold any water. We had a recent event where the system stopped checkpointing, which eventually lead to Robert Treat's therapy session at PostgreSQL Conference East. If you have been good to be able to remotely (via SQL) monitor the system to ensure that the last checkpoint start time is within a reasonable window from current_timestamp. My patch was clearly single purposed and never intended to be a SQL accessible log of checkpoint times. So, in reality, the "finish time" of the checkpoint is really not of any importance to me either. -- Theo Schlossnagle Esoteric Curio -- http://lethargy.org/ OmniTI Computer Consulting, Inc. -- http://omniti.com/ -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
Re: [PATCHES] Expose checkpoint start/finish times into SQL.
On Apr 3, 2008, at 7:08 PM, Andrew Dunstan wrote: Joshua D. Drake wrote: Theo Schlossnagle wrote: First whack at exposing the start and finish checkpoint times into SQL. Why is that useful? For knowing how long checkpoints are taking. If they are taking too long you may need to adjust your bgwriter settings, and it is a serious drag to parse postgresql logs for this info. Even if this were true, surely the answer is to improve the logging. Has this feature been discussed on -hackers? I don't recall it (and my memory has plenty of holes in it), but I'm sure that after attending my talk last Sunday Theo hasn't sent in a patch for an undiscussed feature ;-) Andrew: I don't think this feature has been discussed on hackers. The patch took about 15 minutes to author, so it sounds like the most concise way to start a conversation. Seems silly to start the conversation on hackers with a patch. :-) Alvaro: Thanks, I flip that to GetCurrentTimestamp() Heikki: It it useful for knowing when the last checkpoint occurred. Like Robert, we have situations where reading the log file is a PITA -- so this provides that information. I originally planned on only adding the start time, but figured adding the end would make sense too. Tom: It worked for me in my testing, though I did not extensively tested. I didn't see anywhere the stats are zero'd out, so I believe the timestamp is zero at start and then only ever set to the starttime during a checkpoint invocation. I admittedly don't have a thorough understanding of that code -- but that segment (before my patch) looked pretty concise. -- Theo Schlossnagle Esoteric Curio -- http://lethargy.org/ OmniTI Computer Consulting, Inc. -- http://omniti.com/ -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
[PATCHES] Expose checkpoint start/finish times into SQL.
First whack at exposing the start and finish checkpoint times into SQL. -- Theo Schlossnagle Esoteric Curio -- http://lethargy.org/ OmniTI Computer Consulting, Inc. -- http://omniti.com/ checkpoint_exposed.patch Description: Binary data -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
Re: [HACKERS] [PATCHES] Dynamic Tracing docs
On Dec 1, 2006, at 6:56 PM, Tom Lane wrote: "Simon Riggs" <[EMAIL PROTECTED]> writes: This includes refactoring of some of the trace related GUC docs from config.sgml, so its all in the one place. Why exactly is that a good idea? Since DTrace is Solaris-only, this almost seems like an attempt to hide non-Solaris-specific information where people won't look for it. Moreover, the point of config.sgml is to describe all the configuration parameters in one place. We do not need to have people second-guessing that decision for random subsets of the parameters. There is high likelihood that DTrace will be present in FreeBSD 7.0 and Mac OS 10.5. So, 3 of the support platforms would make use of it. // Theo Schlossnagle // CTO -- http://www.omniti.com/~jesus/ // OmniTI Computer Consulting, Inc. -- http://www.omniti.com/ ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] [BUGS] BUG #2401: spinlocks not available on amd64
Tom Lane wrote: Bruce Momjian writes: Great, changes attached and applied. I removed the solaris_i386 and solaris_x86_64.s files and made just one solaris_x86.s. I updated the build system to use the new file, updated the macros, and added some documentation on the approach. Thanks. BTW, on the replacement of ldstub with cas: according to what I find in google, cas does not exist on pre-V9 SPARCs. Are we sure no one uses sparc v8 chips anymore? Is there any actual advantage to making that change? This is true, and can be addressed with #defines to pull in the old old code. Just to note, you can't run Solaris 10 or any future version of Solaris on sparcv8 either. Sparcv8plus is 3bit sparc code and it does support the cas operation. The instruction cas that operates on a word is more much efficient than the code that it replaced. I'm don't own or have access to any sparc machines old enough to have that issue (even on my guest accounts at my alma mater). If this is a concern, it seems more than reasonable to #elif the case in for that architecture in the sparc assembly file -- being open source, you'll no doubt alienate some dude who thinks its cool to run Postgres on his Sparc ELC. I'd remind everyone that the spinlock stuff is entirely optional at build time. I think it be more elegant approach to discontinue spinlock support on sparcv8 and older sparc architectures and just force them to use heavier weight locking mechanisms. I "accidentally" did this on my Sol10 amd64 box before I realized what the build system did. I also think it immensely useful to replace all of the tas subsystem with cas so that one could reliabily lock these atomics with the process id of the locker. This would allow extremely good diagnostics in the event that a backend process is abruptly teminated while holding a log on that shm segment. If the process ID was in there, it would then be a contition that is both diagnosable and recoverable. I could likely provide the cas bits and pieces to do this stuff on linux/freebsd/mac os x and windows on x86/64 sparcv8plus/sparcv9 and PPC if you think that would be useful. Best regards, Theo ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
