Hi,

I'm curious as to how much (and what *type*) "bit rot"
is likely to creep into an "unattended" (un-managed?)
server over the long run. And, what (automated) actions
I can take to keep this in check (e.g., "registering"
persistent tables and routinely scrubbing "extra"
tables that applications forget to drop, etc.)

In a bug-less world, this shouldn't be an issue.
But... <grin>

Thanks,
--don

On 2011-02-01, D Yuniskis <not.going.to.be (AT) seen (DOT) com> wrote:
we run a number of unmanaged servers (the server management consists of
throwing canned SQL (DDL,DML) at them with each software upgrade)


the typical accumulted cruft is mainly obsolete functions, and a few
spooling tables that get left around (I try to use temporary tables as
much as possible)


--
⚂⚃ 100% natural

Hi Jasen,

On 2/2/2011 4:48 AM, Jasen Betts wrote:
I'm more concerned with temporary tables and the like that
are "orphaned" because a client (application) -- or the
server itself -- was terminated abnormally. Or, clients
that are just poorly written and waste server-side
resources, etc.

I'm working in an embedded system. Imagine PG running *in*
your cell phone with various "apps" talking to it. Apps
written by third parties of dubious quality, etc. Add to
this the fact that you (the human user) might elect to power
down the "phone" at any time -- without informing the
applications (clients) *or* server that you are going to do
so (e.g., you *could* pull the battery out of your phone
so that any "advance warning" tied to the power switch's
activation is circumvented).

Now, imagine running like this for years... in theory, the
resources that you don't *explicitly* use should remain
available *forever* -- regardless of how much misuse/abuse the
system is subjected to.

I suspect that forcing applications (clients) to "register"
tables and other resources that are intended to be durable
would give "me" (some piece of maintenance code running
alongside the RDBMS and clients) a means for identifying
"cruft" that might be left over from previous sessions.

Hopefully, transactions that are unceremoniously aborted
(i.e., server powered off mid-transaction) will correctly
be handled by PG itself (?). I want to know what things
outside PG's dominion should be tracked and handled by a
suitable agent taking the place of a human review of the
RDBMS's collective state.