On Wed, Jul 31, 2024 at 04:49:54PM +0300, Alexander Korotkov wrote:
> On Mon, Jul 29, 2024 at 7:20 PM Robert Haas wrote:
>> I support that idea in general but felt it was overkill in this case:
>> it's new code, and there was only one existing caller of the function
>> that got refactored, and I'm
On Mon, Jul 29, 2024 at 7:20 PM Robert Haas wrote:
> On Fri, Jul 26, 2024 at 4:10 PM Alexander Korotkov
> wrote:
> > 0002 could also use pg_indent and pgperltidy. And I have couple other
> > notes regarding 0002.
>
> As Tom said elsewhere, we don't have a practice of requiring perltidy
> for ev
On Fri, Jul 26, 2024 at 4:10 PM Alexander Korotkov wrote:
> 0002 could also use pg_indent and pgperltidy. And I have couple other
> notes regarding 0002.
As Tom said elsewhere, we don't have a practice of requiring perltidy
for every commit, and I normally don't bother. The tree is
pgindent-clea
On Fri, Jul 26, 2024 at 7:02 PM Robert Haas wrote:
> On Fri, Jul 26, 2024 at 11:51 AM Nathan Bossart
> wrote:
> > nitpick: I think this one needs a pgindent.
>
> Ugh, sorry. I thought of that while I was working on the commit but
> then I messed up some other aspect of it and this went out of my
On Fri, Jul 26, 2024 at 11:51 AM Nathan Bossart
wrote:
> nitpick: I think this one needs a pgindent.
Ugh, sorry. I thought of that while I was working on the commit but
then I messed up some other aspect of it and this went out of my head.
Fixed now, I hope.
--
Robert Haas
EDB: http://www.ent
On Fri, Jul 26, 2024 at 10:09:22AM -0400, Robert Haas wrote:
> On Mon, Jul 22, 2024 at 11:02 AM Robert Haas wrote:
>> I'm still hoping for some review/feedback/testing of these before I
>> commit them, but I also don't want to wait too long.
>
> Hearing nothing, pushed 0001.
nitpick: I think th
On Mon, Jul 22, 2024 at 11:02 AM Robert Haas wrote:
> I'm still hoping for some review/feedback/testing of these before I
> commit them, but I also don't want to wait too long.
Hearing nothing, pushed 0001.
--
Robert Haas
EDB: http://www.enterprisedb.com
I went ahead and committed 0001, which is pretty trivial. Hopefully,
at least, it's trivial enough that I didn't mess it up.
Here's a rebase of 0002 and 0003, now 0001 and 0002, with one minor
fix to hopefully avoid annoying CI.
I'm still hoping for some review/feedback/testing of these before I
On Wed, Jul 10, 2024 at 5:01 PM Robert Haas wrote:
> Here is a draft patch that attempts to fix this problem. I'm not
> certain that it's completely correct, but it does seem to fix the
> reported issue.
I tried to write a test case for this and discovered that there are
actually two separate pro
On Wed, Jul 3, 2024 at 1:07 PM Robert Haas wrote:
> I think the problem here is that the WAL summarizer believes that when
> a new timeline appears, it should pick up from where the old timeline
> ended. And here, that doesn't happen: the new timeline branches off
> before the end of the old timel
On Mon, Jul 1, 2024 at 2:08 AM Michael Paquier wrote:
> Nope. So, Open Item, here we go.
Some initial investigation:
In this test case, pg_subscriber, during the "starting the subscriber"
section of its work, starts up the database in the "sub" directory as
a standby. It enters standby mode, beg
On Mon, Jul 01, 2024 at 02:54:56PM +0900, Fujii Masao wrote:
> In HEAD, I encountered the following assertion failure when I enabled
> summarize_wal
> and ran pg_createsubscriber.
>
> Is this the known issue?
Nope. So, Open Item, here we go.
--
Michael
signature.asc
Description: PGP signature
Hi,
In HEAD, I encountered the following assertion failure when I enabled
summarize_wal
and ran pg_createsubscriber.
2024-07-01 14:42:15.697 JST [19195] LOG: database system is ready to accept
connections
TRAP: failed Assert("switchpoint >= state->EndRecPtr"), File:
"walsummarizer.c", Line:
13 matches
Mail list logo
