Re: [HACKERS] [sqlsmith] Failed assertion in postgres_fdw/deparse.c:1116

On 2016/06/08 14:13, Ashutosh Bapat wrote: > On Tue, Jun 7, 2016 at 6:19 PM, Amit Langote wrote: >> On Tue, Jun 7, 2016 at 7:47 PM, Ashutosh Bapat wrote: >>> Looks good to me. If we add a column from the outer relation, the >> "NULL"ness >>> of inner column would be more clear. May be we should twe

Re: [HACKERS] slower connect from hostnossl clients

2016-06-08 8:26 GMT+02:00 Kyotaro HORIGUCHI : > At Tue, 7 Jun 2016 12:18:31 +0200, Magnus Hagander > wrote in < > cabuevez5qrmq4ebysbz+ujfg_3_ap361zqtgbh_ef+2j6p0...@mail.gmail.com> > > On Tue, Jun 7, 2016 at 11:31 AM, Pavel Stehule > > wrote: > > >> That's definitely not expected behavior. host

Re: [HACKERS] slower connect from hostnossl clients

At Tue, 7 Jun 2016 12:18:31 +0200, Magnus Hagander wrote in > On Tue, Jun 7, 2016 at 11:31 AM, Pavel Stehule > wrote: > >> That's definitely not expected behavior. hostnossl should turn off ssl > >> which should turn off the overhead completely. Does it make a difference if > >> you also disabl

Re: [HACKERS] [BUGS] Routine analyze of single column prevents standard autoanalyze from running at all

W dniu 2016-06-08 o 05:04, Tom Lane pisze: Jim Nasby writes: Is there any significant advantage to not analyzing all columns? Only case I can think of is if you have a fair number of columns that have been toasted; otherwise I'd think IO would completely swamp any other considerations. Yeah,

Re: [HACKERS] Reviewing freeze map code

On Wed, Jun 8, 2016 at 12:19 PM, Amit Kapila wrote: > On Tue, Jun 7, 2016 at 10:10 PM, Masahiko Sawada > wrote: >> >> Thank you for implementing the patch. >> >> I've not test it deeply but here are some comments. >> This check tool only checks if the frozen page has live-unfrozen tuple. >> That

Re: [HACKERS] Reviewing freeze map code

On 2016-06-08 10:04:56 +0530, Amit Kapila wrote: > On Tue, Jun 7, 2016 at 11:01 PM, Andres Freund wrote:> > > I think if we go with the pg_check_visibility approach, we should also > > copy the other consistency checks from vacuumlazy.c, given they can't > > easily be triggered. > > Are you refer

Re: [HACKERS] [sqlsmith] Failed assertion in postgres_fdw/deparse.c:1116

On further thought, I think we need to restrict the join pushdown only for outer joins. Only those joins can produce NULL rows. If we go with that change, we will need my changes as well and a testcase with inner join. On Tue, Jun 7, 2016 at 6:19 PM, Amit Langote wrote: > On Tue, Jun 7, 2016 at

Re: [HACKERS] Reviewing freeze map code

On Tue, Jun 7, 2016 at 11:01 PM, Andres Freund wrote:> > I think if we go with the pg_check_visibility approach, we should also > copy the other consistency checks from vacuumlazy.c, given they can't > easily be triggered. Are you referring to checks that are done in lazy_scan_heap() for each blo

Re: [HACKERS] Reviewing freeze map code

On Wed, Jun 8, 2016 at 8:37 AM, Robert Haas wrote: > > On Tue, Jun 7, 2016 at 10:19 AM, Amit Kapila wrote: > > I have implemented the above function in attached patch. Currently, it > > returns SETOF tupleids, but if we want some variant of same, that should > > also be possible. > > I think we'

Re: [HACKERS] parallel.c is not marked as test covered

On Tue, Jun 07, 2016 at 10:24:33PM +, Clément Prévost wrote: > I also considered setting max_parallel_degree to 1 to make the test more > futur-proof but there is a rather long discussion on the setting name ( > https://www.postgresql.org/message-id/20160424035859.gb29...@momjian.us) so > I can

Re: [HACKERS] Reviewing freeze map code

On Tue, Jun 7, 2016 at 10:10 PM, Masahiko Sawada wrote: > > Thank you for implementing the patch. > > I've not test it deeply but here are some comments. > This check tool only checks if the frozen page has live-unfrozen tuple. > That is, it doesn't care in case where the all-frozen page mistakenl

Re: [HACKERS] Reviewing freeze map code

On Tue, Jun 7, 2016 at 10:19 AM, Amit Kapila wrote: > I have implemented the above function in attached patch. Currently, it > returns SETOF tupleids, but if we want some variant of same, that should > also be possible. I think we'd want to bump the pg_visibility version to 1.1 and do the upgrad

Re: [HACKERS] [BUGS] Routine analyze of single column prevents standard autoanalyze from running at all

Jim Nasby writes: > Is there any significant advantage to not analyzing all columns? Only > case I can think of is if you have a fair number of columns that have > been toasted; otherwise I'd think IO would completely swamp any other > considerations. Yeah, my guess is that the OP's example wh

Re: [HACKERS] Rename max_parallel_degree?

On Fri, Jun 3, 2016 at 9:39 AM, Tom Lane wrote: > Robert Haas writes: >> I think we should just go with max_parallel_workers for a limit on >> total parallel workers within max_work_processes, and >> max_parallel_workers_per_gather for a per-Gather limit. It's slightly >> annoying that we may en

Re: [HACKERS] [sqlsmith] Failed assertion in postgres_fdw/deparse.c:1116

On Tue, Jun 07, 2016 at 09:49:23PM +0900, Amit Langote wrote: > On Tue, Jun 7, 2016 at 7:47 PM, Ashutosh Bapat wrote: > > On Tue, Jun 7, 2016 at 4:07 PM, Amit Langote wrote: > >> On 2016/06/07 19:13, Ashutosh Bapat wrote: > >> > So, your patch looks to be the correct approach (even after we support

Re: [HACKERS] [BUGS] BUG #14155: bloom index error with unlogged table

On Wed, Jun 8, 2016 at 1:23 AM, Tom Lane wrote: > "David G. Johnston" writes: >> On Tue, Jun 7, 2016 at 1:35 AM, Michael Paquier >> wrote: >>> I have finally given a shot at improving the docs with the attached. >>> Comments are welcome. > >> [ assorted comments ] > > I adopted most of David's s

Re: [HACKERS] Problem with dumping bloom extension

On Tue, Jun 07, 2016 at 03:23:46PM -0400, Robert Haas wrote: > On Tue, Jun 7, 2016 at 2:40 PM, Peter Eisentraut > wrote: > > On 6/7/16 11:16 AM, Stephen Frost wrote: > >> > >> Moved to CLOSE_WAIT. > > > > Could you add an explanation on the wiki page about what this section means? > > Noah create

Re: [HACKERS] Parallel pg_dump's error reporting doesn't work worth squat

At Tue, 07 Jun 2016 15:38:04 -0400, Tom Lane wrote in <24181.1465328...@sss.pgh.pa.us> > Kyotaro HORIGUCHI writes: > > At Mon, 06 Jun 2016 11:12:14 -0400, Tom Lane wrote in > > <17504.1465225...@sss.pgh.pa.us> > >> Uh, what? PQcancel is very carefully coded so that it's safe to use > >> in a

Re: [HACKERS] Tracking wait event for latches

On Sat, Jun 4, 2016 at 2:41 AM, Robert Haas wrote: > On Thu, Jun 2, 2016 at 1:34 AM, Michael Paquier > wrote: >> This patch is shaped this way intentionally based on the feedback I >> received at PGCon (Robert and others). We could provide a routine that >> extensions call in _PG_init to register

Re: [HACKERS] Reviewing freeze map code

On 6/6/16 3:57 PM, Peter Geoghegan wrote: On Mon, Jun 6, 2016 at 11:35 AM, Andres Freund wrote: We need a read-only utility which checks that the system is in a correct and valid state. There are a few of those which have been built for different pieces, I believe, and we really should have on

Re: [HACKERS] Typo in pg_visibility

On 2016/06/08 9:38, Amit Langote wrote: > Attached fixes a typo: > > s/PG_ALL_VISIBLE/PD_ALL_VISIBLE/g Oops. Made a couple of mistakes there: Subject: Typo in pg_visibility documentation Patch: Really attached this time. Thanks, Amit diff --git a/doc/src/sgml/pgvisibility.sgml b/doc/src/sgml/p

[HACKERS] Typo in pg_visibility

Attached fixes a typo: s/PG_ALL_VISIBLE/PD_ALL_VISIBLE/g Thanks, Amit -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] [BUGS] Routine analyze of single column prevents standard autoanalyze from running at all

On 6/6/16 3:23 PM, Josh berkus wrote: On 06/06/2016 01:38 PM, Tom Lane wrote: Also, I'd be a bit inclined to disable the counter reset whenever a column list is specified, disregarding the corner case where a list is given but it includes all the table's analyzable columns. It doesn't really s

Re: [HACKERS] installcheck failing on psql_crosstab

On Wed, Jun 8, 2016 at 8:21 AM, Alvaro Herrera wrote: > Tom Lane wrote: >> Michael Paquier writes: >> > On Tue, Jun 7, 2016 at 12:31 PM, Michael Paquier >> > wrote: >> >> On Tue, Jun 7, 2016 at 12:28 AM, Alvaro Herrera >> >> wrote: >> >>> Hmm, so we could solve the complaint by adding an ANALYZ

Re: [HACKERS] installcheck failing on psql_crosstab

Tom Lane wrote: > Michael Paquier writes: > > On Tue, Jun 7, 2016 at 12:31 PM, Michael Paquier > > wrote: > >> On Tue, Jun 7, 2016 at 12:28 AM, Alvaro Herrera > >> wrote: > >>> Hmm, so we could solve the complaint by adding an ANALYZE. I'm open to > >>> that; other opinions? > > >> We could ju

Re: [HACKERS] COMMENT ON, psql and access methods

On Wed, Jun 8, 2016 at 7:06 AM, Alvaro Herrera wrote: > Michael Paquier wrote: >> On Thu, Jun 2, 2016 at 3:42 PM, Michael Paquier >> wrote: >> > On Thu, Jun 2, 2016 at 1:00 PM, Michael Paquier >> > wrote: >> >> I have added an open item for 9.6 regarding this patch, that would be >> >> good to c

Re: [HACKERS] parallel.c is not marked as test covered

> > On Sun, May 15, 2016 at 12:53:13PM +, Clément Prévost wrote: > > After some experiments, I found out that, for my setup (9b7bfc3a88ef7b), > a > > parallel seq scan is used given both parallel_setup_cost > > and parallel_tuple_cost are set to 0 and given that the table is at > least 3 > > ti

Re: [HACKERS] COMMENT ON, psql and access methods

Michael Paquier wrote: > On Thu, Jun 2, 2016 at 3:42 PM, Michael Paquier > wrote: > > On Thu, Jun 2, 2016 at 1:00 PM, Michael Paquier > > wrote: > >> I have added an open item for 9.6 regarding this patch, that would be > >> good to complete this work in this release for consistency with the > >>

Re: [HACKERS] Should phraseto_tsquery('simple', 'blue blue') @@ to_tsvector('simple', 'blue') be true ?

Jean-Pierre Pelletier writes: > I wanted to test if phraseto_tsquery(), new with 9.6 could be used for > matching consecutive words but it won't work for us if it cannot handle > consecutive *duplicate* words. > For example, the following returns true:select > phraseto_tsquery('simple', 'blue

Re: [HACKERS] Parallel query and temp_file_limit

On Tue, Jun 7, 2016 at 8:32 AM, Robert Haas wrote: > You previously offered to write a patch for this. Are you still > planning to do that? OK, I'll get to that in the next few days. I'm slightly concerned that I might have missed a real problem in the code. I'll need to examine the issue more

[HACKERS] Should phraseto_tsquery('simple', 'blue blue') @@ to_tsvector('simple', 'blue') be true ?

Hi, I wanted to test if phraseto_tsquery(), new with 9.6 could be used for matching consecutive words but it won't work for us if it cannot handle consecutive *duplicate* words. For example, the following returns true:select phraseto_tsquery('simple', 'blue blue') @@ to_tsvector('simple', 'bl

Re: [HACKERS] Problem with dumping bloom extension

* Peter Eisentraut (peter.eisentr...@2ndquadrant.com) wrote: > On 6/7/16 11:16 AM, Stephen Frost wrote: > >Moved to CLOSE_WAIT. > > Could you add an explanation on the wiki page about what this section means? I understood it to simply be a step on the way to being resolved- that is, everything go

Re: [HACKERS] Parallel pg_dump's error reporting doesn't work worth squat

Kyotaro HORIGUCHI writes: > At Mon, 06 Jun 2016 11:12:14 -0400, Tom Lane wrote in > <17504.1465225...@sss.pgh.pa.us> >> Uh, what? PQcancel is very carefully coded so that it's safe to use >> in a signal handler. If it's doing mallocs someplace, that would be >> surprising. > PQcancel is disig

Re: [HACKERS] Problem with dumping bloom extension

On Tue, Jun 7, 2016 at 2:40 PM, Peter Eisentraut wrote: > On 6/7/16 11:16 AM, Stephen Frost wrote: >> >> Moved to CLOSE_WAIT. > > Could you add an explanation on the wiki page about what this section means? Noah created that section. My interpretation is that it's supposed to be for things we th

Re: [HACKERS] IPv6 link-local addresses and init data type

On 6/7/16 1:19 AM, Haribabu Kommi wrote: How about the following case, Do we treat them as same or different? select 'fe80::%eth1'::inet = 'fe80::%ETH1'::inet; fe80::%2/64 is only treated as the valid address but not other way as fe80::/64%2. Do we need to throw an error in this case or just ig

Re: [HACKERS] Problem with dumping bloom extension

On 6/7/16 11:16 AM, Stephen Frost wrote: Moved to CLOSE_WAIT. Could you add an explanation on the wiki page about what this section means? -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services -- Sent via pgsql-hack

Re: [HACKERS] parallel.c is not marked as test covered

On 6/7/16 1:27 AM, Noah Misch wrote: Testing under these conditions does not test the planner job at all but at least some parallel code can be run on the build farm and the test suite gets 2643 more lines and 188 more function covered. Nice. Please see also my message

Re: [HACKERS] Reviewing freeze map code

On 2016-06-07 19:49:59 +0530, Amit Kapila wrote: > On Tue, Jun 7, 2016 at 2:52 AM, Robert Haas wrote: > > > > On Mon, Jun 6, 2016 at 5:06 PM, Andres Freund wrote: > > > > > > > I'd also be ok with adding & documenting (beta release notes) > > > CREATE EXTENSION pg_visibility; > > > SELECT relname

Re: [HACKERS] [BUGS] BUG #14155: bloom index error with unlogged table

"David G. Johnston" writes: > Do I understand the process correctly? The current 9.6 docs reflect what > was committed and branched as beta1. Ongoing work is done against master > (devel docs). When beta2 is released it is branched from the current > master; not beta1. At that point the curren

Re: [HACKERS] [BUGS] BUG #14155: bloom index error with unlogged table

On Tue, Jun 7, 2016 at 12:23 PM, Tom Lane wrote: > "David G. Johnston" writes: > > On Tue, Jun 7, 2016 at 1:35 AM, Michael Paquier < > michael.paqu...@gmail.com> > > wrote: > >> I have finally given a shot at improving the docs with the attached. > >> Comments are welcome. > > > [ assorted comme

Re: [HACKERS] Reviewing freeze map code

On Tue, Jun 7, 2016 at 11:19 PM, Amit Kapila wrote: > On Tue, Jun 7, 2016 at 2:52 AM, Robert Haas wrote: >> >> On Mon, Jun 6, 2016 at 5:06 PM, Andres Freund wrote: >> >> >> > I'd also be ok with adding & documenting (beta release notes) >> > CREATE EXTENSION pg_visibility; >> > SELECT relname FR

Re: [HACKERS] [BUGS] BUG #14155: bloom index error with unlogged table

"David G. Johnston" writes: > On Tue, Jun 7, 2016 at 1:35 AM, Michael Paquier > wrote: >> I have finally given a shot at improving the docs with the attached. >> Comments are welcome. > [ assorted comments ] I adopted most of David's suggestions, whacked it around a bit further myself, and comm

Re: [HACKERS] Parallel safety tagging of extension functions

On 06/07/2016 05:44 PM, Robert Haas wrote: cube: I think we need a new extension version. hstore: Does not apply for me. intarray: Does not apply for me. Those three and ltree, pg_trgm, and seg depend on my patch with fixes for the GiST/GIN function signatures in https://www.postgresql.org/me

Re: [HACKERS] Parallel safety tagging of extension functions

On Fri, Jun 3, 2016 at 8:37 PM, Andreas Karlsson wrote: > Here is the patch split into many small patches as you suggested. The > current patches are based on top of the patch which fixes the signatures for > gin and gist functions. Generally, I think that there's no point in changing many of the

Re: [HACKERS] Re: pg9.6 segfault using simple query (related to use fk for join estimates)

Noah Misch writes: > My personal opinion is that the community should not undertake a "rewrite" of > a nontrivial feature after freeze. The fact that a progenitor was present in > the tree at freeze doesn't make the rewrite much less risky than a brand new > feature. So, I suggest that you inste

Re: [HACKERS] Re: [COMMITTERS] pgsql: Avoid extra locks in GetSnapshotData if old_snapshot_threshold

On Sat, Jun 4, 2016 at 4:21 PM, Kevin Grittner wrote: > On Fri, Jun 3, 2016 at 4:24 PM, Kevin Grittner wrote: >> Consequently, causing the index to be ignored in planning when >> using the old index > > That last line should have read "using an old snapshot" > >> is not a nice optimization, but n

Re: [HACKERS] Parallel query and temp_file_limit

On Sun, Jun 5, 2016 at 4:32 PM, Peter Geoghegan wrote: > On Wed, May 18, 2016 at 12:01 PM, Peter Geoghegan wrote: >>> I think for 9.6 we just have to document this issue. In the next >>> release, we could (and might well want to) try to do something more >>> clever. >> >> Works for me. You may w

Re: [HACKERS] Problem with dumping bloom extension

* Noah Misch (n...@leadboat.com) wrote: > The above-described topic is currently a PostgreSQL 9.6 open item. Stephen, > since you committed the patch believed to have created it, you own this open > item. If some other commit is more relevant or if this does not belong as a > 9.6 open item, pleas

Re: [HACKERS] Re: pg9.6 segfault using simple query (related to use fk for join estimates)

On Tue, Jun 07, 2016 at 10:20:44AM -0400, Tom Lane wrote: > Noah Misch writes: > > On Fri, Jun 03, 2016 at 10:32:24AM -0400, Noah Misch wrote: > >> IMMEDIATE ATTENTION REQUIRED. This PostgreSQL 9.6 open item is long past > >> due > >> for your status update. Please reacquaint yourself with the

Re: [HACKERS] Re: pg9.6 segfault using simple query (related to use fk for join estimates)

On Tue, Jun 7, 2016 at 10:20 AM, Tom Lane wrote: > Noah Misch writes: >> On Fri, Jun 03, 2016 at 10:32:24AM -0400, Noah Misch wrote: >>> IMMEDIATE ATTENTION REQUIRED. This PostgreSQL 9.6 open item is long past >>> due >>> for your status update. Please reacquaint yourself with the policy on op

Re: [HACKERS] Why we don't have checksums on clog files

On Tue, Jun 7, 2016 at 5:41 PM, Amit Kapila wrote: > On Mon, Jun 6, 2016 at 8:43 PM, Alex Ignatov > wrote: > >> Why we don't have checksums on clog files. >> >> We have checksum on pg_control, optional checksumming on data files, some >> form of checksumming on wal's. But why we don't have any c

Re: [HACKERS] Why we don't have checksums on clog files

On Mon, Jun 6, 2016 at 8:43 PM, Alex Ignatov wrote: > Hello! > > Why we don't have checksums on clog files. > > We have checksum on pg_control, optional checksumming on data files, some > form of checksumming on wal's. But why we don't have any checksumming on > clogs. Corruptions on clogs lead t

Re: [HACKERS] installcheck failing on psql_crosstab

Michael Paquier writes: > On Tue, Jun 7, 2016 at 12:31 PM, Michael Paquier > wrote: >> On Tue, Jun 7, 2016 at 12:28 AM, Alvaro Herrera >> wrote: >>> Hmm, so we could solve the complaint by adding an ANALYZE. I'm open to >>> that; other opinions? >> We could just enforce work_mem to 64kB and th

Re: [HACKERS] Re: pg9.6 segfault using simple query (related to use fk for join estimates)

Noah Misch writes: > On Fri, Jun 03, 2016 at 10:32:24AM -0400, Noah Misch wrote: >> IMMEDIATE ATTENTION REQUIRED. This PostgreSQL 9.6 open item is long past due >> for your status update. Please reacquaint yourself with the policy on open >> item ownership[1] and then reply immediately. If I do

Re: [HACKERS] Reviewing freeze map code

On Tue, Jun 7, 2016 at 2:52 AM, Robert Haas wrote: > > On Mon, Jun 6, 2016 at 5:06 PM, Andres Freund wrote: > > > > I'd also be ok with adding & documenting (beta release notes) > > CREATE EXTENSION pg_visibility; > > SELECT relname FROM pg_class WHERE relkind IN ('r', 'm') AND NOT pg_check_visib

[HACKERS] WIP: Data at rest encryption

Hi all, I have been working on data-at-rest encryption support for PostgreSQL. In my experience this is a common request that customers make. The short of the feature is that all PostgreSQL data files are encrypted with a single master key and are decrypted when read from the OS. It does not provi

Re: [HACKERS] slower connect from hostnossl clients

Magnus Hagander writes: > One thing that could be taking the time is an extra roundtrip -- e.g. it > tries to connect with ssl fails and retries without. I'd assume a priori that that's it. If so, the fix is to configure libpq to try non-SSL first not SSL first. There is an option for that, IIR

Re: [HACKERS] Problem with dumping bloom extension

Michael, * Michael Paquier (michael.paqu...@gmail.com) wrote: > Stephen, are you working on a patch or should I get one out of my > pocket? That's something we should get fixed quickly. We need as well > to be careful with the support for COMMENT with access methods, the > current consensus on the

Re: [HACKERS] [sqlsmith] Failed assertion in postgres_fdw/deparse.c:1116

On Tue, Jun 7, 2016 at 7:47 PM, Ashutosh Bapat wrote: > On Tue, Jun 7, 2016 at 4:07 PM, Amit Langote wrote: >> On 2016/06/07 19:13, Ashutosh Bapat wrote: >> > So, your patch looks to be the correct approach (even after we support >> > deparsing subqueries). Can you please include a test in regressi

Re: [HACKERS] [BUGS] BUG #14155: bloom index error with unlogged table

On Tue, Jun 7, 2016 at 1:35 AM, Michael Paquier wrote: > On Fri, Jun 3, 2016 at 11:25 PM, Tom Lane wrote: > > Michael Paquier writes: > >> Actually, the docs could be more polished. > > > > I think the docs could stand to be rewritten from scratch ;-). But > > upthread there was an offer to wo

Re: [HACKERS] [BUGS] BUG #14155: bloom index error with unlogged table

On Tue, Jun 7, 2016 at 1:35 AM, Michael Paquier wrote: > On Fri, Jun 3, 2016 at 11:25 PM, Tom Lane wrote: > > Michael Paquier writes: > >> Actually, the docs could be more polished. > > > > I think the docs could stand to be rewritten from scratch ;-). But > > upthread there was an offer to wo

Re: [HACKERS] Problem with dumping bloom extension

On Tue, Jun 7, 2016 at 8:10 PM, Robert Haas wrote: > On Mon, Jun 6, 2016 at 5:55 PM, Michael Paquier > wrote: >>> It seems important to get this fixed. I added it to the open items list. >> >> I added already it as " Access methods created with extensions are >> dumped individually ". That's not

Re: [HACKERS] Problem with dumping bloom extension

On Mon, Jun 6, 2016 at 5:55 PM, Michael Paquier wrote: >> It seems important to get this fixed. I added it to the open items list. > > I added already it as " Access methods created with extensions are > dumped individually ". That's not specific to bloom. Oh, sorry, I didn't spot that. -- Rob

Re: [HACKERS] [sqlsmith] Failed assertion in postgres_fdw/deparse.c:1116

On Tue, Jun 7, 2016 at 4:07 PM, Amit Langote wrote: > On 2016/06/07 19:13, Ashutosh Bapat wrote: > > I thought, columns of inner relation will be set to null during > projection > > from ForeignScan for joins. But I was wrong. If we want to push-down > joins > > in this case, we have two solution

Re: [HACKERS] slower connect from hostnossl clients

2016-06-07 12:18 GMT+02:00 Magnus Hagander : > > > On Tue, Jun 7, 2016 at 11:31 AM, Pavel Stehule > wrote: > >> >> >> 2016-06-07 11:29 GMT+02:00 Magnus Hagander : >> >>> >>> >>> On Tue, Jun 7, 2016 at 11:24 AM, Pavel Stehule >>> wrote: >>> Hi I am testing speed of connection to Po

