Re: logical changeset generation v4

On 2013-01-19 23:42:02 -0500, Steve Singer wrote:
> >5) Currently its only allowed to access catalog tables, its fairly
> >trivial to extend this to additional tables if you can accept some
> >(noticeable but not too big) overhead for modifications on those tables.
> >
> >I was thinking of making that an option for tables, that would be useful
> >for replication solutions configuration tables.
> 
> I think this will make the life of anyone developing a new replication
> system easier.  Slony has a lot of infrastructure for allowing slonik
> scripts to wait for configuration changes to popogate everywhere before
> making other configuration changes because you can get race conditions.  If
> I were designing a new replication system and I had this feature then I
> would try to use it to come up with a simpler model of propagating
> configuration changes.

I pushed support for this, turned out to be a rather moderate patch (after a
cleanup patch that was required anyway):

 src/backend/access/common/reloptions.c | 10 ++++++++++
 src/backend/utils/cache/relcache.c     |  9 ++++++++-
 src/include/utils/rel.h                |  9 +++++++++
 3 files changed, 27 insertions(+), 1 deletion(-)

With the (attached for convenience) patch applied you can do
# ALTER TABLE replication_metadata SET (treat_as_catalog_table = true);

to enable this.
What I wonder about is:
* does anybody have a better name for the reloption?
* Currently this can be set mid-transaction but it will only provide access for
  in the next transaction but doesn't error out when setting it
  mid-transaction. I personally find that acceptable, other opinions?

Greetings,

Andres Freund

-- 
 Andres Freund	                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services