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

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

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

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

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

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] tzdata 2016j

> 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] Partitionning: support for Truncate Table WHERE

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] WIP: Faster Expression Processing and Tuple Deforming (including JIT)

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] Separate connection handling from backends

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] WIP: Faster Expression Processing and Tuple Deforming (including JIT)

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

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

> > > 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] Separate connection handling from backends

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] Separate connection handling from backends

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] Push down more full joins in postgres_fdw

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] Separate connection handling from backends

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] Partitionning: support for Truncate Table WHERE

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] Back-patch use of unnamed POSIX semaphores for Linux?

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

[HACKERS] [sqlsmith] Crash in tsquery_rewrite/QTNBinary

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] Quorum commit for multiple synchronous replication.

At Wed, 7 Dec 2016 13:26:38 +0900, Michael Paquier wrote in

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

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] Back-patch use of unnamed POSIX semaphores for Linux?

> 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] Back-patch use of unnamed POSIX semaphores for Linux?

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] Back-patch use of unnamed POSIX semaphores for Linux?

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] Back-patch use of unnamed POSIX semaphores for Linux?

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] Declarative partitioning - another take

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] Quorum commit for multiple synchronous replication.

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] Quorum commit for multiple synchronous replication.

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] Push down more full joins in postgres_fdw

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)

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

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

[HACKERS] Partitionning: support for Truncate Table WHERE

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] Separate connection handling from backends

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] [GENERAL] Select works only when connected from login postgres

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] Separate connection handling from backends

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] WIP: Faster Expression Processing and Tuple Deforming (including JIT)

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,

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

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] Compiler warnings

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] Separate connection handling from backends

> > 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] WIP: Faster Expression Processing and Tuple Deforming (including JIT)

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] pgcrypto compilation error due to stack-allocated EVP_CIPHER_CTX

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)

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] Compiler warnings

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] WIP: Faster Expression Processing and Tuple Deforming (including JIT)

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] WIP: Faster Expression Processing and Tuple Deforming (including JIT)

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] WIP: Faster Expression Processing and Tuple Deforming (including JIT)

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] Hash Indexes

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] Compiler warnings

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)

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] Push down more full joins in postgres_fdw

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)

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] Compiler warnings

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] WIP: Faster Expression Processing and Tuple Deforming (including JIT)

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] WIP: Faster Expression Processing and Tuple Deforming (including JIT)

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)

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)

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] WIP: Faster Expression Processing and Tuple Deforming (including JIT)

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)

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)

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] Parallel execution and prepared statements

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] [COMMITTERS] pgsql: Account for catalog snapshot in PGXACT->xmin updates.

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] WIP: Faster Expression Processing and Tuple Deforming (including JIT)

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] [COMMITTERS] pgsql: Account for catalog snapshot in PGXACT->xmin updates.

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] Parallel execution and prepared statements

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] Separate connection handling from backends

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] Logical Replication WIP

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] Parallel execution and prepared statements

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] tzdata 2016j

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] UNDO and in-place update

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] tzdata 2016j

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

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

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

[HACKERS] tzdata 2016j

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

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

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

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] [COMMITTERS] pgsql: Account for catalog snapshot in PGXACT->xmin updates.

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] pgcrypto compilation error due to stack-allocated EVP_CIPHER_CTX

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] raw output from copy

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] PSQL commands: \quit_if, \quit_unless

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] Assignment of valid collation for SET operations on queries with UNKNOWN types.

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

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] PSQL commands: \quit_if, \quit_unless

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] pgcrypto compilation error due to stack-allocated EVP_CIPHER_CTX

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] Hash Indexes

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] Quorum commit for multiple synchronous replication.

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] Quorum commit for multiple synchronous replication.

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

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] pg_dump, pg_dumpall and data durability

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] Adding in docs the meaning of pg_stat_replication.sync_state

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] raw output from copy

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] Hash Indexes

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