Re: Streaming replication and non-blocking I/O
От | Fujii Masao |
---|---|
Тема | Re: Streaming replication and non-blocking I/O |
Дата | |
Msg-id | 3f0b79eb0912131956t2912a4b0ua46e8b3acfe0c5fd@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Streaming replication and non-blocking I/O (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Streaming replication and non-blocking I/O
|
Список | pgsql-hackers |
On Mon, Dec 14, 2009 at 11:38 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Do we need a new "PQgetXLogData" function at all? Seems like you could > shove the data through the COPY protocol and not have to touch libpq > at all, rather than duplicating a nontrivial amount of code there. Yeah, I also think that all data (the WAL data itself, its LSN and the flag bits) which the "PQgetXLogData" handles could be shoved through the COPY protocol. But, outside libpq, it's somewhat messy to extract the LSN and the flag bits from the data buffer which "PQgetCopyData" returns, by using ntohs(). So I provided the new libpq function only for replication. That is, I didn't want to expose the low layer of network which libpq should handle. I think that the friendly function would be useful to implement the standby program (e.g., a stand-alone walreceiver tool) outside the core. Regards, -- Fujii Masao NIPPON TELEGRAPH AND TELEPHONE CORPORATION NTT Open Source Software Center
В списке pgsql-hackers по дате отправления: