From: | Michael Paquier <michael(dot)paquier(at)gmail(dot)com> |
---|---|
To: | Stas Kelvich <s(dot)kelvich(at)postgrespro(dot)ru> |
Cc: | David Steele <david(at)pgmasters(dot)net>, PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Simon Riggs <simon(at)2ndquadrant(dot)com>, Andres Freund <andres(at)anarazel(dot)de> |
Subject: | Re: Speedup twophase transactions |
Date: | 2016-04-02 00:14:24 |
Message-ID: | CAB7nPqRpQc7dByVitWZ8+eN7Hyp90GeX6EWj5zh1cFBRdpF1ZQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, Apr 1, 2016 at 10:53 PM, Stas Kelvich <s(dot)kelvich(at)postgrespro(dot)ru> wrote:
> I wrote:
>> While testing the patch, I found a bug in the recovery conflict code
>> path. You can do the following to reproduce it:
>> 1) Start a master with a standby
>> 2) prepare a transaction on master
>> 3) Stop immediate on standby to force replay
>> 4) commit prepare transaction on master
>> 5) When starting the standby, it remains stuck here:
>
> Hm, I wasn’t able to reproduce that. Do you mean following scenario or am I missing something?
>
> (async replication)
>
> $node_master->psql('postgres', "
> begin;
> insert into t values (1);
> prepare transaction 'x';
> ");
> $node_slave->teardown_node;
> $node_master->psql('postgres',"commit prepared 'x'");
> $node_slave->start;
> $node_slave->psql('postgres',"select count(*) from pg_prepared_xacts", stdout => \$psql_out);
> is($psql_out, '0', "Commit prepared on master while slave is down.");
Actually, not exactly, the transaction prepared on master created a
table. Sorry for the lack of precisions in my review.
--
Michael
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Geoghegan | 2016-04-02 00:29:03 | Re: Using quicksort for every external sort run |
Previous Message | Shulgin, Oleksandr | 2016-04-01 23:57:32 | Re: More stable query plans via more predictable column statistics |