On Tue, Oct 29, 2024 at 1:45 PM Thom Brown wrote:
> Taking a look at what's happening under the hood, it seems to be
> getting stuck here:
>
> if (nextMXOffset == 0)
> {
> /* Corner case 2: next multixact is still
> being filled in */
>
> On 1 Nov 2024, at 00:25, Thom Brown wrote:
>
> Unfortunately I didn't gather much information when it was occuring, and
> prioritised getting rid of the process blocking replay. I just attached gdb
> to it, got a backtrace and then "print ProcessInterrupts()".
>
Currently I do not see ho
On Thu, 31 Oct 2024, 17:33 Andrey M. Borodin, wrote:
>
>
> > On 31 Oct 2024, at 17:29, Thom Brown wrote:
> >
> > On Thu, 31 Oct 2024 at 10:47, Andrey M. Borodin
> wrote:
> >>
> >>
> >>
> >>> On 29 Oct 2024, at 21:45, Thom Brown wrote:
> >>>
> >>> It clearly checks for interrupts, but when I sa
On Thu, 31 Oct 2024 at 10:47, Andrey M. Borodin wrote:
>
>
>
> > On 29 Oct 2024, at 21:45, Thom Brown wrote:
> >
> > It clearly checks for interrupts, but when I saw this issue happen, it
> > wasn't interruptible.
>
> Perhaps, that was different multixacts?
> When I was observing this pathology o
> On 31 Oct 2024, at 17:29, Thom Brown wrote:
>
> On Thu, 31 Oct 2024 at 10:47, Andrey M. Borodin wrote:
>>
>>
>>
>>> On 29 Oct 2024, at 21:45, Thom Brown wrote:
>>>
>>> It clearly checks for interrupts, but when I saw this issue happen, it
>>> wasn't interruptible.
>>
>> Perhaps, that
> On 29 Oct 2024, at 21:45, Thom Brown wrote:
>
> It clearly checks for interrupts, but when I saw this issue happen, it
> wasn't interruptible.
Perhaps, that was different multixacts?
When I was observing this pathology on Standby, it was a stream of different
reads encountering different m
On Tue, 29 Oct 2024 at 16:38, Thom Brown wrote:
>
> On Fri, 23 Aug 2024 at 01:29, Michael Paquier wrote:
>>
>> On Thu, Aug 22, 2024 at 10:36:38AM -0400, Alvaro Herrera wrote:
>> > On 2024-Aug-22, Michael Paquier wrote:
>> >> I'm not sure that we need to get down to that until somebody has a
>> >>
On Fri, 23 Aug 2024 at 01:29, Michael Paquier wrote:
> On Thu, Aug 22, 2024 at 10:36:38AM -0400, Alvaro Herrera wrote:
> > On 2024-Aug-22, Michael Paquier wrote:
> >> I'm not sure that we need to get down to that until somebody has a
> >> case where they want to rely on stats of injection points
On Thu, Aug 22, 2024 at 10:36:38AM -0400, Alvaro Herrera wrote:
> On 2024-Aug-22, Michael Paquier wrote:
>> I'm not sure that we need to get down to that until somebody has a
>> case where they want to rely on stats of injection points for their
>> stuff. At this stage, I only want the stats to be
On 2024-Aug-22, Michael Paquier wrote:
> On Wed, Aug 21, 2024 at 01:55:06PM -0400, Alvaro Herrera wrote:
> > Also, maybe it'd make sense for stats to be globally enabled, and that
> > only the tests that require it would disable them? (It's probably easy
> > enough to have a value "injection_poi
On Wed, Aug 21, 2024 at 01:55:06PM -0400, Alvaro Herrera wrote:
> I find it's strange that the information that stats cannot be used with
> injection points that have dependency on critical sections (?), is only
> in the commit message and not in the code.
A comment close to where inj_stats_enable
On 2024-Aug-21, Michael Paquier wrote:
> From fd8ab7b6845a2c56aa2c8d9c60f404f6b3407338 Mon Sep 17 00:00:00 2001
> From: Michael Paquier
> Date: Wed, 21 Aug 2024 15:16:06 +0900
> Subject: [PATCH 2/3] injection_point: Add injection_points.stats
> This GUC controls if statistics should be used or n
On Wed, Aug 21, 2024 at 12:46:31PM +0900, Michael Paquier wrote:
> Sorry, I should have split that for clarity (one patch for the GUC,
> one to change the test to use CACHED/LOAD). It is not an error
> though: if we don't have a controlled way to disable the stats of the
> module, then the test wo
On Tue, Aug 20, 2024 at 08:13:12PM -0400, Alvaro Herrera wrote:
> I don't understand what do the inj_stats_enabled stuff have to do with
> this patch. I suspect it's a git operation error, ie., you seem to have
> squashed two different things together.
Sorry, I should have split that for clarity
On 2024-Aug-21, Michael Paquier wrote:
> I see that you've gone the way with the SQL function doing a load().
> Would it be worth switching the test to rely on the two macros for
> load and caching instead? I've mentioned that previously but never
> got down to present a patch for the sake of thi
On Tue, Aug 20, 2024 at 02:37:34PM -0400, Alvaro Herrera wrote:
> OK, I've made some minor adjustments and pushed. CI seemed OK for me,
> let's see what does the BF have to say.
I see that you've gone the way with the SQL function doing a load().
Would it be worth switching the test to rely on th
On 2024-Aug-19, Andrey M. Borodin wrote:
> > On 5 Jul 2024, at 23:18, Andrey M. Borodin wrote:
> >
> > Alvaro, please find attached the test.
> > I’ve addressed some Michael’s comments in a nearby thread: removed
> > extra load, made injection point names lowercase, fixed some grammar
> > issues
> On 5 Jul 2024, at 23:18, Andrey M. Borodin wrote:
>
> Alvaro, please find attached the test.
> I’ve addressed some Michael’s comments in a nearby thread: removed extra
> load, made injection point names lowercase, fixed some grammar issues.
I’ve made several runs on Github to test stabilit
> On 5 Jul 2024, at 14:16, Michael Paquier wrote:
>
> On Mon, Jun 10, 2024 at 03:10:33PM +0900, Michael Paquier wrote:
>> OK, cool. I'll try to get that into the tree once v18 opens up.
>
> And I've spent more time on this one, and applied it to v18 after some
> slight tweaks. Please feel fr
> On 7 Apr 2024, at 21:41, Alvaro Herrera wrote:
>
> Well, it would be nice to have *some* test, but as you say it is way
> more complex than the thing being tested, and it zooms in on the
> functioning of the multixact creation in insane quantum-physics ways ...
> to the point that you can no
On 2024-Feb-03, Andrey M. Borodin wrote:
> Here's the test draft. This test reliably reproduces sleep on CV when waiting
> next multixact to be filled into "members" SLRU.
> Cost of having this test:
> 1. We need a new injection point type "wait" (in addition to "error" and
> "notice"). It canno
> On 6 Apr 2024, at 14:24, Andrey M. Borodin wrote:
>
> What do you think?
OK, I'll follow this plan.
As long as most parts of this thread were committed, I'll mark CF item as
"committed".
Thanks to everyone involved!
See you in a followup thread about sleeping on CV.
Best regards, Andrey
> On 29 Feb 2024, at 06:59, Kyotaro Horiguchi wrote:
>
> At Sat, 3 Feb 2024 22:32:45 +0500, "Andrey M. Borodin"
> wrote in
>> Here's the test draft. This test reliably reproduces sleep on CV when
>> waiting next multixact to be filled into "members" SLRU.
>
> By the way, I raised a questi
At Sat, 3 Feb 2024 22:32:45 +0500, "Andrey M. Borodin"
wrote in
> Here's the test draft. This test reliably reproduces sleep on CV when waiting
> next multixact to be filled into "members" SLRU.
By the way, I raised a question about using multiple CVs
simultaneously [1]. That is, I suspect tha
> On 28 Jan 2024, at 23:17, Andrey M. Borodin wrote:
>
>
>> Perhaps a test to make the code reach the usleep(1000) can be written
>> using injection points (49cd2b93d7db)?
>
> I've tried to prototype something like that. But interesting point between
> GetNewMultiXactId() and RecordNewMultiX
> On 28 Jan 2024, at 17:49, Alvaro Herrera wrote:
>
> I'd appreciate it if you or Horiguchi-san can update his patch to remove
> use of usleep in favor of a CV in multixact, and keep this CF entry to
> cover it.
Sure! Sounds great!
> Perhaps a test to make the code reach the usleep(1000) can
On 2024-Jan-27, Andrey Borodin wrote:
> thanks for the ping! Most important parts of this patch set are discussed in
> [0]. If that patchset will be committed, I'll withdraw entry for this thread
> from commitfest.
> There's a version of Multixact-specific optimizations [1], but I hope they
> w
> On 20 Jan 2024, at 08:31, vignesh C wrote:
>
> On Mon, 9 Jan 2023 at 09:49, Andrey Borodin wrote:
>>
>> On Tue, Jan 3, 2023 at 5:02 AM vignesh C wrote:
>>> does not apply on top of HEAD as in [1], please post a rebased patch:
>>>
>> Thanks! Here's the rebase.
>
> I'm seeing that there h
On Mon, 9 Jan 2023 at 09:49, Andrey Borodin wrote:
>
> On Tue, Jan 3, 2023 at 5:02 AM vignesh C wrote:
> > does not apply on top of HEAD as in [1], please post a rebased patch:
> >
> Thanks! Here's the rebase.
I'm seeing that there has been no activity in this thread for more
than 1 year now, I'
Hi Dilip! Thank you for the review!
On Tue, Jan 10, 2023 at 9:58 PM Dilip Kumar wrote:
>
> On Mon, Jan 9, 2023 at 9:49 AM Andrey Borodin wrote:
> >
> > On Tue, Jan 3, 2023 at 5:02 AM vignesh C wrote:
> > > does not apply on top of HEAD as in [1], please post a rebased patch:
> > >
> > Thanks! H
On Mon, Jan 9, 2023 at 9:49 AM Andrey Borodin wrote:
>
> On Tue, Jan 3, 2023 at 5:02 AM vignesh C wrote:
> > does not apply on top of HEAD as in [1], please post a rebased patch:
> >
> Thanks! Here's the rebase.
I was looking into this patch, it seems like three different
optimizations are squee
On Tue, Jan 3, 2023 at 5:02 AM vignesh C wrote:
> does not apply on top of HEAD as in [1], please post a rebased patch:
>
Thanks! Here's the rebase.
Best regards, Andrey Borodin.
v24-0001-Divide-SLRU-buffers-into-8-associative-banks.patch
Description: Binary data
On Fri, 19 Aug 2022 at 21:18, wrote:
>
> Andrey Borodin wrote 2022-08-18 06:35:
> >
> > I like the idea of one knob instead of one per each SLRU. Maybe we
> > even could deduce sane value from NBuffers? That would effectively
> > lead to 0 knobs :)
> >
> > Your patch have a prefix "v22-0006", does
On Sat, Jul 23, 2022 at 1:48 AM Thomas Munro wrote:
>
> On Sat, Jul 23, 2022 at 8:41 PM Andrey Borodin wrote:
> > Thomas, do you still have any doubts? Or is it certain that SLRU will be
> > replaced by any better subsystem in 16?
>
> Hi Andrey,
>
> Sorry for my lack of replies on this and the o
Andrey Borodin wrote 2022-08-18 06:35:
I like the idea of one knob instead of one per each SLRU. Maybe we
even could deduce sane value from NBuffers? That would effectively
lead to 0 knobs :)
Your patch have a prefix "v22-0006", does it mean there are 5 previous
steps of the patchset?
Thank yo
> On 17 Aug 2022, at 00:36, i.laza...@postgrespro.ru wrote:
>
>> Andrey Borodin wrote 2022-07-23 11:39:
>> Yura, thank you for your benchmarks!
>> We already knew that patch can save the day on pathological workloads,
>> now we have a proof of this.
>> Also there's the evidence that user can bl
Andrey Borodin wrote 2022-07-23 11:39:
Yura, thank you for your benchmarks!
We already knew that patch can save the day on pathological workloads,
now we have a proof of this.
Also there's the evidence that user can blindly increase size of SLRU
if they want (with the second patch). So there's no
On Sat, Jul 23, 2022 at 8:41 PM Andrey Borodin wrote:
> Thomas, do you still have any doubts? Or is it certain that SLRU will be
> replaced by any better subsystem in 16?
Hi Andrey,
Sorry for my lack of replies on this and the other SLRU thread -- I'm
thinking and experimenting. More soon.
> On 21 Jul 2022, at 18:00, Yura Sokolov wrote:
>
> In this case simple buffer increase does help. But "buckets"
> increase performance gain.
Yura, thank you for your benchmarks!
We already knew that patch can save the day on pathological workloads, now we
have a proof of this.
Also there's t
Good day, all.
I did benchmark of patch on 2 socket Xeon 5220 CPU @ 2.20GHz .
I used "benchmark" used to reproduce problems with SLRU on our
customers setup.
In opposite to Shawn's tests I concentrated on bad case: a lot
of contention.
slru-funcs.sql - function definitions
- functions creates a
> On 20 Feb 2022, at 02:38, Thomas Munro wrote:
>
> Back to this patch: assuming we can settle on a good-enough-for-now
> replacement algorithm, do we want to add this set of 7 GUCs? Does
> anyone else want to weigh in on that?
Hi Thomas!
It seems we don't have any other input besides revie
> On 20 Feb 2022, at 02:42, Andres Freund wrote:
>
> On 2022-02-20 10:38:53 +1300, Thomas Munro wrote:
>> Back to this patch: assuming we can settle on a good-enough-for-now
>> replacement algorithm, do we want to add this set of 7 GUCs? Does
>> anyone else want to weigh in on that?
>
> I'm
On 2022-02-20 10:38:53 +1300, Thomas Munro wrote:
> Back to this patch: assuming we can settle on a good-enough-for-now
> replacement algorithm, do we want to add this set of 7 GUCs? Does
> anyone else want to weigh in on that?
I'm -0.2 on it, given that we have a better path forward.
On Sat, Feb 19, 2022 at 6:34 PM Andrey Borodin wrote:
> There's feature freeze approaching again. I see that you are working on
> moving SLRUs to buffer pools, but it is not clear to which PG version it will
> land. And there is 100% consensus that first patch is useful and helps to
> prevent b
> 8 апр. 2021 г., в 17:22, Thomas Munro написал(а):
>
> Thanks! I chickened out of committing a buffer replacement algorithm
> patch written 11 hours before the feature freeze, but I also didn't
> really want to commit the GUC patch without that. Ahh, if only we'd
> latched onto the real pro
> 21 янв. 2022 г., в 05:19, Shawn Debnath написал(а):
>
> On Thu, Jan 20, 2022 at 09:21:24PM +0500, Andrey Borodin wrote:
>> CAUTION: This email originated from outside of the organization. Do not
>> click links or open attachments unless you can confirm the sender and know
>> the content is
> 20 янв. 2022 г., в 20:44, Shawn Debnath написал(а):
>
> If my test workload can be made better, please let me know. Happy to
> re-run tests as needed.
Shawn, thanks for the benchmarking!
Can you please also test 2nd patch against a large multixact SLRUs?
2nd patch is not intended to do ma
> 15 янв. 2022 г., в 20:46, Justin Pryzby написал(а):
>>>
>>> I was planning on running a set of stress tests on these patches. Could
>>> we confirm which ones we plan to include in the commitfest?
>>
>> Many thanks for your interest. Here's the latest version.
>
> This is failing to compile
On Sat, Jan 15, 2022 at 12:16:59PM +0500, Andrey Borodin wrote:
> > 15 янв. 2022 г., в 03:20, Shawn Debnath написал(а):
> > On Fri, Jan 14, 2022 at 05:28:38PM +0800, Julien Rouhaud wrote:
> >>> PFA rebase of the patchset. Also I've added a patch to combine
> >>> page_number, page_status, and page
> 15 янв. 2022 г., в 03:20, Shawn Debnath написал(а):
>
> On Fri, Jan 14, 2022 at 05:28:38PM +0800, Julien Rouhaud wrote:
>>> PFA rebase of the patchset. Also I've added a patch to combine
>>> page_number, page_status, and page_dirty together to touch less
>>> cachelines.
>>
>> The cfbot rep
Hi,
On Sun, Dec 26, 2021 at 03:09:59PM +0500, Andrey Borodin wrote:
>
>
> PFA rebase of the patchset. Also I've added a patch to combine page_number,
> page_status, and page_dirty together to touch less cachelines.
The cfbot reports some errors on the latest version of the patch:
https://cirru
>> 8 апр. 2021 г., в 15:22, Thomas Munro написал(а):
>>
> I have one more idea inspired by CPU caches.
> Let's make SLRU n-associative, where n ~ 8.
> We can divide buffers into "banks", number of banks must be power of 2.
> All banks are of equal size. We choose bank size to approximately satis
пн, 14 июн. 2021 г. в 15:07, Andrey Borodin :
> PFA patch implementing this idea.
>
I'm benchmarked v17 patches.
Testing was done on a 96-core machine, with PGDATA completely placed in
tmpfs.
PostgreSQL was built with CFLAGS -O2.
for-update PgBench script:
\set aid random_zipfian(1, 100, 2)
begi
> 8 апр. 2021 г., в 15:22, Thomas Munro написал(а):
>
> On Thu, Apr 8, 2021 at 7:24 PM Andrey Borodin wrote:
>> I agree that this version of eviction seems much more effective and less
>> intrusive than RR. And it's still LRU, which is important for subsystem that
>> is called SLRU.
>> share
On Thu, Apr 8, 2021 at 7:24 PM Andrey Borodin wrote:
> I agree that this version of eviction seems much more effective and less
> intrusive than RR. And it's still LRU, which is important for subsystem that
> is called SLRU.
> shared->search_slotno is initialized implicitly with memset(). But th
> 8 апр. 2021 г., в 03:30, Thomas Munro написал(а):
>
> Here's another approach that is a little less exciting than
> "tournament RR" (or whatever that should be called; I couldn't find an
> established name for it). This version is just our traditional linear
> search, except that it stops a
On Thu, Apr 8, 2021 at 12:13 AM Andrey Borodin wrote:
> > 7 апр. 2021 г., в 14:44, Andrey Borodin написал(а):
> > Maybe instead of fully associative cache with random replacement we could
> > use 1-associative cache?
> > i.e. each page can reside only in one spcific buffer slot. If there's
> >
> 7 апр. 2021 г., в 14:44, Andrey Borodin написал(а):
>
> Maybe instead of fully associative cache with random replacement we could use
> 1-associative cache?
> i.e. each page can reside only in one spcific buffer slot. If there's
> something else - evict it.
> I think this would be as effic
> 7 апр. 2021 г., в 08:59, Thomas Munro написал(а):
>
> The remaining thing that bothers me about this patch set is that there is
> still a linear search in the replacement algorithm, and it runs with an
> exclusive lock. That creates a serious problem for large caches that still
> aren't
On Sun, Apr 4, 2021 at 7:57 AM Andrey Borodin wrote:
> I was toying around with big values. For example if we set different big
xact_buffers we can get something like
> FATAL: not enough shared memory for data structure "Notify" (72768 bytes
requested)
> FATAL: not enough shared memory for data
> 1 апр. 2021 г., в 06:40, Thomas Munro написал(а):
>
> 2. Remove the cap of 128 buffers for xact_buffers as agreed. We
> still need a cap though, to avoid a couple of kinds of overflow inside
> slru.c, both when computing the default value and accepting a
> user-provided number. I introduc
On Thu, Apr 1, 2021 at 10:09 AM Andrey Borodin wrote:
> > 29 марта 2021 г., в 11:26, Andrey Borodin написал(а):
> > My TODO list:
> > 1. Try to break patch set v13-[0001-0004]
> > 2. Think how to measure performance of linear search versus hash search in
> > SLRU buffer mapping.
>
> Hi Thomas!
>
> 29 марта 2021 г., в 11:26, Andrey Borodin написал(а):
>
> My TODO list:
> 1. Try to break patch set v13-[0001-0004]
> 2. Think how to measure performance of linear search versus hash search in
> SLRU buffer mapping.
Hi Thomas!
I'm still doing my homework. And to this moment all my catch is
> 29 марта 2021 г., в 02:15, Thomas Munro написал(а):
>
> On Sat, Mar 27, 2021 at 6:31 PM Andrey Borodin wrote:
>>> 27 марта 2021 г., в 01:26, Thomas Munro написал(а):
>>> , and murmurhash which is inlineable and
>>> branch-free.
>
>> I think pageno is a hash already. Why hash any further?
On Sat, Mar 27, 2021 at 6:31 PM Andrey Borodin wrote:
> > 27 марта 2021 г., в 01:26, Thomas Munro написал(а):
> > , and murmurhash which is inlineable and
> > branch-free.
> I think pageno is a hash already. Why hash any further? And pages accessed
> together will have smaller access time due t
> 27 марта 2021 г., в 01:26, Thomas Munro написал(а):
>
> On Sat, Mar 27, 2021 at 4:52 AM Andrey Borodin wrote:
>> Some thoughts on HashTable patch:
>> 1. Can we allocate bigger hashtable to reduce probability of collisions?
>
> Yeah, good idea, might require some study.
In a long run we alw
On Sat, Mar 27, 2021 at 4:52 AM Andrey Borodin wrote:
> Some thoughts on HashTable patch:
> 1. Can we allocate bigger hashtable to reduce probability of collisions?
Yeah, good idea, might require some study.
> 2. Can we use specialised hashtable for this case? I'm afraid hash_search()
> does co
> 26 марта 2021 г., в 11:00, Andrey Borodin написал(а):
>
>> I'm not saying the 0002 patch is bug-free yet though, it's a bit finickity.
> I think the idea of speeding up linear search is really really good for
> scaling SLRUs. It's not even about improving normal performance of the
> cluste
Hi Thomas, Gilles, all!
Thanks for reviewing this!
> 25 марта 2021 г., в 02:31, Thomas Munro написал(а):
>
> I don't think we should put "slru" (the name of the buffer replacement
> algorithm, implementation detail) in the GUC names.
+1
> +It defaults to 0, in this case CLOG size is t
Hi Andrey, all,
I propose some changes, and I'm attaching a new version:
I renamed the GUCs as clog_buffers etc (no "_slru_"). I fixed some
copy/paste mistakes where the different GUCs were mixed up. I made
some changes to the .conf.sample. I rewrote the documentation so that
it states the cor
On Thu, Mar 25, 2021 at 10:31 AM Thomas Munro wrote:
> We already know that increasing the number of CLOG buffers above the
> current number hurts as the linear search begins to dominate
> (according to the commit message for 5364b357), and it doesn't seem
> great to ship a new feature that melts
Hi Andrey,
On Sat, Mar 13, 2021 at 1:44 AM Andrey Borodin wrote:
> [v10]
+intmultixact_offsets_slru_buffers = 8;
+intmultixact_members_slru_buffers = 16;
+intsubtrans_slru_buffers = 32;
+intnotify_slru_buffers = 8;
+intserial_slru_buffe
Le 12/03/2021 à 13:44, Andrey Borodin a écrit :
>
>> 11 марта 2021 г., в 20:50, Gilles Darold написал(а):
>>
>>
>> The patch doesn't apply anymore in master cause of error: patch failed:
>> src/backend/utils/init/globals.c:150
>>
>>
>>
>> An other remark about this patch is that it should be ment
> 11 марта 2021 г., в 20:50, Gilles Darold написал(а):
>
>
> The patch doesn't apply anymore in master cause of error: patch failed:
> src/backend/utils/init/globals.c:150
>
>
>
> An other remark about this patch is that it should be mentionned in the
> documentation (doc/src/sgml/config.
Le 15/02/2021 à 18:17, Andrey Borodin a écrit :
23 дек. 2020 г., в 21:31, Gilles Darold написал(а):
Sorry for the response delay, we have run several others tests trying to figure
out the performances gain per patch but unfortunately we have very heratic
results. With the same parameters an
> 23 дек. 2020 г., в 21:31, Gilles Darold написал(а):
>
> Sorry for the response delay, we have run several others tests trying to
> figure out the performances gain per patch but unfortunately we have very
> heratic results. With the same parameters and patches the test doesn't
> returns th
Le 13/12/2020 à 18:24, Andrey Borodin a écrit :
13 дек. 2020 г., в 14:17, Gilles Darold написал(а):
I've done more review on these patches.
Thanks, Gilles! I'll incorporate all your fixes to patchset.
Can you also benchmark conditional variable sleep? The patch "Add conditional
variable to
> 13 дек. 2020 г., в 22:24, Andrey Borodin написал(а):
>
>
>
>> 13 дек. 2020 г., в 14:17, Gilles Darold написал(а):
>>
>> I've done more review on these patches.
>
> Thanks, Gilles! I'll incorporate all your fixes to patchset.
PFA patches.
Also, I've noted that patch "Add conditional vari
> 13 дек. 2020 г., в 14:17, Gilles Darold написал(а):
>
> I've done more review on these patches.
Thanks, Gilles! I'll incorporate all your fixes to patchset.
Can you also benchmark conditional variable sleep? The patch "Add conditional
variable to wait for next MultXact offset in corner cas
Le 11/12/2020 à 18:50, Gilles Darold a écrit :
> Le 10/12/2020 à 15:45, Gilles Darold a écrit :
>> Le 08/12/2020 à 18:52, Andrey Borodin a écrit :
>>> Hi Gilles!
>>>
>>> Many thanks for your message!
>>>
8 дек. 2020 г., в 21:05, Gilles Darold написал(а):
I know that this report is n
Le 10/12/2020 à 15:45, Gilles Darold a écrit :
Le 08/12/2020 à 18:52, Andrey Borodin a écrit :
Hi Gilles!
Many thanks for your message!
8 дек. 2020 г., в 21:05, Gilles Darold написал(а):
I know that this report is not really helpful
Quite contrary - this benchmarks prove that controllable
Le 08/12/2020 à 18:52, Andrey Borodin a écrit :
Hi Gilles!
Many thanks for your message!
8 дек. 2020 г., в 21:05, Gilles Darold написал(а):
I know that this report is not really helpful
Quite contrary - this benchmarks prove that controllable reproduction exists.
I've rebased patches for P
Le 09/12/2020 à 11:51, Gilles Darold a écrit :
Also PG regression tests are failing too on several part.
Forget this, I have not run the regression tests in the right repository:
...
===
All 189 tests passed.
===
I'm looking why the application is fa
Hi Andrey,
Thanks for the backport. I have issue with the first patch "Use shared
lock in GetMultiXactIdMembers for offsets and members"
(v1106-0001-Use-shared-lock-in-GetMultiXactIdMembers-for-o.patch) the
applications are not working anymore when I'm applying it. Also PG
regression tests ar
Hi Gilles!
Many thanks for your message!
> 8 дек. 2020 г., в 21:05, Gilles Darold написал(а):
>
> I know that this report is not really helpful
Quite contrary - this benchmarks prove that controllable reproduction exists.
I've rebased patches for PG11. Can you please benchmark them (without
Le 13/11/2020 à 12:49, Andrey Borodin a écrit :
10 нояб. 2020 г., в 23:07, Tomas Vondra
написал(а):
On 11/10/20 7:16 AM, Andrey Borodin wrote:
but this picture was not stable.
Seems we haven't made much progress in reproducing the issue :-( I guess
we'll need to know more about the machi
> 10 нояб. 2020 г., в 23:07, Tomas Vondra
> написал(а):
>
> On 11/10/20 7:16 AM, Andrey Borodin wrote:
>>
>>
>> but this picture was not stable.
>>
>
> Seems we haven't made much progress in reproducing the issue :-( I guess
> we'll need to know more about the machine where this happens.
On Wed, Nov 11, 2020 at 7:07 AM Tomas Vondra
wrote:
> Seems we haven't made much progress in reproducing the issue :-( I guess
> we'll need to know more about the machine where this happens. Is there
> anything special about the hardware/config? Are you monitoring size of
> the pg_multixact direct
On 11/10/20 7:16 AM, Andrey Borodin wrote:
>
>
>> 10 нояб. 2020 г., в 05:13, Tomas Vondra
>> написал(а):
>> After the issue reported in [1] got fixed, I've restarted the multi-xact
>> stress test, hoping to reproduce the issue. But so far no luck :-(
>
>
> Tomas, many thanks for looking in
> 10 нояб. 2020 г., в 05:13, Tomas Vondra
> написал(а):
> After the issue reported in [1] got fixed, I've restarted the multi-xact
> stress test, hoping to reproduce the issue. But so far no luck :-(
Tomas, many thanks for looking into this. I figured out that to make multixact
sets bigger
Hi,
After the issue reported in [1] got fixed, I've restarted the multi-xact
stress test, hoping to reproduce the issue. But so far no luck :-(
I've started slightly different tests on two machines - on one machine
I've done this:
a) init.sql
create table t (a int);
insert into t select i
> 29 окт. 2020 г., в 18:49, Tomas Vondra
> написал(а):
>
> On Thu, Oct 29, 2020 at 12:08:21PM +0500, Andrey Borodin wrote:
>>
>>
>>> 29 окт. 2020 г., в 04:32, Tomas Vondra
>>> написал(а):
>>>
>>> It's not my intention to be mean or anything like that, but to me this
>>> means we don't re
On Thu, Oct 29, 2020 at 12:08:21PM +0500, Andrey Borodin wrote:
29 окт. 2020 г., в 04:32, Tomas Vondra
написал(а):
It's not my intention to be mean or anything like that, but to me this
means we don't really understand the problem we're trying to solve. Had
we understood it, we should be ab
Hi,
On Wed, Oct 28, 2020 at 12:34:58PM +0500, Andrey Borodin wrote:
Tomas, thanks for looking into this!
28 окт. 2020 г., в 06:36, Tomas Vondra
написал(а):
This thread started with a discussion about making the SLRU sizes
configurable, but this patch version only adds a local cache. Does t
On Wed, Oct 28, 2020 at 10:36:39PM +0300, Alexander Korotkov wrote:
Hi, Tomas!
Thank you for your review.
On Wed, Oct 28, 2020 at 4:36 AM Tomas Vondra
wrote:
I did a quick review on this patch series. A couple comments:
0001
This looks quite suspicious to me - SimpleLruReadPage_ReadOn
Hi, Tomas!
Thank you for your review.
On Wed, Oct 28, 2020 at 4:36 AM Tomas Vondra
wrote:
> I did a quick review on this patch series. A couple comments:
>
>
> 0001
>
>
> This looks quite suspicious to me - SimpleLruReadPage_ReadOnly is
> changed to return information about what lock was us
Tomas, thanks for looking into this!
> 28 окт. 2020 г., в 06:36, Tomas Vondra
> написал(а):
>
>
> This thread started with a discussion about making the SLRU sizes
> configurable, but this patch version only adds a local cache. Does this
> achieve the same goal, or would we still gain somethin
On Tue, Oct 27, 2020 at 08:23:26PM +0300, Alexander Korotkov wrote:
On Tue, Oct 27, 2020 at 8:02 PM Alexander Korotkov wrote:
On Mon, Oct 26, 2020 at 6:45 PM Andrey Borodin wrote:
> Thanks for your review, Alexander!
> +1 for avoiding double locking in SimpleLruReadPage_ReadOnly().
> Other cha
On Tue, Oct 27, 2020 at 8:02 PM Alexander Korotkov wrote:
> On Mon, Oct 26, 2020 at 6:45 PM Andrey Borodin wrote:
> > Thanks for your review, Alexander!
> > +1 for avoiding double locking in SimpleLruReadPage_ReadOnly().
> > Other changes seem correct to me too.
> >
> >
> > I've tried to find opt
On Mon, Oct 26, 2020 at 6:45 PM Andrey Borodin wrote:
> Thanks for your review, Alexander!
> +1 for avoiding double locking in SimpleLruReadPage_ReadOnly().
> Other changes seem correct to me too.
>
>
> I've tried to find optimal value for cache size and it seems to me that it
> affects multixact
1 - 100 of 118 matches
Mail list logo
