Re: Streaming replication and non-blocking I/O
Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>
From: Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Magnus Hagander <magnus@hagander.net>, Andrew Dunstan <andrew@dunslane.net>, Fujii Masao <masao.fujii@gmail.com>, PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2010-01-16T07:49:42Z
Lists: pgsql-hackers
Attachments
- libpqwalreceiver.c (text/x-csrc)
Tom Lane wrote: > Heikki Linnakangas <heikki.linnakangas@enterprisedb.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 interface: 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 *len) Retrieve any WAL record available through the connection, blocking for maximum of 'timeout' ms. void walrcv_disconnect(void); Disconnect. This is the kind of API Greg Stark requested earlier (http://archives.postgresql.org/message-id/407d949e0912220336u595a05e0x20bd91b9fbc08d4d@mail.gmail.com), though I'm not planning to make it pluggable for 3rd party implementations yet. 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 src/backend/replication/ 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 (http://git.postgresql.org/gitweb?p=users/heikki/postgres.git;a=tree;h=refs/heads/replication-dynmodule;hb=replication-dynmodule) 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. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com