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

Hi, On 2017-10-04 11:36:56 +0200, Alvaro Herrera wrote: > Andrew Dunstan wrote: > > On 10/03/2017 04:43 PM, Tom Lane wrote: > > > I like the new-header-file idea because it will result in minimal code > > > churn and thus minimal back-patching hazards. I'm not sure it's that little code churn,

Re: JIT compiling with LLVM v9.0

Hi, On 2018-01-29 22:51:38 +0100, Tomas Vondra wrote: > Hi, I wanted to look at this, but my attempts to build the jit branch > fail with some compile-time warnings (uninitialized variables) and > errors (unknown types, incorrect number of arguments). See the file > attached. Which git hash are

Re: JIT compiling with LLVM v9.0

Hi, On 2018-01-29 23:49:14 +0100, Tomas Vondra wrote: > On 01/29/2018 11:17 PM, Andres Freund wrote: > > On 2018-01-29 23:01:14 +0100, Tomas Vondra wrote: > >> $ llvm-config --version > >> 5.0.0svn > > > > Is thta llvm-config the one in /usr/local/include/ referenced by the > > error message

Re: JIT compiling with LLVM v9.0

On 01/29/2018 11:49 PM, Tomas Vondra wrote: > > ... > > and that indeed changes the failure to this: > > Writing postgres.bki > Writing schemapg.h > Writing postgres.description > Writing postgres.shdescription > llvmjit_error.cpp: In function ‘void llvm_enter_fatal_on_oom()’: >

VALUES nodes and expression initialization

Hi, In contrast to most other nodes, nodeValuescan.c does expression initialization at "runtime" rather than in initialization: /* * Get rid of any prior cycle's leftovers. We use ReScanExprContext * not just ResetExprContext because we want

Re: JIT compiling with LLVM v9.0

On 01/29/2018 10:57 PM, Andres Freund wrote: > Hi, > > On 2018-01-29 22:51:38 +0100, Tomas Vondra wrote: >> Hi, I wanted to look at this, but my attempts to build the jit branch >> fail with some compile-time warnings (uninitialized variables) and >> errors (unknown types, incorrect number of

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

On Monday, 29 January 2018, Tom Lane wrote: > Oliver Ford writes: > > On Monday, 29 January 2018, Tom Lane wrote: > >> I've started to go through this in some detail, and I'm wondering why > >> you invented a

Re: JIT compiling with LLVM v9.0

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 because there was no 5.x llvm > back then, but it's too far

Re: [HACKERS] why not parallel seq scan for slow functions

On Sun, Jan 28, 2018 at 10:13 PM, Amit Kapila wrote: > If we want to get rid of Gather (Merge) checks in > apply_projection_to_path(), then we need some way to add a projection > path to the subpath of gather node even if that is capable of > projection as we do now. I

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

On Monday, 29 January 2018, Tom Lane wrote: > Oliver Ford writes: > > [ 0001-window-frame-v9.patch ] > > I've started to go through this in some detail, and I'm wondering why > you invented a FRAMEOPTION_EXCLUDE_NO_OTHERS option bit rather than > just

Re: JIT compiling with LLVM v9.0

On 01/24/2018 08:20 AM, Andres Freund wrote: > Hi, > > I've spent the last weeks working on my LLVM compilation patchset. In > the course of that I *heavily* revised it. While still a good bit away > from committable, it's IMO definitely not a prototype anymore. > > There's too many small

Re: JIT compiling with LLVM v9.0

On 2018-01-29 23:01:14 +0100, Tomas Vondra wrote: > On 01/29/2018 10:57 PM, Andres Freund wrote: > > Hi, > > > > On 2018-01-29 22:51:38 +0100, Tomas Vondra wrote: > >> Hi, I wanted to look at this, but my attempts to build the jit branch > >> fail with some compile-time warnings (uninitialized

Re: [HACKERS] MERGE SQL Statement for PG11

On Mon, Jan 29, 2018 at 1:34 PM, Simon Riggs wrote: >> The way that routines like ExecUpdate() interact with MERGE for WHEN >> qual + EPQ handling seems kind of convoluted. I hope for something >> cleaner in the next revision. > > Cleaner? Yeah, cleaner. The fact that when

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

Oliver Ford writes: > On Monday, 29 January 2018, Tom Lane wrote: >> I've started to go through this in some detail, and I'm wondering why >> you invented a FRAMEOPTION_EXCLUDE_NO_OTHERS option bit rather than >> just representing that choice as default (0).

Re: PATCH: Configurable file mode mask

On 1/19/18 4:43 PM, Peter Eisentraut wrote: > On 1/19/18 14:07, David Steele wrote: >> I have yet to add tests for pg_rewindwal and pg_upgrade. pg_rewindwal >> doesn't *have* any tests as far as I can tell and pg_upgrade has tests >> in a shell script -- it's not clear how I would extend it or

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

Oliver Ford writes: > [ 0001-window-frame-v9.patch ] I've started to go through this in some detail, and I'm wondering why you invented a FRAMEOPTION_EXCLUDE_NO_OTHERS option bit rather than just representing that choice as default (0). As you have it, a window definition that

Re: [HACKERS] MERGE SQL Statement for PG11

On 29 January 2018 at 20:41, Peter Geoghegan wrote: > On Mon, Jan 29, 2018 at 6:11 AM, Simon Riggs wrote: >> New patch attached that correctly handles all known concurrency cases, >> with expected test output. > > This revision, v13, seems much improved in

Re: JIT compiling with LLVM v9.0

On 01/29/2018 11:17 PM, Andres Freund wrote: > On 2018-01-29 23:01:14 +0100, Tomas Vondra wrote: >> On 01/29/2018 10:57 PM, Andres Freund wrote: >>> Hi, >>> >>> On 2018-01-29 22:51:38 +0100, Tomas Vondra wrote: Hi, I wanted to look at this, but my attempts to build the jit branch fail

Re: [HACKERS] MERGE SQL Statement for PG11

On 29 January 2018 at 17:35, Peter Geoghegan wrote: > On Mon, Jan 29, 2018 at 8:51 AM, Simon Riggs wrote: >> On 29 January 2018 at 16:44, Bruce Momjian wrote: >> >>> I think the question is how does it handle cases it doesn't support? >>>

Re: JIT compiling with LLVM v9.0

On Mon, Jan 29, 2018 at 1:36 AM, Andres Freund wrote: > There's already a *lot* of integration points in the patchseries. Error > handling needs to happen in parts of code we do not want to make > extensible, the defintion of expression steps has to exactly match, the > core

Re: [HACKERS] MERGE SQL Statement for PG11

On Mon, Jan 29, 2018 at 6:11 AM, Simon Riggs wrote: > New patch attached that correctly handles all known concurrency cases, > with expected test output. This revision, v13, seems much improved in this area. > This means MERGE will work just fine for "normal" UPDATEs, but

Re: PATCH: Exclude unlogged tables from base backups

On Mon, Jan 29, 2018 at 1:17 PM, David Steele wrote: > On 1/29/18 9:13 AM, David Steele wrote: >> On 1/29/18 5:28 AM, Masahiko Sawada wrote: >>> But I >>> have a question; can we exclude temp tables as well? The pg_basebackup >>> includes even temp tables. But I don't think

Re: FOR EACH ROW triggers on partitioned tables

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). That > seems mildly ugly: some users may be

Re: Built-in connection pooling

Bruce>Well, we could have the connection pooler disconnect those, right? I agree. Do you think we could rely on all the applications being configured in a sane way? A fallback configuration at DB level could still be useful to ensure the DB keeps running in case multiple applications access it.

Re: PATCH: Exclude unlogged tables from base backups

On 1/29/18 8:10 PM, Masahiko Sawada wrote: > On Tue, Jan 30, 2018 at 5:45 AM, Adam Brightwell > wrote: >> On Mon, Jan 29, 2018 at 1:17 PM, David Steele wrote: >>> >>> Whoops, my bad. Temp relations are stored in the db directories with a >>>

Re: [HACKERS] MERGE SQL Statement for PG11

On Mon, Jan 29, 2018 at 8:51 AM, Simon Riggs wrote: > On 29 January 2018 at 16:44, Bruce Momjian wrote: > >> I think the question is how does it handle cases it doesn't support? >> Does it give wrong answers? Does it give a helpful error message? Can >>

Re: PATCH: Exclude unlogged tables from base backups

On Fri, Jan 26, 2018 at 4:58 AM, David Steele wrote: > On 1/25/18 12:31 AM, Masahiko Sawada wrote: >> On Thu, Jan 25, 2018 at 3:25 AM, David Steele wrote: Here is the first review comments. + unloggedDelim = strrchr(path, '/');

Re: Enhance pg_stat_wal_receiver view to display connected host

On Tue, Jan 16, 2018 at 05:56:22PM +1100, Haribabu Kommi wrote: > Without PQhostaddr() function, for the connections where the host is not > specified, it will be difficult to find out to remote server. That's true as well, but hostaddr should be used with host only to save IP lookups... There

Re: Regarding ambulkdelete, amvacuumcleanup index methods

On Thu, Jan 25, 2018 at 5:53 PM, Abinaya k wrote: > Thanks for your response. > > Hope those stats will be used by Query Planner. > > So, just for my understanding, if i don't return stats (returning NULL from > index_bulk_delete and index_vacuum_cleanup functions), Query

Re: [HACKERS] WIP: Aggregation push-down

Robert Haas wrote: > On Fri, Jan 26, 2018 at 8:04 AM, Antonin Houska wrote: > > So one problem is that the grouping expression can be inappropriate for > > partial aggregation even if there's no type change during the > > translation. What I consider

Re: [HACKERS] Partition-wise aggregation/grouping

On Sat, Jan 27, 2018 at 1:35 AM, Robert Haas wrote: > On Thu, Jan 18, 2018 at 8:55 AM, Jeevan Chalke > wrote: > > Attached patch with other review points fixed. > > Committed 0001 and 0002 together, with some cosmetic changes, > including

Re: Built-in connection pooling

On 28.01.2018 03:40, Bruce Momjian wrote: On Mon, Jan 22, 2018 at 06:51:08PM +0100, Tomas Vondra wrote: Yes, external connection pooling is more flexible. It allows to perform pooling either at client side either at server side (or even combine two approaches).> Also external connection

Re: pgsql: Local partitioned indexes

On 2018/01/19 23:55, Alvaro Herrera wrote: > Local partitioned indexes > > Modified Files > -- > doc/src/sgml/catalogs.sgml| 23 + > doc/src/sgml/ref/alter_index.sgml | 14 + > doc/src/sgml/ref/alter_table.sgml | 8 +- >

Re: STATISTICS retained in CREATE TABLE ... LIKE (INCLUDING ALL)?

On 28 January 2018 at 10:45, Tom Lane wrote: > David Rowley writes: >> I'd offer to put it back to the order of the enum, but I want to >> minimise the invasiveness of the patch. > > I think the ordering of these items suffers greatly from "add

Re: Logical Decoding and HeapTupleSatisfiesVacuum assumptions

On 29 January 2018 at 07:15, Nikhil Sontakke wrote: >> Having this as responsibility of plugin sounds interesting. It certainly >> narrows the scope for which we need to solve the abort issue. For 2PC >> that may be okay as we need to somehow interact with transaction

Re: Logical Decoding and HeapTupleSatisfiesVacuum assumptions

On 23 January 2018 at 19:17, Petr Jelinek wrote: > I am not sure if this helps streaming use-case though as > there is not going to be any external transaction management involved there. So, I think we need some specific discussion of what to do in that case.

Re: unique indexes on partitioned tables

On 2018/01/29 16:28, Amit Langote wrote: > create table p (a int, b int) partition by list (a); > create table p1 partition of p for values in (1) partition by range (b); > create table p11 partition of p1 for values from (1) to (10); > create table p2 partition of p for values in (2); > > create

Re: JIT compiling with LLVM v9.0

Hi, On 2018-01-28 23:02:56 +0100, Pierre Ducroquet wrote: > I have fixed the build issues with LLVM 3.9 and 4.0. The LLVM documentation > is > really lacking when it comes to porting from version x to x+1. > The only really missing part I found is that in 3.9, GlobalValueSummary has > no >

Re: STATISTICS retained in CREATE TABLE ... LIKE (INCLUDING ALL)?

On 28 January 2018 at 12:00, Tomas Vondra wrote: > On 01/27/2018 10:45 PM, Tom Lane wrote: >> David Rowley writes: >>> I'd offer to put it back to the order of the enum, but I want to >>> minimise the invasiveness of the patch. I'm not

Re: [HACKERS] Restricting maximum keep segments by repslots

Hello, At Mon, 29 Jan 2018 19:26:34 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI wrote in <20180129.192634.217484965.horiguchi.kyot...@lab.ntt.co.jp> > While rechecking the patch, I fixed the message issued on losing > segments in 0001, revised the TAP test

Re: [HACKERS] proposal - Default namespaces for XPath expressions (PostgreSQL 11)

Hello. At Wed, 24 Jan 2018 10:30:39 +0100, Pavel Stehule wrote in

Re: PATCH: pgbench - option to build using ppoll() for larger connection counts

Hello Doug, I'm not sure why you do the following trick, could you explain? +#undef USE_SELECT +#define USE_SELECT This was due to compiler complaint about USE_SELECT being redefined. Have replaced that "trick" with a new #define POLL_USING_SELECT which is used elsewhere in

Re: [HACKERS] proposal - Default namespaces for XPath expressions (PostgreSQL 11)

Hello. I reviewed this and think that this is in Ready for Committer stage. The patch is available here. https://www.postgresql.org/message-id/CAFj8pRBVUVvG1CXxgrs0UipTziUX6M788z-%3DL9gQvwAB4UGLeg%40mail.gmail.com The following list consists of the same items in upthread message as

Re: JIT compiling with LLVM v9.1

Hi, On 2018-01-23 23:20:38 -0800, Andres Freund wrote: > == Code == > > As the patchset is large (500kb) and I'm still quickly evolving it, I do > not yet want to attach it. The git tree is at > https://git.postgresql.org/git/users/andresfreund/postgres.git > in the jit branch > >

Re: JIT compiling with LLVM v9.0

On Monday, January 29, 2018 10:46:13 AM CET Andres Freund wrote: > Hi, > > On 2018-01-28 23:02:56 +0100, Pierre Ducroquet wrote: > > I have fixed the build issues with LLVM 3.9 and 4.0. The LLVM > > documentation is really lacking when it comes to porting from version x > > to x+1. > > The only

Re: [HACKERS] Restricting maximum keep segments by repslots

Thank you for kindly noticing me of that. At Mon, 29 Jan 2018 11:07:31 +1300, Thomas Munro wrote in

Re: PATCH: Exclude unlogged tables from base backups

On Mon, Jan 29, 2018 at 07:28:22PM +0900, Masahiko Sawada wrote: > Thank you for updating the patch! The patch looks good to me. But I > have a question; can we exclude temp tables as well? The pg_basebackup > includes even temp tables. But I don't think that it's necessary for > backups. They

Re: [HACKERS] Secondary index access optimizations

On 29.01.2018 07:34, Thomas Munro wrote: On Sat, Jan 20, 2018 at 5:41 AM, Konstantin Knizhnik wrote: On 19.01.2018 16:14, Antonin Houska wrote: you should test the operator B-tree strategy: BTLessStrategyNumber, BTLessEqualStrategyNumber, etc. The operator string

Re: Logical Decoding and HeapTupleSatisfiesVacuum assumptions

Hi, On 01/29/2018 11:23 AM, Simon Riggs wrote: > On 29 January 2018 at 07:15, Nikhil Sontakke wrote: > >>> Having this as responsibility of plugin sounds interesting. It >>> certainly narrows the scope for which we need to solve the abort >>> issue. For 2PC that may be

Re: [HACKERS] [PATCH] Generic type subscripting

Hi, On Sun, Jan 28, 2018 at 06:26:56PM +0100, Dmitry Dolgov wrote: > > Here is a new version of the patch: > > * rebased to the latest master > > * fixed issues I mentioned above > > * updated an example from the tutorial part I have a few comments.

Re: General purpose hashing func in pgbench

On 29.01.2018 15:03, Fabien COELHO wrote: Patch applies, compiles, pgbench & global "make check" ok, doc built ok. Ok for me, switched to "Ready". Thank you for the thorough review! -- Ildar Musin i.mu...@postgrespro.ru

Re: General purpose hashing func in pgbench

Hello Ildar, Fixed the doc, attached the patch. Thanks! Patch applies, compiles, pgbench & global "make check" ok, doc built ok. Ok for me, switched to "Ready". -- Fabien.

Re: A Generic Question about Generic type subscripting

On Mon, Jan 29, 2018 at 09:45:15AM +0200, Hannu Krosing wrote: > ... > I see two possibilities > > 1) add a third "ARG" to the CREATE OPERATOR syntax, maybe VALUEARG > 2) use composite types - so for > > jsonb1[int1] = jsonb2 > > the operator would be defined by first defining a > > CREATE

Re: JIT compiling with LLVM v9.0

On 26.01.2018 22:38, Andres Freund wrote: And without it perf is not able to unwind stack trace for generated code. You can work around that by using --call-graph lbr with a sufficiently new perf. That'll not know function names et al, but at least the parent will be associated correctly.

Re: [HACKERS] path toward faster partition pruning

Hi Amit, On 01/26/2018 04:17 AM, Amit Langote wrote: I made a few of those myself in the updated patches. Thanks a lot again for your work on this. This needs a rebase. Best regards, Jesper

Re: Logical Decoding and HeapTupleSatisfiesVacuum assumptions

On 29 January 2018 at 13:34, Tomas Vondra wrote: > The important detail is that we only really care > about aborts in transactions that modified catalogs in some way (e.g. by > doing DDL). But we can safely decode (and stream) changes up to the > point when the

Re: [HACKERS] [PATCH] Lockable views

On Fri, 26 Jan 2018 21:30:49 +0900 Yugo Nagata wrote: > On Thu, 25 Jan 2018 20:51:41 +1300 > Thomas Munro wrote: > > > On Sun, Dec 31, 2017 at 11:57 PM, Yugo Nagata wrote: > > > On Fri, 29 Dec 2017 23:39:39 +0900 (JST) >

Re: A Generic Question about Generic type subscripting

Hannu Krosing writes: > I started looking at the thread about "Generic type subscripting" and am > wondering, why does it take the approach of modifying pg_type and > modifying lots of internal functions, when instead it could be defined > in a much lighter and less

Re: [HACKERS] MERGE SQL Statement for PG11

Simon Riggs writes: > On 29 January 2018 at 15:07, Robert Haas wrote: >> An argument could be made that this patch is already too late for PG >> 11, because it's a major feature that was not submitted in relatively >> complete form before the

Re: [HACKERS] MERGE SQL Statement for PG11

On 29 January 2018 at 15:44, Bruce Momjian wrote: > On Mon, Jan 29, 2018 at 03:12:23PM +, Simon Riggs wrote: >> On 29 January 2018 at 14:55, Pavel Stehule wrote: >> >> > My note was not against MERGE or INSERT ON CONFLICT. If I understand to >> >

Re: [HACKERS] MERGE SQL Statement for PG11

On 01/29/2018 11:13 AM, Simon Riggs wrote: > On 29 January 2018 at 15:44, Bruce Momjian wrote: >> Uh, if we know we are going to get question on this, the patch had >> better have an explanation of when to use it. Pushing the problem to >> later doesn't seem helpful. > > What

Re: [HACKERS] MERGE SQL Statement for PG11

On Mon, Jan 29, 2018 at 03:12:23PM +, Simon Riggs wrote: > On 29 January 2018 at 14:55, Pavel Stehule wrote: > > > My note was not against MERGE or INSERT ON CONFLICT. If I understand to this > > topic, I agree so these commands should be implemented separately. But

Re: Built-in connection pooling

Bruce>Yes, it would impact applications and you are right most applications could not handle that cleanly. I would disagree here. We are discussing applications that produce "lots of idle" connections, aren't we? That typically comes from an application-level connection pool. Most of the

Re: [HACKERS] Custom compression methods

On Mon, 29 Jan 2018 17:29:29 +0300 Ildar Musin wrote: > > Patch applies cleanly, builds without any warnings, documentation > builds ok, all tests pass. > > A remark for the committers. The patch is quite big, so I really wish > more reviewers looked into it for more

Re: Built-in connection pooling

On Mon, Jan 29, 2018 at 04:02:22PM +, Vladimir Sitnikov wrote: > Bruce>Yes, it would impact applications and you are right most applications > could not handle that cleanly. > > I would disagree here. > We are discussing applications that produce "lots of idle" connections, aren't > we? That

Re: [HACKERS] MERGE SQL Statement for PG11

On 29 January 2018 at 16:06, Tom Lane wrote: > Simon Riggs writes: >> On 29 January 2018 at 15:07, Robert Haas wrote: >>> An argument could be made that this patch is already too late for PG >>> 11, because it's a major feature

Re: Cancelling parallel query leads to segfault

On Sat, Jan 27, 2018 at 10:45 PM, Andres Freund wrote: > Hi Peter (and others who mucked around with related code), > > While testing another patch I found that cancelling a parallel query on > master segfaults the leader in an interesting manner: ... > It's clearly not OK to

Re: \describe*

On Mon, Jan 29, 2018 at 02:51:53PM +, Ryan Murphy wrote: > > > > >What I propose is in fact a server command, >which at least three of > > >the other popular RDBMSs already have. > > > Well to actually implement it, it would probably be a client command, > because that's what \d* are. Why

Re: [HACKERS] path toward faster partition pruning

Hi Jesper. On 2018/01/29 22:13, Jesper Pedersen wrote: > Hi Amit, > > On 01/26/2018 04:17 AM, Amit Langote wrote: >> I made a few of those myself in the updated patches. >> >> Thanks a lot again for your work on this. >> > > This needs a rebase. AFAICS, v22 cleanly applies to HEAD (c12693d8f3

Re: PATCH: Exclude unlogged tables from base backups

On Tue, Jan 30, 2018 at 5:45 AM, Adam Brightwell wrote: > On Mon, Jan 29, 2018 at 1:17 PM, David Steele wrote: >> On 1/29/18 9:13 AM, David Steele wrote: >>> On 1/29/18 5:28 AM, Masahiko Sawada wrote: But I have a question; can we

Re: JIT compiling with LLVM v9.1

On 29 January 2018 at 22:53, Andres Freund wrote: > Hi, > > On 2018-01-23 23:20:38 -0800, Andres Freund wrote: > > == Code == > > > > As the patchset is large (500kb) and I'm still quickly evolving it, I do > > not yet want to attach it. The git tree is at > >

Re: Security leak with trigger functions?

On 1/22/18 16:04, Chapman Flack wrote: >> PostgreSQL only allows a trigger action of "call this function", so in >> the SQL standard context that would mean we'd need to check the EXECUTE >> privilege of the owner of the trigger. The trick is figuring out who >> the owner is. If it's the

Re: [HACKERS] MERGE SQL Statement for PG11

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 prior to commit. My understanding of this meaning is different than yours. It should not

Re: [HACKERS] GnuTLS support

On 2018-01-17 12:30:16 -0500, Peter Eisentraut wrote: > On 1/2/18 10:35, Peter Eisentraut wrote: > > On 11/26/17 20:05, Andreas Karlsson wrote: > >> I have now implemented this in the attached patch (plus added support > >> for channel binding and rebased it) but I ran into one issue which I >

Re: [HACKERS] GnuTLS support

On Mon, Jan 29, 2018 at 06:24:18PM -0800, Andres Freund wrote: > FWIW, I'm -0.5 on adding gnutls support. I've not seen any non-vague > arguments for it, and having debugged gnutls using applications in the > past, I'm not convinced we're not primarily increasing our workload by > adding support.

Re: JIT compiling with LLVM v9.0

Hi, On Mon, Jan 29, 2018 at 10:40 AM, Andres Freund wrote: > Hi, > > On 2018-01-29 10:28:18 -0800, Jeff Davis wrote: >> OK. How about this: are you open to changes that move us in the >> direction of extensibility later? (By this I do *not* mean imposing a >> bunch of

Re: [HACKERS] GnuTLS support

On Mon, Jan 29, 2018 at 09:16:56PM -0500, Peter Eisentraut wrote: > On 1/28/18 23:43, Michael Paquier wrote: >> The comment at the top of PQinitSSL mentions OpenSSL, you may want to >> get rid of it as well. > > I think that whole business is actually obsolete as of OpenSSL 1.1.0 and > not

Re: [HACKERS] [PATCH] Lockable views

> Attached is the updated patch v5 including fixing SGML and rebase to HEAD. You need to DROP VIEW lock_view4 and lock_view5 in the regression test as well. Best regards, -- Tatsuo Ishii SRA OSS, Inc. Japan English: http://www.sraoss.co.jp/index_en.php Japanese:http://www.sraoss.co.jp

RE: Temporary tables prevent autovacuum, leading to XID wraparound

From: Masahiko Sawada [mailto:sawada.m...@gmail.com] > On Mon, Jan 29, 2018 at 3:33 PM, Tsunakawa, Takayuki > wrote: > > I can understand your concern. On the other hand, it's unfair that one > database could monopolize all workers, because other databases might

Re: [HACKERS] GnuTLS support

On Mon, Jan 29, 2018 at 07:39:33PM -0500, Peter Eisentraut wrote: > I think most users actually still think about the whole topic as "SSL", > and the leading library is called "OpenSSL", so I think we're fine. Yes, that's my impression on the matter as well. While renaming the client-side

Re: [HACKERS] GnuTLS support

Andres Freund writes: > FWIW, I'm -0.5 on adding gnutls support. I've not seen any non-vague > arguments for it, and having debugged gnutls using applications in the > past, I'm not convinced we're not primarily increasing our workload by > adding support. If gnutls would

Re: [HACKERS] GnuTLS support

Hi, On 2018-01-29 22:41:53 -0500, Tom Lane wrote: > But I think a big part of the value here is to verify that we've > cleaned up our internal APIs to the point where a different SSL/TLS > implementation *could* be rolled underneath. Yea, I completely agree with that. > As part of that, we

Re: Enhance pg_stat_wal_receiver view to display connected host

On Mon, Jan 29, 2018 at 7:06 PM, Michael Paquier wrote: > On Tue, Jan 16, 2018 at 05:56:22PM +1100, Haribabu Kommi wrote: > > Without PQhostaddr() function, for the connections where the host is not > > specified, it will be difficult to find out to remote server. > >

Re: Temporary tables prevent autovacuum, leading to XID wraparound

On Mon, Jan 29, 2018 at 3:33 PM, Tsunakawa, Takayuki wrote: > From: Masahiko Sawada [mailto:sawada.m...@gmail.com] >> What I thought is that a worker reports these two values after scanned >> pg_class and after freezed a table. The launcher decides to launch a new

Re: Enhance pg_stat_wal_receiver view to display connected host

On Tue, Jan 30, 2018 at 03:10:12PM +1100, Haribabu Kommi wrote: > Ok, understood. As the libpq gives preference to hostaddr connection > parameter than host while connecting. How about going with one column > "remote_host" that displays either hostaddr(if exists) or hostname. So that > one column

Re: [HACKERS] [PATCH] Lockable views

On Tue, 30 Jan 2018 13:58:30 +0900 (JST) Tatsuo Ishii wrote: > > Attached is the updated patch v5 including fixing SGML and rebase to HEAD. > > You need to DROP VIEW lock_view4 and lock_view5 in the regression > test as well. Thank you for reviewing the patch. I fixed this

Re: [HACKERS] [PATCH] Lockable views

>> You need to DROP VIEW lock_view4 and lock_view5 in the regression >> test as well. > > Thank you for reviewing the patch. > > I fixed this and attached a updated patch v6. Looks good to me. If there's no objection, especially from Thomas Munro, I will mark this as "ready for committer".

Re: [HACKERS] [PATCH] Lockable views

On Tue, Jan 30, 2018 at 6:48 PM, Tatsuo Ishii wrote: >>> You need to DROP VIEW lock_view4 and lock_view5 in the regression >>> test as well. >> >> Thank you for reviewing the patch. >> >> I fixed this and attached a updated patch v6. > > Looks good to me. If there's no

Re: [HACKERS] Custom compression methods

Hello Ildus, On 29.01.2018 14:44, Ildus Kurbangaliev wrote: Thanks! Attached new version of the patch. Patch applies cleanly, builds without any warnings, documentation builds ok, all tests pass. A remark for the committers. The patch is quite big, so I really wish more reviewers looked

Re: [HACKERS] MERGE SQL Statement for PG11

On 29 January 2018 at 14:55, Pavel Stehule wrote: > My note was not against MERGE or INSERT ON CONFLICT. If I understand to this > topic, I agree so these commands should be implemented separately. But if we > use two commands with some intersection, there can be nice to

Re: Built-in connection pooling

On Mon, Jan 29, 2018 at 11:57:36AM +0300, Konstantin Knizhnik wrote: > Right now, if you hit max_connections, we start rejecting new > connections. Would it make sense to allow an option to exit idle > connections when this happens so new users can connect? > > It will require

Re: [HACKERS] MERGE SQL Statement for PG11

On 29 January 2018 at 14:19, Pavel Stehule wrote: >> The concurrency rules are very simple: >> If a MATCHED row is concurrently updated/deleted >> 1. We run EvalPlanQual >> 2. If the updated row is gone EPQ returns NULL slot or EPQ returns a >> row with NULL values, then

Re: [HACKERS] WIP: Aggregation push-down

On Mon, Jan 29, 2018 at 3:32 AM, Antonin Houska wrote: > I think of a variant of this: implement an universal function that tests the > binary values for equality (besides the actual arguments, caller would have to > pass info like typlen, typalign, typbyval for each argument,

Re: [HACKERS] WIP: Aggregation push-down

On 01/29/18 03:32, Antonin Houska wrote: > Robert Haas wrote: >>> only take place if we had a special equality operator which distinguishes >>> the >>> *binary* values (I don't know yet how to store this operator the catalog --- ... >> We don't have an operator that tests

Re: [HACKERS] MERGE SQL Statement for PG11

Hi 2018-01-29 15:11 GMT+01:00 Simon Riggs : > On 26 January 2018 at 11:25, Simon Riggs wrote: > > On 24 January 2018 at 04:12, Simon Riggs wrote: > >> On 24 January 2018 at 01:35, Peter Geoghegan wrote: > >>> >

Re: [HACKERS] [PATCH] Vacuum: Update FSM more frequently

On Mon, Jan 29, 2018 at 4:12 AM, Masahiko Sawada wrote: > On Sat, Jul 29, 2017 at 9:42 AM, Claudio Freire > wrote: >> Introduce a tree pruning threshold to FreeSpaceMapVacuum that avoids >> recursing into branches that already contain enough free

Re: [HACKERS] MERGE SQL Statement for PG11

2018-01-29 15:40 GMT+01:00 Simon Riggs : > On 29 January 2018 at 14:19, Pavel Stehule > wrote: > > >> The concurrency rules are very simple: > >> If a MATCHED row is concurrently updated/deleted > >> 1. We run EvalPlanQual > >> 2. If the updated

Re: Wait for parallel workers to attach

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 allow > leader backend to rely on number of workers that are successfully >

Re: [HACKERS] MERGE SQL Statement for PG11

On Tue, Jan 23, 2018 at 8:51 AM, Simon Riggs wrote: > This is complete and pretty clean now. 1200 lines of code, plus docs and > tests. > > I'm expecting to commit this and then come back for the Partitioning & > RLS later, but will wait a few days for comments and other

Re: [HACKERS] MERGE SQL Statement for PG11

On 29 January 2018 at 15:07, Robert Haas wrote: > Moreover, the patch should have had meaningful review from people not > involved in writing it, and that is a process that generally takes a > few months or at least several weeks, not a few days. The code is about 1200

  1   2   >