Re: Amcheck: do rightlink verification with lock coupling

> 8 авг. 2020 г., в 23:14, Peter Geoghegan написал(а): > > I pushed a cleaned up version of this patch just now. I added some > commentary about this canonical example in header comments for the new > function. Thanks for working on this! Best regards, Andrey Borodin.

Re: Unnecessary delay in streaming replication due to replay lag

I would like to revive this thready by submitting a rebased patch to start streaming replication without waiting for startup process to finish replaying all WAL. The start LSN for streaming is determined to be the LSN that points to the beginning of the most recently flushed WAL segment. The p

Re: Allow some recovery parameters to be changed with reload

On Wed, Aug 05, 2020 at 11:41:49AM -0400, Robert Haas wrote: > On Sat, Mar 28, 2020 at 7:21 AM Sergei Kornilov wrote: >> So... >> We call restore_command only when walreceiver is stopped. >> We use restore_command only in startup process - so we have no race >> condition between processes. >> We

Re: 回复：how to create index concurrently on partitioned table

On Sat, Aug 08, 2020 at 01:37:44AM -0500, Justin Pryzby wrote: > That gave me the idea to layer CIC on top of Reindex, since I think it does > exactly what's needed. For now, I would recommend to focus first on 0001 to add support for partitioned tables and indexes to REINDEX. CIC is much more co

Re: LSM tree for Postgres

On Sat, Aug 8, 2020 at 11:49 PM Konstantin Knizhnik wrote: > On 08.08.2020 21:18, Alexander Korotkov wrote: > > On Sat, Aug 8, 2020 at 5:07 PM Konstantin Knizhnik > > wrote: > >> I agree with your that loosing sequential order of B-Tree pages may have > >> negative impact on performance. > >> But

Re: LSM tree for Postgres

On 08.08.2020 21:18, Alexander Korotkov wrote: On Sat, Aug 8, 2020 at 5:07 PM Konstantin Knizhnik wrote: I agree with your that loosing sequential order of B-Tree pages may have negative impact on performance. But it first of all critical for order-by and range queries, when we should traver

2020-08-13 Update + PostgreSQL 13 Beta 3 Release Announcement Draft

Hi, Attached is a draft of the release announcement for the update release on 2020-08-13, which also includes the release of PostgreSQL 13 Beta 3. Reviews and feedback are welcome. This is a fairly hefty release announcement as it includes notes both about the update release and the beta. I tried

Re: LSM tree for Postgres

On Sat, Aug 8, 2020 at 5:07 PM Konstantin Knizhnik wrote: > I agree with your that loosing sequential order of B-Tree pages may have > negative impact on performance. > But it first of all critical for order-by and range queries, when we > should traverse several subsequent leave pages. > It is le

Re: Amcheck: do rightlink verification with lock coupling

On Thu, Aug 6, 2020 at 10:59 PM Andrey M. Borodin wrote: > But having complete solution with no false positives seems much better. Agreed. I know that you didn't pursue this for no reason -- having the check available makes bt_check_index() a lot more valuable in practice. It detects what is actu

Re: walsender waiting_for_ping spuriously set

Pushed. -- Álvaro Herrerahttps://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Re: Replace remaining StrNCpy() by strlcpy()

Peter Eisentraut writes: > I removed namecpy() altogether because you can just use struct assignment. Makes sense, and I notice it was unused anyway. v3 passes eyeball examination (I didn't bother running tests), with only one remaining nit: the proposed commit message says They are equ

Re: get rid of distprep?

Peter Eisentraut writes: > I'm thinking about whether we should get rid of the distprep target, ... > Who benefits from these prebuilt files? I doubt anyone actually has > problems obtaining useful installations of bison, flex, or perl. I'm sure it was a bigger issue twenty years ago, but yeah

Re: LSM tree for Postgres

On 07.08.2020 15:31, Alexander Korotkov wrote: ср, 5 авг. 2020 г., 09:13 Konstantin Knizhnik : Concerning degrade of basic index - B-Tree itself is balanced tree. Yes, insertion of random keys can cause split of B-Tree page. In the worst case half of B-Tree page will be empty. So B-Tree size

Re: [Patch] Optimize dropping of relation buffers using dlist

On Fri, Aug 7, 2020 at 11:03 PM Robert Haas wrote: > > On Fri, Aug 7, 2020 at 12:52 PM Tom Lane wrote: > > At least in the case of segment zero, the file will still exist. It'll > > have been truncated to zero length, and if the filesystem is stupid about > > holes in files then maybe a write to

Re: [Patch] Optimize dropping of relation buffers using dlist

On Fri, Aug 7, 2020 at 9:33 AM Tom Lane wrote: > > Amit Kapila writes: > > On Sat, Aug 1, 2020 at 1:53 AM Andres Freund wrote: > >> We could also just use pg_class.relpages. It'll probably mostly be > >> accurate enough? > > > Don't we need the accurate 'number of blocks' if we want to invalidat

Re: [PATCH] Covering SPGiST index

> 7 авг. 2020 г., в 16:59, Pavel Borisov написал(а): > > As usual I very much appreciate your feedback Thanks for the patch! Looks interesting. On a first glance the whole concept of non-multicolumn index with included attributes seems...well, just difficult to understand. But I expect for

Re: Should the nbtree page split REDO routine's locking work more like the locking on the primary?

> 8 авг. 2020 г., в 03:28, Peter Geoghegan написал(а): > > On Thu, Aug 6, 2020 at 7:00 PM Peter Geoghegan wrote: >> On Thu, Aug 6, 2020 at 6:08 PM Tom Lane wrote: >>> +1 for making this more like what happens in original execution ("on the >>> primary", to use your wording). Perhaps what yo

get rid of distprep?

I'm thinking about whether we should get rid of the distprep target, the step in the preparation of the official source tarball that creates a bunch of prebuilt files using bison, flex, perl, etc. for inclusion in the tarball. I think this concept is no longer fitting for contemporary software