Re: WAL-based allocation of XIDs is insecure - Mailing list pgsql-hackers

From Vadim Mikheev
Subject Re: WAL-based allocation of XIDs is insecure
Date
Msg-id 058d01c0a704$3de80ee0$4879583f@sectorbase.com
Whole thread Raw
In response to AW: WAL-based allocation of XIDs is insecure  (Zeugswetter Andreas SB <ZeugswetterA@wien.spardat.at>)
List 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




pgsql-hackers by date:

Previous
From: Michael Meskes
Date:
Subject: CeBit
Next
From: Martin Devera
Date:
Subject: WAL & SHM principles