From: | Jeff Janes <jeff(dot)janes(at)gmail(dot)com> |
---|---|
To: | Yves Dorfsman <yves(at)zioup(dot)com> |
Cc: | "pgsql-performance(at)postgresql(dot)org" <pgsql-performance(at)postgresql(dot)org> |
Subject: | Re: unlogged tables |
Date: | 2015-04-14 16:58:46 |
Message-ID: | CAMkU=1wdMTE2w4iV2eLsA6rWXxzdkxFXE47ooGFE0-z1CjrY1g@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
On Tue, Apr 14, 2015 at 8:41 AM, Yves Dorfsman <yves(at)zioup(dot)com> wrote:
> On 2015-04-13 17:49, Jeff Janes wrote:
> >
> > One way would be to lock dirty buffers from unlogged relations into
> > shared_buffers (which hardly seems like a good thing) until the start of
> a
> > "super-checkpoint" and then write them all out as fast as possible
> (which kind
> > of defeats checkpoint_completion_target). And then if the crash happened
> > during a super-checkpoint, the data would still be inconsistent and need
> to be
> > truncated.
> >
>
> What do you call a "super-checkpoint"?
>
A hypothetical checkpoint which includes writing and flushing pages of
unlogged tables.
Presumably you wouldn't want every checkpoint to do this, because if done
the way I described the super-checkpoint is a vulnerable period. Crashes
that happen during it would result in truncation of the unlogged relation.
Since that is the very thing we want to avoid, you would want to make these
vulnerable periods rare.
Cheers,
Jeff
From | Date | Subject | |
---|---|---|---|
Next Message | Jeff Janes | 2015-04-14 17:37:19 | Re: unlogged tables |
Previous Message | dgabriel | 2015-04-14 15:56:10 | Re: unlogged tables |