From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Simon Riggs <simon(at)2ndquadrant(dot)com> |
Cc: | pgsql-committers(at)postgresql(dot)org |
Subject: | Re: pgsql: Create a "relation mapping" infrastructure to support changing |
Date: | 2010-02-07 22:52:02 |
Message-ID: | 8688.1265583122@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-committers pgsql-hackers |
Simon Riggs <simon(at)2ndquadrant(dot)com> writes:
> Few questions:
> We XLogFlush() in normal running, but not in recovery. Would it be
> possible for the map changes to hit disk after the data changes in that
> case?
No, because the map change is flushed to disk on sight of the WAL record
anyway.
> What we're saying is if we process a relmap update WAL record then it
> doesn't really matter whether or not we commit that transaction?
Right. relmap update is committed independently of the surrounding
transaction.
> It would be useful to mention that the return value is volatile and can
> change across transactions or even within a transaction, just like ctid.
Hm. I thought it was more reasonable to treat it as "stable", which is
the normal case. You're right that there are some corner cases where it
could change without the caller's snapshot changing, but I'm not sure
it's worth worrying about.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Simon Riggs | 2010-02-07 23:06:41 | Re: pgsql: Create a "relation mapping" infrastructure to support changing |
Previous Message | Tom Lane | 2010-02-07 22:40:33 | pgsql: Work around deadlock problems with VACUUM FULL/CLUSTER on system |
From | Date | Subject | |
---|---|---|---|
Next Message | Simon Riggs | 2010-02-07 23:06:41 | Re: pgsql: Create a "relation mapping" infrastructure to support changing |
Previous Message | Simon Riggs | 2010-02-07 22:29:17 | Re: pgsql: Create a "relation mapping" infrastructure to support changing |