On Tue, Sep 24, 2019 at 11:33:35AM +0900, Michael Paquier wrote:
> Thanks for the review. Attached is the patch set I am planning to
> commit. I'll wait after the tag of this week as the first patch needs
> to go down to 9.6, the origin of the bug being 47167b7. The second
> patch would go only
On Fri, Sep 20, 2019 at 12:40:51PM +0530, Kuntal Ghosh wrote:
> Okay. Sounds good.
Thanks for the review. Attached is the patch set I am planning to
commit. I'll wait after the tag of this week as the first patch needs
to go down to 9.6, the origin of the bug being 47167b7. The second
patch wou
On Fri, Sep 20, 2019 at 12:38 PM Michael Paquier wrote:
>
> > One small thing:
> >
> > add_int_reloption(bl_relopt_kind, buf,
> >"Number of bits generated for each index column",
> > - DEFAULT_BLOOM_BITS, 1, MAX_BLOOM_BITS);
> > + DEFAULT_BLOOM_BITS, 1, MAX_BLOOM_BITS,
> > + AccessExclusi
On Fri, Sep 20, 2019 at 11:59:13AM +0530, Kuntal Ghosh wrote:
> On Fri, Sep 20, 2019 at 7:08 AM Michael Paquier wrote:
>> Hence attached is a patch set to address those issues:
>> - 0001 makes sure that any existing module creating a custom reloption
>> has the lock mode set to AccessExclusiveMode
On Fri, Sep 20, 2019 at 7:08 AM Michael Paquier wrote:
>
> Hence attached is a patch set to address those issues:
> - 0001 makes sure that any existing module creating a custom reloption
> has the lock mode set to AccessExclusiveMode, which would be a sane
> default anyway. I think that we should
On Fri, Sep 20, 2019 at 10:38:31AM +0900, Michael Paquier wrote:
> Hi all,
>
> This is a new thread related to the bug analyzed here:
> https://www.postgresql.org/message-id/20190919083203.gc21...@paquier.xyz
>
> And in short, if you attempt to do an ALTER TABLE with a custom
> reloptions the com
