From: | Michael Paquier <michael(dot)paquier(at)gmail(dot)com> |
---|---|
To: | Magnus Hagander <magnus(at)hagander(dot)net> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: pg_stat_replication log positions vs base backups |
Date: | 2015-11-27 05:07:52 |
Message-ID: | CAB7nPqT0DfNEELaHERUxHKPuVumfXWbJn+PjVKcWMeS2USsLeQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Nov 26, 2015 at 10:53 PM, Magnus Hagander <magnus(at)hagander(dot)net> wrote:
> On Thu, Nov 26, 2015 at 1:03 PM, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
> wrote:
>>
>> On Thu, Nov 26, 2015 at 6:45 PM, Magnus Hagander wrote:
>> > I'm only talking about the actual value in pg_stat_replication here, not
>> > what we are using internally. These are two different things of course -
>> > let's keep them separate for now. In pg_stat_replication, we explicitly
>> > check for InvalidXLogRecPtr and then explicitly set the resulting value
>> > to
>> > NULL in the SQL return.
>>
>> No objections from here. I guess you already have a patch?
>
> Well, no, because I haven't figured out which way is the logical one - make
> them all return NULL or make them all return 0/0...
It seems to me that NULL is the logical one. We want to define a value
from the user prospective where things are in an undefined state.
That's my logic flow, other opinions are of course welcome.
--
Michael
From | Date | Subject | |
---|---|---|---|
Next Message | Etsuro Fujita | 2015-11-27 05:39:57 | Re: Foreign join pushdown vs EvalPlanQual |
Previous Message | Tom Lane | 2015-11-27 04:39:35 | Re: WIP: About CMake v2 |