Re: pgsql: Create a "relation mapping" infrastructure to support changing - Mailing list pgsql-committers

From Tom Lane
Subject Re: pgsql: Create a "relation mapping" infrastructure to support changing
Date
Msg-id 8688.1265583122@sss.pgh.pa.us
Whole thread Raw
In response to Re: pgsql: Create a "relation mapping" infrastructure to support changing  (Simon Riggs <simon@2ndQuadrant.com>)
Responses Re: pgsql: Create a "relation mapping" infrastructure to support changing  (Simon Riggs <simon@2ndQuadrant.com>)
List pgsql-committers
Simon Riggs <simon@2ndquadrant.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

pgsql-committers by date:

Previous
From: tgl@postgresql.org (Tom Lane)
Date:
Subject: pgsql: Work around deadlock problems with VACUUM FULL/CLUSTER on system
Next
From: Simon Riggs
Date:
Subject: Re: pgsql: Create a "relation mapping" infrastructure to support changing