Skip site navigation (1) Skip section navigation (2)

Re: Clarifying File System Syncs

From: Josh Berkus <josh(at)agliodbs(dot)com>
To: elein <elein(at)varlena(dot)com>
Cc: sfpug(at)postgresql(dot)org
Subject: Re: Clarifying File System Syncs
Date: 2003-09-03 15:50:08
Message-ID: 200309030850.08752.josh@agliodbs.com (view raw or flat)
Thread:
Lists: sfpug
Elein,

> I know how to do this safely with the db down.
> I'm talking about the points of failure for
> a live system.
>
> I'm arguing for the erserver and need some fodder
> against file system "syncing".  Also, I want
> confirmation and someone else's words that the points
> of failure are the cache and intertwined transactions and
> incomplete transactions.

As far as I know, that's the entirety of the problem.   Neither transaction 
flushing nor sync operations is instantaneous; in a busy database, attempts 
to, for example, rsync the database files is more likely to result in partial 
or duplicate transactions than not.  The situation with the WAL files 
themselves is even worse; attempts to sync these files in /xlog would almost 
certainly result in errors.

I can give a detailed explanation if it's needed as a 2nd-party opinion.

The cache should actually not be a problem with sync-ing.   The shared buffer 
cache is just for pending transactions, and its contents therefore do not 
need to be sync-ed, and in theory the kernel cache should notice the request 
for in-memory data from the sync utility and supply the up-to-date files from 
memory if they are resident there.

-- 
Josh Berkus
Aglio Database Solutions
San Francisco

In response to

sfpug by date

Next:From: Josh BerkusDate: 2003-09-03 18:04:30
Subject: PostgreSQL track for PHP Con West
Previous:From: David WheelerDate: 2003-08-28 19:47:49
Subject: Re: Offset

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group