On 12/05/2014 02:31 AM, Andres Freund wrote:
On 2014-12-05 08:58:33 +0900, Michael Paquier wrote:
On Fri, Dec 5, 2014 at 8:09 AM, Andres Freund
wrote:
On 2014-12-04 16:26:02 +0200, Heikki Linnakangas wrote:
Yeah, that's broken.
I propose the attached. Or does anyone want to argue for adding
On 2014-12-05 08:58:33 +0900, Michael Paquier wrote:
> On Fri, Dec 5, 2014 at 8:09 AM, Andres Freund
> wrote:
>
> > On 2014-12-04 16:26:02 +0200, Heikki Linnakangas wrote:
> > > Yeah, that's broken.
> > >
> > > I propose the attached. Or does anyone want to argue for adding an
> > > XLogRecGetFPI
On Fri, Dec 5, 2014 at 8:09 AM, Andres Freund
wrote:
> On 2014-12-04 16:26:02 +0200, Heikki Linnakangas wrote:
> > Yeah, that's broken.
> >
> > I propose the attached. Or does anyone want to argue for adding an
> > XLogRecGetFPILen() accessor macro for the hole_length in xlogreader.h.
> It's
> >
On 2014-12-04 16:26:02 +0200, Heikki Linnakangas wrote:
> Yeah, that's broken.
>
> I propose the attached. Or does anyone want to argue for adding an
> XLogRecGetFPILen() accessor macro for the hole_length in xlogreader.h. It's
> not something a redo routine would need, nor most XLOG-reading appli
On 11/25/2014 05:36 AM, Andres Freund wrote:
Hi,
The new WAL format calculates FPI vs plain record data like:
rec_len = XLogRecGetDataLen(record) + SizeOfXLogRecord;
fpi_len = record->decoded_record->xl_tot_len - rec_len;
Due to the amount of data now handled outside the main da
Hi,
The new WAL format calculates FPI vs plain record data like:
rec_len = XLogRecGetDataLen(record) + SizeOfXLogRecord;
fpi_len = record->decoded_record->xl_tot_len - rec_len;
Due to the amount of data now handled outside the main data portion ,
that doesn't seem correct to me. A
