Re: MultiXact\SLRU buffers configuration

> On 5 Jul 2024, at 14:16, Michael Paquier wrote: > > On Mon, Jun 10, 2024 at 03:10:33PM +0900, Michael Paquier wrote: >> OK, cool. I'll try to get that into the tree once v18 opens up. > > And I've spent more time on this one, and applied it to v18 after some > slight tweaks. Please feel fr

Re: Add GiST support for mixed-width integer operators

> On 5 Jul 2024, at 23:46, Paul Jungwirth wrote: > > this commit adds support for all combinations of int2/int4/int8 for all five > btree operators (=/>). Looks like a nice feature to have. Would it make sense to do something similar to float8? Or, perhaps, some other types from btree_gist?

Re: Add LSN <-> time conversion functionality

Hi! I’m doing another iteration over the patchset. PgStartLSN = GetXLogInsertRecPtr(); Should this be kind of RecoveryEndPtr? How is it expected to behave on Standby in HA cluster, which was doing a crash recovery of 1y WALs in a day, then is in startup for a year as a Hot Standby, and then is

Re: Allow non-superuser to cancel superuser tasks.

> On 10 Jul 2024, at 11:27, Kirill Reshke wrote: > > That's very strange, because the test works fine on my virtual > machine. Also, it seems that it works in Cirrus [0], as there is this > line: So far I could not reproduce that failure. I’ve checkouted 6edec53 from CFbot repository, but it

Re: Amcheck verification of GiST and GIN

Hi Tomas! Thank you so much for your interest in the patchset. > On 10 Jul 2024, at 19:01, Tomas Vondra wrote: > > I realized amcheck GIN/GiST support would be useful for testing my > patches adding parallel builds for these index types, so I decided to > take a look at this and do an initial r

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 your

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 heavy

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

Re: Issue with the PRNG used by Postgres

> On 10 Apr 2024, at 21:48, Parag Paul wrote: > > Yes, the probability of this happening is astronomical, but in production > with 128 core servers with 7000 max_connections, with petabyte scale data, > this did repro 2 times in the last month. We had to move to a local approach > to manage

Re: UUID v7

> On 12 Mar 2024, at 20:41, Jelte Fennema-Nio wrote: > > if e.g. > the RFC got approved 2 weeks after Postgres its feature freeze Jelte, you seem to be the visionary! I would consider participating in lotteries or betting. New UUID is assigned RFC number 9562, it was aproved by RFC editors a

Re: "backend process" confused with "server process"

> 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

Re: plenty code is confused about function level static

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

Re: POC: make mxidoff 64 bits

> 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

Re: broken reading on standby (PostgreSQL 16.2)

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

Re: broken reading on standby (PostgreSQL 16.2)

> On 25 Apr 2024, at 12:06, Pavel Stehule wrote: > > Unfortunately, I have not direct access to backup, so I am not able to test > it. But VACUUM FREEZE DISABLE_PAGE_SKIPPING on master didn't help > If Primary considers all freezable tuples frozen, but a standby does not, "disable page ski

Re: New committers: Melanie Plageman, Richard Guo

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

Re: Weird test mixup

> On 2 May 2024, at 12:27, Michael Paquier wrote: > > On Wed, May 01, 2024 at 04:12:14PM -0700, Noah Misch wrote: >> While writing an injection point test, I encountered a variant of the race >> condition that f4083c4 fixed. It had three sessions and this sequence of >> events: >> >> s1: loc

Re: Weird test mixup

