pg.ddx.io  pgsql-performance@postgresql.org mailing list archive  
help / color / mirror / Atom feed
From: Anibal David Acosta <aa@devshock.com>
To: 'Sergey Konoplev' <gray.ru@gmail.com>
To: 'Richard Huxton' <dev@archonet.com>
Cc: 'Stephen Frost' <sfrost@snowman.net>
Cc: pgsql-performance@postgresql.org
Subject: Re: unlogged tables
Date: Mon, 14 Nov 2011 14:05:51 -0300
Message-ID: <00ea01cca2ef$abcf3a30$036dae90$@devshock.com> (raw)
In-Reply-To: <CAL_0b1sSyTgMUxcRi+2ibTHHV4-qH3fvacsQUCbbeBsu0jYGAQ@mail.gmail.com>
References: <005501cca0ad$b9478440$2bd68cc0$@devshock.com>
	<20111111201822.GN24234@tamriel.snowman.net>
	<CAL_0b1t02q77ft2JWdjMv8q4vaGm=x__K0rzVkpNSvSy2-SjzA@mail.gmail.com>
	<4EC0D827.8090601@archonet.com>
	<CAL_0b1tuxi9YVhGKsNUSTZCUBXgOmppan7w+KkRZARbQ=u4P5w@mail.gmail.com>
	<4EC0EAD6.9010302@archonet.com>
	<CAL_0b1sSyTgMUxcRi+2ibTHHV4-qH3fvacsQUCbbeBsu0jYGAQ@mail.gmail.com>

Maybe an option like "Recover from file " will be useful
So, for example, daily some process do a COPY of entire table to a file 

In case of crash postgres recover content from the file.

:)



-----Mensaje original-----
De: Sergey Konoplev [mailto:gray.ru@gmail.com] 
Enviado el: lunes, 14 de noviembre de 2011 07:39 a.m.
Para: Richard Huxton
CC: Stephen Frost; Anibal David Acosta; pgsql-performance@postgresql.org
Asunto: Re: [PERFORM] unlogged tables

On 14 November 2011 14:17, Richard Huxton <dev@archonet.com> wrote:
> On 14/11/11 10:08, Sergey Konoplev wrote:
>>
>> On 14 November 2011 12:58, Richard Huxton<dev@archonet.com>  wrote:
> Let's say you were doing something like "UPDATE unlogged_table SET x=1 
> WHERE y=2". If a crash occurs during this command, there's no 
> guarantee that the affected disk pages were all updated. Worse, a 
> single page might be partially updated or even have rubbish in it 
> (depending on the nature of the crash).
>
> Without the WAL there's no way to check whether the table is good or 
> not, or even to know what the last updates were. So - the only safe 
> thing to do is truncate the unlogged tables.
>
> 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.

Thank you for the explanation. Now I understand it.

>
> --
>  Richard Huxton
>  Archonet Ltd
>



--
Sergey Konoplev

Blog: http://gray-hemp.blogspot.com
LinkedIn: http://ru.linkedin.com/in/grayhemp
JID/GTalk: gray.ru@gmail.com Skype: gray-hemp




view thread (42+ messages)  latest in thread

Message-ID: <00ea01cca2ef$abcf3a30$036dae90$@devshock.com>
Permalink:  ../00ea01cca2ef$abcf3a30$036dae90$@devshock.com/
Also on:    postgresql.org/message-id/00ea01cca2ef$abcf3a30$036dae90$@devshock.com

 · 

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-performance@postgresql.org
  Cc: aa@devshock.com, gray.ru@gmail.com, dev@archonet.com, sfrost@snowman.net
  Subject: Re: unlogged tables
  In-Reply-To: <00ea01cca2ef$abcf3a30$036dae90$@devshock.com>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox