Re: pgsql: Rethink the way walreceiver is linked into the backend. Instead
От | Fujii Masao |
---|---|
Тема | Re: pgsql: Rethink the way walreceiver is linked into the backend. Instead |
Дата | |
Msg-id | 3f0b79eb1001200252j41e768e2n63c573a8d3176ec3@mail.gmail.com обсуждение исходный текст |
Ответ на | pgsql: Rethink the way walreceiver is linked into the backend. Instead (heikki@postgresql.org (Heikki Linnakangas)) |
Ответы |
Re: pgsql: Rethink the way walreceiver is linked into
the backend. Instead
|
Список | pgsql-committers |
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
В списке pgsql-committers по дате отправления: