On Thu, May 5, 2011 at 8:45 PM, Kevin Grittner
<Kevin.Grittner@wicourts.gov> wrote:
> Simon Riggs <simon@2ndQuadrant.com> wrote:
>> Kevin Grittner <Kevin.Grittner@wicourts.gov> wrote:
>>> Simon Riggs <simon@2ndQuadrant.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
> necessity.
>
> 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.
Your response is definitely about "the other thread" on hackers.
Worth bringing it up because others might have been confused also.
No problem,
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
