| From: | Josh Berkus <josh(at)agliodbs(dot)com> |
|---|---|
| To: | Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov> |
| Cc: | Florian Weimer <fweimer(at)bfk(dot)de>, Alvaro Herrera <alvherre(at)commandprompt(dot)com>, Floris Bos / Maxnet <bos(at)je-eigen-domein(dot)nl>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: Multicolumn index corruption on 8.4 beta 2 |
| Date: | 2009-06-09 17:57:49 |
| Message-ID: | 4A2EA29D.800@agliodbs.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Alvaro, Kevin,
>> Yeah, AFAICT the writes are handed off to the operating system (just
>> not synced), so if it flushes its caches sanely at all there
>> shouldn't be a problem.
>
> I would certainly *hope* that's the case. We sometimes use fsync=off
> for conversions, where we plan to just start over if the conversion
> crashes, and set it to on when the conversion is done. It would be
> disturbing to discover that fsync=off also means "don't bother to
> write dirty buffers to the OS before shutdown."
It doesn't. But what I don't trust, and the *first* place I'd look for
problems, is whether the OS flushes *all* dirty buffers to disk in the
event the application gets killed.
That's why I want more information on Floris' case. Was 8.4 killed or
shut down with -m immediate? Or the os rebooted with 8.4 running?
--
Josh Berkus
PostgreSQL Experts Inc.
www.pgexperts.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Robert Haas | 2009-06-09 18:00:41 | Re: [HACKERS] Cursor with hold emits the same row more than once across commits in 8.3.7 |
| Previous Message | Jeff Davis | 2009-06-09 17:54:16 | Re: Cursor with hold emits the same row more than once across commits in 8.3.7 |