On Fri, Dec 08, 2023 at 01:45:18PM +0900, Michael Paquier wrote:
> Looks acceptable to me. Does somebody object to this removal?
Hearing nothing, done that.
--
Michael
signature.asc
Description: PGP signature
On Thu, Dec 07, 2023 at 05:29:55PM +0530, Bharath Rupireddy wrote:
> The comment atop trace_recovery [1] function says it should go away
> eventually and seems to have served the purpose when the recovery
> related code was introduced in PG 9.0.
>
> FWIW, the attached patch is what I've left with
On Thu, Dec 07, 2023 at 04:50:30PM +0530, Bharath Rupireddy wrote:
> On Mon, Dec 4, 2023 at 12:37 AM Noah Misch wrote:
> > On Sun, Dec 03, 2023 at 08:30:24PM +0530, Bharath Rupireddy wrote:
> > > On Sun, Dec 3, 2023 at 4:00 AM Nathan Bossart
> > > wrote:
> > > > On Sat, Dec 02, 2023 at
On Thu, Dec 7, 2023 at 6:20 AM Bharath Rupireddy
wrote:
> I'm just curious to know what sorts of problems WAL_DEBUG code helps
> debug with. Is the WAL_DEBUG code (1) or (2) or (3) that helped you
> the most? Is converting the LOG messages (3) to DEBUGX level going to
> help in your case? Can you
On Thu, Dec 7, 2023 at 8:10 AM Michael Paquier wrote:
>
> On Wed, Dec 06, 2023 at 11:32:19PM -0300, Euler Taveira wrote:
> > IIUC trace_recovery_messages was a debugging aid in the 9.0 era when the HS
> > was
> > introduced. I'm also wondering if anyone used it in the past years.
>
> FWIW, I'd
On Mon, Dec 4, 2023 at 12:37 AM Noah Misch wrote:
>
> On Sun, Dec 03, 2023 at 08:30:24PM +0530, Bharath Rupireddy wrote:
> > On Sun, Dec 3, 2023 at 4:00 AM Nathan Bossart
> > wrote:
> > > On Sat, Dec 02, 2023 at 07:36:29PM +0530, Bharath Rupireddy wrote:
> > > > b) Remove both the WAL_DEBUG
On Wed, Dec 06, 2023 at 11:32:19PM -0300, Euler Taveira wrote:
> IIUC trace_recovery_messages was a debugging aid in the 9.0 era when the HS
> was
> introduced. I'm also wondering if anyone used it in the past years.
FWIW, I'd be +1 for getting rid of entirely, with its conditional
block in
On Wed, Dec 6, 2023, at 9:51 PM, Michael Paquier wrote:
> PerformWalRecovery() with its log for RM_XACT_ID is something that
> stresses me a bit though because this is in the main redo loop which
> is never free. The same can be said about GenericXLogFinish() because
> the extra computation
On Wed, Dec 06, 2023 at 09:46:09AM -0300, Euler Taveira wrote:
> On Wed, Dec 6, 2023, at 8:27 AM, Peter Eisentraut wrote:
>> This kind of thing could be mostly avoided if we didn't hide all the
>> WAL_DEBUG behind #ifdefs.
>
> AFAICS LOCK_DEBUG also hides its GUCs behind #ifdefs. The fact that
Peter Eisentraut writes:
> This kind of thing could be mostly avoided if we didn't hide all the
> WAL_DEBUG behind #ifdefs. For example, in the attached patch, I instead
> changed it so that
> if (XLOG_DEBUG)
> resolves to
> if (false)
> in the normal case. That way, we don't need
On Wed, Dec 6, 2023, at 8:27 AM, Peter Eisentraut wrote:
> On 02.12.23 15:06, Bharath Rupireddy wrote:
> > I enabled this code by compiling with the WAL_DEBUG macro and setting
> > wal_debug GUC to on. Firstly, the compilation on Windows failed
> > because XL_ROUTINE was passed inappropriately for
On 02.12.23 15:06, Bharath Rupireddy wrote:
I enabled this code by compiling with the WAL_DEBUG macro and setting
wal_debug GUC to on. Firstly, the compilation on Windows failed
because XL_ROUTINE was passed inappropriately for XLogReaderAllocate()
used.
This kind of thing could be mostly
On Mon, Dec 04, 2023 at 10:14:36AM +0900, Michael Paquier wrote:
> I can add the flag in one of my nix animals if we don't have any to
> provide minimal coverage, that's not an issue for me. I'd suggest to
> just fix the build on Windows, this flag is a low maintenance burden.
Hearing nothing
On Sun, Dec 03, 2023 at 11:07:05AM -0800, Noah Misch wrote:
> Can be, but the WAL_DEBUG model is mighty convenient:
> - Cooperates with backtrace_functions
> - Change log_line_prefix to correlate any log_line_prefix fact with WAL
> records
> - See WAL records interleaved with non-WAL log messages
On Sun, Dec 03, 2023 at 08:30:24PM +0530, Bharath Rupireddy wrote:
> On Sun, Dec 3, 2023 at 4:00 AM Nathan Bossart
> wrote:
> > On Sat, Dec 02, 2023 at 07:36:29PM +0530, Bharath Rupireddy wrote:
> > > b) Remove both the WAL_DEBUG macro and the wal_debug GUC. I don't
> > > think (2) is needed to
On Sun, Dec 3, 2023 at 4:00 AM Nathan Bossart wrote:
>
> On Sat, Dec 02, 2023 at 07:36:29PM +0530, Bharath Rupireddy wrote:
> > I started to think if this code is needed at all in production. How
> > about we do either of the following?
>
> Well, the fact that this code is hidden behind an
On Sun, Dec 3, 2023 at 4:16 AM Tom Lane wrote:
>
> Nathan Bossart writes:
> > On Sat, Dec 02, 2023 at 07:36:29PM +0530, Bharath Rupireddy wrote:
> >> I started to think if this code is needed at all in production. How
> >> about we do either of the following?
>
> > Well, the fact that this code
Nathan Bossart writes:
> On Sat, Dec 02, 2023 at 07:36:29PM +0530, Bharath Rupireddy wrote:
>> I started to think if this code is needed at all in production. How
>> about we do either of the following?
> Well, the fact that this code is hidden behind an off-by-default macro
> seems like a
On Sat, Dec 02, 2023 at 07:36:29PM +0530, Bharath Rupireddy wrote:
> I started to think if this code is needed at all in production. How
> about we do either of the following?
Well, the fact that this code is hidden behind an off-by-default macro
seems like a pretty strong indicator that it is
Hi,
I was recently looking at the code around the WAL_DEBUG macro and GUC.
When enabled, the code does the following:
1. Creates a memory context that allows pallocs within critical sections.
2. Decodes (not logical decoding but DecodeXLogRecord()) every WAL
record using the above memory context
20 matches
Mail list logo