Re: [HACKERS] slower connect from hostnossl clients

On Tue, Jun 7, 2016 at 12:41 PM, Andreas Karlsson wrote: > On 06/07/2016 12:18 PM, Magnus Hagander wrote: > > Intersting. Can you check with a network trace that it actually turns > > off ssl, so nothing is broken there? > > > > One thing that could be taking the time is an extra roundtrip -- e.g

Re: [HACKERS] slower connect from hostnossl clients

On 06/07/2016 12:18 PM, Magnus Hagander wrote: > Intersting. Can you check with a network trace that it actually turns > off ssl, so nothing is broken there? > > One thing that could be taking the time is an extra roundtrip -- e.g. it > tries to connect with ssl fails and retries without. A networ

Re: [HACKERS] [sqlsmith] Failed assertion in postgres_fdw/deparse.c:1116

On 2016/06/07 19:13, Ashutosh Bapat wrote: > I thought, columns of inner relation will be set to null during projection > from ForeignScan for joins. But I was wrong. If we want to push-down joins > in this case, we have two solutions > 1. Build queries with subqueries at the time of deparsing. Thu

Re: [HACKERS] [sqlsmith] Failed assertion in postgres_fdw/deparse.c:1116

> That's the patch I came up with initially but it seemed to me to produce > the wrong result. Correct me if that is not so: > > CREATE EXTENSION IF NOT EXISTS postgres_fdw WITH SCHEMA public; > > CREATE SERVER myserver FOREIGN DATA WRAPPER postgres_fdw OPTIONS (dbname > 'test'); > > CREATE USER M

