Re: [HACKERS] [PATCHES] wal_checksum = on (default) | off
* Tom Lane: Florian Weimer [EMAIL PROTECTED] writes: Have you tried switching to Adler32 instead of CRC32? Is anything known about the error detection capabilities of Adler32? There's a lot of math behind CRCs but AFAIR Adler's method is pretty much ad-hoc. Correct me if I'm wrong, but the main reason for the WAL CRC is to detect partial WAL writes (due to improper caching, for instance). This means that you're out of the realm of traditional CRC analysis anyway, because the things you are guarding against are neither burts errors nor n-bit errors (for small n). ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] Async Commit, v21 (now: v22)
+para + Asynchronous commit provides different behaviour to setting + varnamefsync/varname = off, which is a server-wide + setting that will alter the behaviour of all transactions, + overriding the setting of varnamesynchronous_commit/varname, + as well as risking much wider data loss. With varnamefsync/varname + = off the WAL written but not fsynced, so data is lost only in case + of a system crash. Both WAL and datafiles written within the last + few seconds would be at risk, affecting all types of database + transactions. The precise number depends upon whether your operating + system is configured for automatic filesystem writeback and what the + delay is set too; Linux currently defaults to 30 seconds. With + asynchronous commit the WAL is not written to disk at all at commit + time, so data is lost if there is a database server crash, whether or + not the system crashes at the same time. +/para I think fsync=off also endagers metadata, while synchronous_commit=off should be perfectly safe as far as the metadata is concerned. Wouldn't this be worth mentioning as well? -- Florian Weimer[EMAIL PROTECTED] BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstraße 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 ---(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: [PATCHES] Async Commit, v21 (now: v22)
* Simon Riggs: I think fsync=off also endagers metadata, while synchronous_commit=off should be perfectly safe as far as the metadata is concerned. Wouldn't this be worth mentioning as well? Well, I think wider data loss covers it for me, but I don't have a problem with people wanting to detail the various problems that can occur. To be honest, I'm mostly concerned with the synchronous_commit=off does not wedge the whole database part of that statement. For me as a user, this is a crucial piece of information, and I don't like it when such information is merely implied. -- Florian Weimer[EMAIL PROTECTED] BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstraße 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 ---(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
