Thread: pgsql: Rethink the way walreceiver is linked into the backend. Instead
pgsql: Rethink the way walreceiver is linked into the backend. Instead
From
heikki@postgresql.org (Heikki Linnakangas)
Date:
Log Message: ----------- Rethink the way walreceiver is linked into the backend. Instead than shoving walreceiver as whole into a dynamically loaded module, split the libpq-specific parts of it into dynamically loaded module and keep the rest in the main backend binary. Although Tom fixed the Windows compilation problems with the old walreceiver module already, this is a cleaner division of labour and makes the code more readable. There's also the prospect of adding new transport methods as pluggable modules in the future, which this patch makes easier, though for now the API between libpqwalreceiver and walreceiver process should be considered private. The libpq-specific module is now in src/backend/replication/libpqwalreceiver, and the part linked with postgres binary is in src/backend/replication/walreceiver.c. Modified Files: -------------- pgsql/src: Makefile (r1.49 -> r1.50) (http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/Makefile?r1=1.49&r2=1.50) pgsql/src/backend/bootstrap: bootstrap.c (r1.256 -> r1.257) (http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/bootstrap/bootstrap.c?r1=1.256&r2=1.257) pgsql/src/backend/replication: Makefile (r1.1 -> r1.2) (http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/replication/Makefile?r1=1.1&r2=1.2) README (r1.1 -> r1.2) (http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/replication/README?r1=1.1&r2=1.2) walreceiverfuncs.c (r1.1 -> r1.2) (http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/replication/walreceiverfuncs.c?r1=1.1&r2=1.2) pgsql/src/include/replication: walreceiver.h (r1.2 -> r1.3) (http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/include/replication/walreceiver.h?r1=1.2&r2=1.3) Added Files: ----------- pgsql/src/backend/replication: walreceiver.c (r1.1) (http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/replication/walreceiver.c?rev=1.1&content-type=text/x-cvsweb-markup) pgsql/src/backend/replication/libpqwalreceiver: Makefile (r1.1) (http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/replication/libpqwalreceiver/Makefile?rev=1.1&content-type=text/x-cvsweb-markup) libpqwalreceiver.c (r1.1) (http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/replication/libpqwalreceiver/libpqwalreceiver.c?rev=1.1&content-type=text/x-cvsweb-markup) Removed Files: ------------- pgsql/src/backend/replication/walreceiver: Makefile (http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/replication/walreceiver/Makefile) walreceiver.c (http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/replication/walreceiver/walreceiver.c)
On Wed, Jan 20, 2010 at 6:16 PM, Heikki Linnakangas <heikki@postgresql.org> wrote: > Log Message: > ----------- > Rethink the way walreceiver is linked into the backend. Instead than shoving > walreceiver as whole into a dynamically loaded module, split the > libpq-specific parts of it into dynamically loaded module and keep the rest > in the main backend binary. > > Although Tom fixed the Windows compilation problems with the old walreceiver > module already, this is a cleaner division of labour and makes the code > more readable. There's also the prospect of adding new transport methods > as pluggable modules in the future, which this patch makes easier, though for > now the API between libpqwalreceiver and walreceiver process should be > considered private. > > The libpq-specific module is now in src/backend/replication/libpqwalreceiver, > and the part linked with postgres binary is in > src/backend/replication/walreceiver.c. This commit is pretty cool! Thanks! And I found the small bug. Could you fix it? src/backend/replication/libpqwalreceiver/libpqwalreceiver.c > _PG_init(void) > { > /* Tell walreceiver how to reach us */ > if (walrcv_connect != NULL || walrcv_receive != NULL || walrcv_disconnect) > elog(ERROR, "libpqwalreceiver already loaded"); In the above branch on condition, the "walrcv_disconnect" should be compared with "NULL". Regards, -- Fujii Masao NIPPON TELEGRAPH AND TELEPHONE CORPORATION NTT Open Source Software Center
Re: pgsql: Rethink the way walreceiver is linked into the backend. Instead
From
Heikki Linnakangas
Date:
Fujii Masao wrote: > And I found the small bug. Could you fix it? > > src/backend/replication/libpqwalreceiver/libpqwalreceiver.c >> _PG_init(void) >> { >> /* Tell walreceiver how to reach us */ >> if (walrcv_connect != NULL || walrcv_receive != NULL || walrcv_disconnect) >> elog(ERROR, "libpqwalreceiver already loaded"); > > In the above branch on condition, the "walrcv_disconnect" should be compared > with "NULL". Thanks. "walrcv_disconnect" has the same effect as "walrcv_disconnect != NULL", but fixed for the sake of consistency. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com