Hallo Peter,
In "xact.c", maybe I'd assign blockState in the else branch, instead of
overriding it?
I think it was better the way it is, since logically the block state is
first set, then set again after the new transaction starts.
Ok.
About the static _SPI_{commit,rollback} functions: I
Patch has been committed, thanks.
On 2019-03-18 21:20, Fabien COELHO wrote:
> Minor remarks:
>
> In "xact.c", maybe I'd assign blockState in the else branch, instead of
> overriding it?
I think it was better the way it is, since logically the block state is
first set, then set again after the n
Hallo Peter,
Updated patch. I have squashed the two previously separate patches
together in this one.
Ok.
I do not understand the value of the SAVEPOINT in the tests.
The purpose of the SAVEPOINT in the test is because it exercises
different switch cases in CommitTransactionCommand() an
On 2019-02-16 06:22, Andres Freund wrote:
>> +static int save_XactIsoLevel;
>> +static bool save_XactReadOnly;
>> +static bool save_XactDeferrable;
>
> We normally don't define variables in the middle of a file? Also, why
> do these need to be global vars rather than defined where we do
> chaini
Updated patch. I have squashed the two previously separate patches
together in this one.
On 2019-01-06 15:14, Fabien COELHO wrote:
> I do not understand the value of the SAVEPOINT in the tests.
The purpose of the SAVEPOINT in the test is because it exercises
different switch cases in CommitTrans
Hi,
On 2019-01-02 16:02:21 +0100, Peter Eisentraut wrote:
> +++ b/src/backend/access/transam/xact.c
> @@ -189,6 +189,7 @@ typedef struct TransactionStateData
> boolstartedInRecovery; /* did we start in recovery? */
> booldidLogXid; /* has xid b
Hello Peter,
Sure. Within a read-only tx, it could check that transaction_read_only is
on, and still on when chained, though.
I think the tests prove the point that the values are set and unset and
reset in various scenarios. We don't need to test every single
combination, that's not the jo
Hello Peter,
I'm wary of changing the SPI_commit and SPI_rollback interfaces which are
certainly being used outside the source tree and could break countless
code, and it seems quite unclean that commit and rollback would do
anything else but committing or rollbacking.
These are new as of PG
On 26/12/2018 09:47, Fabien COELHO wrote:
> I'm wary of changing the SPI_commit and SPI_rollback interfaces which are
> certainly being used outside the source tree and could break countless
> code, and it seems quite unclean that commit and rollback would do
> anything else but committing or ro
On 26/12/2018 09:20, Fabien COELHO wrote:
> I try to avoid global variables when possible as a principle, because I
> paid to learn that they are bad:-) Maybe I'd do a local struct, declare an
> instance within the function, and write two functions to dump/restore the
> transaction status variab
On 2018-Dec-26, Fabien COELHO wrote:
> > > Copying & comparing nodes are updated. Should making, outing and reading
> > > nodes also be updated?
> >
> > TransactionStmt isn't covered by the node serialization functions, so I
> > didn't see anything to update. What did you have in mind?
>
> Sigh
Updated patch attached. The previous (v2) patch apparently didn't apply
anymore.
Second patch applies cleanly, compiles, "make check" ok.
Also about testing, I'd do less rounds, 4 quite seems enough.
--
Fabien.
Updated patch attached. The previous (v2) patch apparently didn't apply
anymore.
Second patch applies cleanly, compiles, "make check" ok.
As I do not know much about the SPI stuff, some of the comments below may
be very stupid.
I'm wary of changing the SPI_commit and SPI_rollback interfa
Hello Peter,
Shouldn't psql tab completion be updated as well?
Done. (I only did the AND CHAIN, not the AND NO CHAIN.)
Sure, that is the useful part.
I must admit that do not like much the three global variables &
Save/Restore functions. I'd suggest saving directly into 3 local variables
On 04/11/2018 12:20, Fabien COELHO wrote:
> Shouldn't psql tab completion be updated as well?
Done. (I only did the AND CHAIN, not the AND NO CHAIN.)
> I must admit that do not like much the three global variables &
> Save/Restore functions. I'd suggest saving directly into 3 local variables
>
Hello Peter,
Attached is a rebased patch set. No functionality changes.
Patch applies cleanly, compile, global make check ok, doc gen ok.
Shouldn't psql tab completion be updated as well?
About the code:
I must admit that do not like much the three global variables &
Save/Restore functio
On 05/04/2018 10:35, Heikki Linnakangas wrote:
> On 15/03/18 18:39, Alvaro Herrera wrote:
>>> From 517bc6d9fefdee9135857d9562f644f2984ace32 Mon Sep 17 00:00:00 2001
>>> From: Peter Eisentraut
>>> Date: Sun, 18 Feb 2018 09:33:53 -0500
>>> Subject: [PATCH v1 6/8] Turn transaction_isolation into GUC
On 02/10/2018 07:38, Michael Paquier wrote:
> The patch set does not apply anymore, so this patch is moved to next CF,
> waiting on author.
Attached is a rebased patch set. No functionality changes.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Suppor
On Tue, Jul 17, 2018 at 08:21:20PM +0300, Heikki Linnakangas wrote:
> Oh, is that all it does? That's disappointing, because that's a lot less
> powerful than how I understand chained transactions. And at the same time
> relieving, because that's a lot simpler to implement :-).
>
> In Gray & Reute
On 01/03/18 05:35, Peter Eisentraut wrote:
The SQL standard offers the "chained transactions" feature to address
this. The new command variants COMMIT AND CHAIN and ROLLBACK AND CHAIN
immediately start a new transaction with the characteristics (isolation
level, read/write, deferrable) of the pr
On 4/5/18 04:35, Heikki Linnakangas wrote:
> With this patch, this stops working:
>
> set transaction_isolation='default';
But why is this supposed to work? This form is not documented anywhere.
You can use RESET or SET TO DEFAULT.
I suspect this is some artifact in the implementation that thi
On 15/03/18 18:39, Alvaro Herrera wrote:
From 517bc6d9fefdee9135857d9562f644f2984ace32 Mon Sep 17 00:00:00 2001
From: Peter Eisentraut
Date: Sun, 18 Feb 2018 09:33:53 -0500
Subject: [PATCH v1 6/8] Turn transaction_isolation into GUC enum
XXX no idea why it was done the way it was, but this seem
On 3/15/18 12:39, Alvaro Herrera wrote:
>> Subject: [PATCH v1 1/8] Update function comments
>> Subject: [PATCH v1 2/8] Rename TransactionChain functions
>> Subject: [PATCH v1 3/8] Simplify parse representation of savepoint commands
>> Subject: [PATCH v1 4/8] Improve savepoint error messages
>> Subj
Peter Eisentraut wrote:
> Subject: [PATCH v1 1/8] Update function comments
>
> After a6542a4b6870a019cd952d055d2e7af2da2fe102, some function comments
> were misplaced. Fix that.
Note typo WarnNoTranactionChain in one comment. The patch leaves
CheckTransactionChain with no comment whatsoever; m
On 2018-03-05 09:21:33 +, Simon Riggs wrote:
> On 2 March 2018 at 07:18, Andres Freund wrote:
> > Hi,
> >
> > On 2018-02-28 22:35:52 -0500, Peter Eisentraut wrote:
> >> This feature is meant to help manage transaction isolation in
> >> procedures.
> >
> > This is a major new feature, submitted
On 2 March 2018 at 07:18, Andres Freund wrote:
> Hi,
>
> On 2018-02-28 22:35:52 -0500, Peter Eisentraut wrote:
>> This feature is meant to help manage transaction isolation in
>> procedures.
>
> This is a major new feature, submitted the evening before the last CF
> for v11 starts. Therefore I thi
Hi,
On 2018-02-28 22:35:52 -0500, Peter Eisentraut wrote:
> This feature is meant to help manage transaction isolation in
> procedures.
This is a major new feature, submitted the evening before the last CF
for v11 starts. Therefore I think it should just be moved to the next
fest, it doesn't seem
27 matches
Mail list logo
