Re: WAL-based allocation of XIDs is insecure - Mailing list pgsql-hackers

From Vadim Mikheev
Subject Re: WAL-based allocation of XIDs is insecure
Date
Msg-id 054801c0a6f5$2dad3be0$4879583f@sectorbase.com
Whole thread Raw
In response to WAL-based allocation of XIDs is insecure  (Tom Lane <tgl@sss.pgh.pa.us>)
List 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




pgsql-hackers by date:

Previous
From: Andrew McMillan
Date:
Subject: Re: How to shoot yourself in the foot: kill -9 postmaster
Next
From: "Vadim Mikheev"
Date:
Subject: Re: WAL-based allocation of XIDs is insecure