Re: [BUGS] BUG #7534: walreceiver takes long time to detect n/w breakdown
| От | Heikki Linnakangas |
|---|---|
| Тема | Re: [BUGS] BUG #7534: walreceiver takes long time to detect n/w breakdown |
| Дата | |
| Msg-id | 507C1D6C.6080409@vmware.com обсуждение исходный текст |
| Ответ на | Re: [BUGS] BUG #7534: walreceiver takes long time to detect n/w breakdown (Heikki Linnakangas <hlinnakangas@vmware.com>) |
| Ответы |
Re: [BUGS] BUG #7534: walreceiver takes long time to detect n/w breakdown
|
| Список | pgsql-hackers |
On 15.10.2012 13:13, Heikki Linnakangas wrote: > On 13.10.2012 19:35, Fujii Masao wrote: >> ISTM you need to update the protocol.sgml because you added >> the field 'replyRequested' to WalSndrMessage and StandbyReplyMessage. > > Oh, I didn't remember that we've documented the specific structs that we > pass around. It's quite bogus anyway to explain the messages the way we > do currently, as they are actually dependent on the underlying > architecture's endianess and padding. I think we should refactor the > protocol to not transmit raw structs, but use pq_sentint and friends to > construct the messages. This was discussed earlier (see > http://archives.postgresql.org/message-id/4FE2279C.2070506@enterprisedb.com), > I think there's consensus that 9.3 would be a good time to do that as we > changed the XLogRecPtr format anyway. This is what I came up with. The replication protocol is now architecture-independent. The WAL format itself is still architecture-independent, of course, but this is useful if you want to e.g use pg_receivexlog to back up a server that runs on a different platform. I chose the int64 format to transmit timestamps, even when compiled with --disable-integer-datetimes. Please review if you have the time.. - Heikki
Вложения
В списке pgsql-hackers по дате отправления: