Re: Streaming replication and non-blocking I/O
От | Tom Lane |
---|---|
Тема | Re: Streaming replication and non-blocking I/O |
Дата | |
Msg-id | 12218.1260817905@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Streaming replication and non-blocking I/O (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>) |
Ответы |
Re: Streaming replication and non-blocking I/O
|
Список | pgsql-hackers |
Heikki Linnakangas <heikki.linnakangas@enterprisedb.com> writes: > Tom Lane wrote: >> 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. Hm. Perhaps it should be a loadable plugin and not hard-linked into the backend? Compare dblink. The main concern I have with hard-linking libpq is that it has a lot of symbol conflicts with the backend --- and at least the ones from src/port/ aren't easily removed. I foresee problems that will be very difficult to fix on platforms where we can't filter the set of link symbols exposed by libpq. Linking a thread-enabled libpq into the backend could also create problems on some platforms --- it would likely cause a thread-capable libc to get linked, which is not what we want. regards, tom lane
В списке pgsql-hackers по дате отправления: