Peter Eisentraut writes:
> On Tue, 2012-08-21 at 12:01 -0400, Robert Haas wrote:
>> It's possible there's something we want to change here, but it's far
>> from obvious what that thing is. Our WAL file handling is
>> ridiculously hard to understand, but the problem with changing it is
>> that the
On Tue, 2012-08-21 at 12:01 -0400, Robert Haas wrote:
> On Wed, Aug 15, 2012 at 8:43 PM, Bruce Momjian wrote:
> > Are there any TODO items here?
>
> It's possible there's something we want to change here, but it's far
> from obvious what that thing is. Our WAL file handling is
> ridiculously har
On Wed, Aug 15, 2012 at 8:43 PM, Bruce Momjian wrote:
> Are there any TODO items here?
It's possible there's something we want to change here, but it's far
from obvious what that thing is. Our WAL file handling is
ridiculously hard to understand, but the problem with changing it is
that there wi
Are there any TODO items here?
---
On Mon, Sep 12, 2011 at 09:36:02PM +0300, Peter Eisentraut wrote:
> Isn't the naming of the xlog files slightly bogus?
>
> We have the following sequence:
>
> 000108D000FD
> 0
On Tue, Sep 13, 2011 at 12:18 PM, Jaime Casanova wrote:
>> and extending
>> pg_xlogfile_name() so that it accepts not only LSN but also the timeline?
>> This idea enables us to get the backup start WAL file name by executing
>> "SELECT pg_xlogfile_name(pg_current_timeline(), pg_start_backup());".
On Mon, Sep 12, 2011 at 8:44 PM, Fujii Masao wrote:
> On Tue, Sep 13, 2011 at 3:36 AM, Peter Eisentraut wrote:
>> The return value of pg_start_backup that currently looks something like
>>
>> pg_start_backup
>> -
>> 8D1/C9013758
>>
>> should really be
>>
>> 08D1C9013758
>>
On Tue, Sep 13, 2011 at 3:36 AM, Peter Eisentraut wrote:
> The return value of pg_start_backup that currently looks something like
>
> pg_start_backup
> -
> 8D1/C9013758
>
> should really be
>
> 08D1C9013758
>
> (perhaps the timeline should be included?)
This change might b
Peter Eisentraut writes:
> Isn't the naming of the xlog files slightly bogus?
No doubt, but by now there's enough replication-ish third-party code
that knows about them that I'm afraid changing these conventions would
be much more painful than it's worth.
regards, tom lan
On 12.09.2011 21:36, Peter Eisentraut wrote:
PS2: While we're discussing the cleanup of xlog.c, someone daring could
replace XLogRecPtr by a plain uint64 and possibly save hundres of lines
of code and eliminate a lot of the above confusion.
One problem with that is that it would break binary
b
