Re: Logical Decoding Callbacks

From: Xavier Stevens <xavier(at)simple(dot)com>
To: Andres Freund <andres(at)2ndquadrant(dot)com>
Cc: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, PostgreSQL mailing lists <pgsql-general(at)postgresql(dot)org>
Subject: Re: Logical Decoding Callbacks
Date: 2015-02-10 23:47:36
Message-ID: CAFu3Q-+WGOCEL+cd88nvyugrdd2ewwSL_Miq1XmY631Av0h6xQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

There was no reason I needed to run full statements in this case. I just
didn't know I could get the type ids like that.

Thanks for all of your help Andres!

On Tue, Feb 10, 2015 at 1:23 PM, Andres Freund <andres(at)2ndquadrant(dot)com>
wrote:

> On 2015-02-10 10:33:41 -0800, Xavier Stevens wrote:
> > Sorry to raise the issue on startup_cb. I added a whole bunch of logging
> > statements and I was only running the section of code I wanted when the
> > startup callback had options.
>
> Heh.
>
> Just to make sure: You can pass options via replication protocol too.
>
> > This now gets me to the next issue I encounter. In my output plugin, I'm
> > trying to use the SPI interface to query about PostGIS OIDs in the
> startup
> > callback. Just calling SPI_connect() seems to be causing a segfault.
>
> > This is the last thing I see in the logs before the segfault occurs:
> >
> >
> https://github.com/xstevens/decoderbufs/blob/master/src/decoderbufs.c#L151
>
> The problem likely is that in the startup callback you're neither
> guaranteed to be in a transaction, nor to have a snapshot set up.
>
> It'd generally be easier to analyze such problems if you provide a
> backtrace (e.g. by enabling core files). Another generally very
> adviseable thing to do when developing code running in the backend is to
> enable assertions (you may already do that...).
>
> You can lookup types much easier than that btw. C.f.
> TypenameGetTypid(typname)
>
> But note that both that and what you do would possibly fail if there's
> more than one geometry type around. You could either hardcode postgis'
> schema name and use
> namespaceId = LookupExplicitNamespace(schemaname, false);
> typoid = GetSysCacheOid2(TYPENAMENSP, PointerGetDatum(typname),
> ObjectIdGetDatum(namespaceId));
> if (typoid == InvalidOid)
> elog(ERROR, "cache lookup failed for type %u", typoid);
>
> or be a bit more complex and lookup the postgis' extension's schema
> pg_extension.extnamespace first.
>
>
> Anyway, to run full queries in the startup callback you're going to have
> to do something like:
>
> if (!IsTransactionState())
> {
> tx_started = true;
> StartTransactionCommand();
> }
> PushActiveSnapshot(GetTransactionSnapshot());
>
> /* do your stuff */
>
> PopActiveSnapshot();
> if (tx_started)
> CommitTransactionCommand();
>
>
> Note that the begin, change, commit callbacks *do* run with a
> transaction and snapshot setup. But you can't run general SQL queries -
> only catalog tables (or tables marked as such) are accessible.
>
> Greetings,
>
> Andres Freund
>
> --
> Andres Freund http://www.2ndQuadrant.com/
> PostgreSQL Development, 24x7 Support, Training & Services
>

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Mathieu Basille 2015-02-11 00:52:41 Hardware requirements for a PostGIS server
Previous Message Jeremiah Ocasio 2015-02-10 23:26:32 Re: [ADMIN] Change postgresql encoding