| From: | Anthonin Bonnefoy <anthonin(dot)bonnefoy(at)datadoghq(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Michael Paquier <michael(at)paquier(dot)xyz>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Memory context can be its own parent and child in replication command |
| Date: | 2025-03-12 09:13:06 |
| Message-ID: | CAO6_XqrQBspFLxyV22ALWU1hgeh5DjJUfoKhK8SDBOws0LBt+g@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
I've updated the patch with another approach:
0001: This sets the MemoryContext type to T_Invalid just before adding
it to the aset freelist, allowing to distinguish between a
MemoryContext that was placed in the freelist and shouldn't be used,
and a valid one. The existing MemoryContextIsValid checks will be
triggered if a MemoryContext in the freelist is used.
I've also added additional MemoryContextIsValid to make sure the
MemoryContext restored by a transaction is valid.
0002: Keep the replication command alive when there's an ongoing
snapshot export. This way, the context restored is valid and can be
reused. This requires the replication command context to be created
under the TopMemoryContext.
Regards,
Anthonin Bonnefoy
| Attachment | Content-Type | Size |
|---|---|---|
| v02-0001-Add-additional-memory-context-checks.patch | application/octet-stream | 3.2 KB |
| v02-0002-Avoid-using-deleted-context-with-replication-com.patch | application/octet-stream | 6.9 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Dean Rasheed | 2025-03-12 09:28:52 | Re: Wrong results with subquery pullup and grouping sets |
| Previous Message | vignesh C | 2025-03-12 08:58:39 | Re: DOCS - Generated Column Replication Examples |