Hi,
> > Unfortunately the patchset rotted quite a bit since February and needs a
> > rebase.
>
> A consensus was reached to mark this patch as RwF for now. There
> are many patches to be reviewed and this one doesn't seem to be in the
> best shape, so we have to prioritise. Please feel free re-su
Hi,
> Unfortunately the patchset rotted quite a bit since February and needs a
> rebase.
A consensus was reached [1] to mark this patch as RwF for now. There
are many patches to be reviewed and this one doesn't seem to be in the
best shape, so we have to prioritise. Please feel free re-submittin
Hi,
> > Here's a rebased set of patches.
> >
> > The second patch is failing the pg_upgrade tests. Before I dig into
> > that, I'd love to get some feedback on this general approach.
>
> Forgot to include the new "slrulist.h" file in the previous patch, fixed
> here.
Unfortunately the patchset ro
On Mon, Jul 25, 2022 at 11:54:36AM +0300, Heikki Linnakangas wrote:
> 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
On Sat, Sep 17, 2022 at 12:41 PM Bagga, Rishu wrote:
> While I was working on adding the page headers to SLRU pages on your patch, I
> came across this code where it seems like "MultiXactIdToMemberPage" is
> mistakenly being used instead of MultiXactIdToOffsetPage in the TrimMultiXact
> functio
Hi Thomas,
While I was working on adding the page headers to SLRU pages on your patch, I
came across this code where it seems like "MultiXactIdToMemberPage" is
mistakenly being used instead of MultiXactIdToOffsetPage in the TrimMultiXact
function.
Below is the area of concern in the patch:
@@
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
Good day, Thomas
В Пт, 27/05/2022 в 23:24 +1200, Thomas Munro пишет:
> Rebased, debugged and fleshed out a tiny bit more, but still with
> plenty of TODO notes and questions. I will talk about this idea at
> PGCon, so I figured it'd help to have a patch that actually applies,
> even if it doesn't
On Thu, Jun 16, 2022 at 1:13 PM Konstantin Knizhnik wrote:
> I wonder which workload can cause CLOG to become a bottleneck?
> Usually Postgres uses hint bits to avoid clog access. So standard pgbench
> doesn't demonstrate any degrade of performance even in case of presence of
> long living trans
On 28.05.2022 04:13, Thomas Munro wrote:
On Fri, May 27, 2022 at 11:24 PM Thomas Munro wrote:
Rebased, debugged and fleshed out a tiny bit more, but still with
plenty of TODO notes and questions. I will talk about this idea at
PGCon, so I figured it'd help to have a patch that actually appli
Hi,
On 2022-05-28 13:13:20 +1200, Thomas Munro wrote:
> There was a little bit of discussion on #pgcon-stream2 which I could
> summarise as: can we figure out a way to keep parts of the CLOG pinned
> so that backends don't have to do that for each lookup? Then CLOG
> checks become simple reads.
On Fri, May 27, 2022 at 11:24 PM Thomas Munro wrote:
> Rebased, debugged and fleshed out a tiny bit more, but still with
> plenty of TODO notes and questions. I will talk about this idea at
> PGCon, so I figured it'd help to have a patch that actually applies,
> even if it doesn't work quite righ
On Mon, Jan 17, 2022 at 11:23 PM Heikki Linnakangas wrote:
> IIRC one issue with this has been performance. When an SLRU is working
> well, a cache hit in the SLRU is very cheap. Linearly scanning the SLRU
> array is cheap, compared to computing the hash and looking up a buffer
> in the buffer cac
On 13/01/2022 15:59, Thomas Munro wrote:
Hi,
I was re-reviewing the proposed batch of GUCs for controlling the SLRU
cache sizes[1], and I couldn't resist sketching out $SUBJECT as an
obvious alternative. This patch is highly experimental and full of
unresolved bits and pieces (see below for som
On Thu, Jan 13, 2022 at 9:00 AM Thomas Munro wrote:
> I was re-reviewing the proposed batch of GUCs for controlling the SLRU
> cache sizes[1], and I couldn't resist sketching out $SUBJECT as an
> obvious alternative. This patch is highly experimental and full of
> unresolved bits and pieces (see
Hi,
I was re-reviewing the proposed batch of GUCs for controlling the SLRU
cache sizes[1], and I couldn't resist sketching out $SUBJECT as an
obvious alternative. This patch is highly experimental and full of
unresolved bits and pieces (see below for some), but it passes basic
tests and is enough
16 matches
Mail list logo
