Re: pgsql: Create a "relation mapping" infrastructure to support changing

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

In response to

Responses

Browse pgsql-committers by date

  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

Browse pgsql-hackers by date

  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