From: | Thomas Lockhart <lockhart(at)alumni(dot)caltech(dot)edu> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Hackers List <pgsql-hackers(at)postgresql(dot)org>, Vadim Mikheev <vadim(at)pgsql(dot)com> |
Subject: | Database startup info |
Date: | 2000-11-17 15:45:37 |
Message-ID: | 3A1552A1.A0B645E6@alumni.caltech.edu |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
I missed the proposal, discussion, implementation, and announcement of
the recent changes to make dump/reload more robust (it seems that I was
unsubscribed from -hackers for a few days, then out of town for a few
more :/ Amazing what a single week can bring!
Anyway, there were a couple of fields added to the pg_database table:
datistemplate and datallowconn. Tom, you mentioned that these were given
those names to reflect current functionality, but in the long run we
would likely have something closer to a "readonly" attribute.
Upcoming functionality like replication and distributed databases will
need the concept of "readonly" and/or "offline" to help with error
detection and recovery. Other databases (I'm familiar with Ingres) have
this concept already, with the database being allowed to change its
status to protect itself from further damage, and to protect users from
trying to use a damaged database.
These attributes would also help to manage some kinds of dump/restore
operations and will probably be helpful for WAL-related
rollback/rollforward operations (Vadim?).
Would it be reasonable to label these fields for their likely 7.2
functionality, rather than labeling them as they are now? Since this is
the first time they are appearing, it would be nice to not have to
change the names later...
Comments?
- Thomas
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2000-11-17 15:57:09 | Re: Varchar standard compliance |
Previous Message | Thomas Lockhart | 2000-11-17 13:47:49 | Re: Failure to recognise new database |