Hi,
I updated the patch with the following changes:
- Remove the assertion from smgrtruncate() - it would need to assert that it's
called in a critical section.
Not sure why it's not already asserting that?
The function header says:
* ... This function should normally
* be called in
On Mon, Mar 17, 2025 at 07:52:02PM -0400, Andres Freund wrote:
> Here's a proposed patch for this. It turns out that the bug might already be
> reachable, even without defining FDDEBUG. There's a debug ereport() in
> register_dirty_segment() - but it's hard to reach in practice.
>
> I don't really
On Thu, Mar 20, 2025 at 03:53:11PM -0400, Andres Freund wrote:
> I updated the patch with the following changes:
>
> - Remove the assertion from smgrtruncate() - it would need to assert that it's
> called in a critical section.
>
> Not sure why it's not already asserting that?
>
> The func
On Thu, Mar 20, 2025 at 12:06 PM Andres Freund wrote:
> Ah - it effectively is already in a critical section, just a weirdly spelled
> one:
>
> 2025-03-19 19:00:06.398 EDT [2156613][client backend][0/3:0][psql] LOG:
> statement: DROP TABLE foo;
> 2025-03-19 19:00:06.404 EDT [2156613][client bac
Hi,
On 2025-03-20 13:16:44 -0700, Noah Misch wrote:
> Patch looks perfect.
Thanks for the reviews!
Pushed.
Greetings,
Andres Freund
On Wed, Mar 19, 2025 at 06:45:20PM -0400, Andres Freund wrote:
> On 2025-03-19 12:55:53 -0700, Noah Misch wrote:
> > On Mon, Mar 17, 2025 at 07:52:02PM -0400, Andres Freund wrote:
> > > @@ -362,12 +397,16 @@ smgrreleaseall(void)
> > > if (SMgrRelationHash == NULL)
> > > return;
> > >
Hi,
On 2025-03-19 18:45:20 -0400, Andres Freund wrote:
> On 2025-03-19 12:55:53 -0700, Noah Misch wrote:
> > On Mon, Mar 17, 2025 at 07:52:02PM -0400, Andres Freund wrote:
> > > @@ -471,6 +522,8 @@ smgrdounlinkall(SMgrRelation *rels, int nrels, bool
> > > isRedo)
> > > if (nrels == 0)
> > >
Hi,
On 2025-03-19 12:55:53 -0700, Noah Misch wrote:
> On Mon, Mar 17, 2025 at 07:52:02PM -0400, Andres Freund wrote:
> > Here's a proposed patch for this. It turns out that the bug might already be
> > reachable, even without defining FDDEBUG. There's a debug ereport() in
> > register_dirty_segmen
Hi,
On 2025-03-17 19:52:02 -0400, Andres Freund wrote:
> On 2025-03-14 12:57:51 +1300, Thomas Munro wrote:
> > On Fri, Mar 14, 2025 at 12:23 PM Andres Freund wrote:
> >
> > > > 3. Considering errfinish()'s stated goal, a sort of backstop to help
> > > > you cancel looping message-spewing code o
Hi,
On 2025-03-14 12:57:51 +1300, Thomas Munro wrote:
> On Fri, Mar 14, 2025 at 12:23 PM Andres Freund wrote:
>
> > > 3. Considering errfinish()'s stated goal, a sort of backstop to help
> > > you cancel looping message-spewing code only, I wonder if we should
> > > just restrict the kinds of i
On Fri, Mar 14, 2025 at 12:23 PM Andres Freund wrote:
> On 2025-03-14 11:31:47 +1300, Thomas Munro wrote:
> > 2. Somehow tell elog.c not to call CHECK_FOR_INTERRUPTS() instead.
> > Also yuck, but at least elog.c is already the right place to clean
> > state up on non-local exit...
>
> How would t
Hi,
On 2025-03-14 11:31:47 +1300, Thomas Munro wrote:
> 2. Somehow tell elog.c not to call CHECK_FOR_INTERRUPTS() instead.
> Also yuck, but at least elog.c is already the right place to clean
> state up on non-local exit...
How would that differ from HOLD_INTERRUPTS?
> 3. Considering errfinis
On Fri, Mar 14, 2025 at 5:03 AM Andres Freund wrote:
> If there is any LOG/DEBUG elog inside functions like mdreadv(), mdwritev(),
> mdextend(), be it directly or indirectly, the functions become unsafe. The
> problem is that at the end of errfinish() there is a CFI:
>
> /*
> * Ch
Hi,
If there is any LOG/DEBUG elog inside functions like mdreadv(), mdwritev(),
mdextend(), be it directly or indirectly, the functions become unsafe. The
problem is that at the end of errfinish() there is a CFI:
/*
* Check for cancel/die interrupt first --- this is so that the u
14 matches
Mail list logo
