> Yeah, this is a bug. It seems that the WAL summarizer process, when
> restarted, wants to restart from wherever it was previously
> summarizing WAL, which is correct if that WAL is still around, but if
> summarize_wal has been turned off in the meanwhile, it might not be
> correct. Here's a patch
On Tue, Jun 25, 2024 at 3:51 PM Tom Lane wrote:
> This comment seems to be truncated:
Thanks. New version attached.
--
Robert Haas
EDB: http://www.enterprisedb.com
v2-0001-Prevent-summarizer-hang-when-summarize_wal-turned.patch
Description: Binary data
Robert Haas writes:
> Yeah, this is a bug. It seems that the WAL summarizer process, when
> restarted, wants to restart from wherever it was previously
> summarizing WAL, which is correct if that WAL is still around, but if
> summarize_wal has been turned off in the meanwhile, it might not be
> co
On Mon, Jun 24, 2024 at 1:56 PM Israel Barth Rubio
wrote:
> I've been playing a bit with the incremental backup feature which might come
> as
> part of the 17 release, and I think I hit a possible bug in the WAL summarizer
> process.
>
> The issue that I face refers to the summarizer process gett
On Mon, Jun 24, 2024 at 02:56:00PM -0300, Israel Barth Rubio wrote:
> I've been playing a bit with the incremental backup feature which might
> come as
> part of the 17 release, and I think I hit a possible bug in the WAL
> summarizer
> process.
Thanks for testing new features and for this report!
I'm attaching the files which I missed in the original email.
>
19:34:17.437626 epoll_wait(5, [], 1, 8161) = 0 <8.171542>
19:34:25.610176 rt_sigprocmask(SIG_SETMASK, [URG], NULL, 8) = 0 <0.000334>
19:34:25.611012 openat(AT_FDCWD, "pg_wal/0001000200B3", O_RDONLY) =
-1 ENOENT (No such f
