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

Re: Unlogged tables, persistent kind

From: Leonardo Francalanci <m_lists(at)yahoo(dot)it>
To: Simon Riggs <simon(at)2ndQuadrant(dot)com>
Cc: robertmhaas <robertmhaas(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Unlogged tables, persistent kind
Date: 2011-04-26 07:49:57
Message-ID: 987768.25492.qm@web29015.mail.ird.yahoo.com (view raw or flat)
Thread:
Lists: pgsql-hackers
> > If that 1%  is random (not time/transaction related), usually you'd rather 
>have an empty  table.
> 
> Why do you think it would be random?

"Heap blocks would be zeroed if they were found to be damaged, following a 
crash."

If you erase full blocks, you have no idea what data you erased; it could be
something changed 1 hour ago, 1 month ago, 1 year ago. This is very different 
from,
say, synchronous_commit=off: in that case, "the most recent transactions may be
lost if the database should crash". In your case, "some (who knows which???) 
data
is lost". So, to me that sounds like random loss. I don't think that that is 
different
from a corrupted table. You're not deleting rows recently changed; you're 
deleting
everything that is "physically close" to it.

> > In other  words: is a table that is not consistant with anything else in the 
>db  useful?
> 
> That's too big a leap. Why would it suddenly be inconsistent with  the
> rest of the database?


If you delete some data, and you have no idea what data you lost, I don't think 
you have a
consistent db. Unless, of course, your table has no relation with any other 
table in the db.

Of course, all these thoughts are based on the assumption that I know what 
happens when a
block is erased; but my knowledge of postgresql internals is not so good, so I 
might be
*very* wrong

In response to

Responses

pgsql-hackers by date

Next:From: Alexander KorotkovDate: 2011-04-26 09:10:00
Subject: Re: GSoC 2011: Fast GiST index build
Previous:From: Simon RiggsDate: 2011-04-26 07:35:55
Subject: Re: branching for 9.2devel

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