On 12/28/2015 11:48 AM, Tom Lane wrote:
> Joe Conway writes:
>> I retract my earlier suggestion of doing HEAD different from
>> REL9_5_STABLE, at least for the moment. My patch for pg_controldata
>> related functions is going to impact all this anyway, so we might as
>> well not fuss about it now.
Joe Conway writes:
> I retract my earlier suggestion of doing HEAD different from
> REL9_5_STABLE, at least for the moment. My patch for pg_controldata
> related functions is going to impact all this anyway, so we might as
> well not fuss about it now.
Seems reasonable.
> Any objections to the a
On 12/28/2015 10:35 AM, Joe Conway wrote:
> An alternative would be to not have a space at all for those two, e.g.
>
> "Latest checkpoint's oldestCommitTsXid:%u\n"
> "Latest checkpoint's newestCommitTsXid:%u\n"
>
> That isn't too bad and would leave everything aligned.
That seems like the be
On 12/28/2015 10:30 AM, Alvaro Herrera wrote:
> Tom Lane wrote:
>> Joe Conway writes:
>>> I think the attached does the job. Note I settled on
>>> (new|old)estCommitTsXid as that seemed most descriptive and not horribly
>>> longer than before. It did mean, however, that I needed to add a single
>>
Tom Lane wrote:
> Joe Conway writes:
> > I think the attached does the job. Note I settled on
> > (new|old)estCommitTsXid as that seemed most descriptive and not horribly
> > longer than before. It did mean, however, that I needed to add a single
> > space to all the output in pg_resetxlog and pg_
Joe Conway writes:
> I think the attached does the job. Note I settled on
> (new|old)estCommitTsXid as that seemed most descriptive and not horribly
> longer than before. It did mean, however, that I needed to add a single
> space to all the output in pg_resetxlog and pg_controldata, which added
>
On 12/28/2015 09:53 AM, Alvaro Herrera wrote:
>>> The name is just as misleading at the source-code level, maybe more so
>>> since they're all just numbers in C. +1 for changing it everywhere
>>> before somebody makes a mistake based on the incorrect names.
>>
>> Ok, I'm on it now
>
> Great, than
Joe Conway wrote:
> On 12/28/2015 09:03 AM, Tom Lane wrote:
> > Joe Conway writes:
> >> Ok, but now next question -- should we just change the user visible
> >> output to oldestCommitXID/newestCommitXID, or should we change the
> >> variable name everywhere it appears in source as well? Looks like
On 12/28/2015 09:03 AM, Tom Lane wrote:
> Joe Conway writes:
>> Ok, but now next question -- should we just change the user visible
>> output to oldestCommitXID/newestCommitXID, or should we change the
>> variable name everywhere it appears in source as well? Looks like each
>> one appears about 2
Joe Conway writes:
> Ok, but now next question -- should we just change the user visible
> output to oldestCommitXID/newestCommitXID, or should we change the
> variable name everywhere it appears in source as well? Looks like each
> one appears about 25-30 times scattered across 9 or 10 files. Sin
On 12/26/2015 06:32 PM, Michael Paquier wrote:
> On Sun, Dec 27, 2015 at 10:08 AM, Joe Conway wrote:
>> In looking at the exposing pg_controldata as function patch again, it
>> struck me that the following output seems wrong:
>>
>> --
>> Latest checkpoint's oldestCommitTs: 20257
>> L
On Sun, Dec 27, 2015 at 10:08 AM, Joe Conway wrote:
> In looking at the exposing pg_controldata as function patch again, it
> struck me that the following output seems wrong:
>
> --
> Latest checkpoint's oldestCommitTs: 20257
> Latest checkpoint's newestCommitTs: 84159
> --
In looking at the exposing pg_controldata as function patch again, it
struck me that the following output seems wrong:
--
Latest checkpoint's oldestCommitTs: 20257
Latest checkpoint's newestCommitTs: 84159
--
Those numbers are XIDs, not timestamps. Shouldn't we either
13 matches
Mail list logo
