On Tue, Nov 16, 2010 at 7:21 PM, Glen Parker <glenebob@xxxxxxxxxx> wrote:
+1 -- Is there a technical reason to do a TRUNCATE on restart? I'd feel better if I could just have unlogged tables that survive unless something like a power-outage etc... I'm in the exact same boat here, lots of big logging tables that need to survive reboot, but are frustrating when it comes to WAL generation.
On 11/16/2010 03:24 PM, Karsten Hilbert wrote:I have been following loosely this discussion on HACKERS, but seem to have missed the part about truncating such tables on server restart.
PostgreSQL 9.1 is likely to have, as a feature, the ability to create
tables which are "unlogged", meaning that they are not added to the
transaction log, and will be truncated (emptied) on database restart.
Such tables are intended for highly volatile, but not very valuable,
data, such as session statues, application logs, etc.
I have an immediate use for unlogged tables (application logs), but having them truncate after even a clean server restart would be a show stopper. I keep log data for 2 months, and never back it up. Having it disappear after a system melt down is acceptable, but not after a clean restart. That would be utterly ridiculous!
+1 -- Is there a technical reason to do a TRUNCATE on restart? I'd feel better if I could just have unlogged tables that survive unless something like a power-outage etc... I'm in the exact same boat here, lots of big logging tables that need to survive reboot, but are frustrating when it comes to WAL generation.
As to the topic of the thread, I think pg_dump needs to dump unlogged tables by default.
-1 I disagree. I'm fine with having the loaded weapon pointed at my foot.
--Scott
--Scott
-Glen
--
Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
