Hi,
On November 26, 2021 5:53:31 PM PST, Andres Freund wrote:
>Hi,
>
>On November 26, 2021 7:24:15 AM PST, Robert Haas wrote:
>>Fortunately, it seems to have been only a minor oversight.
>
Agreed.
I wonder if we should turn some of these ifdefs into something boiling down to
if (0) { ifdef
On Thu, Nov 25, 2021 at 11:02 PM Tom Lane wrote:
> Robert Haas writes:
> > On Wed, Nov 24, 2021 at 8:01 PM Andres Freund wrote:
> >> Pushed the obvious fix for that. Somehow thought I'd seen more compile
> >> failure
> >> than the one WAL_DEBUG...
>
> > Hmm, thanks. I guess i put too much trust
Robert Haas writes:
> On Wed, Nov 24, 2021 at 8:01 PM Andres Freund wrote:
>> Pushed the obvious fix for that. Somehow thought I'd seen more compile
>> failure
>> than the one WAL_DEBUG...
> Hmm, thanks. I guess i put too much trust in the compiler.
My approach to such patches is always "in gr
On Wed, Nov 24, 2021 at 8:01 PM Andres Freund wrote:
> Pushed the obvious fix for that. Somehow thought I'd seen more compile failure
> than the one WAL_DEBUG...
Hmm, thanks. I guess i put too much trust in the compiler.
--
Robert Haas
EDB: http://www.enterprisedb.com
Hi,
On 2021-11-24 15:12:06 -0800, Andres Freund wrote:
> This fails when building with WAL_DEBUG. There's remaining Read/EndRecPtr
> references in #ifdef WAL_DEBUG sections...
Pushed the obvious fix for that. Somehow thought I'd seen more compile failure
than the one WAL_DEBUG...
Hi,
On 2021-11-24 16:27:58 +, Robert Haas wrote:
> xlog.c: Remove global variables ReadRecPtr and EndRecPtr.
This fails when building with WAL_DEBUG. There's remaining Read/EndRecPtr
references in #ifdef WAL_DEBUG sections...
Greetings,
Andres Freund