Re: [HACKERS] slower connect from hostnossl clients

On Tue, Jun 7, 2016 at 11:31 AM, Pavel Stehule wrote: > > > 2016-06-07 11:29 GMT+02:00 Magnus Hagander : > >> >> >> On Tue, Jun 7, 2016 at 11:24 AM, Pavel Stehule >> wrote: >> >>> Hi >>> >>> I am testing speed of connection to Postgres. >>> >>> The ssl connection is slower, and it is expected. B

Re: [HACKERS] slower connect from hostnossl clients

2016-06-07 11:29 GMT+02:00 Magnus Hagander : > > > On Tue, Jun 7, 2016 at 11:24 AM, Pavel Stehule > wrote: > >> Hi >> >> I am testing speed of connection to Postgres. >> >> The ssl connection is slower, and it is expected. But when I configure >> pg_hba.conf to disable ssl via hostnossl, then ssl

Re: [HACKERS] slower connect from hostnossl clients

On Tue, Jun 7, 2016 at 11:24 AM, Pavel Stehule wrote: > Hi > > I am testing speed of connection to Postgres. > > The ssl connection is slower, and it is expected. But when I configure > pg_hba.conf to disable ssl via hostnossl, then ssl is not used, but the > speed is similar to ssl. > > Is it ex

