> 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
> 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
> 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.
>>
>>
> 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, ); // starts
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)
> 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
> 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 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
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
> 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
> 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 bits, eve
> 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
> 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
> 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:
> 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
> 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
> 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
> 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
> 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]
> 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]
> 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
> 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
> 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
> 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]
> 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,
> 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
> 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.
B
> 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
> 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 "m
> 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
> 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
> 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
> 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
+
> 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
> 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
> 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
> 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.
> 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
> 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
> On 30 Mar 2024, at 11:39, Karl O. Pinc wrote:
>
> Well, Friday has come and gone and I've not gotten to this.
> I'll see if I can spend time tomorrow.
No worries, Karl! I just wanted to know if anyone is interested in this thread,
and, now is obvious that you are. Thanks for your work!
> On 29 Oct 2023, at 21:30, Denis Smirnov wrote:
>
> I have taken a look at this discussion, at the code and I am confused how we
> choose tuple table slot (TTS) type in PG.
After offline discussion with Denis, we decided to withdraw this patch from CF
for now. If anyone is willing to
> On 1 Dec 2023, at 19:00, Karl O. Pinc wrote:
>
> I won't be able to submit
> new patches based on reviews for 2 weeks.
Hi everyone!
Is there any work going on? Maybe is someone interested in moving this forward?
Thanks!
Best regards, Andrey Borodin.
> On 8 Aug 2023, at 12:31, John Naylor wrote:
>
> > > Also the shared counter is the cause of the slowdown, but not the reason
> > > for the numeric limit.
> >
> > Isn't it both? typedef Oid is unsigned int = 2^32, and according to
> > GetNewOidWithIndex() logic if we exhaust the whole OID
> On 18 Jul 2023, at 12:09, Zhijie Hou (Fujitsu) wrote:
>
> Here is the POC patch(0004) for the second approach
Hi everyone!
This thread is registered on CF [0] but is not active since 2023. Is anyone
working on this? I understand that this is a nice feature. Should we move it to
next CF
> On 28 Mar 2024, at 10:51, Akshat Jaimini wrote:
>
> I am currently trying to review the submitted patch
Great, thank you!
> but I am not able to apply it to the master branch.
Please find attached rebased version on current HEAD. For some reason CFbot did
not notify about that rebases
Sorry for this long reply. I was looking on refactoring around
pg_strong_random() and could not decide what to do. Finally, I decided to post
at least something.
> On 22 Mar 2024, at 19:15, Peter Eisentraut wrote:
>
> I have been studying the uuidv() function.
>
> I find this code extremely
> On 22 Mar 2024, at 18:20, Bernd Helmle wrote:
>
> Here is a rebased version of the patch.
FWIW it would be nice at least port tests from commit that I referenced
upthread.
Nowadays we have injection points, so these tests can be much more stable.
Sorry for bringing up this so late.
> On 21 Mar 2024, at 20:21, Jelte Fennema-Nio wrote:
>
> On Wed, 20 Mar 2024 at 19:08, Andrey M. Borodin wrote:
>> Timer-based bits contribute to global sortability. But the real timers we
>> have are not even millisecond adjusted. We can hope for ~few ms variation
> On 21 Mar 2024, at 18:54, Peter Geoghegan wrote:
> Do the posting lists that are corrupt
> (reported on elsewhere) also have duplicate TIDs?
I do not have access now, but AFAIR yes.
Thanks for pointers!
BTW there were also some errors in logs like
ERROR: index "tablename" contains
> On 29 Jun 2022, at 17:43, Robins Tharakan wrote:
Sorry to bump ancient thread, I have some observations that might or might not
be relevant.
Recently we noticed a corruption on one of clusters. The corruption at hand is
not in system catalog, but in user indexes.
The cluster was
> On 19 Mar 2024, at 13:55, Peter Eisentraut wrote:
>
> On 16.03.24 18:43, Andrey M. Borodin wrote:
>>> On 15 Mar 2024, at 14:47, Aleksander Alekseev
>>> wrote:
>>>
>>> +1 to the idea. I doubt that anyone will miss it.
>> PFA v22.
>&
> On 18 Mar 2024, at 06:04, Michael Paquier wrote:
>
> new function call injection_points_local() that can
> be added on top of a SQL test to make it concurrent-safe.
Maybe consider function injection_points_attach_local(‘point name’) instead of
static switch?
Or even
> On 15 Mar 2024, at 14:47, Aleksander Alekseev
> wrote:
>
> +1 to the idea. I doubt that anyone will miss it.
PFA v22.
Changes:
1. Squashed all editorialisation by Jelte
2. Fixed my erroneous comments on using Method 2 (we are using method 1 instead)
3. Remove all traces of
> On 14 Mar 2024, at 20:10, Peter Eisentraut wrote:
>
> I think the behavior of uuid_extract_var(iant) is wrong. The code
> takes just two bits to return, but the draft document is quite clear
> that the variant is 4 bits (see Table 1).
Well, it was correct only for
> On 14 Mar 2024, at 16:07, Peter Eisentraut wrote:
>
> On 10.03.24 13:59, Andrey M. Borodin wrote:
>>> The functions uuid_extract_ver and uuid_extract_var could be named
>>> uuid_extract_version and uuid_extract_variant. Otherwise, it's hard
>>> to t
> On 13 Mar 2024, at 05:23, Alexander Korotkov wrote:
>
> On Tue, Mar 12, 2024 at 10:28 AM Andrey M. Borodin
> wrote:
>>> On 11 Mar 2024, at 16:18, Alexander Korotkov wrote:
>>>
>>> I think if checking psql stderr is problematic, checkin
> On 11 Mar 2024, at 16:18, Alexander Korotkov wrote:
>
> I think if checking psql stderr is problematic, checking just logs is
> fine. Could we wait for the relevant log messages one by one with
> $node->wait_for_log() just like 040_standby_failover_slots_sync.pl do?
PFA version with
> On 12 Mar 2024, at 10:53, Michael Paquier wrote:
>
> It does not strike me as a good idea to rush an implementation without
> a specification officially approved because there is always a risk of
> shipping something that's non-compliant into core. But perhaps I am
> missing something on
> On 11 Mar 2024, at 20:56, Jelte Fennema-Nio wrote:
>
> Attached a few comment fixes/improvements and a pgindent run (patch 0002-0004)
Thanks!
> Now with the added comments, one thing pops out to me: The comments
> mention that we use "Monotonic Random", but when I read the spec that
>
> On 7 Mar 2024, at 00:55, Alexander Korotkov wrote:
>
> On Wed, Mar 6, 2024 at 10:22 AM Andrey M. Borodin
> wrote:
>>> On 25 Feb 2024, at 21:50, Alexander Korotkov wrote:
>>>
>>> Thank you for the patches. I've pushed the 0001 patch to avoid
>&
> On 20 Jan 2024, at 07:46, vignesh C wrote:
>
> I have changed the status of the commitfest entry to "Waiting on
> Author" as there was no follow-up on Alexander's queries. Feel free to
> address them and change the commitfest entry accordingly.
Thanks Vignesh!
At the moment it’s obvious
> On 10 Mar 2024, at 17:59, Andrey M. Borodin wrote:
>
> I tried to "make docs", but it gives me gazilion of errors... Is there an
> easy way to see resulting HTML?
Oops, CFbot expectedly found a problem...
Sorry for the noise, this version, I hope, will pass all the
Hi Peter,
thank you for so thoughtful review.
> On 6 Mar 2024, at 12:13, Peter Eisentraut wrote:
>
> I have various comments on this patch:
>
>
> - doc/src/sgml/func.sgml
>
> The documentation of the new functions should be broken up a bit.
> It's all one paragraph now. At least make it
> On 6 Mar 2024, at 18:49, Andrey M. Borodin wrote:
>
> Here are statuses for "Refactoring" section:
I've made a pass through "Replication and Recovery" and "SQL commands" sections.
"SQL commands" section seems to me most interesting stuf
Hello everyone!
Thanks for working on this, really nice feature!
> On 9 Jan 2024, at 01:40, Joe Conway wrote:
>
> Thanks -- will have a look
Joe, recently folks proposed a lot of patches in this thread that seem like
diverted from original way of implementation.
As an author of CF entry [0]
> On 4 Mar 2024, at 17:09, Aleksander Alekseev wrote:
>
> If you need any help please let me know.
Aleksander, I would greatly appreciate if you join me in managing CF. Together
we can move more stuff :)
Currently, I'm going through "SQL Commands". And so far I had not come to
> On 26 Jan 2024, at 23:36, Dmitry Koval wrote:
>
>
The CF entry was in Ready for Committer state no so long ago.
Stephane, you might want to review recent version after it was rebased on
current HEAD. CFbot's test passed successfully.
Thanks!
Best regards, Andrey Borodin.
> On 8 Mar 2024, at 12:03, Shlok Kyal wrote:
>
>
I haven't digged into the thread, but recent version fails some CFbot's tests.
http://commitfest.cputube.org/euler-taveira.html
https://cirrus-ci.com/task/4833499115421696
==29928==ERROR: AddressSanitizer: heap-use-after-free on address
> On 20 Feb 2024, at 04:09, Noah Misch wrote:
>
I’m not sure if it is connected, but so far many patches in CFbot keep hanging
in this test. For example [0].
I haven’t done root cause analysis yet, but hangs may be related to this
thread. Maybe someone more familiar with similar issues
> On 4 Mar 2024, at 14:51, Andrey M. Borodin wrote:
>
> I’ve read other small sections.
Here are statuses for "Refactoring" section:
* New [relation] options engine
Relatively heavy refactoring. Author keeps interest to the patch for
some years now. As I understo
> On 25 Feb 2024, at 21:50, Alexander Korotkov wrote:
>
> Thank you for the patches. I've pushed the 0001 patch to avoid
> further failures on buildfarm. Let 0004 wait till injections points
> by Mechael are committed.
Thanks!
All prerequisites are committed. I propose something in a line
> On 4 Mar 2024, at 16:47, Ranier Vilela wrote:
>
> Does filling a memory area, one by one, with branches, need strong evidence
> to prove that it is better than filling a memory area, all at once, without
> branches?
I apologise for being too quick to decide to mark the patch RwF. Wold
> On 4 Mar 2024, at 13:42, Andrey M. Borodin wrote:
>
> Here’s my take on “Miscellaneous” section.
I’ve read other small sections.
Monitoring & Control
* Logging parallel worker draught
The patchset on improving loggin os resource starvation when parallel
workers are
> On 3 Mar 2024, at 01:19, Melanie Plageman wrote:
>
> I'm not
> sure if the ones that do have a target version = 17 are actually all
> the patches targeting 17.
Yes, for me it’s only a hint where to bump things up. I will extend scope on
other versions when I fill finish a pass though
> On 29 Feb 2024, at 19:47, Danil Anisimow wrote:
>
> Answering your questions might take some time as I want to write a sample
> patch for pg_stat_statements and make some tests.
> What do you think about putting the patch to commitfest as it closing in a
> few hours?
I’ve switched the
> On 17 Feb 2024, at 00:38, Tom Lane wrote:
>
> Here's a rebase over 9f1337639 --- no code changes, but this affects
> some of the new or changed expected outputs from that commit.
Aleksander, as long as your was reviewing this previously, I’ve added you to
reviewers of this CF entry [0].
> On 18 Feb 2024, at 05:29, Tomas Vondra wrote:
>
> I'm not very familiar with date_bin(), but is this issue inherent or
> could we maybe fix date_bin() to handle DST better?
>
> In particular, isn't part of the problem that date_bin() is defined only
> for timestamp and not for timestamptz?
> On 6 Feb 2024, at 11:21, Michael Paquier wrote:
>
> The problem may be actually trickier than that, no? Could there be
> other factors to take into account for their classification, like
> their sizes (typically, we'd want to process the biggest one first, I
> guess)?
Maxim, what do you
> On 14 Jan 2024, at 18:55, John Naylor wrote:
>
> On Sat, Jan 13, 2024 at 9:36 PM Ranier Vilela wrote:
>>
>> Em ter., 9 de jan. de 2024 às 06:31, John Naylor
>> escreveu:
>
>>> This just moves an operation from one place to the other, while
>>> obliterating the explanatory comment, so I
> On 12 Jan 2024, at 05:51, jian he wrote:
>
> another big difference compare to HEAD:
Hi Jian,
thanks for looking into this. Would you be willing to review the next version
of the patch?
As long as you are looking into this, you might be interested in registering
yourself in a CF entry
> On 23 Jan 2024, at 09:42, Arne Roland wrote:
>
> <0001-fuzzy_underscore_permutation_v5.patch>
Mikhail, there’s a new patch version. May I ask you to review it?
Best regards, Andrey Borodin.
> On 3 Mar 2024, at 20:57, Joe Conway wrote:
>
> New PostgreSQL Contributors:
>
> * Bertrand Drouvot
> * Gabriele Bartolini
> * Richard Guo
>
> New PostgreSQL Major Contributors:
>
> * Alexander Lakhin
> * Daniel Gustafsson
> * Dean Rasheed
> * John Naylor
> * Melanie Plageman
> * Nathan
> On 4 Mar 2024, at 06:44, Michael Paquier wrote:
> so I have applied it
Great! Thank you! A really useful stuff for an asynchronous testing!
> On 4 Mar 2024, at 09:17, Jelte Fennema-Nio wrote:
>
> this code is included in src/test/modules. It sounds like that
> location will make it
Hi hackers!
In this thread, I want to promote entries from CommitFest that require review.
I have scanned through the bugs, clients, and documentation sections, and here
is my take on the current situation. All of these threads are currently in the
"Needs review" state and were marked by the
1 - 100 of 259 matches
Mail list logo
