On Tue, Nov 16, 2010 at 8:15 PM, Tom Lane <tgl@xxxxxxxxxxxxx> wrote:
Not surviving a crash is fine. IMHO, if we'd lose data in myisam files, I'm happy to lose them on pg nologging tables. I just want it to survive a stop / start operation. The benefits (think of multi-host syslog consolidation with FTS <drools> ) on these tables FAR outweigh the off-chance that a crash will cause me some heartache.
Bugs? What bugs :)
Honestly, I've only had a couple of *Prod* crashes (knocks on wood), but the need to restart occurs every now and then.
--Scott
Scott Mead <scott@xxxxxxxxxxxxxx> writes:Keep in mind that these tables are *not* going to survive any type of
> +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.
backend crash.
Not surviving a crash is fine. IMHO, if we'd lose data in myisam files, I'm happy to lose them on pg nologging tables. I just want it to survive a stop / start operation. The benefits (think of multi-host syslog consolidation with FTS <drools> ) on these tables FAR outweigh the off-chance that a crash will cause me some heartache.
Maybe my perceptions are colored because I deal with
Postgres bugs all the time, but I think of backend crashes as pretty
common, certainly much more common than an OS-level crash. I'm afraid
you may be expecting unlogged tables to be significantly more robust
than they really will be.
Bugs? What bugs :)
Honestly, I've only had a couple of *Prod* crashes (knocks on wood), but the need to restart occurs every now and then.
--Scott
regards, tom lane