[HACKERS] slower connect from hostnossl clients

Hi I am testing speed of connection to Postgres. The ssl connection is slower, and it is expected. But when I configure pg_hba.conf to disable ssl via hostnossl, then ssl is not used, but the speed is similar to ssl. Is it expected behave? Regards Pavel

Re: [HACKERS] [sqlsmith] Failed assertion in postgres_fdw/deparse.c:1116

Hi Ashutosh, On 2016/06/07 17:02, Ashutosh Bapat wrote: > On Tue, Jun 7, 2016 at 11:36 AM, Amit Langote wrote: >> On 2016/06/05 23:01, Andreas Seltenreich wrote: ... >>> --8<---cut here---start->8--- >>> create extension postgres_fdw; >>> create server myself

Re: [HACKERS] [sqlsmith] Failed assertion in postgres_fdw/deparse.c:1116

On Tue, Jun 7, 2016 at 11:36 AM, Amit Langote wrote: > On 2016/06/05 23:01, Andreas Seltenreich wrote: > > Creating some foreign tables via postgres_fdw in the regression db of > > master as of de33af8, sqlsmith triggers the following assertion: > > > > TRAP: FailedAssertion("!(const Node

Re: [HACKERS] Improve tab completion for USER MAPPING

Hi, At Tue, 7 Jun 2016 00:03:57 +0900, Masahiko Sawada wrote in > I found that the tab completion for USER MAPPING doesn't work fine. > For example, > > The below is no problem. > postgres=# create user[TAB] > user user mapping for > > But this doesn't work fine. (Note that there