| From: | Simon Riggs <simon(at)2ndquadrant(dot)com> |
|---|---|
| To: | Heikki Linnakangas <heikki(at)enterprisedb(dot)com> |
| Cc: | Jacky Leng <lengjianquan(at)163(dot)com>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: Why copy_relation_data only use wal whenWALarchiving is enabled |
| Date: | 2007-10-17 16:33:22 |
| Message-ID: | 1192638802.4233.102.camel@ebony.site |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers pgsql-patches |
On Wed, 2007-10-17 at 15:02 +0100, Heikki Linnakangas wrote:
> Simon Riggs wrote:
> > If you've got a better problem statement it would be good to get that
> > right first before we discuss solutions.
>
> Reusing a relfilenode of a deleted relation, before next checkpoint
> following the commit of the deleting transaction, for an operation that
> doesn't WAL log the contents of the new relation, leads to data loss on
> recovery.
OK, thanks.
I wasn't aware we reused refilenode ids. The code in GetNewOid() doesn't
look deterministic to me, or at least isn't meant to be.
GetNewObjectId() should be cycling around, so although the oid index
scan using SnapshotDirty won't see committed deleted rows that shouldn't
matter for 2^32 oids. So what gives?
--
Simon Riggs
2ndQuadrant http://www.2ndQuadrant.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Heikki Linnakangas | 2007-10-17 16:36:48 | Re: Why copy_relation_data only use wal whenWALarchivingis enabled |
| Previous Message | Dave Page | 2007-10-17 16:09:25 | Re: rolcanlogin vs. the flat password file |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Heikki Linnakangas | 2007-10-17 16:36:48 | Re: Why copy_relation_data only use wal whenWALarchivingis enabled |
| Previous Message | Tom Lane | 2007-10-17 15:47:34 | Re: BUG #3681: fillers are NULL in pgbench |