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