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

On Sat, Jan 20, 2018 at 7:08 AM, Tomas Vondra wrote: > On 01/19/2018 03:34 PM, Tomas Vondra wrote: >> Attached is v5, fixing a silly bug in part 0006, causing segfault when >> creating a subscription. >> > > Meh, there was a bug in the sgml docs ( vs. ), > causing

Re: A typo in error message

On Wed, Jan 31, 2018 at 08:47:57AM +0300, Alexander Lakhin wrote: > Please consider committing the attached patch to fix a typo in error > message. Yeah.. > if (cxt->ofType) > ereport(ERROR, >

A typo in error message

Hello, Please consider committing the attached patch to fix a typo in error message. Best regards, -- Alexander Lakhin Postgres Professional: http://www.postgrespro.com The Russian Postgres Company diff --git a/src/backend/parser/parse_utilcmd.c b/src/backend/parser/parse_utilcmd.c index

Re: [HACKERS] [PATCH] Improve geometric types

At Sun, 21 Jan 2018 21:59:19 +0100, Emre Hasegeli wrote in > New versions are attached including all changes we discussed. Thanks for the new version. # there's many changes from the previous version..

[PATCH] Add missing type conversion functions for PL/Python

Hi All, PL/Python already has different type conversion functions to convert PostgreSQL datum to Python object. However, the conversion functions from Python object to PostgreSQL datum only has Boolean, Bytea and String functions. In this patch, we add rest of Integer and Float related datatype

Re: Wait for parallel workers to attach

On Wed, Jan 31, 2018 at 8:46 AM, Robert Haas wrote: > On Tue, Jan 30, 2018 at 10:10 PM, Amit Kapila wrote: >> I am not getting what exactly you are suggesting here. The wait loop >> is intended for the case when some workers are not started. We

Re: [HACKERS] [PATCH]make pg_rewind to not copy useless WAL files

On Fri, Jan 26, 2018 at 11:36:09AM +0900, Michael Paquier wrote: > In short, it seems really to me that we should reject the approach as > proposed, and replace it with something that prevents the fetching of > any WAL segments from the source server. I think that we could consider > as well

Re: Wait for parallel workers to attach

On Tue, Jan 30, 2018 at 10:10 PM, Amit Kapila wrote: >> known_started_workers looks a lot like any_message_received. Perhaps >> any_message_received should be renamed to known_started_workers and >> reused here. > > Sure, that sounds good to me. Do you prefer a separate

Re: Wait for parallel workers to attach

On Mon, Jan 29, 2018 at 8:25 PM, Robert Haas wrote: > On Sat, Jan 27, 2018 at 3:14 AM, Amit Kapila wrote: >> During the recent development of parallel operation (parallel create >> index)[1], a need has been arised for $SUBJECT. The idea is to

Re: JIT compiling with LLVM v9.0

Hi, On 2018-01-31 15:48:09 +1300, Thomas Munro wrote: > On Wed, Jan 31, 2018 at 3:05 PM, Andres Freund wrote: > > I'm not quite sure I understand. You mean have it display whether > > available? I think my plan is to "just" set jit_expressions=on (or > > whatever we're going

Re: JIT compiling with LLVM v9.0

On Wed, Jan 31, 2018 at 3:05 PM, Andres Freund wrote: > On 2018-01-31 14:42:26 +1300, Thomas Munro wrote: >> I'm just starting to look at this (amazing) work, and I don't have a >> strong opinion yet. But certainly, making it easy for packagers to >> put the -jit stuff into a

Re: [HACKERS] postgres_fdw bug in 9.6

(2018/01/31 4:56), Robert Haas wrote: On Sat, Jan 20, 2018 at 12:20 AM, Tom Lane wrote: It looks like Etsuro-san's proposed patch locks down the choice of plan more tightly, which is probably a reasonable answer. OK, committed. I added a comment along the lines you

Re: JIT compiling with LLVM v9.0

On 2018-01-31 14:42:26 +1300, Thomas Munro wrote: > I'm just starting to look at this (amazing) work, and I don't have a > strong opinion yet. But certainly, making it easy for packagers to > put the -jit stuff into a separate package for the reasons already > given sounds sensible to me. Some

Re: [HACKERS] GUC for cleanup indexes threshold.

On Fri, Jan 12, 2018 at 1:05 PM, Masahiko Sawada wrote: > On Wed, Jan 10, 2018 at 11:28 AM, Masahiko Sawada > wrote: >> On Sun, Jan 7, 2018 at 8:40 AM, Peter Geoghegan wrote: >>> On Sat, Jan 6, 2018 at 2:20 PM, Stephen Frost

Re: JIT compiling with LLVM v9.0

On Wed, Jan 31, 2018 at 11:57 AM, Andres Freund wrote: > On 2018-01-30 13:46:37 -0500, Robert Haas wrote: >> On Mon, Jan 29, 2018 at 1:40 PM, Andres Freund wrote: >> > It's an optional dependency, and it doesn't increase build time that >> > much... If we

Re: User defined data types in Logical Replication

On Tue, Jan 30, 2018 at 6:36 PM, atorikoshi wrote: > Hi, > > It seems to be in the middle of discussion, but I became a reviewer of > this problem several days ago so I've tested the latest patch > 'fix_slot_store_error_callback_v12.patch'. > > I reproduced the

Re: [Sender Address Forgery]Re: FOR EACH ROW triggers on partitioned tables

On 2018/01/31 9:44, Peter Eisentraut wrote: > On 1/30/18 04:49, Amit Langote wrote: >>> If you are writing a generic >>> trigger function, maybe to dump out all columns, you want to know the >>> physical table and its actual columns. It's easy[citation needed] to >>> get the partition root for a

Re: FOR EACH ROW triggers on partitioned tables

On 1/30/18 04:49, Amit Langote wrote: >> If you are writing a generic >> trigger function, maybe to dump out all columns, you want to know the >> physical table and its actual columns. It's easy[citation needed] to >> get the partition root for a given table, if the trigger code needs >> that.

Re: Regarding drop index

On 1/30/18 04:12, Abinaya Kajendiran wrote: >     We are building in-memory index extension for postgres. For drop > index query, does postgres notify me through index access methods? No, the access methods just write into blocks for the file they are told about. The deleting of that file is not

Re: [HACKERS] GnuTLS support

On 01/26/2018 03:54 AM, Peter Eisentraut wrote: On 1/25/18 20:10, Michael Paquier wrote: Peter, could you change ssl_version() and ssl_cipher() in sslinfo at the same time please? I think that those should use the generic backend-side APIs as well. sslinfo depends heavily on OpenSSL, OK, but if

Re: [HACKERS] MERGE SQL Statement for PG11

On Tue, Jan 30, 2018 at 8:27 AM, Robert Haas wrote: > As far as I am able to understand, the substantive issue here is what > to do when we match an invisible tuple rather than a visible tuple. > The patch currently throws a serialization error on the basis that you >

Re: JIT compiling with LLVM v9.0

> On Jan 30, 2018, at 2:08 PM, Andres Freund wrote: > > With things like apt recommends and such I don't think this is a huge problem. I don’t believe there is a similar widely-supported dependency type in yum/rpm, though. rpm 4.12 adds support for Weak Dependencies, which

Re: JIT compiling with LLVM v9.0

Hi, On 2018-01-30 13:46:37 -0500, Robert Haas wrote: > On Mon, Jan 29, 2018 at 1:40 PM, Andres Freund wrote: > > It's an optional dependency, and it doesn't increase build time that > > much... If we were to move the llvm interfacing code to a .so, there'd > > not even be a

Re: JIT compiling with LLVM v9.0

Hi, On 2018-01-30 22:57:06 +0100, David Fetter wrote: > On Tue, Jan 30, 2018 at 01:46:37PM -0500, Robert Haas wrote: > > On Mon, Jan 29, 2018 at 1:40 PM, Andres Freund wrote: > > > It's an optional dependency, and it doesn't increase build time > > > that much... If we were

Re: JIT compiling with LLVM v9.0

On Tue, Jan 30, 2018 at 01:46:37PM -0500, Robert Haas wrote: > On Mon, Jan 29, 2018 at 1:40 PM, Andres Freund wrote: > > It's an optional dependency, and it doesn't increase build time > > that much... If we were to move the llvm interfacing code to a > > .so, there'd not even

Re: [HACKERS] MERGE SQL Statement for PG11

On Tue, Jan 30, 2018 at 8:56 AM, Simon Riggs wrote: >> Peter is arguing >> that we don't normally issue a serialization error at READ COMMITTED >> (which I think is true) and proposed that we instead try to INSERT. > > Which IMHO is case 4 since it would avoid a concurrent

Re: JIT compiling with LLVM v9.0

On 01/30/2018 12:24 AM, Andres Freund wrote: > Hi, > > On 2018-01-30 00:16:46 +0100, Tomas Vondra wrote: >> FWIW I've installed llvm 5.0.1 from distribution package, and now >> everything builds fine (I don't even need the configure tweak). >> >> I think I had to build the other binaries

Re: JIT compiling with LLVM v9.0

Hi, On 2018-01-30 15:06:02 -0500, Robert Haas wrote: > On Tue, Jan 30, 2018 at 2:08 PM, Andres Freund wrote: > >> That bites, although it's probably tolerable if we expect such errors > >> only in exceptional situations such as a needed shared library failing > >> to load or

Re: JIT compiling with LLVM v9.0

Robert Haas writes: > Unfortunately, that has the pretty significant downside that a lot of > people who actually want the postgresql-server-jit package will not > realize that they need to install it, which sucks. But I think it > might still be the better way to go.

Re: JIT compiling with LLVM v9.0

On Tue, Jan 30, 2018 at 2:08 PM, Andres Freund wrote: >> That bites, although it's probably tolerable if we expect such errors >> only in exceptional situations such as a needed shared library failing >> to load or something. Killing the session when we run out of memory >>

Re: [HACKERS] postgres_fdw bug in 9.6

On Sat, Jan 20, 2018 at 12:20 AM, Tom Lane wrote: > It looks like Etsuro-san's proposed patch locks down the choice of > plan more tightly, which is probably a reasonable answer. OK, committed. I added a comment along the lines you suggested previously, since this no longer

Re: [HACKERS] MERGE SQL Statement for PG11

On Tue, Jan 30, 2018 at 8:27 AM, Robert Haas wrote: > As far as I am able to understand, the substantive issue here is what > to do when we match an invisible tuple rather than a visible tuple. > The patch currently throws a serialization error on the basis that you >

Re: JIT compiling with LLVM v9.0

Hi, On 2018-01-30 13:57:50 -0500, Robert Haas wrote: > > When a libstdc++ new or LLVM error occurs, the handlers set up by the > > above functions trigger a FATAL error. We have to use FATAL rather than > > ERROR, as we *cannot* reliably throw ERROR inside a foreign library > > without risking

Re: [HACKERS] MERGE SQL Statement for PG11

On Tue, Jan 30, 2018 at 11:56 AM, Simon Riggs wrote: > Which IMHO is case 4 since it would avoid a concurrent ERROR. This > meets exactly my original implementation goals as clearly stated on > this thread, so of course I agree with him and have already said I am > happy to

Re: JIT compiling with LLVM v9.0

On Wed, Jan 24, 2018 at 2:20 AM, Andres Freund wrote: > == Error handling == > > There's two aspects to error handling. > > Firstly, generated (LLVM IR) and emitted functions (mmap()ed segments) > need to be cleaned up both after a successful query execution and after > an

Re: [HACKERS] MERGE SQL Statement for PG11

On 30 January 2018 at 16:27, Robert Haas wrote: > As far as I am able to understand, the substantive issue here is what > to do when we match an invisible tuple rather than a visible tuple. > The patch currently throws a serialization error on the basis that you > (Simon)

WINDOW RANGE patch versus leakproofness

I am wondering whether we need to worry about leakproofness in connection with adding in_range support functions to btree opclasses. My initial conclusion is not, but let me lay out the reasoning so people can check it --- I might be missing something. The first question is whether we need to

Re: Add RANGE with values and exclusions clauses to the Window Functions

Once more trying to attach the regression.diffs On 2018-01-30 17:31, Erik Rijkers wrote: On 2018-01-30 17:08, Oliver Ford wrote: On Tue, Jan 30, 2018 at 10:48 AM, Oliver Ford wrote: I will send out v10 soon with the desc functions removed and the EXCLUDE_NO_OTHERS define

Re: Add RANGE with values and exclusions clauses to the Window Functions

On 2018-01-30 17:08, Oliver Ford wrote: On Tue, Jan 30, 2018 at 10:48 AM, Oliver Ford wrote: I will send out v10 soon with the desc functions removed and the EXCLUDE_NO_OTHERS define removed. Here it is. Exclude No Others is still in the parser, but does nothing. All desc

Re: [HACKERS] MERGE SQL Statement for PG11

On Tue, Jan 30, 2018 at 4:45 AM, Simon Riggs wrote: > "You're introducing a behavior/error"... No, I advocate nothing in the > patch, I am merely following the agreement made here: > >

Re: [HACKERS] MERGE SQL Statement for PG11

On Mon, Jan 29, 2018 at 12:03 PM, Simon Riggs wrote: > Partitioning doesn't look too bad, so that looks comfortable for PG11, > assuming it doesn't hit some unhandled complexity. > > Including RLS in the first commit/release turns this into a high risk > patch. Few people

Re: [HACKERS] MERGE SQL Statement for PG11

On Mon, Jan 29, 2018 at 7:15 PM, Michael Paquier wrote: > On Mon, Jan 29, 2018 at 04:34:48PM +, Simon Riggs wrote: >> In terms of timing of commits, I have marked the patch Ready For >> Committer. To me that signifies that it is ready for review by a >> Committer

Re: [HACKERS] MERGE SQL Statement for PG11

On Mon, Jan 29, 2018 at 10:32 AM, Simon Riggs wrote: > The code is about 1200 lines and has extensive docs, comments and tests. > > There are no contentious infrastructure changes, so the debate around > concurrency is probably the main one. So it looks to me like >

Re: [HACKERS][PATCH] Applying PMDK to WAL operations for persistent memory

On Tue, Jan 30, 2018 at 3:37 AM, Yoshimi Ichiyanagi wrote: > Oracle and Microsoft SQL Server suported PMEM [1][2]. > I think it is not too early for PostgreSQL to support PMEM. I agree; it's good to have the option available for those who have access to the

Re: csv format for psql

2018-01-30 9:31 GMT+01:00 Daniel Verite : > Hi, > > > This patch implements csv as an output format in psql > (\pset format csv). It's quite similar to the unaligned format, > except that it applies CSV quoting rules (obviously!) and that > it prints no footer and no

Re: [HACKERS] PoC plpgsql - possibility to force custom or generic plan

2018-01-30 9:06 GMT+01:00 Tatsuro Yamada : > On 2018/01/24 1:08, Pavel Stehule wrote: > >> >> >> 2018-01-22 23:15 GMT+01:00 Stephen Frost sfr...@snowman.net>>: >> >> Pavel, >> >> >> * Pavel Stehule (pavel.steh...@gmail.com >

Re: [HACKERS] path toward faster partition pruning

Hi Amit, On 01/29/2018 07:57 PM, Amit Langote wrote: This needs a rebase. AFAICS, v22 cleanly applies to HEAD (c12693d8f3 [1]), compiles, and make check passes. It was a rebase error; I should have checked against a clean master. Sorry for the noise. Best regards, Jesper

Re: [PATCH] pgbench - refactor some connection finish/null into common function

Hello Doug, This patch refactors all of the connection state PQfinish() and NULL’ing into a single function. Excludes PQfinish() in doConnect(). My 0.02€: The argument could be "PGconn **" instead of a "CState *"? If so, it may be used in a few more places. What is your opinion? I'm fine

Re: Add RANGE with values and exclusions clauses to the Window Functions

On Tuesday, 30 January 2018, Tom Lane wrote: > Another thing I'm a little confused by is the precise API for the in_range > support functions (the lack of any documentation for it doesn't help). > I wonder why you chose to provide two support functions per datatype >

Re: [HACKERS] Subscription code improvements

On Fri, Jan 26, 2018 at 11:41 AM, Peter Eisentraut wrote: > On 1/24/18 02:33, Masahiko Sawada wrote: >> Thank you for notification. Since it seems to me that no one is >> interested in this patch, it would be better to close out this patch. >> This patch is a

Re: non-bulk inserts and tuple routing

(2018/01/30 18:39), Amit Langote wrote: Will wait for your comments before sending a new version then. Ok, I'll post my comments as soon as possible. Best regards, Etsuro Fujita

Re: FOR EACH ROW triggers on partitioned tables

On 2018/01/30 5:30, Peter Eisentraut wrote: > On 1/23/18 17:10, Alvaro Herrera wrote: >> The main question is this: when running the trigger function, it is >> going to look as it is running in the context of the partition, not in >> the context of the parent partitioned table (TG_RELNAME etc).

Re: [HACKERS] MERGE SQL Statement for PG11

On 29 January 2018 at 22:31, Peter Geoghegan wrote: > I don't think that there should be any error, so I can't say. >> I argued that was possible and desirable, but you argued it was not >> and got everybody else to agree with you. I'm surprised to see you >> change your mind on

Re: non-bulk inserts and tuple routing

Fujita-san, On 2018/01/30 18:22, Etsuro Fujita wrote: > (2018/01/25 18:52), Amit Langote wrote: >> On 2018/01/25 18:30, Etsuro Fujita wrote: >>> The patches apply cleanly and compile successfully, but make check fails >>> in an assert-enabled build. >> >> Hmm, I can't seem to reproduce the

Re: non-bulk inserts and tuple routing

(2018/01/25 18:52), Amit Langote wrote: On 2018/01/25 18:30, Etsuro Fujita wrote: The patches apply cleanly and compile successfully, but make check fails in an assert-enabled build. Hmm, I can't seem to reproduce the failure with v4 patches I posted earlier today. Can you please post the

Re: csv format for psql

Hello Daniel, This patch implements csv as an output format in psql (\pset format csv). Would you consider registering it in the next CF? -- Fabien.

Regarding drop index

Hello all, We are building in-memory index extension for postgres. For drop index query, does postgres notify me through index access methods? Currently, we are using event triggers to capture drop index. If there is a better way, please do suggest. Thanks in advance. Regards, Abinaya K

Re: [HACKERS] datetime.h defines like PM conflict with external libraries

> Michael, is there any problem including datatype/* headers in ecpg > that > are frontend clean? I see no such usage so far, that's why I'm > asking. When the pgtypes library was created we tried to include only the bits and pieces needed to not create unnecessary hassles, but if it compiles

csv format for psql

Hi, This patch implements csv as an output format in psql (\pset format csv). It's quite similar to the unaligned format, except that it applies CSV quoting rules (obviously!) and that it prints no footer and no title. As with unaligned, a header with column names is output unless tuples_only

Re: [HACKERS] generated columns

On Sat, Jan 27, 2018 at 05:05:14PM -0500, Peter Eisentraut wrote: > This is expanded in the rewriter, so there is no context like that. > This is exactly how views work, e.g., > > create table t1 (id int, length int); > create view v1 as select id, length * 10 as length_in_nanometers >

Re: [HACKERS] PoC plpgsql - possibility to force custom or generic plan

On 2018/01/24 1:08, Pavel Stehule wrote: 2018-01-22 23:15 GMT+01:00 Stephen Frost >: Pavel, * Pavel Stehule (pavel.steh...@gmail.com ) wrote: > here is a GUC based patch for plancache controlling.

Re: PATCH: Configurable file mode mask

On Mon, Jan 29, 2018 at 04:29:08PM -0500, David Steele wrote: > OK, that being the case I have piggy-backed on the current pg_upgrade > tests in the same way that --wal-segsize did. > > There are now three patches: > > 1) 01-pgresetwal-test > > Adds a *very* basic test suite for pg_resetwal. I