> On 8 Oct 2024, at 19:23, Aleksander Alekseev wrote:
>
> PFA patch v6.
IMO the patch looks RfC.
Best regards, Andrey Borodin.
> On 4 Oct 2024, at 18:55, Christoph Berg wrote:
>
> Thank you and congratulations to all!
Well deserved, congratulations!
Best regards, Andrey Borodin.
> On 27 Sep 2024, at 03:30, Euler Taveira wrote:
>
> Let's say you arbitrarily provide max_log_size = 100
Consider max_log_size = 10Mb. The perspective might look very different. It’s
not about WHERE anymore. It's a guard against heavy abuse.
The feature looks very important for me.
Best
> On 12 Sep 2024, at 00:50, Andrei Lepikhov wrote:
>
> It happens because of documented behaviour [1], which doesn't guarantee
> isolation levels for internal access to the system catalogues.
As far as I understood you are proposing not isolation guaranties, but allowed
isolation anomaly.
> On 9 Sep 2024, at 02:31, David Rowley wrote:
>
> Also, unless Andrey is happy for you to tag onto the work he's doing,
> I'd suggest another thread for that work. I don't think there's any
> good reason for that work to delay Andrey's work.
Stepan asked for mentoring project, so I handed hi
> 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
> On 10 Aug 2024, at 17:25, Konstantin Knizhnik wrote:
>
> So should we take in account sync replication in LR apply worker or not?
There was some relevant discussion of this topic on PGCon2020 Unconference [0].
My recollection is that it would be nice to have LR slot setting akin to
synchro
> On 6 Aug 2024, at 12:47, Michael Paquier wrote:
>
> Hmm. How about loading injection_points with shared_preload_libraries
> now that it has a _PG_init() thanks to 75534436a477 to take care of
> the initialization you need here? We could add two hooks to request
> some shmem based on a size
One of our customers recently asked me to look into buffer mapping.
Following is my POV on the problem of optimal NUM_BUFFER_PARTITIONS.
I’ve found some dead code: BufMappingPartitionLockByIndex() is unused, and
unused for a long time. See patch 1.
> On 23 Feb 2024, at 22:25, Tomas Vondra wrote
> On 28 Jul 2024, at 23:44, Andrey M. Borodin wrote:
>
> PFA version accepting offset interval.
There was a bug: when time was not moving on, I was updating used time by a
nanosecond, instead of 1/4096 of millisecond.
V27 fixes that.
Thanks!
Best regards, Andrey Borodin.
> On 18 Jul 2024, at 03:55, Michael Paquier wrote:
>
> If there is anything else you would like to see adjusted in this area,
> please let me know.
I’ve tried to switch my multixact test to new INJECTION_POINT_CACHED… and it
does not work for me. Could you please take a look?
2024-08-02 18:5
> On 24 Jul 2024, at 17:42, Marat Bukharov wrote:
>
> V5 patch. I've added more tests with different bytea sizes
Hi Marat!
This looks like a nice feature to have.
I’ve took a look into the patch and have few suggestions:
0. Please write more descriptive commit message akin to [0]
1. Use oid
This is a copy of my message for pgsql-hackers mailing list. Unfortunately
original message was rejected due to one of recipients addresses is blocked.
> On 1 Aug 2024, at 10:54, Andrey M. Borodin wrote:
>
>
>
>> On 1 Aug 2024, at 05:44, Melanie Plageman wrote:
>>
> On 31 Jul 2024, at 12:03, Kirill Reshke wrote:
>
> CREATE TABLE AS USING
> (some_access_method)
This looks in a line with usual CREATE TABLE.
+1 for the feature.
Currently we do not have so many TAMs, but I hope eventually we will have some.
Best regards, Andrey Borodin.
> On 30 Jul 2024, at 14:57, Tomas Vondra wrote:
>
>>
>> How do we synchronize Shared Fake LSN with global XLogCtl->unloggedLSN? Just
>> bump XLogCtl->unloggedLSN if necessary?
>> Perhaps, consider using GetFakeLSNForUnloggedRel() instead of shared
>> counter? As long as we do not care about
> On 30 Jul 2024, at 14:05, Tomas Vondra wrote:
>
>
>
> On 7/26/24 14:13, Andrey M. Borodin wrote:
>>
>>
>>> On 26 Jul 2024, at 14:30, Andreas Karlsson wrote:
>>>
>>> I feel the tricky part about doing that is that we need to make
> On 24 Jul 2024, at 04:09, Sergey Prokhorenko
> wrote:
>
> Implementations MAY alter the actual timestamp.
Hmm… looks like we slightly misinterpreted words about clock source.
Well, that’s great, let’s get offset back.
PFA version accepting offset interval.
It works like this:
postgres=# sel
> On 26 Jul 2024, at 14:30, Andreas Karlsson wrote:
>
> I feel the tricky part about doing that is that we need to make sure the fake
> LSNs are all less than the current real LSN when the index build completes
> and while that normally should be the case we will have a almost never
> exerc
> On 24 Jul 2024, at 13:58, Jelte Fennema-Nio wrote:
>
> On Tue, 23 Jul 2024 at 15:22, Andrei Borodin wrote:
>> I'd like to have GROUP BY AUTO (I also proposed version GROUP BY SURPRISE
>> ME). But I wouldn't like to open pandora box of syntax sugar extensions
>> which may will be incompati
> On 22 Jul 2024, at 14:53, Tomas Vondra wrote:
>
>
>
> On 7/22/24 13:08, Andrey M. Borodin wrote:
>>
>>
>>> On 22 Jul 2024, at 12:26, Tomas Vondra
>>> wrote:
>>>
>>> I don't understand how would that solve the pr
> On 22 Jul 2024, at 12:26, Tomas Vondra wrote:
>
> I don't understand how would that solve the problem, can you elaborate?
> Which of the values are you suggesting should be replaced with the
> shared counter? lastlsn?
I think during build we should consider index unlogged and always use
Ge
> On 21 Jul 2024, at 23:42, Tomas Vondra wrote:
>
>>
>> 1. Do I get it right that is_parallel argument for gistGetFakeLSN()
>> is only needed for assertion? And this assertion can be ensured just
>> by inspecting code. Is it really necessary?
>
> Yes, in the patch it's only used for an asser
Hi Tomas!
> On 7 Jun 2024, at 20:41, Tomas Vondra wrote:
>
> After looking into parallel builds for BRIN and GIN indexes, I was
> wondering if there's a way to do parallel builds for GiST too. I knew
> next to nothing about how GiST works, but I gave it a shot and here's
> what I have - the atta
> On 8 May 2024, at 18:37, Andrey M. Borodin wrote:
>
> It's RFC now.
PFA version with references to RFC instead of drafts.
In nearby thread [0] we found out that most systems have enough presicion to
fill additional 12 bits of sub-millisecond information. So I switched
imp
> On 15 Jul 2024, at 12:52, Stepan Neretin wrote:
>
>
> I run benchmark with my patches:
> ./pgbench -c 10 -j2 -t1000 -d postgres
>
> pgbench (18devel)
> starting vacuum...end.
> transaction type:
> scaling factor: 10
> query mode: simple
> number of clients: 10
> number of threads: 2
> max
Hi Tomas!
Thank you so much for your interest in the patchset.
> On 10 Jul 2024, at 19:01, Tomas Vondra wrote:
>
> I realized amcheck GIN/GiST support would be useful for testing my
> patches adding parallel builds for these index types, so I decided to
> take a look at this and do an initial r
> On 10 Jul 2024, at 11:27, Kirill Reshke wrote:
>
> That's very strange, because the test works fine on my virtual
> machine. Also, it seems that it works in Cirrus [0], as there is this
> line:
So far I could not reproduce that failure.
I’ve checkouted 6edec53 from CFbot repository, but it
Hi!
I’m doing another iteration over the patchset.
PgStartLSN = GetXLogInsertRecPtr();
Should this be kind of RecoveryEndPtr? How is it expected to behave on Standby
in HA cluster, which was doing a crash recovery of 1y WALs in a day, then is in
startup for a year as a Hot Standby, and then is
> On 5 Jul 2024, at 23:46, Paul Jungwirth wrote:
>
> this commit adds support for all combinations of int2/int4/int8 for all five
> btree operators (=/>).
Looks like a nice feature to have.
Would it make sense to do something similar to float8? Or, perhaps, some other
types from btree_gist?
> 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 3 Jul 2024, at 01:08, Corey Huinker wrote:
>
> I'll give it a shot.
Great, thank you! Do you have extended access to CF? Like activity log and
mass-mail functions?
If no I think someone from PG_INFRA can grant you necessary access.
> On 3 Jul 2024, at 20:21, Tomas Vondra wrote:
>
>
> On 3 Jul 2024, at 16:29, Hannu Krosing wrote:
>
> We currently do something similar with OIDs where we just keep
> generating them and then testing for conflicts.
>
> I don't think this is the best way to do it but it mostly works when
> you can actually test for uniqueness, like for exampl
> On 3 Jul 2024, at 13:48, Aleksander Alekseev wrote:
>
> Hi,
>
>> That’s a very interesting result, from the UUID POV!
>> If time is almost always advancing, using time readings instead of a counter
>> is very reasonable: we have interprocess monotonicity almost for free.
>> Though time is
> On 2 Jul 2024, at 22:20, Tom Lane wrote:
>
> It sure looks like this is exact-to-the-nanosecond results,
> since the modal values match the overall per-loop timing,
> and there are no zero measurements.
That’s a very interesting result, from the UUID POV!
If time is almost always advancing,
Hello everyone!
As Michael noted in e26810d01d4 [0] hacking for Postgres 17 has begun.
I’ve skimmed through hackers@ list. And it seems that so far role of the
commitfest manager is vacant.
Is anyone up for doing this community work? Make things moving :)
Best regards, Andrey Borodin.
[0] htt
> On 21 Jun 2024, at 10:36, Michael Paquier wrote:
>
> On Fri, Jun 14, 2024 at 03:12:50PM -0500, Nathan Bossart wrote:
>> On Fri, Jun 14, 2024 at 12:06:36PM +0500, Andrey M. Borodin wrote:
>>> This patch looks good to me.
>>
>> Thanks for looking.
>
&
> On 21 Jun 2024, at 09:01, Michael Paquier wrote:
>
> On Fri, Jun 14, 2024 at 12:06:36PM +0500, Andrey M. Borodin wrote:
>> I’ve tried to dig into the test.
>> The problem is CV is allocated in
>>
>> inj_state = GetNamedDSMSegment("injection_points”,
> On 20 Jun 2024, at 06:29, Noah Misch wrote:
>
> This resolves the last inplace update defect known to me.
That’s a huge amount of work, thank you!
Do I get it right, that inplace updates are catalog-specific and some other OOM
corruptions [0] and Standby corruptions [1] are not related to
> On 19 Mar 2024, at 13:28, Peter Eisentraut wrote:
>
> I feel that we don't actually have any information about this portability
> concern. Does anyone know what precision we can expect from gettimeofday()?
> Can we expect the full microsecond precision usually?
At PGConf.dev Hannu Kross
> On 13 Jun 2024, at 02:04, Nathan Bossart wrote:
>
> I adjusted 0001 based on my upthread feedback.
This patch looks good to me. Spellchecker is complaining about “signaling”
instead of “signalling”, but ISTM it’s OK.
I’ve tried to dig into the test.
The problem is CV is allocated in
inj_
FWIW, yesterday we had one more reproduction of stuck spinlock panic which does
not seem as a stuck spinlock.
I don’t see any valuable diagnostic information. The reproduction happened on
hot standby. There’s a message in logs on primary at the same time, but does
not seem to be releated:
"proc
> On 7 Jun 2024, at 04:38, Michael Paquier wrote:
Thanks Michael! Tests of injection points with injection points are neat :)
Alvaro, here’s the test for multixact CV sleep that I was talking about on
PGConf.
It is needed to test [0]. It is based on loaded injection points. This
technique i
> On 5 Jun 2024, at 03:52, Michael Paquier wrote:
>
> Another thing you could do is to define a
> INJECTION_POINT_LOAD() in the code path you're stressing outside the
> critical section where the point is run. This should save from a call
> to the SQL function. This choice is up to the one
> On 4 Jun 2024, at 00:26, Masahiko Sawada wrote:
Thank you! Vacuum enhancement is a really good step forward, and this small
change would help a lot of observability tools.
> On 4 Jun 2024, at 00:49, Peter Geoghegan wrote:
>
> Can we rename this to num_dead_item_ids (or something similar
Hi everyone!
Me, Bharath, and Ilya are on patch review session at the PGConf.dev :) Maybe we
got everything wrong, please consider that we are just doing training on
reviewing patches.
=== Purpose of the patch ===
Currently, we have checkpoint_timeout and max_wal size to know when we need a
c
> On 21 May 2024, at 06:31, Michael Paquier wrote:
>
> So I agree that 0002 ought to call injection_init_shmem() when calling
> injection_points_preload(), but it also seems to me that the test is
> missing the fact that it should heat the backend cache to avoid the
> allocations in the critic
> On 20 May 2024, at 23:37, Robert Haas wrote:
>
> But if that's a practical
> attack, preventing compression prior to the authentication exchange
> probably isn't good enough: the user could also try to guess what
> queries are being sent on behalf of other users through the same
> pooled c
> On 20 May 2024, at 22:48, Robert Haas wrote:
>
> On Mon, May 20, 2024 at 1:23 PM Jacob Champion
> wrote:
>> On Mon, May 20, 2024 at 10:01 AM Robert Haas wrote:
>>> I really hope that you can't poke big enough holes to kill the feature
>>> entirely, though. Because that sounds sad.
>>
>> E
> On 20 May 2024, at 17:01, Andrey M. Borodin wrote:
Ugh, accidentally send without attaching the patch itself. Sorry for the noise.
Best regards, Andrey Borodin.
0001-Add-multixact-CV-sleep.patch
Description: Binary data
Hi!
> On 20 May 2024, at 08:18, Michael Paquier wrote:
Both features look useful to me.
I've tried to rebase my test of CV sleep during multixact generation[0]. I used
it like this:
INJECTION_POINT_PRELOAD("GetNewMultiXactId-done");
multi = GetNewMultiXactId(nmembers, &offset); // star
Hi!
In a thread about sorting comparators[0] Andres noted that we have
infrastructure to help compiler optimize sorting. PFA attached PoC
implementation. I've checked that it indeed works on the benchmark from that
thread.
postgres=# CREATE TABLE arrays_to_sort AS
SELECT array_shuffle(a) ar
> On 18 May 2024, at 15:22, Tomas Vondra wrote:
>
> Let's continue working on that patch/thread, I'll take a look in the
> next CF.
Cool! I'd be happy to review the patch before CF when Bernd or Christoph will
address current issues.
Best regards, Andrey Borodin.
> On 18 May 2024, at 00:41, Tomas Vondra wrote:
>
> if the opclass supports sorted
> builds, because then we could parallelize the sort.
Hi Tomas!
Yup, I'd also be glad to see this feature. PostGIS folks are using their
geometry (sortsupport was developed for this) with object id (this disa
> On 17 May 2024, at 16:39, Robert Haas wrote:
>
> I think Andrey Borodin's nearby suggestion of having a separate CfM
> for each section of the CommitFest does a good job revealing just how
> bad the current situation is. I agree with him: that would actually
> work. Asking somebody, for a on
> On 16 May 2024, at 23:30, Robert Haas wrote:
>
I think we just need 10x CFMs. Let’s have a CFM for each CF section. I’d
happily take "Replication and Recovery” or “System Administration” for July.
“Miscellaneous” or “Performance” look monstrous.
I feel I can easily track ~20 threads (besi
Hi hackers!
StHighload conference will be held on June 24-25[0]. I’m planning to do
“Pre-Commitfest Party” there.
The idea is to help promote patches among potential reviewers. And start
working with the very beginning of PG18 development cycle.
Good patch review of a valuable feature is a grea
> On 10 May 2024, at 06:04, Michael Paquier wrote:
>
> Attached is an updated patch for now
Can you, please, add some more comments regarding purpose of private data?
I somewhat lost understanding of the discussion for a week or so. And I hoped
to grasp the idea of private_data from resultin
> On 3 May 2024, at 11:18, Andrey M. Borodin wrote:
>
> RFC 9562 is not in AUTH48-Done state, it was approved by authors and editor,
> and now should be published.
It's RFC now.
https://datatracker.ietf.org/doc/rfc9562/
Best regards, Andrey Borodin.
> On 3 May 2024, at 11:18, Andrey M. Borodin wrote:
>
Here's the documentation from ClickHouse [0] for their implementation. It's
identical to provided patch in this thread, with few notable exceptions:
1. Counter is 42 bits, not 18. The counter have no guard bi
> On 13 Apr 2024, at 11:58, Andrey M. Borodin wrote:
>
> New UUID is assigned RFC number 9562, it was aproved by RFC editors and is
> now in AUTH48 state.
RFC 9562 is not in AUTH48-Done state, it was approved by authors and editor,
and now should be published.
Best regards, Andrey Borodin.
> On 17 Apr 2024, at 22:47, Kirk Wolak wrote:
>
> Thoughts?
Today we had a hacking session with Nik and Kirk. We produced a patch to assess
how these links might look like.
Also we needed a url_encode() and found none in a codebase. It would be nice to
have this as an SQL-callable function.
> On 2 May 2024, at 13:43, Michael Paquier wrote:
>
> A detach is not a wakeup.
Oh, now I see. Sorry for the noise.
Detaching local injection point of other backend seems to be useless and can be
forbidden.
As far as I understand, your patch is already doing this in
+ if (!injection_p
> On 2 May 2024, at 12:27, Michael Paquier wrote:
>
> On Wed, May 01, 2024 at 04:12:14PM -0700, Noah Misch wrote:
>> While writing an injection point test, I encountered a variant of the race
>> condition that f4083c4 fixed. It had three sessions and this sequence of
>> events:
>>
>> s1: loc
> On 26 Apr 2024, at 16:54, Jonathan S. Katz wrote:
>
> The Core Team would like to extend our congratulations to Melanie Plageman
> and Richard Guo, who have accepted invitations to become our newest
> PostgreSQL committers.
>
> Please join us in wishing them much success and few reverts!
> On 25 Apr 2024, at 12:06, Pavel Stehule wrote:
>
> Unfortunately, I have not direct access to backup, so I am not able to test
> it. But VACUUM FREEZE DISABLE_PAGE_SKIPPING on master didn't help
>
If Primary considers all freezable tuples frozen, but a standby does not,
"disable page ski
> On 25 Apr 2024, at 11:12, Pavel Stehule wrote:
>
> yesterday, I had to fix strange issue on standby server
It’s not just broken reading, if this standby is promoted in HA cluster - this
would lead to data loss.
Recently I’ve observed some lost heap updates ofter OOM-ing cluster on 14.11.
> On 23 Apr 2024, at 11:23, Maxim Orlov wrote:
>
> Make multixact offsets 64 bit.
- ereport(ERROR,
- (errcode(ERRCODE_PROGRAM_LIMIT_EXCEEDED),
-errmsg("multixact \"members\" limit exceeded"),
Personally, I'd be happy
> On 18 Apr 2024, at 02:39, Andres Freund wrote:
>
> There are lots of places that could benefit from adding 'static
> const'.
+1 for helping compiler.
GCC has a -Wsuggest-attribute=const, we can count these warnings and threat
increase as an error :)
Best regards, Andrey Borodin.
> On 15 Apr 2024, at 14:01, jian he wrote:
>
> "is not a PostgreSQL server process" is the same thing as "not a
> PostgreSQL backend process”?
As far as I understand, backend is something attached to frontend.
There might be infrastructure processes like syslogger or stats collector,
client
> On 12 Mar 2024, at 20:41, Jelte Fennema-Nio wrote:
>
> if e.g.
> the RFC got approved 2 weeks after Postgres its feature freeze
Jelte, you seem to be the visionary! I would consider participating in
lotteries or betting.
New UUID is assigned RFC number 9562, it was aproved by RFC editors a
> On 10 Apr 2024, at 21:48, Parag Paul wrote:
>
> Yes, the probability of this happening is astronomical, but in production
> with 128 core servers with 7000 max_connections, with petabyte scale data,
> this did repro 2 times in the last month. We had to move to a local approach
> to manage
> On 9 Apr 2024, at 18:45, Alvaro Herrera wrote:
>
> Maybe we should explicitly advise users to not delete that WAL from
> their archives, until pg_combinebackup is hammered a bit more.
As a backup tool maintainer, I always reference to out-of-the box Postgres
tools as some bulletproof alter
> On 1 Apr 2024, at 09:05, Andrey M. Borodin wrote:
>
> As of April 1 there are 97 committed patches.
Hello everyone!
March Commitfest is closed.
~40 CF entries were committed since April 1st. Despite some drawbacks discussed
in nearby threads, its still huge amount of work and si
> On 8 Apr 2024, at 08:17, Bharath Rupireddy
> wrote:
Hi Bharath!
As far as I understand CF entry [0] is committed? I understand that there are
some open followups, but I just want to determine correct CF item status...
Thanks!
Best regards, Andrey Borodin.
[0] https://commitfest.postgr
> On 24 Mar 2024, at 23:34, Nathan Bossart wrote:
>
> Committed that part.
Hi Nathan and Yurii!
Can I ask you please to help me with determining status of CF item [0]. Is it
committed or there's something to move to next CF?
Thanks!
Best regards, Andrey Borodin.
[0] https://commitfest.p
> On 19 Feb 2024, at 11:33, Peter Eisentraut wrote:
>
> Ok, I didn't see that my feedback had been addressed. I have committed this
> patch.
Justin, Peter, I can't determine actual status of the CF entry [0]. May I ask
someone of you to move patch to next CF or close as committed?
Thanks!
> On 8 Apr 2024, at 17:26, Melanie Plageman wrote:
>
> What if we pick the actual feature freeze time randomly? That is,
> starting on March 15th (or whenever but more than a week before), each
> night someone from RMT generates a random number between $current_day
> and April 8th. If the numb
> On 27 Sep 2023, at 16:06, tender wang wrote:
>
>Do you have any comments or suggestions on this issue? Thanks.
Hi Tender,
there are some review comments in the thread, that you might be interested in.
I'll mark this [0] entry "Waiting on Author" and move to next CF.
Thanks!
Best rega
> On 8 Apr 2024, at 11:55, Michael Paquier wrote:
>
> the point of the test is to make sure that the local
> cleanup happens
Uh, I did not understand this. Because commit message was about stabiilzizing
tests, not extending coverage.
Also, should we drop function wait_pid() at the end of a t
> On 22 Sep 2023, at 18:50, Matthias van de Meent
> wrote:
Hi Matthias!
This is kind reminder that this thread is waiting for your response.
CF entry [0] is in "Waiting on Author", I'll move it to July CF.
Thanks!
Best regards, Andrey Borodin.
[0] https://commitfest.postgresql.org/47/454
> On 29 Feb 2024, at 11:24, Benoit Lobréau wrote:
>
> Yes, thanks for the proposal, I'll work on it on report here.
Hi Benoit!
This is kind reminder that this thread is waiting for your response.
CF entry [0] is in "Waiting on Author", I'll move it to July CF.
Thanks!
Best regards, Andrey
> On 8 Apr 2024, at 10:33, Michael Paquier wrote:
>
> Thoughts?
As an alternative we can make local injection points mutually exclusive.
Best regards, Andrey Borodin.
> 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 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 3 Jan 2024, at 15:15, Pavel Borisov wrote:
>
> Hi and Happy New Year!
>
> I've looked through the patches and the change seems quite small and
> justified. But at the second round, some doubt arises on whether this long
> patchset indeed introduces enough performance gain? I may be wro
> On 15 Mar 2024, at 17:12, Nazir Bilal Yavuz wrote:
>
> I did not have the time to check other things you mentioned but I
> tested the read performance. The table size is 5.5GB, I did 20 runs in
> total.
Hi Nazir!
Do you plan to review anything else? Or do you think it worth to look at by
> 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 &quo
> On 5 Apr 2024, at 07:19, Michael Paquier wrote:
>
> It's been a couple of weeks since this has been sent, and this did not
> get any reviews. I'd still be happy with the simplicity of a single
> injection_points_local() that can be used to link all the injection
> points created in a single
> On 5 Apr 2024, at 02:08, Kirill Reshke wrote:
>
> maybe we need some hooks here? Or maybe, we can take CSN here from extension
> somehow.
I really like the idea of CSN-provider-as-extension.
But it's very important to move on with CSN, at least on standby, to make CSN
actually happen some
> On 5 Apr 2024, at 05:03, Leung, Anthony wrote:
>
> Adding tap test for pg_signal_autovacuum using injection points as a separate
> patch. I also made a minor change on the original patch.
The test looks good, but:
1. remove references to passcheck :)
2. detach injection point when it's not
> On 4 Apr 2024, at 18:45, Peter Eisentraut wrote:
>
> On 26.03.24 18:26, Andrey M. Borodin wrote:
>>> Also, you are initializing 4 bits (I think?) to zero to guard against
>>> counter rollovers (so it's really just an 8 bit counter?). But nothing
>>
> On 3 Apr 2024, at 18:17, Panda Developpeur
> wrote:
>
> Thank you for considering my contribution.
Looks interesting!
+ usleep(50);
Don't we need to make system 500ms faster instead? Let's change it to
+ usl
> On 2 Apr 2024, at 01:21, Nathan Bossart wrote:
>
> I haven't looked too closely, but I'm pretty skeptical that the test suite
> in your patch would be stable. Unfortunately, I don't have any better
> ideas at the moment besides not adding a test for this new role.
We can add tests just lik
> On 20 Mar 2024, at 18:13, wenhui qiu wrote:
>
> Could you take a look at the patch
> (https://commitfest.postgresql.org/47/4284/),How about your opinion
The patch is currently in the "Ready for Committer" state. It's up to the
committer to decide which one to pick. There are 22 prop
> On 1 Mar 2024, at 17:29, Daniel Gustafsson wrote:
>
> It is now March 1 in all timezones, so I have switched 202403 to In Progress
> and 202307 to Open. There are a total of 331 patches registered with 286 of
> those in an open state, 24 of those have been around for 10 CF's or more.
As o
> On 15 Jan 2024, at 13:11, Anton A. Melnikov wrote:
>
> If there are any ideas pro and contra would be glad to discuss them.
Hi, Anton!
This is kind of ancient thread. I've marked CF entry [0] as "Needs review" and
you as an author (seems like you are going to be a point of correspondence
> On 15 Aug 2023, at 07:38, Peter Smith wrote:
>
> A rebase was needed due to a recent push [1].
>
> PSA v3.
> On 14 Jan 2024, at 10:43, vignesh C wrote:
>
> I have changed the status of the patch to "Waiting on Author" as
> Amit's queries at [1] have not been verified and concluded. Plea
> On 11 Jan 2024, at 20:10, vignesh C wrote:
>
> I have changed the status of the patch to "Waiting on Author" as Tom
> Lane's comments have not yet been addressed, feel free to address them
> and update the commitfest entry accordingly.
This CF entry seems to be a fix for actually unexpected
> On 6 Jan 2024, at 20:20, vignesh C wrote:
>
> One of the test has failed in CFBOT at[1] with:
Hi Adam,
This is a kind reminder that CF entry [0] is waiting for an update. Thanks!
Best regards, Andrey Borodin.
[0] https://commitfest.postgresql.org/47/4660/
> On 6 Dec 2023, at 23:52, Robert Haas wrote:
>
> I hope that it's at least somewhat useful.
>
> On 5 Jan 2024, at 15:46, vignesh C wrote:
>
> There is a leak reported
Hi Amit,
this is a kind reminder that some feedback on your patch[0] is waiting for your
reply.
Thank you for your w
1 - 100 of 304 matches
Mail list logo