> On 2 May 2024, at 13:43, Michael Paquier wrote: > > A detach is not a wakeup. Oh, now I see. Sorry for the noise. Detaching local injection point of other backend seems to be useless and can be forbidden. As far as I understand, your patch is already doing this in + if (!injection_p

Re: Idea Feedback: psql \h misses -> Offers Links?

> On 17 Apr 2024, at 22:47, Kirk Wolak wrote: > > Thoughts? Today we had a hacking session with Nik and Kirk. We produced a patch to assess how these links might look like. Also we needed a url_encode() and found none in a codebase. It would be nice to have this as an SQL-callable function.

Re: UUID v7

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

Re: UUID v7

> On 3 May 2024, at 11:18, Andrey M. Borodin wrote: > Here's the documentation from ClickHouse [0] for their implementation. It's identical to provided patch in this thread, with few notable exceptions: 1. Counter is 42 bits, not 18. The counter have no guard bi

Re: UUID v7

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

Re: Weird test mixup

> On 10 May 2024, at 06:04, Michael Paquier wrote: > > Attached is an updated patch for now Can you, please, add some more comments regarding purpose of private data? I somewhat lost understanding of the discussion for a week or so. And I hoped to grasp the idea of private_data from resultin

Pre-Commitfest Party on StHighload conf

Hi hackers! StHighload conference will be held on June 24-25[0]. I’m planning to do “Pre-Commitfest Party” there. The idea is to help promote patches among potential reviewers. And start working with the very beginning of PG18 development cycle. Good patch review of a valuable feature is a grea

Re: commitfest.postgresql.org is no longer fit for purpose

> On 16 May 2024, at 23:30, Robert Haas wrote: > I think we just need 10x CFMs. Let’s have a CFM for each CF section. I’d happily take "Replication and Recovery” or “System Administration” for July. “Miscellaneous” or “Performance” look monstrous. I feel I can easily track ~20 threads (besi

Re: commitfest.postgresql.org is no longer fit for purpose

> 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

Re: allow sorted builds for btree_gist

> On 18 May 2024, at 00:41, Tomas Vondra wrote: > > if the opclass supports sorted > builds, because then we could parallelize the sort. Hi Tomas! Yup, I'd also be glad to see this feature. PostGIS folks are using their geometry (sortsupport was developed for this) with object id (this disa

Re: allow sorted builds for btree_gist

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

Sort functions with specialized comparators

Hi! In a thread about sorting comparators[0] Andres noted that we have infrastructure to help compiler optimize sorting. PFA attached PoC implementation. I've checked that it indeed works on the benchmark from that thread. postgres=# CREATE TABLE arrays_to_sort AS SELECT array_shuffle(a) ar

Re: Injection points: preloading and runtime arguments

Hi! > On 20 May 2024, at 08:18, Michael Paquier wrote: Both features look useful to me. I've tried to rebase my test of CV sleep during multixact generation[0]. I used it like this: INJECTION_POINT_PRELOAD("GetNewMultiXactId-done"); multi = GetNewMultiXactId(nmembers, &offset); // star

Re: Injection points: preloading and runtime arguments

> 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

Re: libpq compression (part 3)

> On 20 May 2024, at 22:48, Robert Haas wrote: > > On Mon, May 20, 2024 at 1:23 PM Jacob Champion > wrote: >> On Mon, May 20, 2024 at 10:01 AM Robert Haas wrote: >>> I really hope that you can't poke big enough holes to kill the feature >>> entirely, though. Because that sounds sad. >> >> E

Re: libpq compression (part 3)

> On 20 May 2024, at 23:37, Robert Haas wrote: > > But if that's a practical > attack, preventing compression prior to the authentication exchange > probably isn't good enough: the user could also try to guess what > queries are being sent on behalf of other users through the same > pooled c

Re: Injection points: preloading and runtime arguments

> On 21 May 2024, at 06:31, Michael Paquier wrote: > > So I agree that 0002 ought to call injection_init_shmem() when calling > injection_points_preload(), but it also seems to me that the test is > missing the fact that it should heat the backend cache to avoid the > allocations in the critic

Re: Add LSN <-> time conversion functionality

Hi everyone! Me, Bharath, and Ilya are on patch review session at the PGConf.dev :) Maybe we got everything wrong, please consider that we are just doing training on reviewing patches. === Purpose of the patch === Currently, we have checkpoint_timeout and max_wal size to know when we need a c

Re: Revive num_dead_tuples column of pg_stat_progress_vacuum

