View Single Post

   
  #9 (permalink)  
Old 04-15-2008, 11:28 PM
Heikki Linnakangas
 
Posts: n/a
Default Re: max_prepared_transactions default ... why 5?

Kevin Grittner wrote:
>>>> On Thu, Oct 18, 2007 at 11:23 AM, in message

> <87ejfswfvw.fsf@oxford.xeocode.com>, Gregory Stark <stark@enterprisedb.com>
> wrote:
>
>> If it's set to 0
>> then there's no real reason we need to wal log lock operations.

>
> Do we currently take advantage of that fact, or log them anyway?


No, we log them anyway.

There's a few other reasons to WAL log lock operations, see comments in
heap_lock_tuple:

> /*
> * XLOG stuff. You might think that we don't need an XLOG record because
> * there is no state change worth restoring after a crash. You would be
> * wrong however: we have just written either a TransactionId or a
> * MultiXactId that may never have been seen on disk before, and we need
> * to make sure that there are XLOG entries covering those ID numbers.
> * Else the same IDs might be re-used after a crash, which would be
> * disastrous if this page made it to disk before the crash. Essentially
> * we have to enforce the WAL log-before-data rule even in this case.
> * (Also, in a PITR log-shipping or 2PC environment, we have to have XLOG
> * entries for everything anyway.)
> */


There's also the risk of torn pages. We set the xmax and the XMAX_*_LOCK
flag in heap_lock_tuple, and it's possible that only one of those
changes is written to disk before crash.

--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com

---------------------------(end of broadcast)---------------------------
TIP 7: You can help support the PostgreSQL project by donating at

http://www.postgresql.org/about/donate

Reply With Quote