On 26 December 2017 at 14:21, Nikhil Sontakke <nikhils@2ndquadrant.com> wrote:
> With logical decoding, there might arise a case that such a row, if it
> belongs to a system catalog table or even a user catalog table
> (https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=66abc2608c7c00fcd449e00a9e23f13f02e65d04),
> then it might be being used for decoding at the very same moment that
> the abort came in. If the row is re-claimed immediately, then it's
> possible that the decoding happening alongside might face issues.
If we want to make this change, I'd like to see something that
explains exactly how the problem in logical decoding occurs, or
preferably a test case. I can't understand the problem by reading the
archives. I'm not suggesting this patch doesn't work, I'm thinking
about whether there are other ways.
Surely if you are decoding a transaction and a concurrent abort is
requested then decoding should be interrupted at the next sensible
point. Allowing the two actions to occur without interlock is an
issue, so I suggest we just don't do it, rather than allow it and fix
subsequent breakage, which is what I understand this patch to do.
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
