Re: Xact end leaves CurrentMemoryContext = TopMemoryContext

Hi, This change seems to have introduced an issue where a deleted context can be restored. This happens when a replication command exports a snapshot since the transaction used is aborted at the start of the next command. This leads to a memory context allocated with itself as a parent and child,

Re: Memory context can be its own parent and child in replication command

The issue seems to have been introduced by 2129d184a206c when transactionState->priorContext was added and is only present in HEAD.

Re: Memory context can be its own parent and child in replication command

On Tue, Mar 11, 2025 at 1:09 AM Michael Paquier wrote: > It seems to me that you mean 1afe31f03cd2, no? Yes, that was a bad copy/paste from me. On Tue, Mar 11, 2025 at 2:13 AM Tom Lane wrote: > > I dunno about this patch: it seems to me it's doing things exactly > backwards, namely trying to re

Re: Memory context can be its own parent and child in replication command

On Tue, Mar 11, 2025 at 10:26 AM Anthonin Bonnefoy wrote: > --- a/src/backend/utils/mmgr/mcxt.c > +++ b/src/backend/utils/mmgr/mcxt.c > @@ -527,6 +527,7 @@ MemoryContextDeleteOnly(MemoryContext context) > > context->methods->delete_context(context); > > +

Re: Memory context can be its own parent and child in replication command

context restored is valid and can be reused. This requires the replication command context to be created under the TopMemoryContext. Regards, Anthonin Bonnefoy v02-0001-Add-additional-memory-context-checks.patch Description: Binary data v02-0002-Avoid-using-deleted-context-with-replication-c

Re: Add Pipelining support in psql

On Thu, Feb 20, 2025 at 9:02 AM Michael Paquier wrote: > You have forgotten the expected output. Not a big issue as the input > was sent. I was writing the mail with the missing file when you sent this mail. This is fixed. > While testing, I have been able to run into an assertion failure by >

Re: Add Pipelining support in psql

On Tue, Feb 25, 2025 at 2:11 AM Michael Paquier wrote: > For the prompt part, I have added a > couple of tests with \echo and the variables. The patch felt > incomplete without these. Perhaps we could extend them more, at least > we have a start point. Good catch. I guess that's also another be

Re: Regression in statement locations

On Tue, May 20, 2025 at 5:59 AM Michael Paquier wrote: > Once I have fixed that, I've been a bit puzzled by the difference in > output in the tests of pg_overexplain, but I think that the new output > is actually the correct one: the queries whose plan outputs have > changed are passed as argument

Re: [PATCH] Add additional extended protocol commands to psql: \parse and \bindx

On Tue, Jun 17, 2025 at 4:05 PM Jelte Fennema-Nio wrote: > > Agreed. My vote is for \closeprepared as that aligns with the libpq function. Since \bind_named is also new, we can also rename it to make it consistent with close meta-command. So what about renaming \bind_named to \bindprepared and \c

Improve doc on parallel stream changes for Stream Abort message

Hi, While adding parsing of logical replication to Wireshark[1], I've found the Stream Abort description possibly misleading. Stream Abort will have the Abort LSN and TS when parallel streaming is enabled. However, the documentation only mentions "This field is available since protocol version 4"

Re: [PATCH] Add additional extended protocol commands to psql: \parse and \bindx

On Thu, Jun 19, 2025 at 9:09 AM Michael Paquier wrote: > Good point. I would be on board with a \close_prepared then, if > that's the consensus we reach, without touching at \bind_named. We > still have time to decide on the name until the release, just let's > make sure to not do a rename multi

Re: Improve doc on parallel stream changes for Stream Abort message

On Tue, Jun 24, 2025 at 7:26 AM Amit Kapila wrote: > How about a slightly modified version like: (a) The LSN of the abort > operation, present only when the change stream can be applied in > parallel. This field is available since protocol version 4. (b) Abort > timestamp of the transaction, prese

Re: Don't keep closed WAL segment in page cache after replay

fter a disconnect), the WAL files will need to be read from disk instead of being already in the page cache. Though I think that's a better default behaviour as I would expect that most replicas don't have cascading replication and removing closed WAL segments would benefit most repl

Don't keep closed WAL segment in page cache after replay

Hi, I've been looking at page cache usage as some of our replicas were under memory pressure (no inactive pages available) which led to WAL replay lag as the recovery process had to read from disk. One thing I've noticed was that the last WAL files are in the pagecache even after having been repla

Document AccessExclusive lock behaviour on standbys

The provided patch adds more details on this in the table-level locks documentation, making it explicit that the tables will be locked on standbys and for how long. Regards, Anthonin Bonnefoy v01-0001-Document-AccessExclusive-lock-behaviour-on-stand.patch Description: Binary data

<    1   2