Re: Support for pg_receivexlog --format=plain|tar

From: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
To: Magnus Hagander <magnus(at)hagander(dot)net>
Cc: PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org>, David Steele <david(at)pgmasters(dot)net>
Subject: Re: Support for pg_receivexlog --format=plain|tar
Date: 2016-12-30 05:41:58
Message-ID: CAB7nPqSejWAY7X490Wp9fV2z_QgBnyr33fBY3tKW00Jc4JmvZg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Dec 29, 2016 at 6:13 PM, Magnus Hagander <magnus(at)hagander(dot)net> wrote:
> On Thu, Dec 29, 2016 at 12:35 AM, Michael Paquier
> <michael(dot)paquier(at)gmail(dot)com> wrote:
>> On Wed, Dec 28, 2016 at 9:31 PM, Magnus Hagander <magnus(at)hagander(dot)net>
>> wrote:
>> >> - I have switched the directory method to use a file pointer instead
>> >> of a file descriptor as gzwrite returns int as the number of
>> >> uncompressed bytes written.
>> >
>> > I don't really follow that reasoning :) Why does the directory method
>> > have
>> > to change to use a filepointer because of that?
>>
>> The only reason is that write() returns size_t and fwrite returns int,
>> while gzwrite() returns int. It seems more consistent to use fwrite()
>> in this case. Or we don't bother about my nitpicking and just cast
>> stuff.
>
>
> I can at least partially see that argument, but your patch doesn't actually
> use fwrite(), it uses write() with fileno()...

That was part of the one/two things I wanted to change before sending
a fresh patch.

> But also, on my platform (debian jessie), fwrite() returns size_t, and
> write() returns ssize_t. So those are apparently both different from what
> your platform does - which one did you get that one?

It looks like I misread the macos man pages previously. Thay actually
list ssize_t. I find a bit surprising the way gzwrite is designed. It
uses an input an unsigned integer and returns to caller a signed
integer, so this will never work with uncompressed buffers of sizes
higher than 2GB. There's little point to worry about that in
pg_receivexlog though, so let's just cast to ssize_t.

Attached is a simplified new version, I have kept the file descriptor
as originally done. Note that tests are actually difficult to work
out, there is no way to run in batch pg_receivexlog..
--
Michael

Attachment Content-Type Size
receivexlog-gzip-v2.patch application/stream 9.2 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2016-12-30 05:44:33 Broken atomics code on PPC with FreeBSD 10.3
Previous Message Craig Ringer 2016-12-30 04:33:59 Re: BUG: pg_stat_statements query normalization issues with combined queries