> > > Hm, wasn't it handling non-atomic disk writes, Andreas?
> >
> > Yes, but for me, that was only one (for me rather minor) issue.
> > I still think that the layout of PostgreSQL pages was designed to
> > reduce the risc of a (heap) page beeing inconsistent because it is
> > only partly writ
> > In short I do not think that the current implementation of
> > "physical log" does what it was intended to do :-(
>
> Hm, wasn't it handling non-atomic disk writes, Andreas?
Yes, but for me, that was only one (for me rather minor) issue.
I still think that the layout of PostgreSQL pages was
> After thinking about this a little, I believe I see why Vadim did it
> the way he did. Suppose we tried to make the code sequence be
>
> obtain write lock on buffer;
> XLogOriginalPage(buffer); // copy page to xlog if first since ckpt
> modify buffer;
> XLogInsert(xl
I wrote:
> The decision whether to log the whole buffer has to be atomic with the
> actual entry of the xlog record. Unless we want to hold the xlog insert
> lock for the entire time that we're (eg) splitting a btree page, that
> means we log the buffer after the modification work is done, not be
> >> 5. We will now run a new transaction with the same XID that was in use
> >> before the crash. If that transaction commits, then we have a tuple on
> >> disk that will be considered valid --- and should not be.
>
> > I do not think this is true. Before any modification to a page the
> > ori
Zeugswetter Andreas SB <[EMAIL PROTECTED]> writes:
> Is it so hard to swap ? First write page to log then modify in shmem.
> Then those pages would have additional value, because
> then utilities could do all sorts of things with those pages.
After thinking about this a little, I believe I see
> >> Hmm. Actually, what is written to the log is the *modified* page not
> >> its original contents.
> > Well, that sure is not what was discussed on the list for implementation !!
> > I thus really doubt above statement.
>
> Read the code.
Ok, sad.
>
> > Each page about to be modified shou
Zeugswetter Andreas SB <[EMAIL PROTECTED]> writes:
>> Hmm. Actually, what is written to the log is the *modified* page not
>> its original contents.
> I thus really doubt above statement.
Read the code.
> Each page about to be modified should be written to the txlog once,
> and only once befo
Hiroshi Inoue <[EMAIL PROTECTED]> writes:
> Yes there must be XLogFlush() before writing buffers.
> BTW how do we get the next XID if WAL files are corrupted ?
My not-yet-committed changes include storing the latest CheckPoint
record in pg_control (as well as in the WAL files). Recovery from
XLO
Zeugswetter Andreas SB <[EMAIL PROTECTED]> writes:
>> 5. We will now run a new transaction with the same XID that was in use
>> before the crash. If that transaction commits, then we have a tuple on
>> disk that will be considered valid --- and should not be.
> I do not think this is true. Befo
> > > 5. We will now run a new transaction with the same XID that was in use
> > > before the crash. If that transaction commits, then we have a tuple on
> > > disk that will be considered valid --- and should not be.
> >
> > I do not think this is true. Before any modification to a page the ori
Zeugswetter Andreas SB wrote:
>
> > 1. A new transaction inserts a tuple. The tuple is entered into its
> > heap file with the new transaction's XID, and an associated WAL log
> > entry is made. Neither one of these are on disk yet --- the heap tuple
> > is in a shmem disk buffer, and the WAL en
> 1. A new transaction inserts a tuple. The tuple is entered into its
> heap file with the new transaction's XID, and an associated WAL log
> entry is made. Neither one of these are on disk yet --- the heap tuple
> is in a shmem disk buffer, and the WAL entry is in the shmem
> WAL buffer.
>
>
13 matches
Mail list logo
