Thread

Re: walprotocol.h vs frontends

Magnus Hagander <magnus@hagander.net> — 2011-08-15T14:44:33Z

On Mon, Aug 15, 2011 at 16:20, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Magnus Hagander <magnus@hagander.net> writes:
>> I'm trying to make my streaming log receiver work properly with 9.1,
>> and have come across a couple of things. The first one that's causing
>> trouble is that the definition of the protocol is currently in
>> walprotocol.h, which is not include:able in a frontend application.
>> AFAICT, this is because it includes utils/timestamp.h, which doesn't
>> work. AFAICT, this means that anybody other than our own backend who
>> wants to talk our replication protocol has to copy the specific struct
>> defines they want in their own code. This seems like a really bad
>> idea. (In my case, it's the StandbyReplyMessage that I need, so I can
>> make my client not get killed by the default settings for timeout)
>
>> The basic reason for this is that we're putting TimestampTz fields in
>> the protocol. This also means that the protocol actually changes
>> definition depending on if the server is compiled with integer or
>> float timestamps. While the replication itself breaks if these are
>> different, this seems like a bad thing to expose in the protocol. It
>> also makes life a lot harder on third party tools.
>
> I don't really see why it matters, given that the data to be shipped is
> also dependent on the timestamp format?

As an example, the stream receiver program needs to be able to
construct the status message and send back - thus needs to be able to
construct a TimestampTz. It never needs to look into the actual WAL
data - it just writes it to a file considering it to be a stream of
pure binary data.


> However, for a narrow fix, I could see moving the data type definition
> to someplace with fewer dependencies.  Perhaps split it into a separate
> file timestamp_type.h, or something like that.

Yes, that seems to fix the problem of timestamptz. See the attached
patch - seems ok?


I also ran into a similar problem with some WAL macro definitions that
are in xlog_internal.h. I've moved them to xlogdefs.h in the attached
xlog.diff file. Does that seem ok as well, or should I move them
somewhere else? (I don't need all those macros, but I moved the
complete block of macros wherever I needed one of them, because
otherwise it would be completely impossible to track). This is just a
simple move of the definitions, zero new logic added and zero removed.


-- 
 Magnus Hagander
 Me: http://www.hagander.net/
 Work: http://www.redpill-linpro.com/