Обсуждение: pgsql: Check interrupts during logical decoding more frequently.
Check interrupts during logical decoding more frequently. When reading large amounts of preexisting WAL during logical decoding using the SQL interface we possibly could fail to check interrupts in due time. Similarly the same could happen on systems with a very high WAL volume while creating a new logical replication slot, independent of the used interface. Previously these checks where only performed in xlogreader's read_page callbacks, while waiting for new WAL to be produced. That's not sufficient though, if there's never a need to wait. Walsender's send loop already contains a interrupt check. Backpatch to 9.4 where the logical decoding feature was introduced. Branch ------ master Details ------- http://git.postgresql.org/pg/commitdiff/1cbc9480106241aaa8db112331e93d0a265b6db0 Modified Files -------------- src/backend/replication/logical/logical.c | 7 ++----- src/backend/replication/logical/logicalfuncs.c | 1 + 2 files changed, 3 insertions(+), 5 deletions(-)
Andres Freund <andres@anarazel.de> writes:
> Check interrupts during logical decoding more frequently.
FWIW, I think it's usually better style to put CHECK_FOR_INTERRUPTS
at the tops of loops rather than the bottoms. If you put it at the
bottom, it's easily bypassed unintentionally by a "continue" somewhere
in the middle of the loop body. (I suppose there could be cases where
that's actually what you want, but if so some comments would be
appropriate, because it's fragile coding.)
regards, tom lane
On 2014-06-30 10:10:24 -0400, Tom Lane wrote: > Andres Freund <andres@anarazel.de> writes: > > Check interrupts during logical decoding more frequently. > > FWIW, I think it's usually better style to put CHECK_FOR_INTERRUPTS > at the tops of loops rather than the bottoms. If you put it at the > bottom, it's easily bypassed unintentionally by a "continue" somewhere > in the middle of the loop body. (I suppose there could be cases where > that's actually what you want, but if so some comments would be > appropriate, because it's fragile coding.) Ok. Will do so from now on. I wanted to put it after the expensive/slow operation which makes the check necessary - obviously putting it at the loop begin essentially has the same effect, but that seemed clearer to me. Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services