Re: [HACKERS] Help with finding checkpoint code

]) -- J. R. Nield [EMAIL PROTECTED] ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster

Re: [HACKERS] Database Caching

:15, Bruce Momjian wrote: Do we want to add query caching to the TODO list, perhaps with a question mark? --- Greg Sabino Mullane wrote: [snip] -- J. R. Nield [EMAIL PROTECTED] ---(end

Re: [HACKERS] PITR, checkpoint, and local relations

On Wed, 2002-08-07 at 23:41, Tom Lane wrote: J. R. Nield [EMAIL PROTECTED] writes: The xlog code must allow us to force an advance to the next log file, and truncate the archived file when it's copied so as not to waste space. Uh, why? Why not just force a checkpoint and remember

Re: [HACKERS] PITR, checkpoint, and local relations

AS SELECT...'. So I will remove the local buffer manager as part of the PITR patch, unless there is further objection. On Fri, 2002-08-02 at 00:49, Tom Lane wrote: J. R. Nield [EMAIL PROTECTED] writes: I am working on a way to do this with a signal, using holdoffs around calls into the storage

Re: [HACKERS] PITR, checkpoint, and local relations

the issue I'm raising? Have I made some kind of blunder, so that this is really not a problem? -- J. R. Nield [EMAIL PROTECTED] ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister

Re: [HACKERS] PITR, checkpoint, and local relations

with the local buffer manager if they continue to work as they do now, which involves major changes. We also have to checkpoint at the start, and flush the log at the end. -- J. R. Nield [EMAIL PROTECTED] ---(end of broadcast)--- TIP 4: Don't 'kill -9

Re: [HACKERS] PITR, checkpoint, and local relations

On Fri, 2002-08-02 at 16:01, Tom Lane wrote: J. R. Nield [EMAIL PROTECTED] writes: The predicate for files we MUST (fuzzy) copy is: File exists at start of backup File exists at end of backup Right, which seems to me to negate all these claims about needing a (horribly messy) way

Re: [HACKERS] PITR, checkpoint, and local relations

time for speed without fear of data-loss. Didn't we have this discussion before? How is this any worse than a table scan? -- J. R. Nield [EMAIL PROTECTED] ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster

Re: [HACKERS] PITR, checkpoint, and local relations

: How do you get atomic block copies otherwise? Eh? The kernel does that for you, as long as you're reading the same-size blocks that the backends are writing, no? Good point. Vadim -- J. R. Nield [EMAIL PROTECTED] ---(end of broadcast

Re: [HACKERS] PITR, checkpoint, and local relations

like a good idea? -- J. R. Nield [EMAIL PROTECTED] ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])

[HACKERS] PITR, checkpoint, and local relations

on the hot backup issue. -- J. R. Nield [EMAIL PROTECTED] ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])

Re: [HACKERS] Issues Outstanding for Point In Time Recovery (PITR)

released to the PostgreSQL Development group by Progress and Multera, or do they still claim copyright interest in it? Regards, J.R. Nield On Thu, 2002-07-18 at 12:56, Richard Tucker wrote: -Original Message- From: J. R. Nield [mailto:[EMAIL PROTECTED]] Sent: Wednesday, July 17

Re: [HACKERS] Issues Outstanding for Point In Time Recovery (PITR)

, then we can't recycle or delete any logs for the duration of the backup, and we have to save them. So I'll finish the XLOG support for this, and then think about the correct way to walk through all the files. -- J. R. Nield [EMAIL PROTECTED] ---(end of broadcast

Re: [HACKERS] Issues Outstanding for Point In Time Recovery (PITR)

/feature-set to make the 7.3 release? -- J. R. Nield [EMAIL PROTECTED] ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html

Re: [HACKERS] pgbench questions

it was done before. ;John Nield -- J. R. Nield [EMAIL PROTECTED] ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]

Re: [HACKERS] please help on query

On Thu, 2002-07-11 at 11:22, Luis Alberto Amigo Navarro wrote: I can't improve performance on this query: Blame Canada! -- J. R. Nield [EMAIL PROTECTED] ---(end of broadcast)--- TIP 6: Have you searched our list archives? http

