Re: [HACKERS] [COMMITTERS] pgsql: Account for catalog snapshot in PGXACT->xmin updates.

2016-12-06 Thread Robert Haas
On Tue, Nov 15, 2016 at 3:55 PM, Tom Lane wrote: > Account for catalog snapshot in PGXACT->xmin updates. > > The CatalogSnapshot was not plugged into SnapshotResetXmin()'s accounting > for whether MyPgXact->xmin could be cleared or advanced. In normal > transactions this was

Re: [HACKERS] [COMMITTERS] pgsql: Add support for restrictive RLS policies

2016-12-06 Thread Stephen Frost
Andres, * Andres Freund (and...@anarazel.de) wrote: > On 2016-12-05 20:51:02 +, Stephen Frost wrote: > > Add support for restrictive RLS policies > This is missing a catversion bump. Ewps, apologies and thanks for pointing it out. Fixed. Stephen signature.asc Description: Digital

Re: [HACKERS] PSQL commands: \quit_if, \quit_unless

2016-12-06 Thread Fabien COELHO
But if it does make sense to share, then that's another reason for not designing something ad-hoc for psql: integrating it later will be more work in total. Yes, but not much: evaluating "[!] :var" special syntax would be dropped, but I do not think that it is the main issue with these

Re: [HACKERS] pgcrypto compilation error due to stack-allocated EVP_CIPHER_CTX

2016-12-06 Thread Asif Naeem
Thanks for updated patch. Although EVP_CIPHER_CTX_cleanup() seems deprecated in OpenSSL >= 1.1.0 i.e. # if OPENSSL_API_COMPAT < 0x1010L > # define EVP_CIPHER_CTX_init(c) EVP_CIPHER_CTX_reset(c) > # define EVP_CIPHER_CTX_cleanup(c) EVP_CIPHER_CTX_reset(c) > # endif I guess use of

Re: [HACKERS] tzdata 2016j

2016-12-06 Thread Tom Lane
Vladimir Borodin writes: > Any chance to get tzdata 2016j in supported branches? When the next scheduled releases come around (February), we'll update to whatever tzdata is current at that time. regards, tom lane -- Sent via pgsql-hackers mailing

[HACKERS] tzdata 2016j

2016-12-06 Thread Vladimir Borodin
Hi all. Any chance to get tzdata 2016j in supported branches? -- May the force be with you… https://simply.name

Re: [HACKERS] raw output from copy

2016-12-06 Thread Kohei KaiGai
2016-12-06 16:59 GMT+09:00 Pavel Stehule : > > > 2016-12-06 1:50 GMT+01:00 Kohei KaiGai : >> >> 2016-12-05 22:45 GMT+09:00 Pavel Stehule : >> > >> > There are more goals: >> > >> > 1. user friendly import of text or binary data

Re: [HACKERS] UNDO and in-place update

2016-12-06 Thread Robert Haas
On Mon, Dec 5, 2016 at 4:49 AM, Amit Kapila wrote: > I can very well understand the reason for not doing so (IIUC, it is > about complexity and time to get it right when we are already trying > to solve one big and complex problem of the system), but saying most > of the

Re: [HACKERS] [COMMITTERS] pgsql: Account for catalog snapshot in PGXACT->xmin updates.

2016-12-06 Thread Tom Lane
Robert Haas writes: > On Tue, Nov 15, 2016 at 3:55 PM, Tom Lane wrote: >> Account for catalog snapshot in PGXACT->xmin updates. > It seems to me that this makes it possible for > ThereAreNoPriorRegisteredSnapshots() to fail spuriously. The only > core

Re: [HACKERS] WIP: Faster Expression Processing and Tuple Deforming (including JIT)

2016-12-06 Thread Tom Lane
Andres Freund writes: > I'm posting a quite massive series of WIP patches here, to get some > feedback. I guess the $64 question that has to be addressed here is whether we're prepared to accept LLVM as a run-time dependency. There are some reasons why we might not be: *

Re: [HACKERS] Parallel execution and prepared statements

2016-12-06 Thread Robert Haas
On Tue, Dec 6, 2016 at 1:07 PM, Tom Lane wrote: > Robert Haas writes: >> Done. > > The comment seems quite confused now: > > * If a tuple count was supplied or data is being written to relation, we > * must force the plan to run without

