Database startup info
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
Thomas Lockhart <lockhart@alumni.caltech.edu> writes:
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...
I don't have a problem with renaming "datallowconn" to "datoffline"
(and reversing its sense) if you feel like doing that --- but please
note that these are only field names, they do not constrain whatever
command-level API we might put on top of the thing later. In any
case, I'm not sure it's a good idea to call the thing "datoffline"
when changing it doesn't actively throw off current connections.
Names that are intended to be suggestive should be accurately
suggestive, IMHO. (Maybe I should've called it datallownewconn.)
As for datistemplate, that is NOT the same as datreadonly, and when
we get around to supporting read-only databases there should be a
separate column for that, IMHO. datistemplate is actually a permissions
bit (are people who are neither superuser nor the database owner
allowed to clone a particular database?) and has nothing to do with
whether the DB is read-only. When we have read-only functionality,
I'd want to change CREATE DATABASE to require the source to be
both datistemplate and datreadonly --- but there are also substantial
uses for databases that are readonly but not templates. So we need
two bits. (Perhaps readonly status should apply to schemas, not
databases, anyway --- haven't studied that part of the spec yet...)
In short: I think datistemplate is fine as is. If you want to tweak
the name or behavior of datallowconn, go for it (though implementing a
command to set it might be a better plan than just tweaking the field
name...)
regards, tom lane