[HACKERS] Issues Outstanding for Point In Time Recovery (PITR)

have the known-good LSN greatest lower bound. backup system: Play-Forward File Recovery or PFFR: The process of bringing an individual backup file up to date. -- J. R. Nield [EMAIL PROTECTED] ---(end of broadcast

Re: [HACKERS] Issues Outstanding for Point In Time Recovery (PITR)

On Thu, 2002-07-04 at 11:45, J. R. Nield wrote: One other item that should be here: The big items so-far are: §1 - Logging Relation file creation, truncation, and removal This is mostly done. Can do infinte play-forward from online logs. §2

Re: [HACKERS] Vacuum Daemon

point me to this discussion, or summarize what the problem was? Was his proposal to keep tuple versions in the UNDO AM, or only pointers to them? The referred-to message seems to be about something else. ;jrnield -- J. R. Nield [EMAIL PROTECTED] ---(end of broadcast

Re: [HACKERS] Vacuum Daemon

On Sat, 2002-06-29 at 21:55, Tom Lane wrote: J. R. Nield [EMAIL PROTECTED] writes: I do not think that is the case; and anyway we've pretty much rejected Vadim's notion of going to an Oracle-style UNDO buffer. Could someone point me to this discussion, or summarize what the problem

Re: [HACKERS] Index Scans become Seq Scans after VACUUM ANALYSE

On Sun, 2002-06-23 at 21:29, J. R. Nield wrote: If is impossible to do what you want. You can not protect against... Wow. The number of typo's in that last one was just amazing. I even started with one. Have an nice weekend everybody :-) ;jrnield -- J. R. Nield [EMAIL PROTECTED

Re: [HACKERS] Index Scans become Seq Scans after VACUUM ANALYSE

competitors. Sincerely, J. R. Nield -- J. R. Nield [EMAIL PROTECTED] ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org

Re: [HACKERS] Index Scans become Seq Scans after VACUUM ANALYSE

On Sun, 2002-06-23 at 23:40, Curt Sampson wrote: On 23 Jun 2002, J. R. Nield wrote: If is impossible to do what you want. You can not protect against partial writes without writing pages twice and calling fdatasync between them while going through a generic filesystem. I agree

Re: [HACKERS] Index Scans become Seq Scans after VACUUM ANALYSE

On Mon, 2002-06-24 at 17:16, Tom Lane wrote: I think you have been missing the point... Yes, this appears to be the case. Thanks especially to Curt for clearing things up for me. -- J. R. Nield [EMAIL PROTECTED] ---(end of broadcast

Re: [HACKERS] Index Scans become Seq Scans after VACUUM ANALYSE

On Sat, 2002-06-22 at 19:17, Bruce Momjian wrote: J. R. Nield wrote: One other point: Page pre-image logging is fundamentally the same as what Jim Grey's book[1] would call careful writes. I don't believe they should be in the XLOG, because we never need to keep the pre-images after

Re: [HACKERS] Index Scans become Seq Scans after VACUUM ANALYSE

found an imaginary race condition there once :-) ;jnield Well, whether or not there's a cheap way depends on whether you consider fsync to be cheap. :-) It's never cheap :-( -- J. R. Nield [EMAIL PROTECTED] ---(end of broadcast

Re: [HACKERS] Index Scans become Seq Scans after VACUUM ANALYSE

know how hard this would be We already log that stuff. The page images are in addition to the Logical Changes, so we could just stop logging the page images. -- J. R. Nield [EMAIL PROTECTED] ---(end of broadcast)--- TIP 3: if posting

Re: [HACKERS] Index Scans become Seq Scans after VACUUM ANALYSE

implement ping-pong writes of some kind if we want protection from partial writes. Does any of this make sense? ;jrnield [1] Grey, J. and Reuter, A. (1993). Transaction Processing: Concepts and Techniques. Morgan Kaufmann. -- J. R. Nield [EMAIL PROTECTED