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

Re: Unlogged vs. In-Memory

From: "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov>
To: "Simon Riggs" <simon(at)2ndQuadrant(dot)com>
Cc: "Joshua Berkus" <josh(at)agliodbs(dot)com>, "Alvaro Herrera" <alvherre(at)commandprompt(dot)com>, "Robert Haas" <robertmhaas(at)gmail(dot)com>, "Rob Wultsch" <wultsch(at)gmail(dot)com>, "Magnus Hagander" <magnus(at)hagander(dot)net>, "Thom Brown" <thom(at)linux(dot)com>, "PostgreSQL Advocacy" <pgsql-advocacy(at)postgresql(dot)org>
Subject: Re: Unlogged vs. In-Memory
Date: 2011-05-05 19:45:53
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-advocacypgsql-hackers
Simon Riggs <simon(at)2ndQuadrant(dot)com> wrote:
> Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov> wrote:
>> Simon Riggs <simon(at)2ndQuadrant(dot)com> wrote:
>>> I doubt that anyone wants the current behaviour.
>> Current behavior would be an exact fit for a few use cases we
>> have.  Attempting to salvage some portion of the data on startup
>> after a crash would yield it unusable for the uses I have in
>> mind.  It would have either all be there, or all gone.
> Those words have been taken out of context, leading to what looks
> to me like a confusion.
Sorry, any misinterpretation wasn't intended.  I just wanted to be
clear that for my purposes it would be best if lack of a clean
shutdown caused *all* non-logged tables to come up empty.  I would
be using several of such tables to build up a single financial
transaction during user data entry.  Since that would be going
through a connection pool, the shared visibility of the tables is a
In our current framework it is possible to bounce the database
server without interruption of user services beyond brief clocking,
which would be supported by saving the contents on clean shutdown
for restoration on startup.  However, if the data appeared to be
present on startup, but portions of it were quietly missing or
modified, that could lead to the posting of an incorrect financial
transaction when the user was done and the software slammed data for
the WIP transaction into the permanent financial tables.
If you're not proposing to break any of that, I can still move to
them from the "normal" permanent tables we're currently using.
Again, if I misunderstood you, sorry for the noise.

In response to


pgsql-hackers by date

Next:From: Magnus HaganderDate: 2011-05-05 19:48:14
Subject: Re: FDW table hints
Previous:From: Simon RiggsDate: 2011-05-05 19:35:08
Subject: Re: Unlogged vs. In-Memory

pgsql-advocacy by date

Next:From: Simon RiggsDate: 2011-05-05 19:52:11
Subject: Re: Unlogged vs. In-Memory
Previous:From: Simon RiggsDate: 2011-05-05 19:35:08
Subject: Re: Unlogged vs. In-Memory

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