Message-ID: <552D79D3.4040801@BlueTreble.com>
Date: Tue, 14 Apr 2015 15:34:27 -0500
From: Jim Nasby <Jim.Nasby@BlueTreble.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9;
 rv:31.0) Gecko/20100101 Thunderbird/31.4.0
MIME-Version: 1.0
To: dgabriel <gabriel.dodan@gmail.com>, <pgsql-performance@postgresql.org>
Subject: Re: unlogged tables
References: <005501cca0ad$b9478440$2bd68cc0$@devshock.com>
 <1428953502160-5845576.post@n5.nabble.com>
 <CAJghg4+NoOaip1VaBK9+cY-LYjmUr_9kFNZ3sdWq5wQRNVc9HA@mail.gmail.com>
 <CAKFQuwYtdCF1BFx7pji78tshjUD-oVCoOOnBcr935_tq5gY-Ag@mail.gmail.com>
 <1429026970751-5845650.post@n5.nabble.com>
In-Reply-To: <1429026970751-5845650.post@n5.nabble.com>
Content-Type: text/plain; charset="windows-1252"; format=flowed
Content-Transfer-Encoding: 7bit
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 14 Apr 2015 20:34:35.3527 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR11MB0676
X-Pg-Spam-Score: -1.9 (-)
List-Archive: <http://archives.postgresql.org/pgsql-performance>
List-Help: <mailto:majordomo@postgresql.org?body=help>
List-ID: <pgsql-performance.postgresql.org>
List-Owner: <mailto:pgsql-performance-owner@postgresql.org>
List-Post: <mailto:pgsql-performance@postgresql.org>
List-Subscribe: <mailto:majordomo@postgresql.org?body=sub%20pgsql-performance>
List-Unsubscribe: 
 <mailto:majordomo@postgresql.org?body=unsub%20pgsql-performance>
X-Mailing-List: pgsql-performance
Precedence: bulk
Sender: pgsql-performance-owner@postgresql.org

On 4/14/15 10:56 AM, dgabriel wrote:
> David G Johnston wrote
>> 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?
>
> If is possible to restore the table at last checkpoint state that will be
> more than enough. I don't care about the changes since last checkpoint, I am
> willing to lose those changes.  There are use cases where is acceptable to
> lose some data, for example in a cache system, it is not a big issue if we
> lose some cached data.

It is not. Unless you ensure that data is written to WAL (on disk) 
BEFORE it is written to the data pages, you will probably have 
corruption after a crash, and have no way to prevent or possibly even 
detect the corruption.
-- 
Jim Nasby, Data Architect, Blue Treble Consulting
Data in Trouble? Get it in Treble! http://BlueTreble.com


-- 
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance