Re: Injection points: some tools to wait and wake

> 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' AND

Re: Injection points: some tools to wait and wake

> 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: $node_primary->wait_for_repla

Re: Injection points: some tools to wait and wake

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

Re: SLRU optimization - configurable buffer pool and partitioning the SLRU lock

> 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", >>>"s

Re: SLRU optimization - configurable buffer pool and partitioning the SLRU lock

> On 27 Feb 2024, at 22:33, Alvaro Herrera wrote: > > These patches look amazing! Best regards, Andrey Borodin.

Re: Injection points: some tools to wait and wake

> 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 mi

Re: Injection points: some tools to wait and wake

> 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.

Re: Injection points: some tools to wait and wake

> On 29 Feb 2024, at 15:20, Bertrand Drouvot > wrote: > > done in v2 attached. Works fine for me. Thanks! Best regards, Andrey Borodin.

Re: Commitfest Manager for March

> 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 experience

Re: Documentation: warn about two_phase when altering a subscription

> 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.

CF entries for 17 to be reviewed

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 pa

Re: Injection points: some tools to wait and wake

> 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 some

Re: PostgreSQL Contributors Updates

> 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 Bo

Re: Permute underscore separated components of columns before fuzzy matching

> 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.

Re: Fix log_line_prefix to display the transaction id (%x) for statements not in a transaction block

> 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 a

Re: Tidy fill hstv array (src/backend/access/heap/pruneheap.c)

> 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

Re: Add Index-level REINDEX with multiple jobs

> 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 thi

Re: date_trunc function in interval version

> 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?

Re: Improving EXPLAIN's display of SubPlan nodes

> 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]. Pl

Re: Comments on Custom RMGRs

> 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 pat

Re: CF entries for 17 to be reviewed

> 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 entr

Re: CF entries for 17 to be reviewed

> 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

Re: Tidy fill hstv array (src/backend/access/heap/pruneheap.c)

> 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 yo

Re: Transaction timeout

> 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 w

Re: CF entries for 17 to be reviewed

> 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

Re: 035_standby_logical_decoding unbounded hang

> 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 cou

Re: speed up a logical replica setup

> 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 0x61a

Re: Add SPLIT PARTITION/MERGE PARTITIONS commands

> 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.

Re: Commitfest Manager for March

> 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 "Performance"

Re: Emitting JSON to file using COPY TO

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] c

Re: CF entries for 17 to be reviewed

> 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

Re: UUID v7

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 sev

Re: UUID v7

> 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

Re: Amcheck verification of GiST and GIN

> 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 th

Re: Transaction timeout

> 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

Re: UUID v7

> 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 > expl

Re: UUID v7

> 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 th

Re: Transaction timeout

> 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 $node->

Re: Transaction timeout

> 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, checking just l

Re: New committers: Nathan Bossart, Amit Langote, Masahiko Sawada

> On 20 Apr 2023, at 22:40, Tom Lane wrote: > > The Core Team would like to extend our congratulations to > Nathan Bossart, Amit Langote, and Masahiko Sawada, who have > accepted invitations to become our newest Postgres committers. > > Please join me in wishing them much success and few reve

Re: psql tests hangs

> On 10 May 2023, at 09:58, Pavel Stehule wrote: > > When I remove this test, then all tests passed Hi Pavel! Can you plz share how sprintf('SELECT 1 \watch c=3 i=%g', 0.01) is formatting 0.01 on your system? And try to run that string against psql. As an alternative I propose to use "i=0”

Re: Allow ALTER SYSTEM SET on unrecognized custom GUCs

> On 17 Oct 2023, at 05:19, Tom Lane wrote: > > In the original discussion about this [1], I initially leaned towards > "they should both fail", but I reconsidered: there doesn't seem to be > any harm in allowing ALTER SYSTEM SET to succeed for any custom GUC > name, as long as you're superuser

Re: race condition in pg_class

> On 25 Oct 2023, at 13:39, Smolkin Grigory wrote: > > We are running PG13.10 and recently we have encountered what appears to be a > bug due to some race condition between ALTER TABLE ... ADD CONSTRAINT and > some other catalog-writer, possibly ANALYZ > I've tried to reproduce this scenari

Re: SLRU optimization - configurable buffer pool and partitioning the SLRU lock

> On 30 Oct 2023, at 09:20, Dilip Kumar wrote: > > changed the logic of SlruAdjustNSlots() in 0002, such that now it > starts with the next power of 2 value of the configured slots and > keeps doubling the number of banks until we reach the number of banks > to the max SLRU_MAX_BANKS(128) and b

Re: SLRU optimization - configurable buffer pool and partitioning the SLRU lock

> On 6 Nov 2023, at 09:09, Dilip Kumar wrote: > > >> Having hashtable to find SLRU page in the buffer IMV is too slow. Some >> comments on this approach can be found here [0]. >> I'm OK with having HTAB for that if we are sure performance does not degrade >> significantly, but I really doubt

Re: SLRU optimization - configurable buffer pool and partitioning the SLRU lock

> On 6 Nov 2023, at 14:31, Alvaro Herrera wrote: > > dynahash is notoriously slow, which is why we have simplehash.h since > commit b30d3ea824c5. Maybe we could use that instead. Dynahash has lock partitioning. Simplehash has not, AFAIK. The thing is we do not really need a hash function - p

Re: SLRU optimization - configurable buffer pool and partitioning the SLRU lock

> 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

Re: SLRU optimization - configurable buffer pool and partitioning the SLRU lock

> 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 skimm

Re: SLRU optimization - configurable buffer pool and partitioning the SLRU lock

> 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 for

Re: WIP: libpq: add a possibility to not send D(escribe) when executing a prepared statement

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

Re: Transaction timeout

> 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 r

Re: Transaction timeout

> 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

Re: Proposal to add page headers to SLRU pages

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

Re: Transaction timeout

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

Re: Transaction timeout

> 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 "transaction_time

Re: Transaction timeout

> 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

Re: SLRU optimization - configurable buffer pool and partitioning the SLRU lock

> 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 Sokolo

Re: SLRU optimization - configurable buffer pool and partitioning the SLRU lock

> 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

Re: SLRU optimization - configurable buffer pool and partitioning the SLRU lock

> 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 pageno

Re: SLRU optimization - configurable buffer pool and partitioning the SLRU lock

> 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.

Re: SLRU optimization - configurable buffer pool and partitioning the SLRU lock

> 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.

Re: Transaction timeout

> 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 f

Re: Transaction timeout

> 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

Re: Transaction timeout

> 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

Re: SLRU optimization - configurable buffer pool and partitioning the SLRU lock

> 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 p

Re: Transaction timeout

> 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 mac

Re: Transaction timeout

> 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-

Re: Autonomous transactions 2023, WIP

> 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

Re: SLRU optimization - configurable buffer pool and partitioning the SLRU lock

> 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 reorgani

Re: Transaction timeout

> 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, tests

Re: Transaction timeout

> 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. No

Re: libpq compression (part 3)

> 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

Re: Transaction timeout

> 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,

Re: Transaction timeout

> 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

Re: UUID v7

> 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 millisecon

Re: SLRU optimization - configurable buffer pool and partitioning the SLRU lock

> 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? >

Re: UUID v7

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 tes

Re: Transaction timeout

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 permutatio

Re: Transaction timeout

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 COM

Re: Transaction timeout

> 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 &quo

Re: Transaction timeout

> 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 100ms

Re: UUID v7

> On 21 Aug 2023, at 13:42, Andrey M. Borodin wrote: > > FPA attached next version. Changes: - implemented protection from time leap backwards when series is generated on the same backend - counter overflow is now translated into ms step forward Best regards, Andrey Borodin.

Re: UUID v7

Thanks for interesting ideas, Mat! > On 31 Aug 2023, at 20:32, Mat Arye wrote: > > From a user perspective, it would be great to add 2 things: > - A function to extract the timestamp from a V7 UUID (very useful for > defining constraints if partitioning by the uuid-embedded timestamps, for > i

Re: Transaction timeout

Thanks for looking into this! > On 6 Sep 2023, at 13:16, Fujii Masao wrote: > > While testing v4 patch, I noticed it doesn't handle the COMMIT AND CHAIN case > correctly. > When COMMIT AND CHAIN is executed, I believe the transaction timeout counter > should reset > and start from zero with th

Re: pglz performance

Hi Petr! > 4 авг. 2019 г., в 05:41, Petr Jelinek написал(а): > > Just so that we don't idly talk, what do you think about the attached? > It: > - adds new GUC compression_algorithm with possible values of pglz (default) > and lz4 (if lz4 is compiled in), requires SIGHUP > - adds --with-lz4 conf

Re: [PATCH] Btree BackwardScan race condition on Standby during VACUUM

Hi Michail! Very interesting bug. > 16 марта 2020 г., в 19:07, Michail Nikolaev > написал(а): > > So, I think right way is to lock all three pages as it is done on the > primary. As far as I can see it is not causes any real performance > regression. It seems to me that it's exactly the same

Re: [PATCH] Btree BackwardScan race condition on Standby during VACUUM

> 18 марта 2020 г., в 00:37, Peter Geoghegan написал(а): > > On Mon, Mar 16, 2020 at 10:20 PM Andrey M. Borodin > wrote: >> It seems to me that it's exactly the same check that I was trying to verify >> in amcheck patch [0]. >> But there it was veri

Re: Injection points: preloading and runtime arguments

> 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

Re: Injection points: preloading and runtime arguments

> 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

Re: Issue with the PRNG used by Postgres

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

Re: Allow non-superuser to cancel superuser tasks.

> 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_

Re: What is a typical precision of gettimeofday()?

> 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

Re: datfrozenxid > relfrozenxid w/ crash before XLOG_HEAP_INPLACE

> 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

Re: Allow non-superuser to cancel superuser tasks.

> 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”,

Re: Allow non-superuser to cancel superuser tasks.

> 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. > &

Commitfest manager for July 2024

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

Re: What is a typical precision of gettimeofday()?

> 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,

Re: What is a typical precision of gettimeofday()?

> 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

Re: What is a typical precision of gettimeofday()?

> 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

Re: Commitfest manager for July 2024

> 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: > >

<    1   2   3   4   >