On Thu, Jul 12, 2018 at 1:29 PM, Michael Paquier <michael@paquier.xyz> wrote:
> On Thu, Jul 12, 2018 at 07:33:54AM +0000, Amit Kapila wrote:
>> Allow using the updated tuple while moving it to a different partition.
>>
>> An update that causes the tuple to be moved to a different partition was
>> missing out on re-constructing the to-be-updated tuple, based on the latest
>> tuple in the update chain. Instead, it's simply deleting the latest tuple
>> and inserting a new tuple in the new partition based on the old tuple.
>> Commit 2f17844104 didn't consider this case, so some of the updates were
>> getting lost.
>>
>> In passing, change the argument order for output parameter in ExecDelete
>> and add some commentary about it.
>
> Looks unrelated, but flaviventris (a snake?) has just complained:
> https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=flaviventris&dt=2018-07-12%2007%3A36%3A01
>
Yeah, I am confused as to how this commit can lead to that failure.
Anyway, just to clarify my understanding, it seems that master node
has executed an Insert statement (INSERT INTO replayed(val) SELECT
coalesce(max(val),0) + 1 AS newval FROM replayed RETURNING val) and
waiting for standby to sync up. In the meantime, some background
process (probably walsender ?) crashed. Are you seeing anything
different? Any other clue?
By the way, I could see the same (appears to be same) failure in other
buildfarm (skink, serinus, etc.) logs in some previous runs:
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=skink&dt=2017-11-30%2008%3A47%3A34
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=serinus&dt=2018-05-18%2020%3A14%3A01
--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com