<div>We are waiting for the fix :)</div><div> </div><div>-- <br />С уважением, Павел</div><div> </div><div> </div><div> </div><div>05.03.2021, 19:25, "David Steele" <david(at)pgmasters(dot)net>:</div><blockquote><p>On 10/28/20 10:01 AM, Amit Langote wrote:</p><blockquote> On Tue, Oct 27, 2020 at 10:55 PM Pavel Biryukov <<a href="mailto:79166341370(at)yandex(dot)ru" rel="noopener noreferrer">79166341370(at)yandex(dot)ru</a>> wrote:<blockquote> Hi!<br /><br /> What's the state with this issue?</blockquote> I think that the patch that Andres Freund posted earlier on this<br /> thread [1] would be fine as a workaround at least for stable releases<br /> v12 and v13. I have attached with this email a rebased version of<br /> that patch, although I also made a few changes. The idea of the patch<br /> is to allocate and use a partition-specific *non-virtual* slot, one<br /> that is capable of providing system columns when the RETURNING<br /> projection needs them. Andres' patch would allocate such a slot even<br /> if RETURNING contained no system columns, whereas I changed the slot<br /> creation code stanza to also check that RETURNING indeed contains<br /> system columns. I've attached 2 patch files: one for HEAD and another<br /> for v12 and v13 branches.<br /><br /> That said, the discussion on what to do going forward to *cleanly*<br /> support accessing system columns through partitioned tables is<br /> pending, but maybe the "workaround" fix will be enough in the meantime<br /> (at least v12 and v13 can only get a workaround fix).<br /> stgresql.org/message-id/20200811180629.zx57llliqcmcgfyr%40alap3.anarazel.de</blockquote><p><br />This thread has been quiet for while. Does everyone agree with Amit's<br />proposal to use this patch as a workaround?<br /><br />Also, is there a CF entry for this issue? If so I am unable to find it.<br /><br />Regards,<br /> </p>--<br />-David<br /><a href="mailto:david(at)pgmasters(dot)net" rel="noopener noreferrer">david(at)pgmasters(dot)net</a><br /> </blockquote>