Re: [HACKERS] PSQL commands: \quit_if, \quit_unless

2016-12-06 Thread Robert Haas
On Tue, Dec 6, 2016 at 8:45 AM, Fabien COELHO wrote: > There are some differences: pgbench already had one operator at a time > expressions, while psql has survived till today with none, which suggest a > less pressing need. I don't really think so. People have been wanting

Re: [HACKERS] Parallel execution and prepared statements

2016-12-06 Thread Robert Haas
On Mon, Dec 5, 2016 at 5:18 AM, Albe Laurenz wrote: > Tobias Bussmann wrote: >>> I think if we don't see any impact then we should backpatch this >>> patch. However, if we decide to go some other way, then I can provide >>> a separate patch for back branches. BTW, what

Re: [HACKERS] Logical Replication WIP

2016-12-06 Thread Peter Eisentraut
On 12/5/16 6:24 PM, Petr Jelinek wrote: > I think that the removal of changes to ReplicationSlotAcquire() that you > did will result in making it impossible to reacquire temporary slot once > you switched to different one in the session as the if (active_pid != 0) > will always be true for temp

Re: [HACKERS] Separate connection handling from backends

2016-12-06 Thread Kevin Grittner
On Mon, Dec 5, 2016 at 6:54 PM, Jim Nasby wrote: > On 12/5/16 2:14 PM, David Fetter wrote: >> What do you see as the relationship between this proposal and the >> earlier one for admission control? >> >>

Re: [HACKERS] [COMMITTERS] pgsql: Account for catalog snapshot in PGXACT->xmin updates.

2016-12-06 Thread Robert Haas
On Tue, Dec 6, 2016 at 1:36 PM, Tom Lane wrote: > Robert Haas writes: >> On Tue, Nov 15, 2016 at 3:55 PM, Tom Lane wrote: >>> Account for catalog snapshot in PGXACT->xmin updates. > >> It seems to me that this makes it possible for

Re: [HACKERS] Parallel execution and prepared statements

2016-12-06 Thread Tom Lane
Robert Haas writes: > Done. The comment seems quite confused now: * If a tuple count was supplied or data is being written to relation, we * must force the plan to run without parallelism, because we might exit * early. Exit early is exactly what we *won't*

Re: [HACKERS] Back-patch use of unnamed POSIX semaphores for Linux?

2016-12-06 Thread Tatsuo Ishii
> Potential risks involving minor upgrades are far higher than the risks > involved by systemd, so -1 for a backpatch seen from here. As long as we would have a compile time switch to enable/disable the back-patched feature, it seems it would be acceptable. In the worst case, the back-patching

Re: [HACKERS] Quorum commit for multiple synchronous replication.

2016-12-06 Thread Kyotaro HORIGUCHI
At Wed, 7 Dec 2016 13:26:38 +0900, Michael Paquier wrote in

[HACKERS] [sqlsmith] Crash in tsquery_rewrite/QTNBinary

2016-12-06 Thread Andreas Seltenreich
Hi, the following query crashes master as of 4212cb7. select ts_rewrite( tsquery_phrase( tsquery $$'sanct' & 'peter'$$, tsquery $$'5' <-> '6'$$, 42), tsquery $$'5' <-> '6'$$, plainto_tsquery('I') ); Backtrace below. regards,

Re: [HACKERS] Separate connection handling from backends

2016-12-06 Thread Jim Nasby
On 12/6/16 1:46 PM, Adam Brusselback wrote: BTW, it just occurred to me that having this separation would make it relatively easy to support re-directing DML queries from a replica to the master; if the backend throws the error indicating you tried to write data, the connection

Re: [HACKERS] Assignment of valid collation for SET operations on queries with UNKNOWN types.

2016-12-06 Thread Michael Paquier
On Wed, Dec 7, 2016 at 4:24 PM, Michael Paquier wrote: > On Tue, Dec 6, 2016 at 10:42 PM, Rahila Syed wrote: >> Thank you for suggestion. Attached is a patch which resolves the columns >> with literal constants as TEXT for view creation. You

[HACKERS] Partitionning: support for Truncate Table WHERE

2016-12-06 Thread legrand legrand
Hello, Working in a DSS environment, we often need to truncate table partitions regarding a WHERE condition and have to: - query the dictionnary to identify thoses partitions, - build SQL statements, - truncate all partitions covered by the WHERE condition - eventually delete the rest ...

