On Mon, Feb 25, 2019 at 02:28:23PM +0900, Michael Paquier wrote:
> Done. I have spent some time today looking at the performance of the
> patch, designing a worst-case scenario to see how much bloat this adds
> in COMMIT PREPARED by running across many sessions 2PC transactions
> taking SHARE lock
On Sat, Feb 23, 2019 at 08:44:43AM +0900, Michael Paquier wrote:
> Thanks. I am still looking at this patch an extra time, so this may
> take at most a couple of days from my side. For now I have committed
> the test portion, which is independently useful and caused recovery of
> multixact post-c
On Fri, Feb 22, 2019 at 12:17:01PM +0100, Oleksii Kliukin wrote:
> Thank you for updating the patch and sorry for the delay, it looks good to
> me, the tests pass on my system.
Thanks. I am still looking at this patch an extra time, so this may
take at most a couple of days from my side. For now
Hi,
Michael Paquier wrote:
> On Wed, Feb 20, 2019 at 11:50:42AM +0100, Oleksii Kliukin wrote:
>> RecoverPreparedTransactions calls ProcessRecords with
>> twophase_recover_callbacks right after releasing the TwoPhaseStateLock, so I
>> think lock_held should be false here (matching the similar cal
On Wed, Feb 20, 2019 at 11:50:42AM +0100, Oleksii Kliukin wrote:
> RecoverPreparedTransactions calls ProcessRecords with
> twophase_recover_callbacks right after releasing the TwoPhaseStateLock, so I
> think lock_held should be false here (matching the similar call of
> TwoPhaseGetDummyProc at lock
Michael Paquier wrote:
>
> Attached is an updated patch. Thanks for the feedback.
@@ -1755,7 +1755,7 @@ void
multixact_twophase_recover(TransactionId xid, uint16 info,
void *recdata, uint32 len)
{
- BackendId dummyBackendId = TwoPhaseGetDummyBackendId(xid);
+
On Wed, Feb 20, 2019 at 03:14:07PM +0900, Masahiko Sawada wrote:
> @@ -811,6 +811,9 @@ TwoPhaseGetGXact(TransactionId xid)
> static TransactionId cached_xid = InvalidTransactionId;
> static GlobalTransaction cached_gxact = NULL;
>
> + Assert(!lock_held ||
> +
On Tue, Feb 19, 2019 at 12:27 PM Michael Paquier wrote:
>
> On Mon, Feb 18, 2019 at 05:05:13PM +0100, Oleksii Kliukin wrote:
> > That looks like a race condition to me. What happens is that another
> > transaction with the name identical to the running one can start and proceed
> > to the prepare
On Tue, Feb 19, 2019 at 08:17:14PM +0100, Oleksii Kliukin wrote:
> I gave it a spin on the same VM host as shown to constantly reproduce the
> issue and observed neither 'identifier already in use' nor any locking
> issues over a few dozens of runs, so it looks good to me.
Thanks for the confirmat
Hi,
Oleksii Kliukin wrote:
>
> The approach looks good to me. Surprisingly, I saw no stalled backends
> because of the double acquisition of lock at TwoPhaseGetGXact once I put a
> simple TwoPhaseStateLock right before the "gxact->valid = false” line; I
> will test your patch and post the outcom
On Tue, Feb 19, 2019 at 10:59:33AM +0100, Oleksii Kliukin wrote:
> Michael Paquier wrote:
>> If you run two transactions in parallel using your script, the second
>> transaction would wait at LOCK time until the first transaction
>> releases its locks with the COMMIT PREPARED.
>
> That is the des
Hi,
Michael Paquier wrote:
> On Mon, Feb 18, 2019 at 05:05:13PM +0100, Oleksii Kliukin wrote:
>> That looks like a race condition to me. What happens is that another
>> transaction with the name identical to the running one can start and proceed
>> to the prepare phase while the original one com
On Tue, Feb 19, 2019 at 12:26:04PM +0300, Konstantin Knizhnik wrote:
> May be I missed something, but why it is not possible just to move removing
> 2PC GXact before releasing transaction locks:
Because we need to keep the 2PC reference in shared memory when
releasing the locks before removing the
On 19.02.2019 7:44, Michael Paquier wrote:
On Tue, Feb 19, 2019 at 01:07:06AM -0300, Alvaro Herrera wrote:
On 2019-Feb-19, Michael Paquier wrote:
extern GlobalTransaction MarkAsPreparing(TransactionId xid, const char *gid,
Hmm, ABI break ...
Well, sure. I always post patches for HEAD fi
On Tue, Feb 19, 2019 at 01:07:06AM -0300, Alvaro Herrera wrote:
> On 2019-Feb-19, Michael Paquier wrote:
>> extern GlobalTransaction MarkAsPreparing(TransactionId xid, const char *gid,
>
> Hmm, ABI break ...
Well, sure. I always post patches for HEAD first. And I was actually
wondering if that
On 2019-Feb-19, Michael Paquier wrote:
> diff --git a/src/include/access/twophase.h b/src/include/access/twophase.h
> index 6228b091d8..2dcd08e9fa 100644
> --- a/src/include/access/twophase.h
> +++ b/src/include/access/twophase.h
> @@ -34,7 +34,7 @@ extern void TwoPhaseShmemInit(void);
> extern v
On Mon, Feb 18, 2019 at 05:05:13PM +0100, Oleksii Kliukin wrote:
> That looks like a race condition to me. What happens is that another
> transaction with the name identical to the running one can start and proceed
> to the prepare phase while the original one commits, failing at last instead
> of
Hello,
We have an app that copies some metrics between predefined tables on the
source and destination clusters, truncating the table at the source
afterward.
The app locks both the source and the destination table at the beginning and
then, once copy concludes, prepares a transaction on each of
18 matches
Mail list logo
