Re: Data loss, vacuum, transaction wrap-around - Mailing list pgsql-hackers

[ Shrugs ] and looks at other database systems ...

CA has put Ingres into Open Source last year.

Very reliable system with a replicator worth looking at.

Just a thought.




-------- Ursprüngliche Nachricht --------
Betreff: Re: [HACKERS] Data loss, vacuum, transaction wrap-around
Datum: Sat, 19 Feb 2005 09:15:14 -0500 (EST)
Von: pgsql@mohawksoft.com
An: "Tom Lane" <tgl@sss.pgh.pa.us>
CC: pgsql@mohawksoft.com, "Russell Smith" <mr-russ@pws.com.au>,    pgsql-hackers@postgresql.org
Referenzen: <16672.24.91.171.78.1108743398.squirrel@mail.mohawksoft.com>    <19175.1108746609@sss.pgh.pa.us> 
<200502191302.58099.mr-russ@pws.com.au>    <16585.24.91.171.78.1108780763.squirrel@mail.mohawksoft.com> 
<6391.1108784131@sss.pgh.pa.us>
> pgsql@mohawksoft.com writes:>> I think there should be a 100% no data loss fail safe.

OK, maybe I was overly broad in my statement, but I assumed a context that
I guess you missed. Don't you think that in normal operations, i.e. with
no hardware of OS failure, we should see any data loss as unacceptable?

If a bug causes data loss, it is a big deal right?>> Possibly we need to recalibrate our expectations here.  The
current>situation is that PostgreSQL will not lose data if:>>     1. Your disk drive doesn't screw up (eg, lie about
writecomplete,>        or just plain die on you).>     2. Your kernel and filesystem don't screw up.>     3. You follow
theinstructions about routine vacuuming.>     4. You don't hit any bugs that we don't know about.>
 

See, here is where I strongly disagree.Items (1) and (2) are completely
out of our control and no one would blame PostgreSQL.

Item (4) is an issue with all software, every now and then people hit bugs
and the bug is reported and assumed to get fixed.

Item (3) is just nasty, RTFM or else sucka! I think it is a very user
hostile stance.

> I agree that it's a nice idea to be able to eliminate assumption #3 from> our list of gotchas, but the big picture is
thatit's hard to believe> that doing this will make for a quantum jump in the overall level of> reliability.  I think I
listedthe risks in roughly the right order of> severity ...
 

Sometimes the edge conditions of a problem are not so obscure. I think (3)
is a huge issue, iamgine I'm in this meeting:

DBA: We can't use PostgreSQL, if we forget to do normal maintenence we'll
lose all our data.

ME: Well, there is an amount of truth in that, but we just won't forget.

DBA: Sorry, I don't trust it.

CTO: Mark, I think joe has some serious issues that need to be resolved
before we can move on this.

Boom!! Lost.
>> I'm willing to fix this for 8.1 (and am already in process of drafting a> patch), especially since it ties into some
otherknown problems such as> the pg_pwd/pg_group files not being properly reconstructed after PITR> recovery.  But I
thinkthat a "Chinese fire drill" is not called for,> and backpatching a significant but poorly tested change falls into
that>category IMHO.>>             regards, tom lane>> ---------------------------(end of
broadcast)--------------------------->TIP 7: don't forget to increase your free space map settings>
 


---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org