From: | Michael Paquier <michael(dot)paquier(at)gmail(dot)com> |
---|---|
To: | leohuanruan(at)gmail(dot)com |
Cc: | PostgreSQL mailing lists <pgsql-bugs(at)postgresql(dot)org>, Andres Freund <andres(at)anarazel(dot)de> |
Subject: | Re: BUG #14319: Logical decoding dropping statements in subtransactions |
Date: | 2016-09-13 07:33:40 |
Message-ID: | CAB7nPqSvrUR5j1bhnBbYspvCEj3T_o4JCjoh62LDM9innUqcvA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
On Fri, Sep 9, 2016 at 10:26 AM, <leohuanruan(at)gmail(dot)com> wrote:
> When inserting records within a subtransaction, not all inserts are reported
> by pg_logical_slot_peek_changes(). With more than 4096 inserts, the output
> is truncated to the nearest multiple of 4096.
>
> This occurs in 9.5.4, but not in 9.5.3.
And the first commit to cause this regression is this one:
commit: 8caf9fe62544b351d4f6219bf416f5ce08ef3c21
author: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
date: Thu, 30 Jun 2016 12:37:02 -0400
Fix typo in ReorderBufferIterTXNInit().
This looks like it would cause changes from subtransactions to be missed
by the iterator being constructed, if those changes had been spilled to
disk previously. This implies that large subtransactions might be lost
(in whole or in part) by logical replication. Found and fixed by
Petru-Florin Mihancea, per bug #14208.
Report: <20160622144830(dot)5791(dot)22512(at)wrigleys(dot)postgresql(dot)org>
4096 matches the maximum number of changes that can be saved in memory
from reorderbuffer.c. Andres?
--
Michael
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2016-09-13 15:52:31 | Re: BUG #14320: systemd terminates postgresql hot standby instance 90 seconds after start |
Previous Message | lilacyd | 2016-09-13 00:34:01 | BUG #14323: char input does not work |