Re: [HACKERS] Quorum commit for multiple synchronous replication.

2016-12-06 Thread Fujii Masao
On Tue, Dec 6, 2016 at 6:57 PM, Masahiko Sawada wrote: > On Tue, Dec 6, 2016 at 1:11 PM, Fujii Masao wrote: >> On Mon, Nov 28, 2016 at 8:03 PM, Masahiko Sawada >> wrote: >>> On Sat, Nov 26, 2016 at 10:27 PM, Michael Paquier

Re: [HACKERS] Separate connection handling from backends

2016-12-06 Thread Craig Ringer
On 7 December 2016 at 10:19, Tom Lane wrote: > What it sounds like to me is building a connection pooler into the > backend. I'm not really convinced we ought to go there. If we do, it probably needs to be able to offer things that out-of-tree ones can't. The main things I

Re: [HACKERS] WIP: Faster Expression Processing and Tuple Deforming (including JIT)

2016-12-06 Thread Craig Ringer
On 7 December 2016 at 14:39, Craig Ringer wrote: > On 7 December 2016 at 04:13, Robert Haas wrote: > >> I wonder how feasible it would be to make this a run-time dependency >> rather than a compile option. > > Or something that's compiled with the

Re: [HACKERS] tzdata 2016j

2016-12-06 Thread Vladimir Borodin
> 6 дек. 2016 г., в 19:19, David Fetter написал(а): > > On Tue, Dec 06, 2016 at 10:52:47AM -0500, Tom Lane wrote: >> Vladimir Borodin writes: >>> Any chance to get tzdata 2016j in supported branches? >> >> When the next scheduled releases come around

Re: [HACKERS] Assignment of valid collation for SET operations on queries with UNKNOWN types.

2016-12-06 Thread Michael Paquier
On Tue, Dec 6, 2016 at 10:42 PM, Rahila Syed wrote: > Hello, > >>And ideally fix things so >>that the type of the view column will be resolved as text, so that you >>don't hit this condition in the first place; but there is no good that >>comes out of allowing a view to be

Short reads in hash indexes (was: [HACKERS] [sqlsmith] Failed assertion in _hash_splitbucket_guts)

2016-12-06 Thread Andreas Seltenreich
Amit Kapila writes: > On Sat, Dec 3, 2016 at 3:44 PM, Andreas Seltenreich > wrote: >> Amit Kapila writes: >> >>> [2. text/x-diff; fix_hash_bucketsplit_sqlsmith_v1.patch] >> Ok, I'll do testing with the patch applied. Good news: the assertion hasn't fired since the patch is

Re: [HACKERS] Partitionning: support for Truncate Table WHERE

2016-12-06 Thread Craig Ringer
On 7 December 2016 at 07:29, legrand legrand wrote: > Working in a DSS environment, we often need to truncate table partitions > regarding a WHERE condition and have to > [...] > Would be pleased to ear your feedback regarding this. It sounds like something that'd

Re: [HACKERS] Separate connection handling from backends

2016-12-06 Thread Jim Nasby
On 12/6/16 10:34 PM, Craig Ringer wrote: In other words, we could start to separate session state from executor state in a limited manner. That'd definitely be valuable, IMO; it's a real shame that Pg's architecture so closely couples the two. So - is just doing "PgInCoreBouncer" a good idea?

Re: [HACKERS] Partitionning: support for Truncate Table WHERE

2016-12-06 Thread Amit Langote
On 2016/12/07 15:26, Craig Ringer wrote: > On 7 December 2016 at 07:29, legrand legrand > wrote: > >> Working in a DSS environment, we often need to truncate table partitions >> regarding a WHERE condition and have to >> [...] >> Would be pleased to ear your feedback

Re: [HACKERS] Quorum commit for multiple synchronous replication.

2016-12-06 Thread Michael Paquier
On Wed, Dec 7, 2016 at 2:49 PM, Kyotaro HORIGUCHI wrote: > Aside from measurement of the two sorting methods, I'd like to > point out that quorum commit basically doesn't need > sorting. Counting conforming santdbys while scanning the > walsender(receiver) LSN

Re: [HACKERS] Separate connection handling from backends

2016-12-06 Thread Jim Nasby
On 12/6/16 6:19 PM, Tom Lane wrote: I'm kind of mystified how a simple code restructuring could solve the fundamental problems with a large number of backends. It sounds like what you're describing would just push the problem around, you would end up with some other maximum instead,

Re: [HACKERS] Back-patch use of unnamed POSIX semaphores for Linux?

2016-12-06 Thread Craig Ringer
On 7 December 2016 at 10:53, Tom Lane wrote: > Just saw another report of what's probably systemd killing off Postgres' > SysV semaphores, as we've discussed previously at, eg, > https://www.postgresql.org/message-id/flat/57828C31.5060409%40gmail.com > Since the systemd people

Re: [HACKERS] Push down more full joins in postgres_fdw

2016-12-06 Thread Ashutosh Bapat
On Wed, Dec 7, 2016 at 1:57 AM, Robert Haas wrote: > On Mon, Dec 5, 2016 at 6:20 AM, Ashutosh Bapat > wrote: >> 4. I am still not happy with this change >> +/* >> + * Since (1) the expressions in foreignrel's reltarget

Re: [HACKERS] Push down more full joins in postgres_fdw

2016-12-06 Thread Ashutosh Bapat
> > > Ashutosh proposed this to do the comparison: > > On 2016/11/22 18:28, Ashutosh Bapat wrote: >> >> I guess, the reason why you are doing it this way, is SELECT clause for >> the >> outermost query gets deparsed before FROM clause. For later we call >> deparseRangeTblRef(), which builds the

Re: [HACKERS] WIP: Faster Expression Processing and Tuple Deforming (including JIT)

2016-12-06 Thread Craig Ringer
On 7 December 2016 at 04:13, Robert Haas wrote: > I wonder how feasible it would be to make this a run-time dependency > rather than a compile option. Or something that's compiled with the server, but produces a separate .so that's the only thing that links to LLVM. So

[HACKERS] Back-patch use of unnamed POSIX semaphores for Linux?

2016-12-06 Thread Tom Lane
Just saw another report of what's probably systemd killing off Postgres' SysV semaphores, as we've discussed previously at, eg, https://www.postgresql.org/message-id/flat/57828C31.5060409%40gmail.com Since the systemd people are generally impervious to suggestions that they might be mistaken, I do

Re: [HACKERS] Push down more full joins in postgres_fdw

2016-12-06 Thread Etsuro Fujita
On 2016/12/07 5:27, Robert Haas wrote: On Mon, Dec 5, 2016 at 6:20 AM, Ashutosh Bapat wrote: 4. I am still not happy with this change +/* + * Since (1) the expressions in foreignrel's reltarget doesn't contain + * any PHVs and (2)

Re: [HACKERS] Back-patch use of unnamed POSIX semaphores for Linux?

2016-12-06 Thread Tom Lane
Robert Haas writes: > On Tue, Dec 6, 2016 at 9:53 PM, Tom Lane wrote: >> I think we should give serious consideration to back-patching commit >> ecb0d20a9, which changed the default semaphore type to unnamed-POSIX >> on Linux. > Urk. That sounds like

Re: [HACKERS] [GENERAL] Select works only when connected from login postgres

2016-12-06 Thread Tom Lane
Joseph Brenner writes: > Well, my take would be that if you've taken the trouble to set an > empty string as the PAGER that means something, and it probably means > you don't want any pager to be used. Yeah, on reflection that argument seems pretty persuasive. So I propose

Re: [HACKERS] Back-patch use of unnamed POSIX semaphores for Linux?

2016-12-06 Thread Robert Haas
On Tue, Dec 6, 2016 at 9:53 PM, Tom Lane wrote: > Just saw another report of what's probably systemd killing off Postgres' > SysV semaphores, as we've discussed previously at, eg, > https://www.postgresql.org/message-id/flat/57828C31.5060409%40gmail.com > Since the systemd

Re: [HACKERS] Back-patch use of unnamed POSIX semaphores for Linux?

2016-12-06 Thread Michael Paquier
On Wed, Dec 7, 2016 at 1:43 PM, Robert Haas wrote: > Urk. That sounds like a scary thing to back-patch. The fact that the > buildfarm has reported no problems is good as far as it goes, but user > environments can be expected to be considerably more diverse than the >

Re: [HACKERS] Quorum commit for multiple synchronous replication.

2016-12-06 Thread Michael Paquier
On Wed, Dec 7, 2016 at 12:32 PM, Fujii Masao wrote: > So, isn't it better to compare the performance of some algorithms and > confirm which is the best for quorum commit? Since this code is hot, i.e., > can be very frequently executed, I'd like to avoid waste of cycle as

Re: [HACKERS] Separate connection handling from backends

2016-12-06 Thread Greg Stark
On 5 December 2016 at 19:48, Jim Nasby wrote: > One solution to this would be to segregate connection handling from actual > backends, somewhere along the lines of separating the main loop from the > switch() that handles libpq commands. Benefits: I'm kind of mystified

Re: [HACKERS] Declarative partitioning - another take

2016-12-06 Thread Robert Haas
On Wed, Nov 30, 2016 at 10:56 AM, Amit Langote wrote: > The latest patch I posted earlier today has this implementation. I decided to try out these patches today with #define CLOBBER_CACHE_ALWAYS 1 in pg_config_manual.h, which found a couple of problems: 1.

Re: [HACKERS] tzdata 2016j

2016-12-06 Thread David Fetter
On Tue, Dec 06, 2016 at 10:52:47AM -0500, Tom Lane wrote: > Vladimir Borodin writes: > > Any chance to get tzdata 2016j in supported branches? > > When the next scheduled releases come around (February), we'll update > to whatever tzdata is current at that time. I'm guessing

Re: [HACKERS] Separate connection handling from backends

2016-12-06 Thread Tom Lane
Greg Stark writes: > On 5 December 2016 at 19:48, Jim Nasby wrote: >> One solution to this would be to segregate connection handling from actual >> backends, somewhere along the lines of separating the main loop from the >> switch() that handles libpq

Re: [HACKERS] WIP: Faster Expression Processing and Tuple Deforming (including JIT)

2016-12-06 Thread Andres Freund
Hi, On 2016-12-06 13:56:28 -0500, Tom Lane wrote: > Andres Freund writes: > > I'm posting a quite massive series of WIP patches here, to get some > > feedback. > > I guess the $64 question that has to be addressed here is whether we're > prepared to accept LLVM as a

Re: [HACKERS] WIP: Faster Expression Processing and Tuple Deforming (including JIT)

2016-12-06 Thread Andres Freund
On 2016-12-06 15:13:21 -0500, Robert Haas wrote: > Presumably this is going to need to be something that a user can get > via yum install or apt-get install on common systems. Right. apt-get install llvm-dev (or llvm-3.9-dev or such if you want to install a specific version), does the trick

Re: [HACKERS] WIP: Faster Expression Processing and Tuple Deforming (including JIT)

2016-12-06 Thread Nico Williams
On Tue, Dec 06, 2016 at 12:27:51PM -0800, Andres Freund wrote: > On 2016-12-06 14:19:21 -0600, Nico Williams wrote: > > A bigger concern might be interface stability. IIRC the LLVM C/C++ > > interfaces are not very stable, but bitcode is. > > The C API is a lot more stable than the C++ bit,

Re: [HACKERS] WIP: Faster Expression Processing and Tuple Deforming (including JIT)

2016-12-06 Thread Andres Freund
On 2016-12-06 11:10:59 -0800, Andres Freund wrote: > > * Are there any currently-interesting platforms that LLVM doesn't work > > for? (I'm worried about RISC-V as much as legacy systems.) > > LLVM itself I don't think is a problem, it seems to target a wide range > of platforms. The platforms

Re: [HACKERS] Compiler warnings

2016-12-06 Thread Stephen Frost
All, * Stephen Frost (sfr...@snowman.net) wrote: > Not sure if anyone else has been seeing these, but I'm getting a bit > tired of them. Neither is a live bug, but they also seem pretty simple > to fix. The attached patch makes both of these warnings go away. At > least for my common build,

Re: [HACKERS] Compiler warnings

2016-12-06 Thread Robert Haas
On Tue, Dec 6, 2016 at 3:23 PM, Stephen Frost wrote: > * Stephen Frost (sfr...@snowman.net) wrote: >> Not sure if anyone else has been seeing these, but I'm getting a bit >> tired of them. Neither is a live bug, but they also seem pretty simple >> to fix. The attached patch

Re: [HACKERS] WIP: Faster Expression Processing and Tuple Deforming (including JIT)

2016-12-06 Thread Robert Haas
On Tue, Dec 6, 2016 at 2:10 PM, Andres Freund wrote: >> * The sheer mass of the dependency. What's the installed footprint of >> LLVM, versus a Postgres server? How hard is it to install from source? > > Worked for me first try, but I'm perhaps not the best person to judge.

Re: [HACKERS] WIP: Faster Expression Processing and Tuple Deforming (including JIT)

2016-12-06 Thread Tom Lane
Andres Freund writes: > On 2016-12-06 13:56:28 -0500, Tom Lane wrote: >> I guess the $64 question that has to be addressed here is whether we're >> prepared to accept LLVM as a run-time dependency. There are some reasons >> why we might not be: > Indeed. It'd only be a soft

Re: [HACKERS] WIP: Faster Expression Processing and Tuple Deforming (including JIT)

2016-12-06 Thread Andres Freund
On 2016-12-06 15:25:44 -0500, Tom Lane wrote: > Andres Freund writes: > > On 2016-12-06 13:56:28 -0500, Tom Lane wrote: > >> I guess the $64 question that has to be addressed here is whether we're > >> prepared to accept LLVM as a run-time dependency. There are some reasons >

Re: [HACKERS] Hash Indexes

2016-12-06 Thread Jeff Janes
On Thu, Dec 1, 2016 at 10:54 PM, Amit Kapila wrote: > On Thu, Dec 1, 2016 at 8:56 PM, Robert Haas wrote: > > On Thu, Dec 1, 2016 at 12:43 AM, Amit Kapila > wrote: > >> On Thu, Dec 1, 2016 at 2:18 AM, Robert Haas

Re: [HACKERS] raw output from copy

2016-12-06 Thread Pavel Stehule
2016-12-06 1:50 GMT+01:00 Kohei KaiGai : > 2016-12-05 22:45 GMT+09:00 Pavel Stehule : > > > > There are more goals: > > > > 1. user friendly import of text or binary data - import text data (with > > psql) from file is possible - but you have to load

Re: [HACKERS] Adding in docs the meaning of pg_stat_replication.sync_state

2016-12-06 Thread Fujii Masao
On Tue, Dec 6, 2016 at 4:54 PM, Michael Paquier wrote: > On Tue, Dec 6, 2016 at 4:38 PM, Fujii Masao wrote: >> I changed the order of descriptions of the walsender state in >> intuitive one rather than alphabetical one. Also I enhanced >> the

Re: [HACKERS] pg_dump, pg_dumpall and data durability

2016-12-06 Thread Michael Paquier
On Tue, Dec 6, 2016 at 6:00 PM, Fujii Masao wrote: > One idea is to provide the utility or extension which fsync's the specified > files and directories (including all the files under them). It may be > overkill, > though. But it would be useful for other purposes, for

Re: [HACKERS] Quorum commit for multiple synchronous replication.

2016-12-06 Thread Masahiko Sawada
On Tue, Dec 6, 2016 at 1:11 PM, Fujii Masao wrote: > On Mon, Nov 28, 2016 at 8:03 PM, Masahiko Sawada > wrote: >> On Sat, Nov 26, 2016 at 10:27 PM, Michael Paquier >> wrote: >>> On Tue, Nov 15, 2016 at 7:08 PM, Masahiko

Re: [HACKERS] pg_dump, pg_dumpall and data durability

2016-12-06 Thread Fujii Masao
On Wed, Nov 16, 2016 at 1:27 AM, Robert Haas wrote: > On Sun, Nov 13, 2016 at 4:18 AM, Andres Freund wrote: >> On 2016-11-08 18:18:01 -0500, Tom Lane wrote: >>> I think this might be better addressed by adding something to backup.sgml >>> pointing out

Re: [HACKERS] Quorum commit for multiple synchronous replication.

2016-12-06 Thread Michael Paquier
On Tue, Dec 6, 2016 at 6:57 PM, Masahiko Sawada wrote: > On Tue, Dec 6, 2016 at 1:11 PM, Fujii Masao wrote: >> If M (i.e., number of quorum sync standbys) is enough large, >> your choice would be good. But usually M seems not so large. >> > > Thank

Re: [HACKERS] PSQL commands: \quit_if, \quit_unless

2016-12-06 Thread Fabien COELHO
Hello Robert, Your experience as an seasoned core developer and a committer is probably different:-) Well, everybody can have their own opinion on what is reasonable. Sure. There are times I argue for making a patch smaller (frequent) and times when I argue for making it bigger (rare).

Re: [HACKERS] Hash Indexes

2016-12-06 Thread Amit Kapila
On Tue, Dec 6, 2016 at 1:29 PM, Jeff Janes wrote: > > > I just occasionally insert a bunch of equal tuples, which have to be in > overflow pages no matter how much splitting happens. > > I am getting vacuum errors against HEAD, after about 20 minutes or so (8 > cores). > >

Re: [HACKERS] pgcrypto compilation error due to stack-allocated EVP_CIPHER_CTX

2016-12-06 Thread Asif Naeem
Hi Michael, Thank you for v2 patch, I would like to comment on it. It seems that you have used function EVP_CIPHER_CTX_reset in the patch that was introduced in OpenSSL 1.1.0, older library version might not work now, is it intentional change ?. Regards, Muhammad Asif Naeem On Tue, Dec 6, 2016

Re: [HACKERS] PSQL commands: \quit_if, \quit_unless

2016-12-06 Thread Robert Haas
On Tue, Dec 6, 2016 at 1:28 AM, Fabien COELHO wrote: > First, my experience as a basic patch submitter is that any patch which does > more than one thing at a time, even somehow closely related changes, is > asked to be split into distinct sub-patches, and is harder to get

Re: [HACKERS] Assignment of valid collation for SET operations on queries with UNKNOWN types.

2016-12-06 Thread Rahila Syed
Hello, >And ideally fix things so >that the type of the view column will be resolved as text, so that you >don't hit this condition in the first place; but there is no good that >comes out of allowing a view to be created like this Thank you for suggestion. Attached is a patch which resolves the

Re: [HACKERS] pgcrypto compilation error due to stack-allocated EVP_CIPHER_CTX

2016-12-06 Thread Michael Paquier
On Tue, Dec 6, 2016 at 9:31 PM, Asif Naeem wrote: > Thank you for v2 patch, I would like to comment on it. It seems that you > have used function EVP_CIPHER_CTX_reset in the patch that was introduced in > OpenSSL 1.1.0, older library version might not work now, is it

Re: [HACKERS] WIP: Faster Expression Processing and Tuple Deforming (including JIT)

2016-12-06 Thread Robert Haas
On Tue, Dec 6, 2016 at 1:56 PM, Tom Lane wrote: > Andres Freund writes: >> I'm posting a quite massive series of WIP patches here, to get some >> feedback. > > I guess the $64 question that has to be addressed here is whether we're > prepared to accept

Re: [HACKERS] WIP: Faster Expression Processing and Tuple Deforming (including JIT)

2016-12-06 Thread Andres Freund
On 2016-12-06 14:04:09 -0500, Robert Haas wrote: > I've heard at least one and maybe several PGCon presentations about > people JITing tuple deformation and getting big speedups, and I'd like > to finally hear one from somebody who intends to integrate that into > PostgreSQL. I certainly want to.

Re: [HACKERS] WIP: Faster Expression Processing and Tuple Deforming (including JIT)

2016-12-06 Thread Nico Williams
On Tue, Dec 06, 2016 at 01:56:28PM -0500, Tom Lane wrote: > Andres Freund writes: > > I'm posting a quite massive series of WIP patches here, to get some > > feedback. > > I guess the $64 question that has to be addressed here is whether we're > prepared to accept LLVM as a

Re: [HACKERS] Push down more full joins in postgres_fdw

2016-12-06 Thread Robert Haas
On Mon, Dec 5, 2016 at 6:20 AM, Ashutosh Bapat wrote: > 4. I am still not happy with this change > +/* > + * Since (1) the expressions in foreignrel's reltarget doesn't > contain > + * any PHVs and (2) foreignrel's local_conds is empty,

Re: [HACKERS] WIP: Faster Expression Processing and Tuple Deforming (including JIT)

2016-12-06 Thread Andres Freund
Hi, On 2016-12-06 14:19:21 -0600, Nico Williams wrote: > A bigger concern might be interface stability. IIRC the LLVM C/C++ > interfaces are not very stable, but bitcode is. The C API is a lot more stable than the C++ bit, that's the primary reason I ended up using it, despite the C++ docs

Re: [HACKERS] Hash Indexes

2016-12-06 Thread Jeff Janes
On Tue, Dec 6, 2016 at 4:00 AM, Amit Kapila wrote: > On Tue, Dec 6, 2016 at 1:29 PM, Jeff Janes wrote: > > > > > > I just occasionally insert a bunch of equal tuples, which have to be in > > overflow pages no matter how much splitting happens. > >

Re: [HACKERS] WIP: Faster Expression Processing and Tuple Deforming (including JIT)

2016-12-06 Thread Andres Freund
On 2016-12-06 14:35:43 -0600, Nico Williams wrote: > On Tue, Dec 06, 2016 at 12:27:51PM -0800, Andres Freund wrote: > > On 2016-12-06 14:19:21 -0600, Nico Williams wrote: > > > > I concur with your feeling that hand-rolled JIT is right out. But > > > > > > Yeah, that way lies maintenance

Re: [HACKERS] Compiler warnings

2016-12-06 Thread Stephen Frost
Robert, * Robert Haas (robertmh...@gmail.com) wrote: > On Tue, Dec 6, 2016 at 3:23 PM, Stephen Frost wrote: > > Given the lack of screaming, I'll push the attached in a bit, which just > > initializes the two variables being complained about. As mentioned, > > there doesn't

Re: [HACKERS] Separate connection handling from backends

2016-12-06 Thread Adam Brusselback
> > BTW, it just occurred to me that having this separation would make it > relatively easy to support re-directing DML queries from a replica to the > master; if the backend throws the error indicating you tried to write data, > the connection layer could re-route that. This also sounds like it

Re: [HACKERS] Compiler warnings

2016-12-06 Thread Robert Haas
On Tue, Dec 6, 2016 at 3:46 PM, Stephen Frost wrote: > Good thought, thanks! > > Updated patch attached with that change and I also added an Assert() to > GetCachedPlan(), in case that code gets whacked around later and somehow > we end up falling through without actually

Re: [HACKERS] WIP: Faster Expression Processing and Tuple Deforming (including JIT)

2016-12-06 Thread Nico Williams
On Tue, Dec 06, 2016 at 12:36:41PM -0800, Andres Freund wrote: > On 2016-12-06 15:25:44 -0500, Tom Lane wrote: > > I'm not entirely thrilled with the idea of this being a configure-time > > decision, because that forces packagers to decide for their entire > > audience whether it's okay to depend

Re: [HACKERS] pgcrypto compilation error due to stack-allocated EVP_CIPHER_CTX

2016-12-06 Thread Michael Paquier
On Tue, Dec 6, 2016 at 11:42 PM, Asif Naeem wrote: > Thanks for updated patch. Although EVP_CIPHER_CTX_cleanup() seems deprecated > in OpenSSL >= 1.1.0 i.e. > >> # if OPENSSL_API_COMPAT < 0x1010L >> # define EVP_CIPHER_CTX_init(c) EVP_CIPHER_CTX_reset(c) >> #

Re: [HACKERS] WIP: Faster Expression Processing and Tuple Deforming (including JIT)

2016-12-06 Thread Peter Geoghegan
On Mon, Dec 5, 2016 at 7:49 PM, Andres Freund wrote: > I tried to address 2) by changing the C implementation. That brings some > measurable speedups, but it's not huge. A bigger speedup is making > slot_getattr, slot_getsomeattrs, slot_getallattrs very trivial wrappers; > but

Re: [HACKERS] Patch to implement pg_current_logfile() function

2016-12-06 Thread Gilles Darold
Le 02/12/2016 à 02:08, Karl O. Pinc a écrit : > On Sun, 27 Nov 2016 21:54:46 +0100 > Gilles Darold wrote: > >> I've attached the v15 of the patch >> I've not applied patch patch_pg_current_logfile-v14.diff.backoff to >> prevent constant call of logfile_writename() on a

Re: [HACKERS] WIP: Faster Expression Processing and Tuple Deforming (including JIT)

2016-12-06 Thread Andres Freund
On 2016-12-06 13:27:14 -0800, Peter Geoghegan wrote: > On Mon, Dec 5, 2016 at 7:49 PM, Andres Freund wrote: > > I tried to address 2) by changing the C implementation. That brings some > > measurable speedups, but it's not huge. A bigger speedup is making > > slot_getattr,