Re: Unlogged tables, persistent kind

On Mon, Apr 25, 2011 at 1:42 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> On Mon, Apr 25, 2011 at 5:04 AM, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
>> On Mon, Apr 25, 2011 at 8:14 AM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>>> On Apr 24, 2011, at 1:22 PM, Simon Riggs <simon(at)2ndQuadrant(dot)com> wrote:
>>>> Unlogged tables are a good new feature.
>>>
>>> Thanks.
>>>
>>>> I noticed Bruce had mentioned they were the equivalent of NoSQL, which
>>>> I don't really accept.
>>>
>>> Me neither. I thought that was poorly said.
>>>
>>>> Heap blocks would be zeroed if they were found to be damaged, following a crash.
>>>
>>> The problem is not so much the blocks that are damaged (e.g. half-written, torn page) but the ones that were never written at all. For example, read page A, read page B, update tuple on page A putting new version on page B, write one but not both of A and B out to the O/S, crash.  Everything on disk is a valid page, but they are not coherent taken as a whole.  It's normally XLOG replay that fixes this type of situation...
>>
>> Not really sure it matters what the cause of data loss is, does it?
>> The zeroing of the blocks definitely causes data loss but the
>> intention is to bring the table back to a consistent physical state,
>> not to in any way repair the data loss.
>
> Right, but the trick is how you identify which blocks you need to
> zero.  You used the word "damaged", which to me implied that the block
> had been modified in some way but ended up with other than the
> expected contents, so that something like a CRC check might detect the
> problem.  My point (as perhaps you already understand) is that you
> could easily have a situation where every block in the table passes a
> hypothetical block-level CRC check, but the table as a whole is still
> damaged because update chains aren't coherent.  So you need some kind
> of mechanism for identifying which portions of the table you need to
> zero to get back to a guaranteed-coherent state.

That sounds like progress.

The current mechanism is "truncate complete table". There are clearly
other mechanisms that would not remove all data.

Probably the common case would be for insert-only data.

--
 Simon Riggs                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services