> > > 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
> > 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 written to an acc
> > 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
> On third thought --- we could still log the original page contents and
> the modification log record atomically, if what were logged in the xlog
> record were (essentially) the parameters to the operation being logged,
> not its results. That is, make the log entry before you start doing the
> m
Zeugswetter Andreas SB <[EMAIL PROTECTED]> wrote:
>
> 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?
And for what else "physical log" could be used?
The point was - copy entir
> The point is to make the allocation of XIDs and OIDs work the same way.
> In particular, if we are forced to reset the XLOG using what's stored in
> pg_control, it would be good if what's stored in pg_control is a value
> beyond the last-used XID/OID, not a value less than the last-used ones.
I
> Consider the following scenario:
>
> 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 entr
Ian Lance Taylor <[EMAIL PROTECTED]> writes:
> I described myself unclearly. I was suggesting an addition to what
> you are suggesting. The worst case can not be worse.
Then I didn't (and still don't) understand your suggestion. Want to
try again?
> If you are going to allocate a few thousand
> 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.
>
>
Ian Lance Taylor <[EMAIL PROTECTED]> writes:
> Tom Lane <[EMAIL PROTECTED]> writes:
>> Up through 7.0, Postgres allocated XIDs a thousand at a time, and not
>> only did the not-yet-used XIDs get lost in a crash, they'd get lost in
>> a normal shutdown too. What I propose will waste XIDs in a cras
Tom Lane <[EMAIL PROTECTED]> writes:
> Ian Lance Taylor <[EMAIL PROTECTED]> writes:
> > I described myself unclearly. I was suggesting an addition to what
> > you are suggesting. The worst case can not be worse.
>
> Then I didn't (and still don't) understand your suggestion. Want to
> try aga
Tom Lane <[EMAIL PROTECTED]> writes:
> Ian Lance Taylor <[EMAIL PROTECTED]> writes:
> > I think your example demonstrates something slightly different. I
> > think it demonstrates that Postgres must flush the XLOG entry to disk
> > before it flushes any buffer to disk which uses an XID which was
Ian Lance Taylor <[EMAIL PROTECTED]> writes:
> I think your example demonstrates something slightly different. I
> think it demonstrates that Postgres must flush the XLOG entry to disk
> before it flushes any buffer to disk which uses an XID which was just
> allocated.
That would be an alternati
Tom Lane <[EMAIL PROTECTED]> writes:
> After thinking about this for a little, it seems to me that XID
> assignment should be handled more like OID assignment: rather than
> handing out XIDs one-at-a-time, varsup.c should allocate them in blocks,
> and should write an XLOG record to reflect the a
Consider the following scenario:
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
25 matches
Mail list logo
