Fujii Masao wrote:
On Tue, Apr 6, 2010 at 11:48 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
Fujii Masao wrote:
On Tue, Apr 6, 2010 at 8:02 PM, Fujii Masao masao.fu...@gmail.com wrote:
Should we throw an error in pg_xlogfile_name() if called during
recovery? It's not
Fujii Masao wrote:
On Fri, Apr 2, 2010 at 2:22 AM, Robert Haas robertmh...@gmail.com 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
On Tue, Apr 6, 2010 at 7:25 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
Fujii Masao wrote:
On Fri, Apr 2, 2010 at 2:22 AM, Robert Haas robertmh...@gmail.com wrote:
Can someone explain to me in plain language what problem this is
trying to fix? I'm having trouble figuring
On Tue, Apr 6, 2010 at 8:02 PM, Fujii Masao masao.fu...@gmail.com 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
Fujii Masao wrote:
On Tue, Apr 6, 2010 at 8:02 PM, Fujii Masao masao.fu...@gmail.com 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
On Tue, Apr 6, 2010 at 11:48 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
Fujii Masao wrote:
On Tue, Apr 6, 2010 at 8:02 PM, Fujii Masao masao.fu...@gmail.com wrote:
Should we throw an error in pg_xlogfile_name() if called during
recovery? It's not doing anything useful as
On Tue, Mar 30, 2010 at 5:14 AM, Fujii Masao masao.fu...@gmail.com wrote:
On Wed, Mar 3, 2010 at 11:03 PM, Fujii Masao masao.fu...@gmail.com wrote:
On Tue, Mar 2, 2010 at 10:52 PM, Fujii Masao masao.fu...@gmail.com wrote:
It's not clear what it should return, a TLI corresponding the filename
On Fri, Apr 2, 2010 at 2:22 AM, Robert Haas robertmh...@gmail.com 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
On Wed, Mar 3, 2010 at 11:03 PM, Fujii Masao masao.fu...@gmail.com wrote:
On Tue, Mar 2, 2010 at 10:52 PM, Fujii Masao masao.fu...@gmail.com 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
On Wed, March 3, 2010 15:03, Fujii Masao wrote:
On Tue, Mar 2, 2010 at 10:52 PM, Fujii Masao masao.fu...@gmail.com 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
On Tue, Mar 2, 2010 at 10:52 PM, Fujii Masao masao.fu...@gmail.com 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,
Fujii Masao wrote:
On Fri, Feb 26, 2010 at 6:26 AM, Erik Rijkers e...@xs4all.nl 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
On Tue, Mar 2, 2010 at 8:54 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com 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,
Sorry for the delay.
On Fri, Feb 26, 2010 at 6:26 AM, Erik Rijkers e...@xs4all.nl 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
On Thu, 2010-02-25 at 12:02 +0900, Fujii Masao wrote:
On Wed, Feb 24, 2010 at 7:56 AM, Simon Riggs si...@2ndquadrant.com 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;
On Thu, Feb 25, 2010 at 6:33 PM, Simon Riggs si...@2ndquadrant.com 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?
-
On Thu, Feb 25, 2010 at 11:57 AM, Fujii Masao masao.fu...@gmail.com wrote:
On Tue, Feb 23, 2010 at 4:08 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com 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,
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 Tue, Feb 23, 2010 at 4:08 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com 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
On Wed, Feb 24, 2010 at 7:56 AM, Simon Riggs si...@2ndquadrant.com 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
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 current
Fujii Masao wrote:
On Thu, Jan 28, 2010 at 5:28 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com 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
On Mon, Feb 22, 2010 at 9:30 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com 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
Fujii Masao wrote:
On Mon, Feb 22, 2010 at 9:30 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com 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
On Thu, Jan 28, 2010 at 5:28 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com 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',
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 related
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
27 matches
Mail list logo
