Re: replicating DROP commands across servers - Mailing list pgsql-hackers

From Alvaro Herrera
Subject Re: replicating DROP commands across servers
Date
Msg-id 20141003183346.GF7043@eldon.alvh.no-ip.org
Whole thread Raw
In response to Re: replicating DROP commands across servers  (Heikki Linnakangas <hlinnakangas@vmware.com>)
Responses Re: replicating DROP commands across servers
Re: replicating DROP commands across servers
List pgsql-hackers
Heikki Linnakangas wrote:
> On 10/03/2014 09:06 PM, Alvaro Herrera wrote:

> >Well, the return value from get_object_address is an ObjectAddress.
> >It's simple enough to create an SQL wrapper that takes the
> >address_names/address_args arrays and return an ObjectAddress; would
> >this be useful?
> 
> An ObjectAddress consists of a classid, objid, and objsubid.
> pg_event_trigger_dropped_objects already returns all of those as
> separate fields. What am I missing?

Precisely the point is not returning those values, because they are
useless to identify the equivalent object in a remote database.  What we
need is the object names and other stuff used to uniquely identify it
"by user-visible name".  We transmit those name arrays to a remote
server, then on the remote server we can run get_object_address and get
the ObjectAddress, which has the classid,objid,objsubid values you cite ...
but for the remote server.  The object can then be dropped there.

Initially we thought that we would use the object_identity object for
this (which is why we invented that functionality and added the column
in 9.3), but this turned out not to work very well for unusual object
types; hence this patch.

-- 
Álvaro Herrera                http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services



pgsql-hackers by date:

Previous
From: Arthur Silva
Date:
Subject: Re: Fixed xloginsert_locks for 9.4
Next
From: Robert Haas
Date:
Subject: Re: test_shm_mq failing on anole (was: Sending out a request for more buildfarm animals?)