Re: WAL-based allocation of XIDs is insecure

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

Browse pgsql-hackers by date

  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