From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Jason Williams" <jwilliams(at)wc-group(dot)com> |
Cc: | "Dominic J(dot) Eidson" <sauron(at)the-infinite(dot)org>, pgsql-general(at)postgresql(dot)org |
Subject: | Re: always forced restart after status 139? |
Date: | 2002-03-18 19:47:17 |
Message-ID: | 1028.1016480837@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
"Jason Williams" <jwilliams(at)wc-group(dot)com> writes:
> The problem is this: we are planning to make this database for a commercial
> website that will handle financial transactions. What will happen if the
> database receives a seg fault and another user of the database is in the
> middle of submitting a "critical" update? I'm assuming it will rollback
> gracefully?
The seg fault as such is not a problem. What concerns me a tad is that
your buggy C extension may scribble on shared-memory disk buffers at
some point before it causes an outright crash. If corrupted data
manages to get written to disk before the backend crash and ensuing
restart, there's no guarantee we can clean it up. The odds of this are
probably not high (assuming you use conservatively-sized shared buffers,
rather than a large fraction of your address space as some here have
been known to suggest) ... but they're not zero.
I concur with Dominic: fix your extension *before* you put it in
production, not after. If you don't have confidence in your ability
to get the bugs out then maybe you shouldn't be writing C functions.
The interpreted PLs are a great deal safer.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Jason Williams | 2002-03-18 20:00:57 | Re: always forced restart after status 139? |
Previous Message | Dominic J. Eidson | 2002-03-18 19:10:22 | Re: always forced restart after status 139? |