From: | Heikki Linnakangas <hlinnaka(at)iki(dot)fi> |
---|---|
To: | Thomas Munro <thomas(dot)munro(at)gmail(dot)com> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Yura Sokolov <y(dot)sokolov(at)postgrespro(dot)ru> |
Subject: | Re: SLRUs in the main buffer pool, redux |
Date: | 2022-07-25 08:54:36 |
Message-ID: | 7f09b521-36e3-4e09-2d50-7317490d5003@iki.fi |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 25/07/2022 09:54, Heikki Linnakangas wrote:
> In RecordTransactionCommit(), we enter a critical section, and then call
> TransactionIdCommitTree() to update the CLOG pages. That now involves a
> call to ReadBuffer_common(), which in turn calls
> ResourceOwnerEnlargeBuffers(). That can fail, because it might require
> allocating memory, which is forbidden in a critical section. I ran into
> an assertion about that with "make check" when I was playing around with
> a heavily modified version of this patch. Haven't seen it with your
> original one, but I believe that's just luck.
>
> Calling ResourceOwnerEnlargeBuffers() before entering the critical
> section would probably fix that, although I'm a bit worried about having
> the Enlarge call so far away from the point where it's needed.
Oh I just saw that you had a comment about that in the patch and had
hacked around it. Anyway, calling ResourceOwnerEnlargeBuffers() might be
a solution. Or switch to a separate "CriticalResourceOwner" that's
guaranteed to have enough pre-allocated space, before entering the
critical section.
- Heikki
From | Date | Subject | |
---|---|---|---|
Next Message | Amit Kapila | 2022-07-25 08:54:43 | Re: Handle infinite recursion in logical replication setup |
Previous Message | vignesh C | 2022-07-25 08:54:00 | Re: Handle infinite recursion in logical replication setup |