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

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

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

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

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

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

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

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.

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

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

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

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 what

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:

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'

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

> 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

Re: Transaction timeout

> 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

Re: Injection points: some tools to wait and wake

> 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

Re: Transaction timeout

> 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

Re: Injection points: some tools to wait and wake

> 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

Re: Transaction timeout

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

Re: glibc qsort() vulnerability

> 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

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

> 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

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

> 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

Re: MultiXact\SLRU buffers configuration

> 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

Re: UUID v7

> 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

Re: UUID v7

> 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

Re: UUID v7

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

Re: Transaction timeout

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

Re: UUID v7

> 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

Re: MultiXact\SLRU buffers configuration

> 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

Re: Transaction timeout

> 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

Re: Transaction timeout

> 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

Re: UUID v7

> 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

Re: UUID v7

> 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

Re: UUID v7

> 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

Re: UUID v7

> 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

Re: UUID v7

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

Re: UUID v7

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

Re: UUID v7

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

Re: [PATCH] Add sortsupport for range types and btree_gist

> 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

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

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 "

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 COMMIT AND CH

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 permutations.Looking thro

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

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

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

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,

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

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

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

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

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

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

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

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

> 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

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

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

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

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

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

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

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

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

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

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 >

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

> On 20 Aug 2023, at 23:56, Andrey M. Borodin wrote: > > I've observed, that pre-generating and buffering random numbers makes UUID generation 10 times faster. Without buffering postgres=# with x as (select gen_uuid_v7() from generate_series(1,1e6)) select count(*) from x; Time:

Re: UUID v7

> On 30 Jul 2023, at 13:08, Andrey M. Borodin wrote: > > > After discussion on GitHub with Sergey Prokhorenko [0] I understood that > counter is optional, but useful part of UUID v7. It actually promotes > sortability of data generated at high speed. > The standard doe

Re: libpq compression (part 2)

> On 10 Aug 2023, at 19:47, Jonah H. Harris wrote: > > Pinging to see if anyone has continued to work on this behind-the-scenes or > whether this is the latest patch set there is. It's still on my TODO list, but I haven't done much review cycles yet. And the patch series already needs

Re: UUID v7

On 10 Jul 2023, at 21:50, Peter Eisentraut wrote:I suggest we keep this thread to v7, which has pretty straightforward semantics for PostgreSQL.  v8 by definition has many possible implementations, so you're going to have to make pretty strong arguments that

Re: UUID v7

> On 6 Jul 2023, at 21:38, Peter Eisentraut > wrote: > > I think it would be reasonable to review this patch now. +1. Also, I think we should discuss UUID v8. UUID version 8 provides an RFC-compatible format for experimental or vendor-specific use cases. Revision 1 of IETF draft contained

Re: pg_upgrade instructions involving "rsync --size-only" might lead to standby corruption?

Fast upgrade of highly available cluster is a vital part of being industry-acceptable solution for any data management system. Because the cluster is required to be highly available. Without this documented technique upgrade of 1Tb cluster would last many hours, not seconds. There are industry

Re: Bypassing shared_buffers

Hi! > On 15 Jun 2023, at 03:57, Vladimir Churyukin wrote: > > Hello, > > There is often a need to test particular queries executed in the worst-case > scenario, i.e. right after a server restart or with no or minimal amount of > data in shared buffers. In Postgres it's currently hard to

Add some more corruption error codes to relcache

Hi hackers, Relcache errors from time to time detect catalog corruptions. For example, recently I observed following: 1. Filesystem or nvme disk zeroed out leading 160Kb of catalog index. This type of corruption passes through data_checksums. 2. RelationBuildTupleDesc() was failing with

Re: psql: Could we get "-- " prefixing on the **** QUERY **** outputs? (ECHO_HIDDEN)

> On 18 May 2023, at 02:23, Kirk Wolak wrote: > > I labelled this v2. +1 to the feature and the patch looks good to me. I have a question, but mostly for my own knowledge. Translation changes seem trivial for all languages, do we typically fix .po files in such cases? Or do we leave it

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

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

<    1   2   3   >