Re: Getting rid of "tuple concurrently updated" elog()s with concurrent DDLs (at least ALTER TABLE)

On December 26, 2017 5:55:03 AM GMT+01:00, Michael Paquier wrote: >Hi all, > >Triggering "tuple concurrently updated" from heapam.c, which is an >elog(), >is not that difficult for some DDL commands. For example with ALTER >ROLE, >just create a role: >psql

Deadlock in multiple CIC.

c3d09b3bd23f5f6 fixed it so concurrent CIC would not deadlock (or at least not as reliably as before) by dropping its own snapshot before waiting for all the other ones to go away. With commit 8aa3e47510b969354ea02a, concurrent CREATE INDEX CONCURRENTLY on different tables in the same database

Getting rid of "tuple concurrently updated" elog()s with concurrent DDLs (at least ALTER TABLE)

Hi all, Triggering "tuple concurrently updated" from heapam.c, which is an elog(), is not that difficult for some DDL commands. For example with ALTER ROLE, just create a role: psql --no-psqlrc -c 'create role popo' And then run that in two sessions and the error will show up, triggered from

Re: AS OF queries

On Thu, Dec 21, 2017 at 3:57 AM, Alvaro Hernandez wrote: > > > On 20/12/17 14:48, Konstantin Knizhnik wrote: > > > > On 20.12.2017 16:12, Laurenz Albe wrote: > > Konstantin Knizhnik wrote: > > I wonder if Postgres community is interested in supporting time travel > queries in

Re: [HACKERS] Replication status in logical replication

On Tue, Dec 26, 2017 at 1:10 AM, Petr Jelinek wrote: > On 21/11/17 22:06, Masahiko Sawada wrote: >> >> After investigation, I found out that my previous patch was wrong >> direction. I should have changed XLogSendLogical() so that we can >> check the read LSN and set

Re: How to Works with Centos

On Mon, Dec 25, 2017 at 06:48:09PM -0500, Jaime Casanova wrote: > so you have two options: > > 1) use the packages from yum.postgresql.org for a supported version > 2) get commercial support for your out-of-community-support verssion > > but even if you do 2, that would be a preparatory step

Re: How to Works with Centos

On 25 December 2017 at 09:39, Benyamin Guedj wrote: > > Upon doing so, our DevOps team in response insisted (and still insists) that > we keep using version 9.2 as it is part of the Centos 7 distribution, and > they believe that version to be “best practice”, even though

How to Works with Centos

Hello, The company I’m working for develops a product which uses Centos 6/7 (different versions of the product) and also uses Vertica and PostgreSQL. During the course of the development of the latest version of our product, we ran into problems that lead us to contact Vertica’s R team, which

Re: PATCH: logical_work_mem and logical streaming of large in-progress transactions

That indeed fixed the problem: running that same pgbench test, I see no crashes anymore (on any of 3 different machines, and with several pgbench parameters). Thank you, Erik Rijkers

Re: Unique indexes & constraints on partitioned tables

Amit Langote wrote: > Have you considered what happens when ON CONFLICT code tries to depend on > such an index (a partitioned unique index)? Not yet, but it was on my list of things to fix. Thanks for working on it -- I'll be reviewing this soon. > +create table parted_conflict_test_2

Re: PATCH: logical_work_mem and logical streaming of large in-progress transactions

On 12/24/2017 10:00 AM, Erik Rijkers wrote: > > logical replication of 2 instances is OK but 3 and up fail with: > > TRAP: FailedAssertion("!(last_lsn < change->lsn)", File: > "reorderbuffer.c", Line: 1773) > > I can cobble up a script but I hope you have enough from

Re: General purpose hashing func in pgbench

Hello, However, the key can be used if controlled so that different values do not have the same randomization in different part of the script, so as to avoid using the same patterns for different things if not desirable. Original murmur algorithm accepts seed as a parameter, which can be

Re: [HACKERS] Replication status in logical replication

On 21/11/17 22:06, Masahiko Sawada wrote: > > After investigation, I found out that my previous patch was wrong > direction. I should have changed XLogSendLogical() so that we can > check the read LSN and set WalSndCaughtUp = true even after read a > record without wait. Attached updated patch

Re: compress method for spgist - 2

Now, this patch is ready for committer from my point of view. Thank you, pushed -- Teodor Sigaev E-mail: teo...@sigaev.ru WWW: http://www.sigaev.ru/

Re: BUGFIX: standby disconnect can corrupt serialized reorder buffers

Hi, thanks for writing the patch. On 05/12/17 06:58, Craig Ringer wrote: > Hi all > > [...] >> The cause appears to be that walsender.c's ProcessRepliesIfAny writes a > LOG for unexpected EOF then calls proc_exit(0). But  serialized txn > cleanup is done by  > ReorderBufferRestoreCleanup, as

Re: General purpose hashing func in pgbench

25/12/2017 17:12, Fabien COELHO пишет: > > However, the key can be used if controlled so that different values do > not have the same randomization in different part of the script, so as > to avoid using the same patterns for different things if not desirable. Original murmur algorithm accepts

Re: genomic locus

I think I can wrangle this type into GiST just by tweaking consistent(), union(), and picksplit(), if I manage to express my needs in C without breaking too many things. My first attempt segfaulted. Actually, consistent() can determ actual query data type by strategy number. See examples in

Re: [HACKERS] Flexible configuration for full-text search

Hi Arthur, Thank you for the review. On Thu, 21 Dec 2017 17:46:42 +0300 Arthur Zakirov wrote: > I noticed that there are typos in the documentation. And I think it > is necessary to keep information about previous sintax. The syntax > will be supported anyway. For

Re: General purpose hashing func in pgbench

Hello Fabien, 24/12/2017 11:12, Fabien COELHO пишет: > > Yep. The ugliness is significantly linked to the choice of name. With > MM2_MUL and MM2_ROT ISTM that it is more readable: > >>     k *= MM2_MUL; >>     k ^= k >> MM2_ROT; >>     k *= MM2_MUL; >>     result ^= k; >>     result *= MM2_MUL;

Re: Unique indexes & constraints on partitioned tables

Hi Alvaro, On 2017/12/23 6:29, Alvaro Herrera wrote: > Hello, > > I'm giving this patch its own thread for mental sanity, but this is > essentially what already posted in [1], plus some doc fixes. This patch > depends on the main "local partitioned indexes" in that thread, last > version of

Re: [HACKERS] Proposal: Local indexes for partitioned table

On 2017/12/25 13:52, Amit Langote wrote: > Hi Alvaro, > > On 2017/12/23 0:10, Alvaro Herrera wrote: >> I believe these are all fixed by the attached delta patch. > > @@ -1676,7 +1694,12 @@ psql_completion(const char *text, int start, int end) > "UNION SELECT

Re: AS OF queries

On 25.12.2017 06:26, Craig Ringer wrote: On 24 December 2017 at 04:53, konstantin knizhnik > wrote: But what if I just forbid to change recent_global_xmin? If it is stalled at FirstNormalTransactionId and never changed?