Skip site navigation (1) Skip section navigation (2)

Re: Reporting WAL file containing checkpoint's REDO record in pg_controldata's result

From: Fujii Masao <masao(dot)fujii(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Magnus Hagander <magnus(at)hagander(dot)net>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Reporting WAL file containing checkpoint's REDO record in pg_controldata's result
Date: 2012-03-27 09:40:34
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On Mon, Mar 26, 2012 at 11:18 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> On Mon, Mar 26, 2012 at 2:50 AM, Magnus Hagander <magnus(at)hagander(dot)net> wrote:
>>>> s/segment/file/g?
>>> We're already using "file" to mean something different *internally*,
>>> don't we? And since pg_controldata shows fairly internal information,
>>> I'm not sure this is the best idea.
>>> Maybe compromise and call it "segment file" - that is both easier to
>>> understand than segment, and not actually using a term that means
>>> something else...
>> It's also kind of wordy.  I think "file" is fine.
> +1 for "file".  I think the internal usage of "file" to mean "roughly
> 4GB worth of WAL" is going to go away soon anyway, as there won't be
> much reason to worry about the concept once LSN arithmetic is 64-bit.

Agreed. This would mean that the following lots of log messages need to
be changed after 64-bit LSN will have been committed.

	errmsg("could not fdatasync log file %u, segment %u: %m",
		   log, seg)));

Anyway, should I add this patch into the next CF? Or is anyone planning
to commit the patch for 9.2?


Fujii Masao
NTT Open Source Software Center

In response to


pgsql-hackers by date

Next:From: Fujii MasaoDate: 2012-03-27 11:13:34
Subject: Re: PATCH: pg_basebackup (missing exit on error)
Previous:From: Albe LaurenzDate: 2012-03-27 09:36:54
Subject: Re: pgsql_fdw, FDW for PostgreSQL server

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group