> > > Before commit or rollback the xlog is not flushed to disk, thus you can loose
> > > those xlog entries, but the index page might already be on disk because of
> > > LRU buffer reuse, no ?
> >
> > No. Buffer page is written to disk *only after corresponding records are flushed
> > to log* (W
> > Before commit or rollback the xlog is not flushed to disk, thus you can loose
> > those xlog entries, but the index page might already be on disk because of
> > LRU buffer reuse, no ?
>
> No. Buffer page is written to disk *only after corresponding records are flushed
> to log* (WAL means Wr
> Before commit or rollback the xlog is not flushed to disk, thus you can loose
> those xlog entries, but the index page might already be on disk because of
> LRU buffer reuse, no ?
No. Buffer page is written to disk *only after corresponding records are flushed
to log* (WAL means Write-Ahead-Log
> > I do not however see how the current solution fixes the original problem,
> > that we don't have a rollback for index modifications.
> > The index would potentially point to an empty heaptuple slot.
>
> How? There will be an XLOG entry inserting the heap tuple before the
> XLOG entry that u
Zeugswetter Andreas SB <[EMAIL PROTECTED]> writes:
> I do not however see how the current solution fixes the original problem,
> that we don't have a rollback for index modifications.
> The index would potentially point to an empty heaptuple slot.
How? There will be an XLOG entry inserting the
