Re: WAL-based allocation of XIDs is insecure

From: "Vadim Mikheev" <vmikheev(at)sectorbase(dot)com>
To: "Zeugswetter Andreas SB" <ZeugswetterA(at)wien(dot)spardat(dot)at>, "PostgreSQL Development" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: WAL-based allocation of XIDs is insecure
Date: 2001-03-07 12:43:41
Message-ID: 058d01c0a704$3de80ee0$4879583f@sectorbase.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> > 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 acceptable minimum. If your hw and os can

I believe that I explained why it's not minor issue (and never was).
Eg - PageRepaireFragmentation "compacts" page exactly like other,
overwriting, DBMSes do and partial write of modified page means
lost page content.

> > And for what else "physical log" could be used?
>
> 1. create a consistent state if rollforward bails out for some reason
> but log is still readable

What difference between consistent state as it was before checkpoint and
after that? Why should we log old page images? New (after modification) page
images are also consistent and can be used to create consistent state.

> 2. have an easy way to handle index rollforward/abort
> (might need to block some index modifications during checkpoint though)

There is no problems now. Page is either splitted (new page created/
properly initialized, right sibling updated) or not.

> 3. ease the conversion to overwrite smgr

?

> 4. ease the creation of BAR to create consistent snapshot without
> need for log rollforward

Isn't it the same as 1. with "snapshot" == "state"?

> > Now, why should we log page as it was *before* modification?
> > We would log modification anyway (yet another log record!) and
>
> Oh, so currently you only do eighter ? I would at least add the
> info which slot was inserted/modified (maybe that is already there (XID)).

Relfilenode + TID are saved, as well as anything else that would required
to UNDO operation, in future.

> > would apply it to page, so result would be the same as now when
> > we log page after modification - consistent *modifyed* page.
>
> Maybe I am too focused on the implementation of one particular db,
> that I am not able to see this without prejudice,
> and all is well as is :-)
^^^^^^^^^^^^^^^^^^^^^
I hope so -:)

Vadim

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Martin Devera 2001-03-07 12:47:07 WAL & SHM principles
Previous Message Michael Meskes 2001-03-07 12:20:02 CeBit