Re: [Fwd: Deferred Transactions, Transaction Guaranteeand COMMITwithout waiting] - Mailing list pgsql-patches

From Simon Riggs
Subject Re: [Fwd: Deferred Transactions, Transaction Guaranteeand COMMITwithout waiting]
Date
Msg-id 1175612819.4386.1155.camel@silverbirch.site
Whole thread Raw
In response to Re: [Fwd: Deferred Transactions, Transaction Guarantee and COMMITwithout waiting]  (Heikki Linnakangas <heikki@enterprisedb.com>)
List pgsql-patches
On Tue, 2007-04-03 at 15:04 +0100, Heikki Linnakangas wrote:
> Simon Riggs wrote:
> >> Here's the next version (v10) of the patch, ready for review.

Thanks for reviewing.

> >> I've struggled with what to call all of the new concepts inherent in
> >> this patch, but I think I've got something now. COMMIT NOWAIT doesn't
> >> describe this feature, since there is no command of that name in the
> >> implementation that we've agreed. So what's it called?
>
> Hmm. Deferred commit? Asynchronous commit?

I'll change everything to whatever we agree. Other ideas?

> >> wal_writer_delay = 0 (default) ms enables this feature at server start.
> >> Once enabled, individual sessions or transactions may request
> >> transaction_guarantee = off, or it may be set for the whole server.
>
> This error message talks about commit_fsync_delay:
> ERROR:  cannot set transaction guarantee when server commit_fsync_delay = 0
>
> Should be wal_writer_delay, I suppose.

Thanks, will change.

> The HeapTupleSetVisibilityInfo function with it's action-argument looks
> funny to me.

Lets see what others think as well.

> You don't need to check if a transaction has been flushed when setting
> the HEAP_XMAX/XMIN_INVALID flags for aborted transactions.

I was after as little change as possible in the code, which is why I
left that as it was. But I think you're right and that's a one line
change to avoid that is possible. Will do.

--
  Simon Riggs
  EnterpriseDB   http://www.enterprisedb.com



pgsql-patches by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: RESET SESSION v2
Next
From: Andrew Dunstan
Date:
Subject: Re: COPY-able sql log outputs