Streaming replication and non-blocking I/O
in [PgSql]
|
Prev: Sought after architectures for the PostgreSQL buildfarm?
Next: [HACKERS] 答复: questions about concurrency control in Postgresql
From: Heikki Linnakangas on 14 Dec 2009 14:05 Tom Lane wrote: > Heikki Linnakangas <heikki.linnakangas(a)enterprisedb.com> writes: >> BTW, something that's been bothering me a bit with this patch is that we >> now have to link the backend with libpq. I don't see an immediate >> problem with that, but I'm not a packager. Does anyone see a problem >> with that? > > Yeah, I have a problem with that. What's the backend doing with libpq? > It's not receiving this data, it's sending it. walreceiver is a postmaster subprocess too. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Fujii Masao on 15 Dec 2009 01:07 On Tue, Dec 15, 2009 at 4:11 AM, Tom Lane <tgl(a)sss.pgh.pa.us> wrote: > Hm. Perhaps it should be a loadable plugin and not hard-linked into the > backend? Compare dblink. You mean that such plugin is supplied in shared_preload_libraries, a new process is forked and the shared-memory related to walreceiver is created by using shmem_startup_hook? Since this approach would solve the problem discussed previously, ISTM this makes sense. http://archives.postgresql.org/pgsql-hackers/2009-11/msg00031.php Some additional code might be required to control the termination of walreceiver. Regards, -- Fujii Masao NIPPON TELEGRAPH AND TELEPHONE CORPORATION NTT Open Source Software Center -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Fujii Masao on 15 Dec 2009 22:28 On Tue, Dec 15, 2009 at 3:47 AM, Heikki Linnakangas <heikki.linnakangas(a)enterprisedb.com> wrote: > Tom Lane wrote: >> The very, very large practical problem with this is that if you decide >> to change the behavior at any time, the only way to be sure that the WAL >> receiver is using the right libpq version is to perform a soname major >> version bump. The transformations done by libpq will essentially become >> part of its ABI, and not a very visible part at that. > > Not having to change the libpq API would certainly be a big advantage. Done; I replaced PQgetXLogData and PQputXLogRecPtr with PQgetCopyData and PQputCopyData. git://git.postgresql.org/git/users/fujii/postgres.git branch: replication Regards, -- Fujii Masao NIPPON TELEGRAPH AND TELEPHONE CORPORATION NTT Open Source Software Center -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Heikki Linnakangas on 17 Dec 2009 07:02 Fujii Masao wrote: > On Wed, Dec 16, 2009 at 6:53 PM, Heikki Linnakangas > <heikki.linnakangas(a)enterprisedb.com> wrote: >> 0. Begin by connecting to the master just like a normal backend does. We >> don't necessarily need the new ProtocolVersion code either, though it's >> probably still a good idea to reject connections to older server versions. > > And, I think that such backend should switch to walsender mode when the startup > packet arrives. Otherwise, we would have to authenticate such backend twice > on different context, i.e., a normal backend and walsender. So the settings for > each context would be required in pg_hba.conf. This is odd, I think. Thought? True. >> This is identical to what happens when a query is executed against a >> normal backend using the simple query protocol, so walsender can use >> PQexec() for this. > > s/walsender/walreceiver ? Right. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Fujii Masao on 17 Dec 2009 08:00
On Thu, Dec 17, 2009 at 9:02 PM, Heikki Linnakangas <heikki.linnakangas(a)enterprisedb.com> wrote: >> And, I think that such backend should switch to walsender mode when the startup >> packet arrives. Otherwise, we would have to authenticate such backend twice >> on different context, i.e., a normal backend and walsender. So the settings for >> each context would be required in pg_hba.conf. This is odd, I think. Thought? > > True. Currently this switch depends on whether XLOG_STREAMING_CODE is sent from the standby or not, also which depends on whether PQstartXLogStreaming() is called or not. But, as the next step, we should get rid of also such changes of libpq. I'm thinking of making the standby send the "walsender-switch-code" the same way as application_name; walreceiver always specifies the option like "replication=on" in conninfo string and calls PQconnectdb(), which sends the code as a part of startup packet. And, the environment variable for that should not be defined to avoid user's mis-configuration, I think. Thought? Better idea? Regards, -- Fujii Masao NIPPON TELEGRAPH AND TELEPHONE CORPORATION NTT Open Source Software Center -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |