Re: [HACKERS] advanced partition matching algorithm for partition-wise join

On 2018/06/26 18:02, Ashutosh Bapat wrote: > On Tue, Jun 26, 2018 at 2:27 PM, Amit Langote > wrote: >> Hi Ashutosh, >> >> On 2018/05/14 20:14, Ashutosh Bapat wrote: >>> 0001-Hash-partition-bound-equality-refactoring.patch >>> 0002-Targetlist-of-a-child-join-is-produced-by-translatin.patch >>> 0003

Re: Portability concerns over pq_sendbyte?

Hi, On 2018-06-14 13:25:30 -0700, Andres Freund wrote: > On 2018-06-14 16:17:28 -0400, Tom Lane wrote: > > Alvaro Herrera writes: > > > How about not renaming the functions, but just change argument types? > > Yea, I'm in favor of this. I don't think the 'u' in there would benefit > us, and the

Re: postgresql_fdw doesn't handle defaults correctly

On 2018/06/27 15:33, Pavel Stehule wrote: >>> Unfortunately, when I use identity column >>> >>> create table foo(a int GENERATED BY DEFAULT AS IDENTITY PRIMARY KEY, b >> date >>> default current_date, c int); >>> >>> then import doesn't fail, but still it doesn't work >> >> It seems that, unlike DE

Re: Constraint documentation

On 6/26/18 09:49, Lætitia Avrot wrote: > + > + > + Check constraints are not designed to enforce business rules across > tables. > + Avoid using check constraints with a function accessing other tables and > + use instead. Although PostgreSQL won't > prevent you > + from d

Re: [WIP] [B-Tree] Retail IndexTuple deletion

On 23.06.2018 00:43, Peter Geoghegan wrote: On Fri, Jun 22, 2018 at 4:24 AM, Andrey V. Lepikhov wrote: According to your feedback, i develop second version of the patch. In this version: 1. High-level functions index_beginscan(), index_rescan() not used. Tree descent made by _bt_search(). _bt

Re: postgresql_fdw doesn't handle defaults correctly

