On Tue, Jun 15, 2010 at 4:22 AM, Fujii Masao wrote:
> On Tue, Jun 15, 2010 at 2:41 PM, Heikki Linnakangas
> wrote:
>> On 15/06/10 08:23, Fujii Masao wrote:
>>>
>>> On Thu, Jun 10, 2010 at 11:06 PM, Tom Lane wrote:
I'm not sure if it's worth the trouble, or even a particularly smart
>>>
On Tue, Jun 15, 2010 at 2:41 PM, Heikki Linnakangas
wrote:
> On 15/06/10 08:23, Fujii Masao wrote:
>>
>> On Thu, Jun 10, 2010 at 11:06 PM, Tom Lane wrote:
>>>
>>> I'm not sure if it's worth the trouble, or even a particularly smart
>>> idea, to force the output of the status function to be monoto
On 15/06/10 08:23, Fujii Masao wrote:
On Thu, Jun 10, 2010 at 11:06 PM, Tom Lane wrote:
I'm not sure if it's worth the trouble, or even a particularly smart
idea, to force the output of the status function to be monotonic
regardless of what happens underneath. I think removing that claim
from
On Thu, Jun 10, 2010 at 11:06 PM, Tom Lane wrote:
> Heikki Linnakangas writes:
>> Even then, we wouldn't need to start from the beginning of the WAL
>> segment AFAICS. The point is to start from the Redo pointer, not from
>> the checkpoint record, because as soon as we read the checkpoint record
Heikki Linnakangas writes:
> Even then, we wouldn't need to start from the beginning of the WAL
> segment AFAICS. The point is to start from the Redo pointer, not from
> the checkpoint record, because as soon as we read the checkpoint record
> we'll need to start applying WAL from the Redo poin
On 10/06/10 11:37, Fujii Masao wrote:
On Thu, Jun 10, 2010 at 5:04 PM, Heikki Linnakangas
wrote:
I believe that starting from the beginning of the WAL segment is just
paranoia, to avoid creating a WAL file that's missing some data from the
beginning. Right?
Only when the recovery starting re
On Thu, Jun 10, 2010 at 5:04 PM, Heikki Linnakangas
wrote:
>>> Should we:
>>> 1. Just document that,
>>> 2. Change pg_last_xlog_location() to not move backwards in that case, or
>>> 3. Change the behavior so that we start streaming at the exact byte
>>> location
>>> where we left off?
>>
>> I'm fo
On 10/06/10 10:43, Fujii Masao wrote:
On Thu, Jun 10, 2010 at 4:07 PM, Heikki Linnakangas
wrote:
BTW, the docs claim about pg_last_xlog_location() that "While streaming
replication is in progress this will increase monotonically." That's a bit
misleading: when the replication connection is bro
On Thu, Jun 10, 2010 at 4:07 PM, Heikki Linnakangas
wrote:
> Ah, I just committed a patch to do the same, before seeing your email.
> Thanks anyway.
Yeah, thanks a lot!
> BTW, the docs claim about pg_last_xlog_location() that "While streaming
> replication is in progress this will increase monot
On 10/06/10 09:42, Fujii Masao wrote:
On Thu, Jun 10, 2010 at 11:56 AM, Tom Lane wrote:
Robert Haas writes:
On Wed, Jun 9, 2010 at 9:46 PM, Takahiro Itagaki
wrote:
I found a term "InvalidXLogRecPtr" in 9.0 docs.
http://developer.postgresql.org/pgdocs/postgres/functions-admin.html#FUNCTIONS
On 10/06/10 05:56, Tom Lane wrote:
Robert Haas writes:
On Wed, Jun 9, 2010 at 9:46 PM, Takahiro Itagaki
wrote:
I found a term "InvalidXLogRecPtr" in 9.0 docs.
http://developer.postgresql.org/pgdocs/postgres/functions-admin.html#FUNCTIONS-RECOVERY-INFO-TABLE
| ... then the return value will b
On Thu, Jun 10, 2010 at 11:56 AM, Tom Lane wrote:
> Robert Haas writes:
>> On Wed, Jun 9, 2010 at 9:46 PM, Takahiro Itagaki
>> wrote:
>>> I found a term "InvalidXLogRecPtr" in 9.0 docs.
>>> http://developer.postgresql.org/pgdocs/postgres/functions-admin.html#FUNCTIONS-RECOVERY-INFO-TABLE
>>> | .
Robert Haas writes:
> On Wed, Jun 9, 2010 at 9:46 PM, Takahiro Itagaki
> wrote:
>> I found a term "InvalidXLogRecPtr" in 9.0 docs.
>> http://developer.postgresql.org/pgdocs/postgres/functions-admin.html#FUNCTIONS-RECOVERY-INFO-TABLE
>> | ... then the return value will be InvalidXLogRecPtr (0/0).
On Wed, Jun 9, 2010 at 9:46 PM, Takahiro Itagaki
wrote:
> I found a term "InvalidXLogRecPtr" in 9.0 docs.
> http://developer.postgresql.org/pgdocs/postgres/functions-admin.html#FUNCTIONS-RECOVERY-INFO-TABLE
> | ... then the return value will be InvalidXLogRecPtr (0/0).
>
> I think it should not ap
14 matches
Mail list logo
