On Tue, Sep 21, 2021 at 2:07 AM Tom Lane wrote:
> Alexander Korotkov writes:
> > On Mon, Sep 20, 2021 at 10:48 PM Andres Freund wrote:
> >> I assume you're planning to backpatch this?
>
> > Yes.
>
> Probably good to wait 24 hours until 14rc1 has been tagged.
OK, NP!
--
Regards,
Alexander K
Alexander Korotkov writes:
> On Mon, Sep 20, 2021 at 10:48 PM Andres Freund wrote:
>> I assume you're planning to backpatch this?
> Yes.
Probably good to wait 24 hours until 14rc1 has been tagged.
regards, tom lane
On Mon, Sep 20, 2021 at 10:48 PM Andres Freund wrote:
> On 2021-09-19 18:45:45 +0300, Alexander Korotkov wrote:
> > Any objections to pushing this?
>
> lgtm
Thanks!
> I assume you're planning to backpatch this?
Yes.
--
Regards,
Alexander Korotkov
On 2021-09-19 18:45:45 +0300, Alexander Korotkov wrote:
> Any objections to pushing this?
lgtm
I assume you're planning to backpatch this?
On Sat, Sep 18, 2021 at 11:35 PM Alvaro Herrera wrote:
> On 2021-Sep-18, Alexander Korotkov wrote:
>
> > I see now. I think I'm rather favoring splitting visibilitymap.h.
>
> Agreed, this looks sane to me. However, I think the
> VM_ALL_{VISIBLE,FROZEN} macros should remain in visibilitymap.h, si
On 2021-Sep-18, Alexander Korotkov wrote:
> I see now. I think I'm rather favoring splitting visibilitymap.h.
Agreed, this looks sane to me. However, I think the
VM_ALL_{VISIBLE,FROZEN} macros should remain in visibilitymap.h, since
they depend on the visibilitymap_get_status function (and pg_u
Hi,
On Sat, Sep 18, 2021 at 3:06 AM Andres Freund wrote:
> On 2021-09-18 02:51:09 +0300, Alexander Korotkov wrote:
> > On Tue, Sep 14, 2021 at 6:53 AM Tom Lane wrote:
> > > Without having looked at the details, I think using a forward-declare
> > > to avoid including relcache.h in visibilitymap.
Hi,
On 2021-09-18 02:51:09 +0300, Alexander Korotkov wrote:
> On Tue, Sep 14, 2021 at 6:53 AM Tom Lane wrote:
> > Without having looked at the details, I think using a forward-declare
> > to avoid including relcache.h in visibilitymap.h might be a reasonably
> > non-painful fix.
>
> I like that
On Tue, Sep 14, 2021 at 6:53 AM Tom Lane wrote:
> Andres Freund writes:
> > On 2021-09-13 22:40:19 -0400, Tom Lane wrote:
> >> As for the fix ... what in the world is pg_upgrade doing including
> >> relcache.h? It seems like there's a more fundamental problem here:
> >> either relcache.h is decl
On Tue, Sep 14, 2021 at 5:40 AM Tom Lane wrote:
> Andres Freund writes:
> > I noticed that postgres.h is included from relcache.h (starting in [1]) and
> > wanted to fix that - it violates our usual policy against including
> > postgres.h
> > from within headers.
>
> Ugh, yeah, that's entirely a
Andres Freund writes:
> On 2021-09-13 22:40:19 -0400, Tom Lane wrote:
>> As for the fix ... what in the world is pg_upgrade doing including
>> relcache.h? It seems like there's a more fundamental problem here:
>> either relcache.h is declaring something that needs to be elsewhere,
>> or pg_upgrad
Hi,
On 2021-09-13 22:40:19 -0400, Tom Lane wrote:
> Andres Freund writes:
> > I noticed that postgres.h is included from relcache.h (starting in [1]) and
> > wanted to fix that - it violates our usual policy against including
> > postgres.h
> > from within headers.
>
> Ugh, yeah, that's entirel
Andres Freund writes:
> I noticed that postgres.h is included from relcache.h (starting in [1]) and
> wanted to fix that - it violates our usual policy against including postgres.h
> from within headers.
Ugh, yeah, that's entirely against policy.
As for the fix ... what in the world is pg_upgrad
13 matches
Mail list logo
