On 2015-03-02 18:45:18 +0100, Andres Freund wrote:
On 2015-03-02 19:23:56 +0200, Heikki Linnakangas wrote:
Pass the prepared XID as yet another argument to XactEmitCommitRecord, and
have XactEmitCommitRecord emit the xl_xact_commit_prepared part of the
record too. It might even make sense
On 2015-03-15 16:30:16 +0100, Andres Freund wrote:
The attached patch does pretty much what you suggested above and tries
to address all the point previously made. I plan to push this fairly
soon; unless somebody has further input.
Pushed, after fixing two typos in decode.c I introduced while
On 2015-03-02 19:11:15 +0200, Heikki Linnakangas wrote:
Come to think of it, it would be cleaner anyway to move the
XLogBeginInsert() and XLogInsert() calls inside XactEmitCommitRecord. Then
those structs don't need to be static either.
That was my first thought as well - but it doesn't easily
On 2015-02-25 12:10:42 +0100, Andres Freund wrote:
On 2015-02-24 20:51:42 +0200, Heikki Linnakangas wrote:
Regarding XactEmitCommitRecord and XactEmitAbortRecord, I wonder if you
could pass an xl_xact_parsed/abort_commit struct to them, instead of the
individual fields? You could then also
On 03/02/2015 06:51 PM, Andres Freund wrote:
On 2015-02-25 12:10:42 +0100, Andres Freund wrote:
On 2015-02-24 20:51:42 +0200, Heikki Linnakangas wrote:
Regarding XactEmitCommitRecord and XactEmitAbortRecord, I wonder if you
could pass an xl_xact_parsed/abort_commit struct to them, instead of
On 03/02/2015 07:14 PM, Andres Freund wrote:
On 2015-03-02 19:11:15 +0200, Heikki Linnakangas wrote:
Come to think of it, it would be cleaner anyway to move the
XLogBeginInsert() and XLogInsert() calls inside XactEmitCommitRecord. Then
those structs don't need to be static either.
That was my
On Fri, Feb 27, 2015 at 7:10 AM, Michael Paquier
michael.paqu...@gmail.com wrote:
No, no. I meant that it is good the way your patch does it in
xactdesc.c, where both frontend and backend can reach it.
Agreed, that seems much better than duplicating it.
--
Robert Haas
EnterpriseDB:
On 2015-02-27 16:26:08 +0900, Michael Paquier wrote:
On Wed, Feb 25, 2015 at 8:10 PM, Andres Freund and...@2ndquadrant.com wrote:
On 2015-02-24 20:51:42 +0200, Heikki Linnakangas wrote:
On 02/20/2015 05:21 PM, Andres Freund wrote:
There's one bit that I'm not so sure about though: To avoid
On Fri, Feb 27, 2015 at 6:49 PM, Andres Freund and...@2ndquadrant.com wrote:
On 2015-02-27 16:26:08 +0900, Michael Paquier wrote:
On Wed, Feb 25, 2015 at 8:10 PM, Andres Freund and...@2ndquadrant.com
wrote:
On 2015-02-24 20:51:42 +0200, Heikki Linnakangas wrote:
On 02/20/2015 05:21 PM,
On Wed, Feb 25, 2015 at 8:10 PM, Andres Freund and...@2ndquadrant.com wrote:
On 2015-02-24 20:51:42 +0200, Heikki Linnakangas wrote:
On 02/20/2015 05:21 PM, Andres Freund wrote:
There's one bit that I'm not so sure about though: To avoid duplication
I've added Parse(Commit/Abort)Record(), but
On 24 February 2015 at 18:51, Heikki Linnakangas
hlinnakan...@vmware.com wrote:
On 02/20/2015 05:21 PM, Andres Freund wrote:
In the attached patch I've merged compact/noncompact code, made aborts
use similar logic to avoid including useless bytes and used both for the
2pc equivalents.
+1
Hi,
On 2015-02-24 20:51:42 +0200, Heikki Linnakangas wrote:
On 02/20/2015 05:21 PM, Andres Freund wrote:
To avoid using more space in the compact case the 'xinfo' field
indicating the presence of further data is only included when a byte in
the xl_info flag is set (similar to what heap rmgr
On 02/20/2015 05:21 PM, Andres Freund wrote:
In the attached patch I've merged compact/noncompact code, made aborts
use similar logic to avoid including useless bytes and used both for the
2pc equivalents.
+1 for this approach in general.
To avoid using more space in the compact case the
13 matches
Mail list logo
