Duplicated row after promote in synchronous streaming replication

From: Dang Minh Huong <kakalot49(at)gmail(dot)com>
To: pgsql-bugs(at)postgresql(dot)org
Cc: "<pgsql-hackers(at)postgresql(dot)org>" <pgsql-hackers(at)postgresql(dot)org>
Subject: Duplicated row after promote in synchronous streaming replication
Date: 2014-03-26 15:08:11
Message-ID: B44DAC9C-FD62-4BD1-88A7-89F184396E99@gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs pgsql-hackers

Hi all,

I'm using PostgreSQL 9.1.10 for my HA project and have found this problem.

I did (multiple times) the following sequence in my primary/standby synchronous replication environment,

1. Update rows in a table (which have primary key constraint column) in active DB

2. Stop active DB

3. Promote standby DB

4. Confirm the updated table in promoted standby (new primary) and found that, there's a duplicate updated row (number of row was increased).

I think it is a replication bug but wonder if it was fixed yet.
Can somebody help me?

I'm not yet confirm PostgreSQL source, but here is my investigation result.

Updated table before promoted were HOT update (index file was not changed).

After promote i continue update that duplicated row (it returned two row updated), and confirm with pg_filedump, i found the duplicated row and only one is related to primary key index constraint.

Compare with old active DB, i saw that after promote line pointer of updated row (duplicated row) is broken into two line pointer, the new one is related to primary index constraint and the other is not related to. Some thing like below,

Old active DB:
ctid(0,3)->ctid(0,6)->ctid(0,7)

New active DB (after promote and update):
ctid(0,3)->ctid(0,9)
ctid(0,7)->ctid(0,10)

ctid(0,10) is not related to primary key index constraint.

Is something was wrong in redo log in standby DB? Or line pointer in HOT update feature?

Thanks and best regards,
Huong,

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Thom Brown 2014-03-26 15:18:21 Re: [HACKERS] Duplicated row after promote in synchronous streaming replication
Previous Message Tom Lane 2014-03-26 13:58:35 Re: BUG #9722: select ILIKE is not case insensitive in UTF8 cyrillic

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2014-03-26 15:12:58 Re: Useless "Replica Identity: NOTHING" noise from psql \d
Previous Message Robert Haas 2014-03-26 14:51:03 Re: Only first XLogRecData is visible to rm_desc with WAL_DEBUG