From: | Nikhil Sontakke <nikhils(at)2ndquadrant(dot)com> |
---|---|
To: | Michael Paquier <michael(dot)paquier(at)gmail(dot)com> |
Cc: | Simon Riggs <simon(at)2ndquadrant(dot)com>, Stas Kelvich <s(dot)kelvich(at)postgrespro(dot)ru>, PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org>, Jesper Pedersen <jesper(dot)pedersen(at)redhat(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com> |
Subject: | Re: Speedup twophase transactions |
Date: | 2017-01-27 13:02:07 |
Message-ID: | CAMGcDxfUCe2-QNPen53fp-z_xM3vW1M0H4HaM0SAdtRNEXRK-w@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | Postg토토 꽁 머니SQL |
>>> The xact_redo code will add prepared transactions to the
>>> KnownPreparedList in memory. Earlier it used to create the on-disk 2PC
>>> file.
>>>
>>> At standby promote, the surviving (yet uncommitted) prepared
>>> transactions from KnownPreparedList need to be persisted, right?
>>
>> I don't see why, so please explain or show the error that can be
>> caused if we don't.
>
> I agree with Simon here. There is no point to fsync the 2PC files are
> in case of an immediate crash after promotion replay will happen from
> the last checkpoint, aka the one before the promotion has been
> triggered. So there is no point to flush them at promotion, they would
> be replayed anyway.
1) start master
2) start streaming replica
3) on master
begin;
create table test1(g int);
prepare transaction 'test';
4) Promote standby via trigger file or via "pg_ctl promote"
I thought if we don't fsync the KnownPreparedList then we might not
create the 2PC state properly on the standby.
However, I do realize that we will be calling
RecoverPreparedTransactions() eventually on promote. This function
will be modified to go through the KnownPreparedList to reload shmem
appropriately for 2PC. So, all good in that case.
Apologies for the digression.
Regards,
Nikhils
--
Nikhil Sontakke http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Simon Riggs | 2017-01-27 13:02:23 | Re: pg_ls_dir & friends still have a hard-coded superuser check |
Previous Message | Tom Lane | 2017-01-27 12:56:19 | Re: Failure in commit_ts tap tests |