From: | "Vadim Mikheev" <vmikheev(at)sectorbase(dot)com> |
---|---|
To: | "PostgreSQL Development" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: WAL-based allocation of XIDs is insecure |
Date: | 2001-03-07 10:55:52 |
Message-ID: | 054801c0a6f5$2dad3be0$4879583f@sectorbase.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> The point is to make the allocation of XIDs and OIDs work the same way.
> In particular, if we are forced to reset the XLOG using what's stored in
> pg_control, it would be good if what's stored in pg_control is a value
> beyond the last-used XID/OID, not a value less than the last-used ones.
If we're forced to reset log (ie it's corrupted/lost) then we're forced
to dump, and only dump, data *because of they are not consistent*.
So, I wouldn't worry about XID/OID/anything - we can only provide user
with way to restore data ... *manually*.
If user really cares about his data he must
U1. Buy good disks for WAL (data may be on not so good disks).
U2. Set up distributed DB if U1. is not enough.
To help user with above we must
D1. Avoid bugs in WAL
D2. Implement WAL based BAR (so U1 will have sence).
D3. Implement distributed DB.
There will be no D2 & D3 in 7.1, and who knows about D1.
So, manual restoring data is the best we can do for 7.1.
And actually, "manual restoring" is what we had before,
anyway.
Vadim
From | Date | Subject | |
---|---|---|---|
Next Message | Vadim Mikheev | 2001-03-07 11:28:11 | Re: WAL-based allocation of XIDs is insecure |
Previous Message | Andrew McMillan | 2001-03-07 10:39:28 | Re: How to shoot yourself in the foot: kill -9 postmaster |