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
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.
-Kevin