Re: Incorrect initialization of sentPtr in walsender.c

From: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
To: Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>
Cc: PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Incorrect initialization of sentPtr in walsender.c
Date: 2014-09-12 12:16:42
Message-ID: CAB7nPqRUaFyTJ024W-HiihW4PwfcadZN9HFMsJQfOZSQtZtDUA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Sep 12, 2014 at 4:55 PM, Heikki Linnakangas
<hlinnakangas(at)vmware(dot)com> wrote:
> I haven't looked at those places closely, but it seems possible that at
> least some of those variables are supposed to be initialized to a value
> smaller than any valid WAL position, rather than just Invalid. In other
> words, if we defined InvalidXLogRecPtr as INT64_MAX rather than 0, we would
> still want those variables to be initialized to zero. As I said, I didn't
> check the code, but before we change those that ought to be checked.

Ah, OK. I just had a look at that, and receivedUpto and lastComplaint
in xlog.c need to use the lowest pointer value possible as they do a
couple of comparisons with other positions. This is as well the case
of sentPtr in walsender.c. However, that's not the case of writePtr
and flushPtr in walreceiver.c as those positions are just used for
direct comparison with LogstreamResult, so we could use
InvalidXLogRecPtr in this case.

What do you think of the addition of a #define for the lowest possible
XLOG location pointer? I've wanted that as well a couple of times when
working on clients using replication connections for for example
START_REPLICATION. That would be better than hardcoding a position
like '0/0', and would make the current code more solid.

Patch attached in case.

Regards,
--
Michael

Attachment Content-Type Size
20140912_wal_incorrect_ptr_v2.patch text/x-diff 2.9 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2014-09-12 12:28:49 Re: bad estimation together with large work_mem generates terrible slow hash joins
Previous Message Dilip kumar 2014-09-12 11:37:10 Re: pg_basebackup vs. Windows and tablespaces