2018-06-27 8:28 GMT+02:00 Amit Langote : > On 2018/06/27 2:47, Pavel Stehule wrote: > > 2018-06-25 4:30 GMT+02:00 Amit Langote : > >> It seems you missed using OPTIONS (import_default 'true') here. > >> > >> create schema foo; > >> create table foo.foo (a serial primary key, b date default current

libpq example doesn't work

Hi, When I tried to use libpq, I found that libpq example[1] does not work. That's because SELECT pg_catlog.set_config() never returns PGRES_COMMAND_OK which is expected, but actually returns PGRES_TUPLES_OK. Patch attached. I changed both src/test/example and document. [1] https://www.postgr

Re: postgresql_fdw doesn't handle defaults correctly

On 2018/06/27 2:47, Pavel Stehule wrote: > 2018-06-25 4:30 GMT+02:00 Amit Langote : >> It seems you missed using OPTIONS (import_default 'true') here. >> >> create schema foo; >> create table foo.foo (a serial primary key, b date default current_date >> not null, c int); >> >> import foreign schema

Re: ssl_library parameter

On 6/26/18 17:48, Tom Lane wrote: > (1) I'm not really clear why we need this. GUC variables aren't free. > > (2) Are there security issues with exposing this info to everybody? This functionality was requested in the threads about GnuTLS and other SSL implementations so that users/admins can de

Re: Typo in llvm_function_reference

Hi, On 2018-06-27 10:46:35 +0530, Rushabh Lathia wrote: > There is multiple return statement in llvm_function_reference > and that's definitely looks typo. Here is the patch to fix the > same. > diff --git a/src/backend/jit/llvm/llvmjit.c b/src/backend/jit/llvm/llvmjit.c > index daae964..5d0cdab

commitfest app moving patch error

I tried to move a patch from 2018-07 to 2018-09 and got this error: "Cannot move patch to the same commitfest, and multiple future commitfests exist!" -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Re: [HACKERS] GnuTLS support

On 3/8/18 20:13, Peter Eisentraut wrote: > In the thread about Secure Transport we agreed to move the consideration > of new SSL libraries to PG12. > > Here is my current patch, after all the refactorings. > > The status is that it works fine and could be used. > > There are two failures in the

Re: Server crashed with TRAP: FailedAssertion("!(parallel_workers > 0)" when partitionwise_aggregate true.

On Fri, Jun 22, 2018 at 6:58 PM, Robert Haas wrote: > On Fri, Jun 22, 2018 at 2:26 AM, Rajkumar Raghuwanshi > wrote: > > I have applied patch and checked reported issue. Patch applied cleanly > and > > issues not reproducible any more. > > Committed, with a few changes: > Thanks Robert. > > -

Re: partitioning - changing a slot's descriptor is expensive

On 2018/06/27 14:55, Andres Freund wrote: > On 2018-06-27 14:46:26 +0900, Amit Langote wrote: >> There is however similar code that runs in non-error paths, such as in >> ExecPrepareTupleRouting(), that is executed *if* the leaf partition and >> the root parent have differing attribute numbers. So

Re: Thinko/typo in ExecSimpleRelationInsert

On Wed, Jun 27, 2018 at 11:24 AM, Amit Kapila wrote: >> >> I don't understand what do you mean by consistent. Do you mean to say >> that current usage " Store the slot into tuple ... " is correct? >> > > Oh no, I was talking about replacing it with below comment which is > used at other places in

Re: unexpected relkind: 73 ERROR with partition table index

Thanks for fix and commit. It is working fine now. Thanks & Regards, Rajkumar Raghuwanshi QMG, EnterpriseDB Corporation On Tue, Jun 26, 2018 at 8:39 PM, Alvaro Herrera wrote: > On 2018-Jun-27, David Rowley wrote: > > > On 27 June 2018 at 00:18, Rajkumar Raghuwanshi > > wrote: > > > postgres=>

Re: partitioning - changing a slot's descriptor is expensive

On 2018-06-27 14:46:26 +0900, Amit Langote wrote: > Hi Andres, > > On 2018/06/27 14:09, Andres Freund wrote: > > Hi, > > > > (sorry if I CCed the wrong folks, the code has changed a fair bit) > > > > I noticed that several places in the partitioning code look like: > > > > /* > > * If

Re: Thinko/typo in ExecSimpleRelationInsert

On Wed, Jun 27, 2018 at 10:09 AM, Ashutosh Bapat wrote: > On Tue, Jun 26, 2018 at 8:43 PM, Amit Kapila wrote: >> On Tue, Jun 26, 2018 at 7:02 PM, Ashutosh Bapat >> wrote: >>> On Tue, Jun 26, 2018 at 6:18 PM, Amit Kapila >>> wrote: On Tue, Jun 26, 2018 at 4:33 PM, Ashutosh Bapat wrot

Re: partitioning - changing a slot's descriptor is expensive

Hi Andres, On 2018/06/27 14:09, Andres Freund wrote: > Hi, > > (sorry if I CCed the wrong folks, the code has changed a fair bit) > > I noticed that several places in the partitioning code look like: > > /* > * If the tuple has been routed, it's been converted to the > * partition

Re: Excessive PostmasterIsAlive calls slow down WAL redo

On Wed, Apr 25, 2018 at 6:23 PM, Thomas Munro wrote: > On Tue, Apr 24, 2018 at 7:37 PM, Michael Paquier wrote: >> Thomas, trying to understand here... Why this place for the signal >> initialization? Wouldn't InitPostmasterChild() be a more logical place >> as we'd want to have this logic caugh

Typo in llvm_function_reference

Hi, There is multiple return statement in llvm_function_reference and that's definitely looks typo. Here is the patch to fix the same. Thanks, Rushabh Lathia www.EnterpriseDB.com diff --git a/src/backend/jit/llvm/llvmjit.c b/src/backend/jit/llvm/llvmjit.c index daae964..5d0cdab 100644 --- a/src/b

partitioning - changing a slot's descriptor is expensive

Hi, (sorry if I CCed the wrong folks, the code has changed a fair bit) I noticed that several places in the partitioning code look like: /* * If the tuple has been routed, it's been converted to the * partition's rowtype, which might differ from the root * table's. We must co

Re: Thinko/typo in ExecSimpleRelationInsert

On Tue, Jun 26, 2018 at 8:43 PM, Amit Kapila wrote: > On Tue, Jun 26, 2018 at 7:02 PM, Ashutosh Bapat > wrote: >> On Tue, Jun 26, 2018 at 6:18 PM, Amit Kapila wrote: >>> On Tue, Jun 26, 2018 at 4:33 PM, Ashutosh Bapat >>> wrote: Looks like we need similar adjustment in ExecSimpleRelationUp

Re: Speedup of relation deletes during recovery

On Wed, Jun 27, 2018 at 4:17 PM, Andres Freund wrote: > On 2018-06-27 15:56:58 +1200, Thomas Munro wrote: >> Without range-scannable buffer mapping (Andres's radix tree thing), >> that bet doesn't work out too well when you do it more than once. >> Hmm... we could just... not do that? > > That'd p

Re: Speedup of relation deletes during recovery

Hi, On 2018-06-27 15:56:58 +1200, Thomas Munro wrote: > That's a different code path that eats a lot of CPU on the *primary*, because: While that's obviously not great, I think it's far less dangerous than the standby having worse complexity than the primary. There's an obvious backpressure if co

Re: [WIP] [B-Tree] Retail IndexTuple deletion

On 26.06.2018 15:31, Masahiko Sawada wrote: On Fri, Jun 22, 2018 at 8:24 PM, Andrey V. Lepikhov wrote: Hi, According to your feedback, i develop second version of the patch. In this version: 1. High-level functions index_beginscan(), index_rescan() not used. Tree descent made by _bt_search()

Re: Speedup of relation deletes during recovery

On Wed, Jun 27, 2018 at 1:46 PM, Andres Freund wrote: > On 2018-06-27 13:44:03 +1200, Thomas Munro wrote: >> On further reflection, on the basis that it's the most conservative >> change, +1 for Fujii-san's close-in-reverse-order idea. We should >> reconsider that data structure for 12; there doe

Re: Is PG built on any C compilers where int division floors?

Chapman Flack writes: > Do PG's operators just do what the underlying C compiler generates? Yes. This is generally true for both the int and float operators. regards, tom lane

Re: Is PG built on any C compilers where int division floors?

On 06/24/18 23:38, Tom Lane wrote: > Chapman Flack writes: >> C99 finally pinned down what / does on signed ints, truncating toward zero. >> Before that, it could truncate toward zero, or floor toward -inf. >> Is PostgreSQL built on any compilers/platforms that have the floor >> behavior? > > I'm

Re: Speedup of relation deletes during recovery

On 2018-06-27 13:44:03 +1200, Thomas Munro wrote: > On further reflection, on the basis that it's the most conservative > change, +1 for Fujii-san's close-in-reverse-order idea. We should > reconsider that data structure for 12; there doesn't seems to be a > good reason to carry all those comments

Re: Speedup of relation deletes during recovery

On Wed, Jun 27, 2018 at 1:13 PM, Thomas Munro wrote: > On Wed, Jun 27, 2018 at 12:16 PM, Thomas Munro > wrote: >> I think we should take the hint in the comments and make it O(1) >> anyway. See attached draft patch. > > Alternatively, here is a shorter and sweeter dlist version (I did the > open

Re: Speedup of relation deletes during recovery

On Wed, Jun 27, 2018 at 12:16 PM, Thomas Munro wrote: > I think we should take the hint in the comments and make it O(1) > anyway. See attached draft patch. Alternatively, here is a shorter and sweeter dlist version (I did the open-coded one thinking of theoretical back-patchability). -- Thoma

Re: Speedup of relation deletes during recovery

On Fri, Jun 22, 2018 at 5:41 AM, Andres Freund wrote: > On 2018-06-21 14:40:58 +0900, Michael Paquier wrote: >> On Wed, Jun 20, 2018 at 08:43:11PM -0700, Andres Freund wrote: >> > On 2018-06-18 11:13:47 -0700, Andres Freund wrote: >> >> We could do that - but add_to_unowned_list() is actually a bo

Re: Name of main process differs between servers (postmaster vs postgres)

On Tue, Jun 26, 2018 at 2:51 PM, Jonathan Lemig wrote: > From what I can tell, things are running fine on both servers, I guess I > just don't like there is a difference/inconsistency. Can anyone please > explain this? > > ​Best guess, one of the servers has upgrades from previous versions appli

Re: Name of main process differs between servers (postmaster vs postgres)

On Tue, Jun 26, 2018 at 04:51:32PM -0500, Jonathan Lemig wrote: > Hi, > > I noticed on two of my postgres servers, one has "postmaster" for the main > process, and the other has "postgres". My question is - why is this? For > example: On my centos6 servers: 1518140 lrwxrwxrwx 1 root

Re: Query Rewrite for Materialized Views (Postgres Extension)

Hi Nico, By the way, I do agree with your point about MERGE — if we can factor MV updates in that fashion, it will certainly save. I didn’t reply immediately because your point caught me off guard: > […] If you look at my > sketch for how to do it, you'll notice that many of the sorts of queri

Name of main process differs between servers (postmaster vs postgres)

Hi, I noticed on two of my postgres servers, one has "postmaster" for the main process, and the other has "postgres". My question is - why is this? For example: Server1: postgres 909 1 0 May08 ?00:03:55 /usr/pgsql-9.6/bin/postmaster -D /var/lib/pgsql/9.6/data/ Server2: postgre

Re: wrong query result with jit_above_cost= 0

On 2018-06-26 21:55:07 +0100, Andrew Gierth wrote: > > "Dmitry" == Dmitry Dolgov <9erthali...@gmail.com> writes: > > Dmitry> Yep, my bad, forgot to turn it on. Now I see what's the > Dmitry> problem, one of the null fields is screwed up, will try to > Dmitry> figure out why is that. > > Th

Re: wrong query result with jit_above_cost= 0

> "Dmitry" == Dmitry Dolgov <9erthali...@gmail.com> writes: Dmitry> Yep, my bad, forgot to turn it on. Now I see what's the Dmitry> problem, one of the null fields is screwed up, will try to Dmitry> figure out why is that. The handling of nulls in grouping set results is a bit icky, see pr

Re: [HACKERS] [PATCH] WIP Add ALWAYS DEFERRED option for constraints

Nico Williams writes: > [Re-send; first attempt appears to have hit /dev/null somewhere. My > apologies if you get two copies.] > > I've finally gotten around to rebasing this patch and making the change > that was requested, which was: merge the now-would-be-three deferral- > related bool colum

Re: Fix slot's xmin advancement and subxact's lost snapshots in decoding.

Pushed this to 9.4 - master after some more tinkering. It occurred to me that it might be better to have ReorderBufferSetBaseSnapshot do the IncrRefCount instead of expecting caller to do it. But I wouldn't backpatch that change, so I refrained. Thanks for the patch. -- Álvaro Herrera

Re: found xmin from before relfrozenxid on pg_catalog.pg_authid

Hackers, felt like reporting this relevant tidbit in case of interest... My site is among the few who've hit this bug. We observed recently a case of pg_database having joined pg_authid and pg_auth_members in the bad xmin, unable to vacuum shcatalog group, however... pg_database then started wor

Re: [bug fix] ECPG: freeing memory for pgtypes crashes on Windows

From: Thomas Munro > Ok, back-patched. Thank you very much! > It seems like the other patch[1] might need the same treatment, right? I believe so, because that patch is based on the same cause. Regards MauMau

Re: wrong query result with jit_above_cost= 0

> On 26 June 2018 at 22:11, Andres Freund wrote: > On 2018-06-26 22:09:10 +0200, Dmitry Dolgov wrote: >> > On 26 June 2018 at 20:23, Andres Freund wrote: >> > Hi, >> > >> > On 2018-06-26 23:50:32 +0530, Rushabh Lathia wrote: >> >> I found the below query which returns the wrong output >> >> when

Re: wrong query result with jit_above_cost= 0

On 2018-06-26 22:09:10 +0200, Dmitry Dolgov wrote: > > On 26 June 2018 at 20:23, Andres Freund wrote: > > Hi, > > > > On 2018-06-26 23:50:32 +0530, Rushabh Lathia wrote: > >> I found the below query which returns the wrong output > >> when jit_above_cost= 0 is set. > >> > >> Steps to reproduce: >

Re: wrong query result with jit_above_cost= 0

> On 26 June 2018 at 20:23, Andres Freund wrote: > Hi, > > On 2018-06-26 23:50:32 +0530, Rushabh Lathia wrote: >> I found the below query which returns the wrong output >> when jit_above_cost= 0 is set. >> >> Steps to reproduce: >> >> CREATE TABLE emp ( >> epno NUMERIC(4), >> ena

Re: Fix slot's xmin advancement and subxact's lost snapshots in decoding.

Alvaro Herrera writes: > I'm struggling with this assert. I find that test_decoding passes tests > with this assertion in branch master, but fails in 9.4 - 10. Maybe I'm > running the tests wrong (no assertions in master?) but I don't see it. > It *should* fail ... Your v3 patch fails for me

Re: Constraint documentation

On Tue, Jun 26, 2018 at 4:24 AM, Vik Fearing wrote: > Looks good to me. I'll second that. Looks good to me too.

Re: Unexpected behavior of DROP VIEW/TABLE IF EXISTS

On Tue, Jun 26, 2018 at 10:06 AM, Tom Lane wrote: > Pavel Stehule writes: > > 2018-06-26 18:22 GMT+02:00 David G. Johnston >: > >>> So I am not sure, if proposed change is practical because views and > >>> tables shares same namespace and current behave has sense too. > > >> I'm doubtful that t

Re: effect of JIT tuple deform?

On 2018-06-26 21:25:54 +0200, Pavel Stehule wrote: > Hi > > I played with it and maybe I got interesting result. > > When I played with really big table, then I got IO waits and effect of > jit_tuple_deforming is near to zero (as expected) > > When I played with smaller table under RAM, then I c

Re: effect of JIT tuple deform?

Hi I played with it and maybe I got interesting result. When I played with really big table, then I got IO waits and effect of jit_tuple_deforming is near to zero (as expected) When I played with smaller table under RAM, then I can see positive effect of JIT_TD, but only when optimization is act

Re: Fix slot's xmin advancement and subxact's lost snapshots in decoding.

On 2018-Jun-26, Arseny Sher wrote: > Alvaro Herrera writes: > > * I'm a bit unsure about the comment atop ReorderBufferSetBaseSnapshot. > > Obviously, the bit within the #if 0/#endif I'm going to remove before > > push. > > It looks like you've started editing that bit and didn't finish. Y

Re: wrong query result with jit_above_cost= 0

Hi, On 2018-06-26 23:50:32 +0530, Rushabh Lathia wrote: > I found the below query which returns the wrong output > when jit_above_cost= 0 is set. > > Steps to reproduce: > > CREATE TABLE emp ( > epno NUMERIC(4), > ename VARCHAR(10), > job VARCHAR(9), >

wrong query result with jit_above_cost= 0

Hi, I found the below query which returns the wrong output when jit_above_cost= 0 is set. Steps to reproduce: CREATE TABLE emp ( epno NUMERIC(4), ename VARCHAR(10), job VARCHAR(9), mgr NUMERIC(4), hiredateDATE, sal

Re: postgresql_fdw doesn't handle defaults correctly

Hi 2018-06-25 4:30 GMT+02:00 Amit Langote : > Hi. > > On 2018/06/24 2:23, Pavel Stehule wrote: > > Hi > > > > I have a table boo > > > > create table boo(id serial primary key, inserted date default > current_date, > > v varchar); > > > > I imported this table via simple > > > > IMPORT FOREIGN SC

Re: Global shared meta cache

Hi, On 2018-06-26 06:48:28 +, Ideriha, Takeshi wrote: > > I think it would be interested for somebody to build a prototype here > > that ignores all the problems but the first and uses some > > straightforward, relatively unoptimized locking strategy for the first > > problem. Then benchmark i

Re: Unexpected behavior of DROP VIEW/TABLE IF EXISTS

Pavel Stehule writes: > 2018-06-26 18:22 GMT+02:00 David G. Johnston : >>> So I am not sure, if proposed change is practical because views and >>> tables shares same namespace and current behave has sense too. >> I'm doubtful that there is any meaningful technical/practical challenge >> involved

RE: Global shared meta cache

Takeshi-san, >My customer created hundreds of thousands of partition tables and tried to >select data from hundreds of applications, >which resulted in enormous consumption of memory because it consumed # of >backend multiplied by # > of local memory (ex. 100 backends X 1GB = 100GB). >Relation

Re: Unexpected behavior of DROP VIEW/TABLE IF EXISTS

On Tuesday, June 26, 2018, Pavel Stehule wrote: > > Just I don't see this proposal as clean win. More it is not limited only > this case. It should be consistent with DROP INDEX, SEQUENCE, ... > Yes, they are likely all broken in the same way and whomever agrees with the "it's bugged" conclusion

Re: Unexpected behavior of DROP VIEW/TABLE IF EXISTS

2018-06-26 18:22 GMT+02:00 David G. Johnston : > On Tuesday, June 26, 2018, Pavel Stehule wrote: >> >> My note is related to @b. I understand to the motivation, but I am not >> sure if it is good idea. Tables and views shares one namespace. >> > > But the command say "drop table" and so it must o

Re: Unexpected behavior of DROP VIEW/TABLE IF EXISTS

On Tuesday, June 26, 2018, Pavel Stehule wrote: > > My note is related to @b. I understand to the motivation, but I am not > sure if it is good idea. Tables and views shares one namespace. > But the command say "drop table" and so it must only be concerned with that subset of the namespace when s

Re: Unexpected behavior of DROP VIEW/TABLE IF EXISTS

2018-06-26 17:48 GMT+02:00 David G. Johnston : > On Tuesday, June 26, 2018, Pavel Stehule wrote: > >> 2018-06-26 17:23 GMT+02:00 Peter Moser : >> >>> Hi, >>> I want to delete a table X, that may not exist, hence I execute >>> >>> DROP TABLE IF EXISTS X; >>> >>> However, if X is a view, I

Re: ALTER TABLE does not check for column existence before starting operations

Hello, On Fri, Mar 02, 2018 at 12:36:41PM +0100, Pierre Ducroquet wrote: > The attached patch fixes this behaviour by adding a small check in the first > pass of alter table to make sure that a column referenced by an alter command > exists first. It also checks if the column is added by another

Re: Small fixes about backup history file in doc and pg_standby

On Tue, Jun 26, 2018 at 5:47 PM, Yugo Nagata wrote: > Hi, > > While looking into the backup and recovery code, I found small documentation > bugs. > The documatation says that the backup history files can be requested for > recovery, > but it's not used by the system and not requested anymore si

Re: "wal receiver" process hang in syslog() while exiting after receiving SIGTERM while the postgres has been promoted.

On Tue, Jun 26, 2018 at 4:12 AM, Chen, Yan-Jack (NSB - CN/Hangzhou) wrote: > Hi, > Well, if you agree with do not write log in signal handling function in any > circumstance I don't understand this sentence. > I see in many cases in postgresql signal handling function just set one flag > whi

Unexpected behavior of DROP VIEW/TABLE IF EXISTS

On Tuesday, June 26, 2018, Pavel Stehule wrote: > 2018-06-26 17:23 GMT+02:00 Peter Moser : > >> Hi, >> I want to delete a table X, that may not exist, hence I execute >> >> DROP TABLE IF EXISTS X; >> >> However, if X is a view, I get an error >> >> ERROR: "X" is not a table >> >

Re: ssl_library parameter

Peter Eisentraut writes: > Extracted from the GnuTLS thread/patch, here is a patch to add a > server-side read-only parameter ssl_library, which currently reports > either 'OpenSSL' or an empty string, depending on what SSL library was > built with. This is analogous to the libpq function call >

Re: Unexpected behavior of DROP VIEW/TABLE IF EXISTS

On 06/26/2018 05:34 PM, Pavel Stehule wrote: 2018-06-26 17:23 GMT+02:00 Peter Moser >: What do you think, is it worth to create a patch to solve this issue, where a DROP TABLE does not fail, if the given name is actually a VIEW or vice-versa? DROP TABLE sh

Re: Unexpected behavior of DROP VIEW/TABLE IF EXISTS

2018-06-26 17:23 GMT+02:00 Peter Moser : > Hi, > I want to delete a table X, that may not exist, hence I execute > > DROP TABLE IF EXISTS X; > > However, if X is a view, I get an error > > ERROR: "X" is not a table > HINT: Use DROP VIEW to remove a view. > SQL state

Re: [GSoC] working status

got it, will start to use these tools and add more comments. On Tue, Jun 26, 2018, 7:44 AM Aleksander Alekseeev < a.aleks...@postgrespro.ru> wrote: > Hello Charles, > > >Here is my current working status. Resolved all warnings found by > > Aleksander previously. Having two threads in parallel

Unexpected behavior of DROP VIEW/TABLE IF EXISTS

Hi, I want to delete a table X, that may not exist, hence I execute DROP TABLE IF EXISTS X; However, if X is a view, I get an error ERROR: "X" is not a table HINT: Use DROP VIEW to remove a view. SQL state: 42809 That is unexpected and also difficult to handle,

Re: Thinko/typo in ExecSimpleRelationInsert

On Tue, Jun 26, 2018 at 7:02 PM, Ashutosh Bapat wrote: > On Tue, Jun 26, 2018 at 6:18 PM, Amit Kapila wrote: >> On Tue, Jun 26, 2018 at 4:33 PM, Ashutosh Bapat >> wrote: >>> Looks like we need similar adjustment in ExecSimpleRelationUpdate() as >>> well. Updated the patch. >>> >> >> - /* Store t

Re: Avoid extra Sort nodes between WindowAggs when sorting can be reused

Daniel, I took a look at the patch. It applies and compiles, the tests pass. Some thoughts about the code: * Postgres lists cache their lengths, so you don't need uniqueLen. * Use an array of WindowClauseSortNode's instead of a list. It's more suitable here because you are going to sort (qsor

Re: unexpected relkind: 73 ERROR with partition table index

On 2018-Jun-27, David Rowley wrote: > On 27 June 2018 at 00:18, Rajkumar Raghuwanshi > wrote: > > postgres=> ALTER INDEX part_idx RENAME TO part_idx_renamed; > > ERROR: unexpected relkind: 73 > > Seems to be caused by the auth failure code path in > RangeVarCallbackForAlterRelation(). Ah, yeah

Re: Performance regression with PostgreSQL 11 and partitioning

Le 26/06/2018 à 16:43, Alvaro Herrera a écrit : > On 2018-Jun-25, Tom Lane wrote: > >> Alvaro Herrera writes: >>> On 2018-Jun-18, David Rowley wrote: I've attached a patch which cleans up my earlier version and moves the setup of the append_rel_array into its own function instead of

Re: [GSoC] working status

Hello Charles, >Here is my current working status. Resolved all warnings found by > Aleksander previously. Having two threads in parallel. One is the > thrift binary type implementation, the other is thrift compact byte > interface implementation. For these two threads, simple data type has >

Re: Performance regression with PostgreSQL 11 and partitioning

On 2018-Jun-25, Tom Lane wrote: > Alvaro Herrera writes: > > On 2018-Jun-18, David Rowley wrote: > >> I've attached a patch which cleans up my earlier version and moves the > >> setup of the append_rel_array into its own function instead of > >> sneaking code into setup_simple_rel_arrays(). I've

Re: Few cosmetic suggestions for commit 16828d5c (Fast Alter Table Add Column...)

On 2018-Jun-26, Amit Kapila wrote: > Andrew, Alvaro, do you think we can go ahead with above naming > suggestions or do we want to brainstorm more on it? Looks good to me in a quick skim. -- Álvaro Herrerahttps://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote

Re: Fix slot's xmin advancement and subxact's lost snapshots in decoding.

Alvaro Herrera writes: > Firstly -- this is top-notch detective work, kudos and thanks for the > patch and test cases. (I verified that both fail before the code fix.) Thank you! > Here's a v3. I applied a lot of makeup in order to try to understand > what's going on. I *think* I have a gr

patch to allow disable of WAL recycling

Hello All, Attached is a patch to provide an option to disable WAL recycling. We have found that this can help performance by eliminating read-modify-write behavior on old WAL files that are no longer resident in the filesystem cache. The is a lot more detail on the background of the motivation fo

Re: Thinko/typo in ExecSimpleRelationInsert

On Tue, Jun 26, 2018 at 6:18 PM, Amit Kapila wrote: > On Tue, Jun 26, 2018 at 4:33 PM, Ashutosh Bapat > wrote: >> Looks like we need similar adjustment in ExecSimpleRelationUpdate() as >> well. Updated the patch. >> > > - /* Store the slot into tuple that we can write. */ > + /* Materialize slot

Re: Online enabling of checksums

Hello I tried build this patch and got error during make docs > postgres.sgml:19626: element xref: validity error : IDREF attribute linkend > references an unknown ID "runtime-checksumhelper-cost-limit" > postgres.sgml:19625: element xref: validity error : IDREF attribute linkend > references an

Re: [HACKERS] GUC for cleanup indexes threshold.

On Tue, Jun 26, 2018 at 4:11 PM Darafei "Komяpa" Praliaskouski wrote: > вт, 26 июн. 2018 г. в 15:42, Alexander Korotkov : >> >> On Tue, Jun 26, 2018 at 1:46 PM Masahiko Sawada >> wrote: >> > On Fri, Jun 22, 2018 at 6:55 PM, Alexander Korotkov >> > wrote: >> > > So, I propose to just >> > > incr

Re: [HACKERS] GUC for cleanup indexes threshold.

вт, 26 июн. 2018 г. в 15:42, Alexander Korotkov : > On Tue, Jun 26, 2018 at 1:46 PM Masahiko Sawada > wrote: > > On Fri, Jun 22, 2018 at 6:55 PM, Alexander Korotkov > > wrote: > > > So, I propose to just > > > increase maximum value for both GUC and reloption. See the attached > > > patch. It

Re: unexpected relkind: 73 ERROR with partition table index

On 27 June 2018 at 00:18, Rajkumar Raghuwanshi wrote: > postgres=> ALTER INDEX part_idx RENAME TO part_idx_renamed; > ERROR: unexpected relkind: 73 Seems to be caused by the auth failure code path in RangeVarCallbackForAlterRelation(). Patch attached. -- David Rowley http:/

Re: [PROPOSAL] Nepali Snowball dictionary

Hello all, On Wed, Feb 28, 2018 at 11:16:24AM +0300, Arthur Zakirov wrote: > I've sent a pull request with nepali snowball algorithm into > https://github.com/snowballstem [1]. They aren't againts the patch. > > They haven't merged it yet, though. There are some problems with > continuous testing

Re: Thinko/typo in ExecSimpleRelationInsert

On Tue, Jun 26, 2018 at 4:33 PM, Ashutosh Bapat wrote: > Looks like we need similar adjustment in ExecSimpleRelationUpdate() as > well. Updated the patch. > - /* Store the slot into tuple that we can write. */ + /* Materialize slot into a tuple that we can inspect. */ tuple = ExecMaterializeSlo

Re: [HACKERS] GUC for cleanup indexes threshold.

On Tue, Jun 26, 2018 at 1:46 PM Masahiko Sawada wrote: > On Fri, Jun 22, 2018 at 6:55 PM, Alexander Korotkov > wrote: > > So, I propose to just > > increase maximum value for both GUC and reloption. See the attached > > patch. It also changes calculations _bt_vacuum_needs_cleanup() for > > bett

Re: Concurrency bug in UPDATE of partition-key

On Tue, Jun 26, 2018 at 11:40 AM, Amit Khandekar wrote: > On 25 June 2018 at 17:20, Amit Kapila wrote: >> On Mon, Jun 25, 2018 at 3:06 PM, Amit Khandekar >> wrote: >>> On 23 June 2018 at 15:46, Amit Kapila wrote: > Why do you need to update when newslot is NULL? Already *epqslot

Re: Internal error XX000 with enable_partition_pruning=on, pg 11 beta1 on Debian

On 20 June 2018 at 13:20, David Rowley wrote: > select count(*) from (select * from p union all select * from p) p; > > Unpatched: > tps = 8.530355 (excluding connections establishing) > > Patched: > tps = 7.853939 (excluding connections establishing) I've been thinking about this and I'm not so

unexpected relkind: 73 ERROR with partition table index

Hi, I am getting "ERROR: unexpected relkind: 73" when trying to rename partition table index with below test case. create user u1 superuser; create user u2 nosuperuser login; \c postgres u1 create table public.part(c1 int, c2 int) partition by range(c1); create table public.part_p1 partition of

Re: [bug fix] ECPG: freeing memory for pgtypes crashes on Windows

On Mon, Jun 25, 2018 at 8:16 PM, Tsunakawa, Takayuki wrote: > From: Kyotaro HORIGUCHI [mailto:horiguchi.kyot...@lab.ntt.co.jp] >> However I also don't see a problem to back-patch it, I don't see >> a problem on such difference between versions. > > Thank you, Horiguchi-san and Robert. Ok, back-pa

Re: Online enabling of checksums

On Mon, Apr 9, 2018 at 7:22 PM, Magnus Hagander wrote: > On Sat, Apr 7, 2018 at 6:22 PM, Andres Freund wrote: > >> Hi, >> >> On 2018-04-07 08:57:03 +0200, Magnus Hagander wrote: >> > Note however that I'm sans-laptop until Sunday, so I will revert it >> then or >> > possibly Monday. >> >> I'll d

Re: Small fixes about backup history file in doc and pg_standby

Hello. Good catch! At Tue, 26 Jun 2018 17:47:52 +0900, Yugo Nagata wrote in <20180626174752.0ce505e3.nag...@sraoss.co.jp> > Hi, > > While looking into the backup and recovery code, I found small documentation > bugs. > The documatation says that the backup history files can be requested for

Re: Thinko/typo in ExecSimpleRelationInsert

Looks like we need similar adjustment in ExecSimpleRelationUpdate() as well. Updated the patch. On Tue, Jun 26, 2018 at 3:12 PM, Ashutosh Bapat wrote: > Hi, > There seems to be a thinko/typo in ExecSimpleRelationInsert(). A tuple > can never store a slot, but a comment in that function says so. T

Re: [HACKERS] GUC for cleanup indexes threshold.

On Fri, Jun 22, 2018 at 6:55 PM, Alexander Korotkov wrote: > On Wed, Jun 20, 2018 at 12:00 PM Alexander Korotkov > wrote: >> On Wed, Jun 20, 2018 at 8:32 AM Masahiko Sawada >> wrote: >> > On Wed, Jun 20, 2018 at 1:00 AM, Alexander Korotkov >> > > Ok. I've rephrased comment a bit. Also, you cr

Re: [WIP] [B-Tree] Retail IndexTuple deletion

On Fri, Jun 22, 2018 at 8:24 PM, Andrey V. Lepikhov wrote: > Hi, > According to your feedback, i develop second version of the patch. > In this version: > 1. High-level functions index_beginscan(), index_rescan() not used. Tree > descent made by _bt_search(). _bt_binsrch() used for positioning on

Re: AtEOXact_ApplyLauncher() and subtransactions

Added this into the July 2018 commitfest : https://commitfest.postgresql.org/18/1696/ On 20 June 2018 at 22:22, Amit Khandekar wrote: > On 18 June 2018 at 15:02, Amit Khandekar wrote: >> On 16 June 2018 at 00:03, Amit Khandekar wrote: >>> The way I am implementing this can be seen in attached

RE: ON CONFLICT DO NOTHING on pg_dump

>> I agree with you though supporting MERGE or ON-CONFLICT-DO-UPDATE seems >hard work. >> Only ON-CONCLICT-DO-NOTHING use case may be narrow. > >Is it narrow, or is it just easy enough to add quickly? Sorry for late replay. I read your comment and rethought about it. What I meant by "narrow" is th

RE: "wal receiver" process hang in syslog() while exiting after receiving SIGTERM while the postgres has been promoted.

Hi, Well, if you agree with do not write log in signal handling function in any circumstance? I see in many cases in postgresql signal handling function just set one flag which triggers its main process to handling the progress. How about simply remove the code lines? --- walreceiver_old.c

  1   2   >