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
xlog.c: Remove global variables ReadRecPtr and EndRecPtr.
In most places, the variables necessarily store the same value as the
eponymous members of the XLogReaderState that we use during WAL
replay, because ReadRecord() assigns the values from the structure
members to the global variables just af
