Re: unlogged tables - Mailing list pgsql-hackers

From Robert Haas
Subject Re: unlogged tables
Date
Msg-id AANLkTin9MKJ5EXA9q6Y5FV2Y4uppKn+TOqTUfTjn4Ks_@mail.gmail.com
Whole thread Raw
In response to Re: unlogged tables  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Tue, Dec 7, 2010 at 5:31 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> On Tue, Dec 7, 2010 at 3:44 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>> I think a more relevant question is how complicated it'll be to issue
>>> those fsyncs --- do you have a concrete implementation in mind?
>
>> It can reuse most of the infrastructure we use for re-initializing
>> everything after a crash or unclean shutdown.  We just iterate over
>> every tablepace/dbspace directory and look for files with _init forks.
>>  If we find any then we open the main fork files and fsync() each one.
>
> I assume you meant "all the other fork files", but OK.

Oh, good point.

> Still, couldn't
> that be rather expensive in a large DB?

Well, that's why I asked whether it would be acceptable to take that
approach.  I'm guessing the overhead isn't too horrible.  If you
didn't want to take this approach but did want to survive a clean
shutdown, you would need to fsync everything written since the last
checkpoint.  The amount of additional stuff that needs to be written
here is just whatever you failed to write out during previous
checkpoints, which is probably not a ton.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


pgsql-hackers by date:

Previous
From: Jan Urbański
Date:
Subject: Re: pl/python improvements
Next
From: Tom Lane
Date:
Subject: Re: Final(?) proposal for wal_sync_method changes