On Tue, Feb 10, 2015 at 9:52 AM, Xavier Stevens wrote: > I'm trying to write a logical decoding plugin and I'm seeing some > interesting behavior around the startup callback. When I use psql and the > built-in SQL functions (like pg_logical_slot_peek_changes) to use my module > I see the startup_cb get called. I have written my own streaming replication > client and for some reason when I use my client the startup_cb does not get > called, but I can still see the changes just fine. The reason why the > startup_cb is particularly important in my case, is I'm trying to set two > dynamic OIDs for PostGIS geometry and geography types. I've tried setting > them both as globals and as part of the output_plugin_private data. > > Any idea what's wrong here? Did I miss something in the streaming > replication documentation? Not sure, I would imagine that your problem is in the manipulation of the memory contexts related to the decoder plugin and the way your variables are saved. The documentation states that startup_cb is called each time a replication slot is created or when a slot is asked to stream changes, be it through the psql interface or using the replication protocol: http://www.postgresql.org/docs/devel/static/logicaldecoding-output-plugin.html#LOGICALDECODING-OUTPUT-PLUGIN-CALLBACKS Just in case, I have just done a quick test with pg_recvlogical on latest HEAD of REL9_4_STABLE and the startup_cb gets called: DEBUG: received replication command: IDENTIFY_SYSTEM DEBUG: received replication command: START_REPLICATION SLOT "slot" LOGICAL 0/0 LOG: called startup_cb_wrapper Note that on 9.5 (master HEAD at c619c23) I am seeing an assertion failure. What is the server version you are using? I would imagine 9.4 but let's be sure. Regards, -- Michael -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
