Re: unlogged tables

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Andy Colson <andy(at)squeakycode(dot)net>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: unlogged tables
Date: 2010-12-07 23:00:57
Message-ID: AANLkTin9MKJ5EXA9q6Y5FV2Y4uppKn+TOqTUfTjn4Ks_@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Dec 7, 2010 at 5:31 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> On Tue, Dec 7, 2010 at 3:44 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2010-12-07 23:11:22 Re: Final(?) proposal for wal_sync_method changes
Previous Message Jan Urbański 2010-12-07 22:56:43 Re: pl/python improvements