Tom Lane wrote:
> Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> writes:
>> Before we sprinkle all the global variables it touches with that, let me
>> explain what I meant by dividing walreceiver code differently between
>> dynamically loaded module and backend code. Right now I have to go to
>> sleep, though, but I'll try to get back to during the weekend.
> Yeah, nothing to be done till we get another buildfarm cycle anyway.
Ok, looks like you did that anyway, let's see if it fixed it. Thanks.
So what I'm playing with is to pull walreceiver back into the backend
executable. To avoid the link dependency, walreceiver doesn't access
libpq directly, but loads a module dynamically which implements this
bool walrcv_connect(char *conninfo, XLogRecPtr startpoint)
Establish connection to the primary, and starts streaming from 'startpoint'.
Returns true on success.
bool walrcv_receive(int timeout, XLogRecPtr *recptr, char **buffer, int
Retrieve any WAL record available through the connection, blocking for
maximum of 'timeout' ms.
This is the kind of API Greg Stark requested earlier
though I'm not planning to make it pluggable for 3rd party
The module doesn't need to touch backend internals much at all, no
tinkering with shared memory for example, so I would feel much better
about moving that out of src/backend. Not sure where, though; it's not
an executable, so src/bin is hardly the right place, but I wouldn't want
to put it in contrib either, because it should still be built and
installed by default. So I'm inclined to still leave it in
I've pushed that 'replication-dynmodule' branch in my git repo. The diff
is hard to read, because it mostly just moves code around, but I've
attached libpqwalreceiver.c here, which is the dynamic module part. You
can also browse the tree via the web interface
I like this division of labor much more than making the whole
walreceiver process a dynamically loaded module, so barring objections I
will review and test this more, and commit next week.
In response to
pgsql-hackers by date
|Next:||From: Heikki Linnakangas||Date: 2010-01-16 07:54:28|
|Subject: Re: Streaming replication and non-blocking I/O|
|Previous:||From: Markus Wanner||Date: 2010-01-16 06:51:00|
|Subject: Re: Testing with concurrent sessions|