> On 4 Jun 2024, at 00:26, Masahiko Sawada wrote: Thank you! Vacuum enhancement is a really good step forward, and this small change would help a lot of observability tools. > On 4 Jun 2024, at 00:49, Peter Geoghegan wrote: > > Can we rename this to num_dead_item_ids (or something similar

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

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 achie

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

Re: Sort functions with specialized comparators

> On 9 Sep 2024, at 02:31, David Rowley wrote: > > Also, unless Andrey is happy for you to tag onto the work he's doing, > I'd suggest another thread for that work. I don't think there's any > good reason for that work to delay Andrey's work. Stepan asked for mentoring project, so I handed hi

Re: Accept invalidation messages before the query starts inside a transaction

> On 12 Sep 2024, at 00:50, Andrei Lepikhov wrote: > > It happens because of documented behaviour [1], which doesn't guarantee > isolation levels for internal access to the system catalogues. As far as I understood you are proposing not isolation guaranties, but allowed isolation anomaly.

Re: Sort functions with specialized comparators

> On 15 Jul 2024, at 12:52, Stepan Neretin wrote: > > > I run benchmark with my patches: > ./pgbench -c 10 -j2 -t1000 -d postgres > > pgbench (18devel) > starting vacuum...end. > transaction type: > scaling factor: 10 > query mode: simple > number of clients: 10 > number of threads: 2 > max

Re: UUID v7

> On 8 May 2024, at 18:37, Andrey M. Borodin wrote: > > It's RFC now. PFA version with references to RFC instead of drafts. In nearby thread [0] we found out that most systems have enough presicion to fill additional 12 bits of sub-millisecond information. So I switched imp

Re: WIP: parallel GiST index builds

Hi Tomas! > On 7 Jun 2024, at 20:41, Tomas Vondra wrote: > > After looking into parallel builds for BRIN and GIN indexes, I was > wondering if there's a way to do parallel builds for GiST too. I knew > next to nothing about how GiST works, but I gave it a shot and here's > what I have - the atta

Re: WIP: parallel GiST index builds

> On 21 Jul 2024, at 23:42, Tomas Vondra wrote: > >> >> 1. Do I get it right that is_parallel argument for gistGetFakeLSN() >> is only needed for assertion? And this assertion can be ensured just >> by inspecting code. Is it really necessary? > > Yes, in the patch it's only used for an asser

Re: WIP: parallel GiST index builds

> On 22 Jul 2024, at 12:26, Tomas Vondra wrote: > > I don't understand how would that solve the problem, can you elaborate? > Which of the values are you suggesting should be replaced with the > shared counter? lastlsn? I think during build we should consider index unlogged and always use Ge

Re: WIP: parallel GiST index builds

> On 22 Jul 2024, at 14:53, Tomas Vondra wrote: > > > > On 7/22/24 13:08, Andrey M. Borodin wrote: >> >> >>> On 22 Jul 2024, at 12:26, Tomas Vondra >>> wrote: >>> >>> I don't understand how would that solve the pr

Re: [PATCH] GROUP BY ALL

> On 24 Jul 2024, at 13:58, Jelte Fennema-Nio wrote: > > On Tue, 23 Jul 2024 at 15:22, Andrei Borodin wrote: >> I'd like to have GROUP BY AUTO (I also proposed version GROUP BY SURPRISE >> ME). But I wouldn't like to open pandora box of syntax sugar extensions >> which may will be incompati

Re: WIP: parallel GiST index builds

> On 26 Jul 2024, at 14:30, Andreas Karlsson wrote: > > I feel the tricky part about doing that is that we need to make sure the fake > LSNs are all less than the current real LSN when the index build completes > and while that normally should be the case we will have a almost never > exerc

Re: UUID v7

> On 24 Jul 2024, at 04:09, Sergey Prokhorenko > wrote: > > Implementations MAY alter the actual timestamp. Hmm… looks like we slightly misinterpreted words about clock source. Well, that’s great, let’s get offset back. PFA version accepting offset interval. It works like this: postgres=# sel

Re: WIP: parallel GiST index builds

> On 30 Jul 2024, at 14:05, Tomas Vondra wrote: > > > > On 7/26/24 14:13, Andrey M. Borodin wrote: >> >> >>> On 26 Jul 2024, at 14:30, Andreas Karlsson wrote: >>> >>> I feel the tricky part about doing that is that we need to make

Re: WIP: parallel GiST index builds

> On 30 Jul 2024, at 14:57, Tomas Vondra wrote: > >> >> How do we synchronize Shared Fake LSN with global XLogCtl->unloggedLSN? Just >> bump XLogCtl->unloggedLSN if necessary? >> Perhaps, consider using GetFakeLSNForUnloggedRel() instead of shared >> counter? As long as we do not care about

Re: Lack of possibility to specify CTAS TAM

> On 31 Jul 2024, at 12:03, Kirill Reshke wrote: > > CREATE TABLE AS USING > (some_access_method) This looks in a line with usual CREATE TABLE. +1 for the feature. Currently we do not have so many TAMs, but I hope eventually we will have some. Best regards, Andrey Borodin.

Re: Add LSN <-> time conversion functionality

This is a copy of my message for pgsql-hackers mailing list. Unfortunately original message was rejected due to one of recipients addresses is blocked. > On 1 Aug 2024, at 10:54, Andrey M. Borodin wrote: > > > >> On 1 Aug 2024, at 05:44, Melanie Plageman wrote: >>

Re: [PATCH] Add min/max aggregate functions to BYTEA

> On 24 Jul 2024, at 17:42, Marat Bukharov wrote: > > V5 patch. I've added more tests with different bytea sizes Hi Marat! This looks like a nice feature to have. I’ve took a look into the patch and have few suggestions: 0. Please write more descriptive commit message akin to [0] 1. Use oid

Re: Injection points: preloading and runtime arguments

> On 18 Jul 2024, at 03:55, Michael Paquier wrote: > > If there is anything else you would like to see adjusted in this area, > please let me know. I’ve tried to switch my multixact test to new INJECTION_POINT_CACHED… and it does not work for me. Could you please take a look? 2024-08-02 18:5

Re: UUID v7

> On 28 Jul 2024, at 23:44, Andrey M. Borodin wrote: > > PFA version accepting offset interval. There was a bug: when time was not moving on, I was updating used time by a nanosecond, instead of 1/4096 of millisecond. V27 fixes that. Thanks! Best regards, Andrey Borodin.

Re: Thoughts about NUM_BUFFER_PARTITIONS

One of our customers recently asked me to look into buffer mapping. Following is my POV on the problem of optimal NUM_BUFFER_PARTITIONS. I’ve found some dead code: BufMappingPartitionLockByIndex() is unused, and unused for a long time. See patch 1. > On 23 Feb 2024, at 22:25, Tomas Vondra wrote

Re: Injection points: preloading and runtime arguments

> On 6 Aug 2024, at 12:47, Michael Paquier wrote: > > Hmm. How about loading injection_points with shared_preload_libraries > now that it has a _PG_init() thanks to 75534436a477 to take care of > the initialization you need here? We could add two hooks to request > some shmem based on a size

Re: asynchronous commit&synchronous replication

> On 10 Aug 2024, at 17:25, Konstantin Knizhnik wrote: > > So should we take in account sync replication in LR apply worker or not? There was some relevant discussion of this topic on PGCon2020 Unconference [0]. My recollection is that it would be nice to have LR slot setting akin to synchro

Re: MultiXact\SLRU buffers configuration

> On 5 Jul 2024, at 23:18, Andrey M. Borodin wrote: > > Alvaro, please find attached the test. > I’ve addressed some Michael’s comments in a nearby thread: removed extra > load, made injection point names lowercase, fixed some grammar issues. I’ve made several runs on

Re: Yet another fast GiST build (typo)

> 1 июля 2020 г., в 17:05, Daniel Gustafsson написал(а): > >> On 29 Feb 2020, at 18:24, Andrey M. Borodin wrote: > >> I've fixed this and added patch with GiST reloption to provide sort support >> function. > > 0002 in this patchset fails to apply,

Re: Yet another fast GiST build (typo)

> 6 июля 2020 г., в 17:55, Andrey M. Borodin написал(а): > > > >> 1 июля 2020 г., в 17:05, Daniel Gustafsson написал(а): >> >>> On 29 Feb 2020, at 18:24, Andrey M. Borodin wrote: >> >>> I've fixed this and added patch with GiST relopti

Re: MultiXact\SLRU buffers configuration

> 2 июля 2020 г., в 17:02, Daniel Gustafsson написал(а): > >> On 15 May 2020, at 02:03, Kyotaro Horiguchi wrote: > >> Generally in such cases, condition variables would work. In the >> attached PoC, the reader side gets no penalty in the "likely" code >> path. The writer side always calls C

Re: Yet another fast GiST build (typo)

> 10 июля 2020 г., в 10:53, Thomas Munro написал(а): > > On Tue, Jul 7, 2020 at 7:03 PM Andrey M. Borodin wrote: >> Oops. I've mismerged docs and did not notice this with check world. PFA v8 >> with fixed docs. > > It looks like point_zorder_internal() ha

Re: recovering from "found xmin ... from before relfrozenxid ..."

Hi! > 14 июля 2020 г., в 02:12, Robert Haas написал(а): > > So I have these questions: > > - Do people think it would me smart/good/useful to include something > like this in PostgreSQL? > > - If so, how? I would propose a new contrib module that we back-patch > all the way My 0.05₽. At Yan

Re: Allow ERROR from heap_prepare_freeze_tuple to be downgraded to WARNING

Hi Dilip! > 17 июля 2020 г., в 15:46, Dilip Kumar написал(а): > > The attached patch allows the vacuum to continue by emitting WARNING > for the corrupted tuple instead of immediately error out as discussed > at [1]. > > Basically, it provides a new GUC called vacuum_tolerate_damage, to > cont

Re: Allow ERROR from heap_prepare_freeze_tuple to be downgraded to WARNING

> 20 июля 2020 г., в 21:44, Alvaro Herrera > написал(а): > >> I think we shall do that in some cases >> but IMHO it's not a very good idea in all the cases. Basically, if >> the xmin precedes the relfrozenxid then probably we should allow to >> update the relfrozenxid whereas if the xmin pre

Re: Amcheck: do rightlink verification with lock coupling

Hi! > 23 янв. 2020 г., в 00:59, Peter Geoghegan написал(а): > > On Fri, Jan 17, 2020 at 5:43 PM Peter Geoghegan wrote: >> I tried to come up with a specific example of how this could be >> unsafe, but my explanation was all over the place (this could have had >> something to do with it being Fr

Re: Allow ERROR from heap_prepare_freeze_tuple to be downgraded to WARNING

> 21 июля 2020 г., в 00:36, Alvaro Herrera > написал(а): > > >> FWIW we coped with this by actively monitoring this kind of corruption >> with this amcheck patch [0]. One can observe this lost page updates >> cheaply in indexes and act on first sight of corruption: identify >> source of the

Allow pg_read_all_stats to read pg_stat_progress_*

Hi! One of our users asked me why they cannot read details of pg_stat_progress_vacuum while they have pg_read_all_stats role. Maybe I'm missing something, but I think they should be able to read stats... PFA fix. This affects pg_stat_progress_analyze, pg_stat_progress_basebackup, pg_stat_progre

Re: Allow pg_read_all_stats to read pg_stat_progress_*

> 15 апр. 2020 г., в 15:25, Magnus Hagander написал(а): > > > I think that makes perfect sense. The documentation explicitly says "can read > all pg_stat_* views", which is clearly wrong -- so either the code or the > docs should be fixed, and it looks like it's the code that should be fixe

Re: Allow pg_read_all_stats to read pg_stat_progress_*

> 16 апр. 2020 г., в 17:46, Magnus Hagander написал(а): > > > If we do that, it may be better that we define "PGSTAT_VIEW_PRIV()" or > something like and replace the all occurances of the idiomatic > condition with it. > > You mean something like the attached? > > Is it correct that we u

Re: Own index methods

Hi! > 5 мая 2020 г., в 17:21, Benjamin Schaller > написал(а): > > Even though it's described as fairly complicated: If I would want to define > my own index method, what would be a good approach to do so? I'm working on presentation describing how to fork AM out of core to extension. Hope to

Re: PG 13 release notes, first draft

> 5 мая 2020 г., в 08:16, Bruce Momjian написал(а): > > I have committed the first draft of the PG 13 release notes. You can > see them here: > > https://momjian.us/pgsql_docs/release-13.html > > It still needs markup, word wrap, and indenting. The community doc > build should happen

Re: PG 13 release notes, first draft

> 7 мая 2020 г., в 04:35, Bruce Momjian написал(а): > > On Wed, May 6, 2020 at 11:17:54AM +0500, Andrey M. Borodin wrote: >> >> >>> 5 мая 2020 г., в 08:16, Bruce Momjian написал(а): >>> >>> I have committed the first draft of the

MultiXact\SLRU buffers configuration

Hi, hackers! *** The problem *** I'm investigating some cases of reduced database performance due to MultiXactOffsetLock contention (80% MultiXactOffsetLock, 20% IO DataFileRead). The problem manifested itself during index repack and constraint validation. Both being effectively full table scans

Re: MultiXact\SLRU buffers configuration

> 8 мая 2020 г., в 21:36, Andrey M. Borodin написал(а): > > *** The problem *** > I'm investigating some cases of reduced database performance due to > MultiXactOffsetLock contention (80% MultiXactOffsetLock, 20% IO DataFileRead). > The problem manifested itself

Re: Our naming of wait events is a disaster.

> 12 мая 2020 г., в 20:16, Tom Lane написал(а): > > Thoughts? > I've been coping with cognitive load of these names recently. 2 cents of my impressions: 1. Names are somewhat recognisable and seem to have some meaning. But there is not so much information about them in the Internet. But I

Re: MultiXact\SLRU buffers configuration

> 11 мая 2020 г., в 16:17, Andrey M. Borodin написал(а): > > I've went ahead and created 3 patches: > 1. Configurable SLRU buffer sizes for MultiXacOffsets and MultiXactMembers > 2. Reduce locking level to shared on read of MultiXactId members > 3. Configurable cache si

Re: MultiXact\SLRU buffers configuration

> 14 мая 2020 г., в 06:25, Kyotaro Horiguchi > написал(а): > > At Wed, 13 May 2020 23:08:37 +0500, "Andrey M. Borodin" > wrote in >> >> >>> 11 мая 2020 г., в 16:17, Andrey M. Borodin >>> написал(а): >>> >>> I&#

Re: MultiXact\SLRU buffers configuration

> 14 мая 2020 г., в 11:16, Kyotaro Horiguchi > написал(а): > > At Thu, 14 May 2020 10:19:42 +0500, "Andrey M. Borodin" > wrote in >>>> I'm looking more at MultiXact and it seems to me that we have a race >>>> condition there. &

Re: MultiXact\SLRU buffers configuration

> 15 мая 2020 г., в 05:03, Kyotaro Horiguchi > написал(а): > > At Thu, 14 May 2020 11:44:01 +0500, "Andrey M. Borodin" > wrote in >>> GetMultiXactIdMembers believes that 4 is successfully done if 2 >>> returned valid offset, but actually that

Re: Yet another fast GiST build

Hi Thomas! Thanks for looking into this! I’ll fix your notices asap. > On 24 февр. 2020 г., at 01:58, Thomas Munro wrote: > > On Thu, Feb 20, 2020 at 10:14 AM Thomas Munro wrote: >> 1. We expect floats to be in IEEE format, and the sort order of IEEE >> floats is mostly correlated to the bina

Re: Yet another fast GiST build

Hi! > On 24 февр. 2020 г., at 13:50, Andrey M. Borodin wrote: > > Hi Thomas! > > Thanks for looking into this! I’ll fix your notices asap. PFA v5. Thomas, I've used your wording almost exactly with explanation how point_zorder_internal() works. It has more explanation po

Re: Yet another fast GiST build (typo)

> On 29 февр. 2020 г., at 17:20, Erik Rijkers wrote: > > Small typo alert: > In v5-0002-Implement-GiST-build-using-sort-support.patch there is: > > + method is also optional and is used diring fast GiST build. > > 'diring' should be 'during' > Thanks! I've fixed this and added patch with

Re: Yet another fast GiST build

> 15 сент. 2020 г., в 16:36, Heikki Linnakangas написал(а): > > Another patch version, fixed a few small bugs pointed out by assertion > failures in the regression tests. > > - Heikki > These changes in create_index.out do not seem correct to me SELECT * FROM point_tbl ORDER BY f1 <-> '0

Re: Yet another fast GiST build

> 15 сент. 2020 г., в 22:07, Heikki Linnakangas написал(а): > > regression=# SELECT f1, f1 <-> '0,1' FROM point_tbl ORDER BY f1 <-> '0,1'; >f1 | ?column? > ---+-- > (0,0) |1 > (1e-300,-1e-300) |1

Re: Yet another fast GiST build

> 17 сент. 2020 г., в 13:38, Heikki Linnakangas написал(а): > > On 15/09/2020 14:36, Heikki Linnakangas wrote: >> Another patch version, fixed a few small bugs pointed out by assertion >> failures in the regression tests. > > Pushed. Thanks everyone! That's wonderful! Thank you, Heikki! Bes

Re: Concurrency issue in pg_rewind

> 18 сент. 2020 г., в 11:10, Michael Paquier написал(а): > > On Thu, Sep 17, 2020 at 10:20:16AM +0200, Oleksandr Shulgin wrote: >> Ouch. I think pg_rewind shouldn't try to remove any random files in pg_wal >> that it doesn't know about. >> What if the administrator made a backup of some WAL s

Re: Concurrency issue in pg_rewind

> 18 сент. 2020 г., в 11:59, Michael Paquier написал(а): > > On Fri, Sep 18, 2020 at 11:31:26AM +0500, Andrey M. Borodin wrote: >> This is whole point of having prefetch. restore_command just links >> file from the same partition. > > If this stuff is willing

Batching page logging during B-tree build

Hi! There's a thread about GiST build [0]. And we've found out there that logging newly created index with batches of 32 pages is slightly faster. Heikki implemented new logging routine log_newpages() for GiST build and it makes code for this batching nice and clean. Here is PoC with porting th

Re: Yet another fast GiST build

> 21 сент. 2020 г., в 13:45, Heikki Linnakangas написал(а): > > On 21/09/2020 11:08, Heikki Linnakangas wrote: >> I think they need to, so that they can stamp the page with the LSN of >> the WAL record. But GiST build is special in that regard, because it >> stamps all pages with GistBuildLSN.

Re: Yet another fast GiST build

> 21 сент. 2020 г., в 17:15, Heikki Linnakangas написал(а): > > On 21/09/2020 12:06, Andrey M. Borodin wrote >> >> I think we don't set rightlinks during index build. > > The new GiST sorting code does not, but the regular insert-based code does. > >

Re: Yet another fast GiST build

> 21 сент. 2020 г., в 18:29, Andrey M. Borodin > написал(а): > > It was a conscious decision with incorrect motivation. I was thinking that it > will help to reduce number of "false positive" inspecting right pages. But > now I see that: > 1. There should be

Re: MultiXact\SLRU buffers configuration

Hi, Anastasia! > 28 авг. 2020 г., в 23:08, Anastasia Lubennikova > написал(а): > > 1) The first patch is sensible and harmless, so I think it is ready for > committer. I haven't tested the performance impact, though. > > 2) I like the initial proposal to make various SLRU buffers configurable

Re: Yet another fast GiST build

> 28 сент. 2020 г., в 13:12, Heikki Linnakangas написал(а): > > On 21/09/2020 17:19, Andrey M. Borodin wrote: >>> 21 сент. 2020 г., в 18:29, Andrey M. Borodin >>> написал(а): >>> >>> It was a conscious decision with incorrect motivation. I

<    1   2   3   4   >