Fujii Masao wrote:
> On Tue, Apr 6, 2010 at 11:48 PM, Heikki Linnakangas
> wrote:
>> Fujii Masao wrote:
>>> On Tue, Apr 6, 2010 at 8:02 PM, Fujii Masao wrote:
> Should we throw an error in pg_xlogfile_name() if called during
> recovery? It's not doing anything useful as it is.
I have
On Tue, Apr 6, 2010 at 11:48 PM, Heikki Linnakangas
wrote:
> Fujii Masao wrote:
>> On Tue, Apr 6, 2010 at 8:02 PM, Fujii Masao wrote:
Should we throw an error in pg_xlogfile_name() if called during
recovery? It's not doing anything useful as it is.
>>> I have no objection for now.
>>
>>
Fujii Masao wrote:
> On Tue, Apr 6, 2010 at 8:02 PM, Fujii Masao wrote:
>>> Should we throw an error in pg_xlogfile_name() if called during
>>> recovery? It's not doing anything useful as it is.
>> I have no objection for now.
>
> Here is the patch.
> ...
> + if (RecoveryInProgress())
> +
On Tue, Apr 6, 2010 at 8:02 PM, Fujii Masao wrote:
>> Should we throw an error in pg_xlogfile_name() if called during
>> recovery? It's not doing anything useful as it is.
>
> I have no objection for now.
Here is the patch.
Regards,
--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT
On Tue, Apr 6, 2010 at 7:25 PM, Heikki Linnakangas
wrote:
> Fujii Masao wrote:
>> On Fri, Apr 2, 2010 at 2:22 AM, Robert Haas wrote:
>>> Can someone explain to me in plain language what problem this is
>>> trying to fix? I'm having trouble figuring it out.
>>
>> The problem is that pg_xlogfile_n
Fujii Masao wrote:
> On Fri, Apr 2, 2010 at 2:22 AM, Robert Haas wrote:
>> Can someone explain to me in plain language what problem this is
>> trying to fix? I'm having trouble figuring it out.
>
> The problem is that pg_xlogfile_name(pg_last_xlog_receive_location()) and
> pg_xlogfile_name(pg_la
On Fri, Apr 2, 2010 at 2:22 AM, Robert Haas wrote:
> Can someone explain to me in plain language what problem this is
> trying to fix? I'm having trouble figuring it out.
The problem is that pg_xlogfile_name(pg_last_xlog_receive_location()) and
pg_xlogfile_name(pg_last_xlog_replay_location()) mi
On Tue, Mar 30, 2010 at 5:14 AM, Fujii Masao wrote:
> On Wed, Mar 3, 2010 at 11:03 PM, Fujii Masao wrote:
>> On Tue, Mar 2, 2010 at 10:52 PM, Fujii Masao wrote:
It's not clear what it should return, a TLI corresponding the filename
of the WAL segment the record was replayed from, so th
On Wed, Mar 3, 2010 at 11:03 PM, Fujii Masao wrote:
> On Tue, Mar 2, 2010 at 10:52 PM, Fujii Masao wrote:
>>> It's not clear what it should return, a TLI corresponding the filename
>>> of the WAL segment the record was replayed from, so that you can use
>>> pg_xlogfile_name() to find out the file
On Wed, March 3, 2010 15:03, Fujii Masao wrote:
> On Tue, Mar 2, 2010 at 10:52 PM, Fujii Masao wrote:
>
> Here is the revised patch. I used new local variable instead of lastPageTLI
> to track the tli of last applied record. It is updated with the tli of the
> log page header when reading the page
On Tue, Mar 2, 2010 at 10:52 PM, Fujii Masao wrote:
>> It's not clear what it should return, a TLI corresponding the filename
>> of the WAL segment the record was replayed from, so that you can use
>> pg_xlogfile_name() to find out the filename of the WAL segment being
>> replayed, or the accurate
On Tue, Mar 2, 2010 at 8:54 PM, Heikki Linnakangas
wrote:
> This still suffers from ambiguity around a shutdown checkpoint that
> changes the TLI. On the page the shutdown checkpoint is on, what is the
> TLI in the page header? The TLI before the checkpoint record, I presume.
> Now consider a reco
Fujii Masao wrote:
> On Fri, Feb 26, 2010 at 6:26 AM, Erik Rijkers wrote:
>> With this patch the standby compiles, tests, installs OK.
>> I wanted to check with you if the following is expected.
>
> Thanks for the test and bug report!
>
>> With standby (correctly) as follows :
>> LOG: redo star
Sorry for the delay.
On Fri, Feb 26, 2010 at 6:26 AM, Erik Rijkers wrote:
> With this patch the standby compiles, tests, installs OK.
> I wanted to check with you if the following is expected.
Thanks for the test and bug report!
> With standby (correctly) as follows :
> LOG: redo starts at 0/1
On Thu, February 25, 2010 17:34, Fujii Masao wrote:
>
> I attached the revised patch which uses lastPageTLI instead of curFileTLI
> as the timeline of the last applied record.
>
With this patch the standby compiles, tests, installs OK.
I wanted to check with you if the following is expected.
With
On Thu, Feb 25, 2010 at 11:57 AM, Fujii Masao wrote:
> On Tue, Feb 23, 2010 at 4:08 PM, Heikki Linnakangas
> wrote:
>>> So it's not the TLI of the first record in the file, isn't it?
>>
>> Hmm, or is it the TLI of the last record? Not sure. Anyway, if there's a
>> TLI switch in the current WAL fi
On Thu, Feb 25, 2010 at 6:33 PM, Simon Riggs wrote:
> If we expose the timeline as part of an "xlog location", then we should
> do that everywhere as a change for 9.0.
Everywhere? You mean changing the format of the return value of all
the following functions?
- pg_start_backup()
- pg_stop_backu
On Thu, 2010-02-25 at 12:02 +0900, Fujii Masao wrote:
> On Wed, Feb 24, 2010 at 7:56 AM, Simon Riggs wrote:
> > On Thu, 2010-01-28 at 10:28 +0200, Heikki Linnakangas wrote:
> >> Fujii Masao wrote:
> >> > In relation to the functions added recently, I found an annoying problem;
> >> > pg_xlogfile_n
On Wed, Feb 24, 2010 at 7:56 AM, Simon Riggs wrote:
> On Thu, 2010-01-28 at 10:28 +0200, Heikki Linnakangas wrote:
>> Fujii Masao wrote:
>> > In relation to the functions added recently, I found an annoying problem;
>> > pg_xlogfile_name(pg_last_xlog_receive/replay_location()) might report the
>>
On Tue, Feb 23, 2010 at 4:08 PM, Heikki Linnakangas
wrote:
>> So it's not the TLI of the first record in the file, isn't it?
>
> Hmm, or is it the TLI of the last record? Not sure. Anyway, if there's a
> TLI switch in the current WAL file, curFileTLI doesn't always represent
> the TLI of the curre
On Thu, 2010-01-28 at 10:28 +0200, Heikki Linnakangas wrote:
> Fujii Masao wrote:
> > In relation to the functions added recently, I found an annoying problem;
> > pg_xlogfile_name(pg_last_xlog_receive/replay_location()) might report the
> > wrong name because pg_xlogfile_name() always uses the cur
Fujii Masao wrote:
> On Mon, Feb 22, 2010 at 9:30 PM, Heikki Linnakangas
> wrote:
>> Thinking about this again, I'm not sure this is a good idea. Using
>> curFileTLI makes sense if you're going to call pg_xlogfile_name() and
>> would expect it to return the filename of the file containing the WAL
On Mon, Feb 22, 2010 at 9:30 PM, Heikki Linnakangas
wrote:
> Thinking about this again, I'm not sure this is a good idea. Using
> curFileTLI makes sense if you're going to call pg_xlogfile_name() and
> would expect it to return the filename of the file containing the WAL
> record being replayed. B
Fujii Masao wrote:
> On Thu, Jan 28, 2010 at 5:28 PM, Heikki Linnakangas
> wrote:
>> How about extending the format of the string returned by
>> pg_last_xlog_receive/replay_location() to include the timeline ID? When
>> it currently returns e.g '6/200016C', it could return '1/6/200016C',
>> where
On Thu, Jan 28, 2010 at 5:28 PM, Heikki Linnakangas
wrote:
> How about extending the format of the string returned by
> pg_last_xlog_receive/replay_location() to include the timeline ID? When
> it currently returns e.g '6/200016C', it could return '1/6/200016C',
> where 1 is the timeline ID. Then
Fujii Masao wrote:
> In relation to the functions added recently, I found an annoying problem;
> pg_xlogfile_name(pg_last_xlog_receive/replay_location()) might report the
> wrong name because pg_xlogfile_name() always uses the current timeline,
> and a backend doesn't know the actual timeline relat
Hi,
In relation to the functions added recently, I found an annoying problem;
pg_xlogfile_name(pg_last_xlog_receive/replay_location()) might report the
wrong name because pg_xlogfile_name() always uses the current timeline,
and a backend doesn't know the actual timeline related to the location
whi
27 matches
Mail list logo
