On 26 December 2017 at 14:21, Nikhil Sontakke <nikh...@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
