Re: unlogged tables

On 4/13/15 3:49 PM, David G. Johnston wrote:
> On Monday, April 13, 2015, Matheus de Oliveira
> <matioli(dot)matheus(at)gmail(dot)com <mailto:matioli(dot)matheus(at)gmail(dot)com>> wrote:
> On Mon, Apr 13, 2015 at 4:31 PM, dgabriel <gabriel(dot)dodan(at)gmail(dot)com
> <javascript:_e(%7B%7D,'cvml','gabriel(dot)dodan(at)gmail(dot)com');>> wrote:
>
> "In the event of a normal shutdown, we can flush all the writes
> to disk
> so we know all the data has been written, so there is no need to
> truncate."
>
> Isn't possible to periodically flush data to disk and in case of
> crush
> postgres to load only the data that existed at last flush? The
> periodic
> flush could be configurable, for example every 30 minutes or
> after x rows
> updated/inserted.
>
> There is no such facility implemented for UNLOGGED TABLEs. That
> could be a feature request though.
>
> Well, that is half right anyway. UNLOGGED tables obey checkpoints just
> like any other table. The missing feature is an option to
> leaved restored the last checkpoint. Instead, not knowing whether there
> were changes since the last checkpoint, the system truncated the relation.
>
> What use case is there for a behavior that the last checkpoint data is
> left on the relation upon restarting - not knowing whether it was
> possible the other data could have been written subsequent?

Yeah, this is not something that would be very easy to accomplish,
because a buffer can get evicted and written to disk at any point. It
wouldn't be too hard to read every unlogged table during recovery and
see if there are any pages that were written after the last checkpoint,
but that obviously won't be very fast.

Actually, I suppose we could dedicate a fork for unlogged tables and use
that to record the newest LSN of any page that's been written out. But
if you have much of any write activity on the table that's probably
going to be completely useless.
--
Jim Nasby, Data Architect, Blue Treble Consulting
Data in Trouble? Get it in Treble! http://BlueTreble.com