On 23/01/18 18:19, Marco Nenciarini wrote: > Il 23/01/18 18:13, Petr Jelinek ha scritto: >> Hi, >> >> On 23/01/18 15:38, Marco Nenciarini wrote: >>> Il 22/01/18 23:18, Petr Jelinek ha scritto: >>>> On 22/01/18 19:45, Petr Jelinek wrote: >>>> >>>> Actually on second look, I don't like the new boolean parameter much. >>>> I'd rather we didn't touch the input list and always close only >>>> relations opened inside the ExecuteTruncateGuts(). >>>> >>>> It may mean more list(s) but the current interface is still not clean. >>>> >>> >>> Now ExecuteTruncateGuts unconditionally closes the relations that it >>> opens. The caller has now always the responsibility to close the >>> relations passed with the explicit_rels list. >> >> This looks good. >> >>> >>> Version 15 attached. >>> >> >> I see you still do CASCADE on the subscriber though. >> > > No it doesn't. The following code in worker.c prevents that. > > > + /* > + * Even if we used CASCADE on the upstream master we explicitly > + * default to replaying changes without further cascading. > + * This might be later changeable with a user specified option. > + */ > + cascade = false;
Ah, that's pretty ugly, why don't we just use DROP_RESTRICT always instead of this (keeping the comment). Unless you plan to make it option as part of this patch, the current coding is confusing. -- Petr Jelinek http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services