> 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
> On 26 Feb 2024, at 14:14, Bertrand Drouvot
> wrote:
>
> As the patch as it is now looks good to Amit (see [1]), I prefer to let him
> decide which wording he pefers to push.
Added Amit to cc, just to be sure. Thanks!
Best regards, Andrey Borodin, learning how to be CFM.
> On 1 Mar 2024, at 17:29, Daniel Gustafsson wrote:
>
> The call for a CFM volunteer is still open.
I always wanted to try. And most of the stuff I'm interested in is already
committed.
But given importance of last commitfest before feature freeze, we might be
interested in more
> On 29 Feb 2024, at 15:20, Bertrand Drouvot
> wrote:
>
> done in v2 attached.
Works fine for me. Thanks!
Best regards, Andrey Borodin.
> On 29 Feb 2024, at 13:35, Bertrand Drouvot
> wrote:
>
> Something like the attached?
There's extraneous print "done\n";
Also can we have optional backend type :)
Best regards, Andrey Borodin.
> On 28 Feb 2024, at 09:26, Michael Paquier wrote:
>
> Now, a routine should be only about waiting on
> pg_stat_activity to report something
BTW, if we had an SQL function such as injection_point_await(name), we could
use it in our isolation tests as well as our TAP tests :)
However, this
> On 27 Feb 2024, at 22:33, Alvaro Herrera wrote:
>
>
These patches look amazing!
Best regards, Andrey Borodin.
> On 27 Feb 2024, at 21:03, Alvaro Herrera wrote:
>
> On 2024-Feb-27, Dilip Kumar wrote:
>
>>> static const char *const slru_names[] = {
>>>"commit_timestamp",
>>>"multixact_members",
>>>"multixact_offsets",
>>>"notify",
>>>"serializable",
>>>
Hi,
> On 27 Feb 2024, at 16:08, Bertrand Drouvot
> wrote:
>
> On Tue, Feb 27, 2024 at 11:00:10AM +0500, Andrey M. Borodin wrote:
>>
>> But, AFAICS, the purpose is the same: wait until event happened.
>
> I think it's easier to understand the tests (I mean what
> On 27 Feb 2024, at 04:29, Michael Paquier wrote:
>
> For
> example, the test just posted here does not rely on that:
> https://www.postgresql.org/message-id/zdyzya4yrnapw...@ip-10-97-1-34.eu-west-3.compute.internal
Instead, that test is scanning logs
+ # Note:
> On 26 Feb 2024, at 08:57, Michael Paquier wrote:
>
>
Would it be possible to have a helper function to check this:
+ok( $node_standby->poll_query_until(
+ 'postgres',
+ qq[SELECT count(*) FROM pg_stat_activity
+ WHERE backend_type = 'checkpointer'
> On 23 Feb 2024, at 12:36, Dilip Kumar wrote:
>
>> Another thing I've been thinking is that perhaps it would be useful to
>> make the banks smaller, when the total number of buffers is small. For
>> example, if you have 16 or 32 buffers, it's not really clear to me that
>> it makes sense to
> On 19 Feb 2024, at 15:17, Japin Li wrote:
>
>
> +1
PFA patch set of 4 patches:
1. remove all potential flaky tests. BTW recently we had a bingo when 3 of them
failed together [0]
2-3. waiting injection points patchset by Michael Paquier, intact v2 from
nearby thread.
4. prototype of
> On 20 Feb 2024, at 02:21, Michael Paquier wrote:
>
> On Mon, Feb 19, 2024 at 11:54:20AM +0300, Andrey M. Borodin wrote:
>> 1. injection_points_wake() will wake all of waiters. But it's not
>> suitable for complex tests. I think there must be a way to wake on
> On 18 Feb 2024, at 22:16, Andrey M. Borodin wrote:
>
> But it seems a little strange that session 3 did not fail at all
It was only coincidence. Any test that verifies FATALing out in 100ms can fail,
see new failure here [0].
In a nearby thread Michael is proposing injectio
> On 19 Feb 2024, at 09:01, Michael Paquier wrote:
>
> Thoughts and comments are welcome.
Hi Michael,
thanks for your work on injection points! I want to test a bunch of stuff using
this facility.
I have a wishlist of functionality that I'd like to see in injection points. I
hope you
Alexander, thanks for pushing this! This is small but very awaited feature.
> On 16 Feb 2024, at 02:08, Andres Freund wrote:
>
> Isn't this test going to be very fragile on busy / slow machines? What if the
> pg_sleep() takes one second, because there were other tasks to schedule? I'd
> be
> On 8 Feb 2024, at 06:52, Nathan Bossart wrote:
>
> For the same compASC() test, I see an ~8.4% improvement with your int64
> code and a ~3.4% improvement with this:
If we care about branch prediction in comparison function, maybe we could
produce sorting that inlines comparator, thus
> On 7 Feb 2024, at 10:58, Dilip Kumar wrote:
>
>> commit_timestamp_slru_buffers
>> transaction_slru_buffers
>> etc
>
> I am not sure we are exposing anything related to SLRU to the user,
I think we already tell something about SLRU to the user. I’d rather consider
if
> On 4 Feb 2024, at 18:38, Alvaro Herrera wrote:
>
> In other words, these barriers are fully useless.
+1. I've tried to understand ideas behind barriers, but latest_page_number is
heuristics that does not need any guarantees at all. It's also is used in
safety check which can fire only
> 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 b
> On 30 Jan 2024, at 15:33, Junwang Zhao wrote:
>
> It's always good to add a newline at the end of a source file, though
> this might be nitpicky.
Thanks, also fixed warning found by CFBot.
Best regards, Andrey Borodin.
v17-0001-Implement-UUID-v7.patch
Description: Binary data
> On 30 Jan 2024, at 12:28, Sergey Prokhorenko
> wrote:
>
>
> I think this phrase is outdated: "This function can optionally accept a
> timestamp used instead of current time.
> This allows implementation of k-way sotable identifiers.”
Fixed.
> This phrase is wrong: "Both functions return
> On 30 Jan 2024, at 01:38, Jelte Fennema-Nio wrote:
>
> Yeah, I liked the feature to generate UUIDv7 based on timestamp too.
> But following the spec seems more important than a nice feature to me.
PFA v15. Changes: removed timestamp argument, incorporated Jelte’s
documentation addons.
> On 26 Jan 2024, at 19:58, Japin Li wrote:
>
> Thanks for updating the patch. Here are some comments for v24.
>
> +
> +Terminate any session that spans longer than the specified amount of
> +time in transaction. The limit applies both to explicit transactions
> +
> On 25 Jan 2024, at 22:04, Sergey Prokhorenko
> wrote:
>
> Aleksander,
>
> In this case the documentation must state that the functions
> uuid_extract_time() and uuidv7(T) are against the RFC requirements, and that
> developers may use these functions with caution at their own risk, and
> 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 26 Jan 2024, at 11:44, Andrey M. Borodin wrote:
>
>
> 1. It’s unsafe for isaoltion tester to await transaction_timeout within a
> query. Usually it gets
> FATAL: terminating connection due to transaction timeout
> But if VM is a bit slow it can get occasional
&g
> On 22 Jan 2024, at 11:23, Peter Smith wrote:
>
> Hi, This patch has a CF status of "Needs Review" [1], but it seems
> there was a CFbot test failure last time it was run [2]. Please have a
> look and post an updated version if necessary.
Thanks Peter!
I’ve inspected CI fails and they were
> On 25 Jan 2024, at 09:40, Nikolay Samokhvalov wrote:
>
> From a practical point of view, these two things are extremely important to
> have to support partitioning. It is better to implement limitations than
> throw them away.
Postgres always was a bit hackerish, allowing slightly more
> On 24 Jan 2024, at 20:46, Aleksander Alekseev
> wrote:
>
> Only the
> fact that timestamp from the far past generates UUID from the future
> bothers me.
PFA implementation of guard checks, but I'm afraid that this can cause failures
in ID generation unexpected to the user...
See tests
> On 24 Jan 2024, at 18:29, Aleksander Alekseev
> wrote:
>
> Hi,
>
>> Function to extract timestamp does not provide any guarantees at all.
>> Standard states this, see Kyzer answers upthread.
>> Moreover, standard urges against relying on that if uuidX was generated
>> before uuidY, then
> On 24 Jan 2024, at 18:02, Aleksander Alekseev
> wrote:
>
> Hi,
>
>> UUIDv7 range does not correspond to timestamp range. But it’s purpose is not
>> in storing timestamp, but in being unique identifier. So I don’t think it
>> worth throwing an error when overflowing value is given. BTW
> On 24 Jan 2024, at 17:31, Aleksander Alekseev
> wrote:
>
> Hi,
>
>> Cfbot also seems to be happy with the patch so I'm changing the CF
>> entry status to RfC.
>
> I've found a bug:
>
> ```
> =# select now() - interval '5000 years';
>?column?
>
> On 16 Jan 2024, at 21:49, Sergey Prokhorenko
> wrote:
>
> It is not clear how to interpret uuid_v7_time():
> • uuid_v7 to time() (extracting the timestamp)
> • time() to uuid_v7 (generation of the uuid_v7)
> It is worth improving the naming, for example, adding prepositions.
Thanks for your review, Aleksander!
> On 16 Jan 2024, at 18:00, Aleksander Alekseev
> wrote:
>
>
> ```
> +Datum
> +pg_node_tree_in(PG_FUNCTION_ARGS)
> +{
> +if (!IsBootstrapProcessingMode())
> +elog(ERROR, "cannot accept a value of type pg_node_tree_in");
> +return
> On 10 Jan 2024, at 19:18, jian he wrote:
>
> what I am confused:
> In fmgr.h
>
> /*
> * Support for cleaning up detoasted copies of inputs. This must only
> * be used for pass-by-ref datatypes, and normally would only be used
> * for toastable types. If the given pointer is different
> On 4 Jan 2024, at 07:14, Japin Li wrote:
>
> Does the timeout is too short for testing? I see the timeouts for lock_timeout
> and statement_timeout is more bigger than transaction_timeout.
Makes sense. Done. I've also put some effort into fine-tuning timeouts Nik's
case tests. To have
> On 3 Jan 2024, at 16:46, Andrey M. Borodin wrote:
>
> I do not understand why, but mailing list did not pick patches that I sent.
> I'll retry.
Sorry for the noise. Seems like Apple updated something in Mail.App couple of
days ago and it started to use strange "
On 3 Jan 2024, at 11:39, Andrey M. Borodin <x4...@yandex-team.ru> wrote:On 1 Jan 2024, at 19:28, Andrey M. Borodin <x4...@yandex-team.ru> wrote: 3. Check that timeout is not rescheduled by new queries (Nik's case)The test of Nik's case was not stable enough together with COMMIT AND CH
On 1 Jan 2024, at 19:28, Andrey M. Borodin <x4...@yandex-team.ru> wrote: 3. Check that timeout is not rescheduled by new queries (Nik's case)The test of Nik's case was not stable enough together with COMMIT AND CHAIN. So I've separated these cases into different permutations.Looking thro
On 2 Jan 2024, at 14:17, Andrey M. Borodin <x4...@yandex-team.ru> wrote:Tests verify that get_uuid_v7_time(gen_uuid_v7()) differs no more than 1ms from now(). Maybe we should allow more tolerant values for slow test machines.Indeed, CFbot complained about flaky tests. I've increased test tol
> On 2 Jan 2024, at 19:23, Robert Haas wrote:
>
>>
>> And it would be even better if page for transaction statuses would be
>> determined by backend id somehow. Or at least cache line. Can we allocate a
>> range (sizeof(cacheline)) of xids\subxids\multixacts\whatever for each
>> backend?
> On 9 Oct 2023, at 23:46, Andrey Borodin wrote:
Here's next iteration of the patch. I've added get_uuid_v7_time().
This function extracts timestamp from uuid, iff it is v7. Timestamp correctness
only guaranteed if the timestamp was generated by the same implementation (6
bytes for
> On 29 Dec 2023, at 16:15, Andrey M. Borodin wrote:
PFA v20. Code steps are intact.
Further refactored tests:
1. Check termination of active and idle queries (previously tests from Li
were testing only termination of idle query)
2. Check timeout reschedule (even when last act
> On 29 Dec 2023, at 16:00, Junwang Zhao wrote:
>
> After exploring the code, I found scheduling the timeout in
> `StartTransaction` might be a reasonable idea, all the chain
> commands will call this function.
>
> What concerns me is that it is also called by StartParallelWorkerTransaction,
> On 21 Dec 2023, at 05:30, Jelte Fennema-Nio wrote:
>
> One thing I'm wondering: should it be possible for the client to change the
> compression it wants mid-connection?
This patchset allows sending CompressionMethod message, which allows to set
another codec\level picked from the set of
> On 28 Dec 2023, at 21:02, Junwang Zhao wrote:
>
> Seems V5~V17 doesn't work as expected for Nikolay's case:
>
Yeah, that's a problem.
> So I propose the following change, what do you think?
This breaks COMMIT AND CHAIN.
PFA v18: I've added a test for Nik's case and for COMMIT AND CHAIN.
> On 22 Dec 2023, at 10:39, Japin Li wrote:
>
>
> I try to split the test for transaction timeout, and all passed on my CI [1].
I like the refactoring you did in timeout.spec. I thought it is impossible,
because permutations would try to reinitialize FATALed sessions. But,
obviously,
> On 19 Dec 2023, at 10:34, Dilip Kumar wrote:
Just a side node.
It seems like commit log is kind of antipattern of data contention. Even when
we build a super-optimized SLRU. Nearby **bits** are written by different CPUs.
I think that banks and locks are good thing. But also we could
> On 15 Dec 2023, at 16:28, Ivan Kush wrote:
>
>
>
> Hello. I'm working on the support of autonomous transactions in Postgres.
>
> # Summary
> * Add pragma AUTONOMOUS_TRANSACTION in the functions. When function
> contains this pragma, the it's executed autonomously
> * Background workers
> On 19 Dec 2023, at 13:26, Andrey M. Borodin wrote:
>
> I don’t have Windows machine, so I hope CF bot will pick this.
I used Github CI to produce version of tests that seems to be is stable on
Windows.
Sorry for the noise.
Best regards, Andrey Borodin.
v13-0001-
> On 19 Dec 2023, at 06:25, Japin Li wrote:
>
> On Windows, there still have an error:
Uhhmm, yes. Connection termination looks different on windows machine.
I’ve checked how this looks in relication slot tests and removed select that
was observing connection failure.
I don’t have Windows
> On 18 Dec 2023, at 22:30, Robert Haas wrote:
>
> On Mon, Dec 18, 2023 at 12:04 PM Robert Haas wrote:
>> certain sense they are competing for the same job. However, they do
>> aim to alleviate different TYPES of contention: the group XID update
>> stuff should be most valuable when lots of
> On 18 Dec 2023, at 14:32, Japin Li wrote:
>
>
> Thanks for updating the patch
Sorry for the noise, but commitfest bot found one more bug in handling
statement timeout. PFA v11.
Best regards, Andrey Borodin.
v11-0001-Introduce-transaction_timeout.patch
Description: Binary data
> On 16 Dec 2023, at 05:58, Japin Li wrote:
>
>
> On Fri, 15 Dec 2023 at 17:51, Andrey M. Borodin wrote:
>>> On 8 Dec 2023, at 15:29, Japin Li wrote:
>>>
>>> Thanks for updating the patch. LGTM.
>>
>> PFA v9. Changes:
>> 1. A
> On 8 Dec 2023, at 15:29, Japin Li wrote:
>
> Thanks for updating the patch. LGTM.
PFA v9. Changes:
1. Added tests for idle_in_transaction_timeout
2. Suppress statement_timeout if it’s shorter than transaction_timeout
Consider changing status of the commitfest entry if you think it’s ready
> On 14 Dec 2023, at 16:32, tender wang wrote:
>
> enable -O2, only one instruction:
> xor eax, eax
This is not fast code. This is how friendly C compiler suggests you that mask
must be 127, not 128.
Best regards, Andrey Borodin.
> On 14 Dec 2023, at 16:06, Dilip Kumar wrote:
>
> I have noticed
> a very good improvement with the addition of patch 0003.
Indeed, a very impressive results! It’s almost x2 of performance on high
contention scenario, on top of previous improvements.
Best regards, Andrey Borodin.
> On 14 Dec 2023, at 14:28, tender wang wrote:
>
> Now that AND is more faster, Can we replace the '% SLRU_MAX_BANKLOCKS'
> operation in SimpleLruGetBankLock() with '& 127'
unsigned int GetBankno1(unsigned int pageno) {
return pageno & 127;
}
unsigned int GetBankno2(unsigned int
> On 14 Dec 2023, at 08:12, Amul Sul wrote:
>
>
> + int bankno = pageno & ctl->bank_mask;
>
> I am a bit uncomfortable seeing it as a mask, why can't it be simply a number
> of banks (num_banks) and get the bank number through modulus op (pageno %
> num_banks) instead of bitwise & operation
> On 12 Dec 2023, at 18:28, Alvaro Herrera wrote:
>
> Andrey, do you have any stress tests or anything else that you used to
> gain confidence in this code?
We are using only first two steps of the patchset, these steps do not touch
locking stuff.
We’ve got some confidence after Yura
> On 8 Dec 2023, at 12:59, Japin Li wrote:
>
>
> On Thu, 07 Dec 2023 at 20:40, Andrey M. Borodin wrote:
>>> On 7 Dec 2023, at 06:25, Japin Li wrote:
>>>
>>> If idle_in_transaction_timeout is bigger than transaction_timeout,
>>> the idle-in-tr
> On 7 Dec 2023, at 06:25, Japin Li wrote:
>
> If idle_in_transaction_timeout is bigger than transaction_timeout,
> the idle-in-transaction timeout don't needed, right?
Yes, I think so.
>
>> TODO: as Yuhang pointed out prepared transactions must not be killed, thus
>> name
Thanks Yuhang!On 7 Dec 2023, at 13:39, 邱宇航 wrote:I read the V6 patch and found something needs to be improved.Fixed. PFA v7.Best regards, Andrey Borodin.
v7-0001-Introduce-transaction_timeout.patch
Description: Binary data
Hi Yong!
+1 to the idea to protect SLRUs from corruption. I'm slightly leaning towards
the idea of separating checksums from data pages, but anyway this checksums are
better than no checksums.
> On 7 Dec 2023, at 10:06, Li, Yong wrote:
>
> I am still working on patching the pg_upgrade. Just
> On 30 Nov 2023, at 20:06, Andrey M. Borodin wrote:
>
>
> Tomorrow I plan to fix raising of the timeout when the transaction is idle.
> Renaming transaction_timeout to something else (to avoid confusion with
> prepared xacts) also seems correct to me.
Here's a v6 vers
> On 20 Nov 2023, at 06:33, 邱宇航 wrote:
Nikolay, Peter, Fujii, Tung, Yuhang, thank you for reviewing this.
I'll address feedback soon, this patch has been for a long time on my TODO list.
I've started with fixing problem of COMMIT AND CHAIN by restarting timeout
counter.
Tomorrow I plan to fix
Hi Ivan,
thank you for the patch.
> On 22 Nov 2023, at 03:58, Ivan Trofimov wrote:
>
> Currently libpq sends B(ind), D(escribe), E(execute), S(ync) when executing a
> prepared statement.
> The response for that D message is a RowDescription, which doesn't change
> during prepared
> statement
> On 20 Nov 2023, at 13:51, Dilip Kumar wrote:
>
> 2) Do we really need one separate lwlock tranche for each SLRU?
>
> IMHO if we use the same lwlock tranche then the wait event will show
> the same wait event name, right? And that would be confusing for the
> user, whether we are waiting
> On 17 Nov 2023, at 16:11, Dilip Kumar wrote:
>
> On Fri, Nov 17, 2023 at 1:09 PM Dilip Kumar wrote:
>>
>> On Thu, Nov 16, 2023 at 3:11 PM Alvaro Herrera
>> wrote:
>
> PFA, updated patch version, this fixes the comment given by Alvaro and
> also improves some of the comments.
I’ve
> On 8 Nov 2023, at 14:17, Ants Aasma wrote:
>
> Is there a particular reason why lock partitions need to be bigger? We have
> one lock per buffer anyway, bankwise locks will increase the number of locks
> < 10%.
The problem was not attracting much attention for some years. So my reasoning
101 - 200 of 288 matches
Mail list logo