Re: [HACKERS] [sqlsmith] crashes in RestoreSnapshot on hot standby

Amit Kapila writes: > On Fri, Jul 1, 2016 at 9:38 AM, Thomas Munro > wrote: >> Or maybe just like this? >> >> - snapshot->subxip = snapshot->xip + serialized_snapshot->xcnt; >> + snapshot->subxip = ((TransactionId *) (snapshot + 1)) + >>

Re: [HACKERS] Forthcoming SQL standards about JSON and Multi-Dimensional Arrays (FYI)

Hi 2016-06-29 1:51 GMT+02:00 Stefan Keller : > Hi, > > FYI: I'd just like to point you to following two forthcoming standard > parts from "ISO/IEC JTS 1/SC 32" comittee: one on JSON, and one on > "Multi-Dimensional Arrays" (SQL/MDA). > > They define there some things

Re: [HACKERS] [sqlsmith] crashes in RestoreSnapshot on hot standby

On Fri, Jul 1, 2016 at 9:38 AM, Thomas Munro wrote: > On Fri, Jul 1, 2016 at 3:25 PM, Amit Kapila wrote: >> On Fri, Jul 1, 2016 at 8:48 AM, Thomas Munro >> wrote: >>> If serialized_snapshot->xcnt == 0, then

Re: [HACKERS] Broken handling of lwlocknames.h

On Tue, Jun 28, 2016 at 12:26:00PM +0900, Michael Paquier wrote: > On Tue, Jun 28, 2016 at 3:22 AM, Christoph Berg wrote: > > Re: Tom Lane 2016-06-27 <31398.1467036...@sss.pgh.pa.us> > >> Bjorn Munch reported off-list that this sequence: > >> > >> unpack tarball, cd into it > >>

Re: [HACKERS] [sqlsmith] crashes in RestoreSnapshot on hot standby

On Fri, Jul 1, 2016 at 3:25 PM, Amit Kapila wrote: > On Fri, Jul 1, 2016 at 8:48 AM, Thomas Munro > wrote: >> If serialized_snapshot->xcnt == 0, then snapshot->xip never gets >> initialized to a non-NULL value. Then if

Re: [HACKERS] Bug in batch tuplesort memory CLUSTER case (9.6 only)

On Sun, Jun 26, 2016 at 09:14:05PM -0700, Peter Geoghegan wrote: > In general, moving tuplesort.c batch memory caller tuples around > happens when batch memory needs to be recycled, or freed outright with > pfree(). > > I failed to take into account that CLUSTER tuplesorts need an extra > step

Re: [HACKERS] Is a UDF binary portable across different minor releases and PostgreSQL distributions?

> From: pgsql-hackers-ow...@postgresql.org > [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Michael Paquier > So perhaps the best answer, is not 1 nor 2. Just saying that the routines > are carefully maintained with a best effort, though sometimes you may need > to rebuild depending on

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

On Thu, Jun 16, 2016 at 01:56:44PM -0500, Kevin Grittner wrote: > On Thu, Jun 16, 2016 at 1:32 PM, Andres Freund wrote: > > > With old_snapshot_threshold=1 I indeed can reproduce the issue. I > > disabled autovacuum, to make the scheduling more predictable. But it > > should

Re: [HACKERS] [sqlsmith] crashes in RestoreSnapshot on hot standby

On Fri, Jul 1, 2016 at 8:48 AM, Thomas Munro wrote: > > On Fri, Jul 1, 2016 at 2:17 PM, Michael Paquier > wrote: > > On Fri, Jul 1, 2016 at 6:26 AM, Andreas Seltenreich wrote: > >> #1 0x00822032 in

Re: [HACKERS] Is a UDF binary portable across different minor releases and PostgreSQL distributions?

On Fri, Jul 1, 2016 at 12:19 PM, Tsunakawa, Takayuki wrote: >> From: Tom Lane [mailto:t...@sss.pgh.pa.us] >> To make this situation better, what we'd really need is a bunch of work >> to identify and document the specific APIs that we would promise won't change >>

Re: [HACKERS] Is a UDF binary portable across different minor releases and PostgreSQL distributions?

> From: Tom Lane [mailto:t...@sss.pgh.pa.us] > "Tsunakawa, Takayuki" writes: > > Option 2: > > Rebuild UDFs with the target PostgreSQL distribution. > > You do not have to rebuild UDFs when you upgrade or downgrade the > > minor release. (If your UDF doesn't work

Re: [HACKERS] [sqlsmith] crashes in RestoreSnapshot on hot standby

On Fri, Jul 1, 2016 at 2:17 PM, Michael Paquier wrote: > On Fri, Jul 1, 2016 at 6:26 AM, Andreas Seltenreich > wrote: >> #1 0x00822032 in RestoreSnapshot >> (start_address=start_address@entry=0x7f2701d5a110 > memory at address

Re: [HACKERS] Is a UDF binary portable across different minor releases and PostgreSQL distributions?

On Fri, Jul 1, 2016 at 11:33 AM, Tsunakawa, Takayuki wrote: > OK, I understood that your choice is option 2. And the UDF developer should > report the problem and ask for its reason on pgsql-bugs, possibly end up > haveing to rebuild the UDF. But if so, it

Re: [HACKERS] Is a UDF binary portable across different minor releases and PostgreSQL distributions?

> From: pgsql-hackers-ow...@postgresql.org > [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Michael Paquier > On Fri, Jul 1, 2016 at 10:35 AM, Tsunakawa, Takayuki > wrote: > > I'd like to document the policy clearly in the upgrade section of > PostgreSQL

Re: [HACKERS] Is a UDF binary portable across different minor releases and PostgreSQL distributions?

"Tsunakawa, Takayuki" writes: > I'd like to document the policy clearly in the upgrade section of PostgreSQL > manual, eliminating any ambiguity, so that users can determine what they > should do without fear like "may or may not work". Which of the following >

Re: [HACKERS] [sqlsmith] crashes in RestoreSnapshot on hot standby

On Fri, Jul 1, 2016 at 6:26 AM, Andreas Seltenreich wrote: > #1 0x00822032 in RestoreSnapshot > (start_address=start_address@entry=0x7f2701d5a110 memory at address 0x7f2701d5a110>) at snapmgr.c:2020 memcpy(snapshot->subxip, serialized_xids +

Re: [HACKERS] Reviewing freeze map code

On Thu, Jun 30, 2016 at 8:10 PM, Masahiko Sawada wrote: > On Thu, Jun 30, 2016 at 3:12 PM, Amit Kapila wrote: >> On Thu, Jun 30, 2016 at 9:13 AM, Andres Freund wrote: >>> On 2016-06-30 08:59:16 +0530, Amit Kapila wrote: On

Re: [HACKERS] OpenSSL 1.1 breaks configure and more

On Fri, Jul 1, 2016 at 9:27 AM, Andreas Karlsson wrote: > Hi, > > Here is an initial set of patches related to OpenSSL 1.1. Everything should > still build fine on older OpenSSL versions (and did when I tested with > 1.0.2h). > > 0001-Fixes-for-compiling-with-OpenSSL-1.1.patch

Re: [HACKERS] _mdfd_getseg can be expensive

On 2016-06-30 18:34:20 -0700, Peter Geoghegan wrote: > On Thu, Jun 30, 2016 at 6:23 PM, Andres Freund wrote: > > I plan to, once the tree opens again. Likely needs some considerable > > updates for recent changes. > > Offhand, do you think that CREATE INDEX calls to

Re: [HACKERS] Is a UDF binary portable across different minor releases and PostgreSQL distributions?

On Fri, Jul 1, 2016 at 10:35 AM, Tsunakawa, Takayuki wrote: > I'd like to document the policy clearly in the upgrade section of PostgreSQL > manual, eliminating any ambiguity, so that users can determine what they > should do without fear like "may or may not

Re: [HACKERS] Is a UDF binary portable across different minor releases and PostgreSQL distributions?

> From: pgsql-hackers-ow...@postgresql.org > [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Michael Paquier > On Fri, Jul 1, 2016 at 9:33 AM, Tsunakawa, Takayuki > wrote: > > [Q1] > > Can the same UDF binary be used with different PostgreSQL minor

Re: [HACKERS] _mdfd_getseg can be expensive

On Thu, Jun 30, 2016 at 6:23 PM, Andres Freund wrote: > I plan to, once the tree opens again. Likely needs some considerable > updates for recent changes. Offhand, do you think that CREATE INDEX calls to smgrextend() could be appreciably affected by this bottleneck? If that's

Re: [HACKERS] initdb issue on 64-bit Windows - (Was: [pgsql-packagers] PG 9.6beta2 tarballs are ready)

On 1 July 2016 at 09:02, Michael Paquier wrote: > On Fri, Jul 1, 2016 at 9:57 AM, Alvaro Herrera > wrote: > > Craig Ringer wrote: > >> On 30 June 2016 at 20:19, Alvaro Herrera > wrote: > >> > >> > Hmm, so what about

[HACKERS] Bad behavior from plpython 'return []'

CREATE FUNCTION pg_temp.bad() RETURNS text[] LANGUAGE plpythonu AS $$return []$$; SELECT pg_temp.bad(); bad - {} (1 row) SELECT pg_temp.bad() = '{}'::text[]; ?column? -- f (1 row) Erm?? Turns out this is because SELECT array_dims(pg_temp.bad()), array_dims('{}'::text[]);

Re: [HACKERS] _mdfd_getseg can be expensive

On 2016-06-30 18:14:15 -0700, Peter Geoghegan wrote: > On Tue, Dec 15, 2015 at 10:04 AM, Andres Freund wrote: > > Took a while. But here we go. The attached version is a significantly > > revised version of my earlier patch. Notably I've pretty much entirely > > revised the

Re: [HACKERS] _mdfd_getseg can be expensive

On Tue, Dec 15, 2015 at 10:04 AM, Andres Freund wrote: > Took a while. But here we go. The attached version is a significantly > revised version of my earlier patch. Notably I've pretty much entirely > revised the code in _mdfd_getseg() to be more similar to the state in >

Re: [HACKERS] initdb issue on 64-bit Windows - (Was: [pgsql-packagers] PG 9.6beta2 tarballs are ready)

On Fri, Jul 1, 2016 at 9:57 AM, Alvaro Herrera wrote: > Craig Ringer wrote: >> On 30 June 2016 at 20:19, Alvaro Herrera wrote: >> >> > Hmm, so what about a pure 32bit build, if such a thing still exists? If >> > so and it causes the same

Re: [HACKERS] Is a UDF binary portable across different minor releases and PostgreSQL distributions?

On Fri, Jul 1, 2016 at 9:33 AM, Tsunakawa, Takayuki wrote: > [Q1] > Can the same UDF binary be used with different PostgreSQL minor releases? If > it is, is it a defined policy (e.g. written somewhere in the manual, wiki, > documentation in the source code)? > >

Re: [HACKERS] initdb issue on 64-bit Windows - (Was: [pgsql-packagers] PG 9.6beta2 tarballs are ready)

Craig Ringer wrote: > On 30 June 2016 at 20:19, Alvaro Herrera wrote: > > > Hmm, so what about a pure 32bit build, if such a thing still exists? If > > so and it causes the same crash, perhaps we should have one member for > > each VS version running on 32bit x86. > >

Re: [HACKERS] initdb issue on 64-bit Windows - (Was: [pgsql-packagers] PG 9.6beta2 tarballs are ready)

On 30 June 2016 at 20:19, Alvaro Herrera wrote: > Craig Ringer wrote: > > On 30 June 2016 at 07:21, Tom Lane wrote: > > > > > Alvaro Herrera writes: > > > > Tom Lane wrote: > > > >> Thanks for investigating! I'll go

Re: [HACKERS] primary_conninfo missing from pg_stat_wal_receiver

On Fri, Jul 1, 2016 at 8:50 AM, Michael Paquier wrote: > On Fri, Jul 1, 2016 at 8:48 AM, Alvaro Herrera > wrote: >> Michael Paquier wrote: >>> Yeah, I know. Now my opinion regarding this view is that we should >>> show information about a

[HACKERS] Is a UDF binary portable across different minor releases and PostgreSQL distributions?

Hello, While I was thinking of application binary compatibility between PostgreSQL releases, some questions arose about C language user-defined functions (UDFs) and extensions that depend on them. [Q1] Can the same UDF binary be used with different PostgreSQL minor releases? If it is, is it

Re: [HACKERS] OpenSSL 1.1 breaks configure and more

Hi, Here is an initial set of patches related to OpenSSL 1.1. Everything should still build fine on older OpenSSL versions (and did when I tested with 1.0.2h). 0001-Fixes-for-compiling-with-OpenSSL-1.1.patch This patch fixes the code so it builds with OpenSSL 1.1 (except the CRYPTO_LOCK

[HACKERS] Allow INSTEAD OF DELETE triggers to modify the tuple for RETURNING

Hi, Currently the tuple returned by INSTEAD OF triggers on DELETEs is only used to determine whether to pretend that the DELETE happened or not, which is often not helpful enough; for example, the actual tuple might have been concurrently UPDATEd by another transaction and one or more of the

Re: [HACKERS] primary_conninfo missing from pg_stat_wal_receiver

On Fri, Jul 1, 2016 at 8:48 AM, Alvaro Herrera wrote: > Michael Paquier wrote: >> Yeah, I know. Now my opinion regarding this view is that we should >> show information about a currently-working WAL receiver, and that it >> has nothing to do with reporting information of

Re: [HACKERS] primary_conninfo missing from pg_stat_wal_receiver

Michael Paquier wrote: > On Fri, Jul 1, 2016 at 8:35 AM, Alvaro Herrera > wrote: > > Michael Paquier wrote: > >> On Thu, Jun 30, 2016 at 11:24 PM, Alvaro Herrera > >> wrote: > >> > Also, actually, I see no reason for the conninfo to be shown

Re: [HACKERS] primary_conninfo missing from pg_stat_wal_receiver

On Fri, Jul 1, 2016 at 8:35 AM, Alvaro Herrera wrote: > Michael Paquier wrote: >> On Thu, Jun 30, 2016 at 11:24 PM, Alvaro Herrera >> wrote: >> > Also, actually, I see no reason for the conninfo to be shown differently >> > regardless of a

Re: [HACKERS] primary_conninfo missing from pg_stat_wal_receiver

Michael Paquier wrote: > On Thu, Jun 30, 2016 at 11:24 PM, Alvaro Herrera > wrote: > > Also, actually, I see no reason for the conninfo to be shown differently > > regardless of a connection being already established. If we show the > > conninfo that the server is

Re: [HACKERS] primary_conninfo missing from pg_stat_wal_receiver

On Thu, Jun 30, 2016 at 11:24 PM, Alvaro Herrera wrote: > Also, actually, I see no reason for the conninfo to be shown differently > regardless of a connection being already established. If we show the > conninfo that the server is trying to use, it might be easier to >

Re: [HACKERS] WIP: About CMake v2

On Fri, Jul 1, 2016 at 5:19 AM, Andrew Dunstan wrote: > On 06/30/2016 03:13 AM, Yury Zhuravlev wrote: >> Only one extra phase (mkdir build). I think it's not so important. For >> windows and macosx I used cmake GUI it's so easy. > > We need this to be scriptable, not using a

Re: [HACKERS] fixing subplan/subquery confusion

On Mon, Jun 27, 2016 at 4:12 PM, Robert Haas wrote: >>> Tom, do you want to commit this, or do you want me to handle it, or >>> something else? >> >> I was not sure if you'd agreed that the patch was correct, and in any >> case I thought you wanted to fold it into the

Re: [HACKERS] parallel workers and client encoding

On Wed, Jun 29, 2016 at 10:52 PM, Peter Eisentraut wrote: > I'm happy with this patch. Great. I have committed it. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list

Re: [HACKERS] fixing consider_parallel for upper planner rels

On Thu, Jun 30, 2016 at 5:54 PM, Tom Lane wrote: >> That's pretty much right, but there are two conceptually separate >> things. The first is whether or not we actually attempt to spawn >> workers, and the second is whether or not we enter parallel mode. >> Entering parallel

Re: [HACKERS] fixing consider_parallel for upper planner rels

On Thu, Jun 30, 2016 at 1:13 PM, Tom Lane wrote: > BTW, I just had another thought about reducing the cost of > has_parallel_hazard checks, to wit: you already made one pass over the > entire query to verify that there's no PARALLEL UNSAFE functions anywhere. > If that pass

Re: [HACKERS] fixing consider_parallel for upper planner rels

Robert Haas writes: > On Thu, Jun 30, 2016 at 12:04 PM, Tom Lane wrote: >> * It seems like the initialization of root->parallelModeNeeded is still >> overcomplicated and/or underexplained. > That's pretty much right, but there are two conceptually

Re: [HACKERS] fixing consider_parallel for upper planner rels

On Thu, Jun 30, 2016 at 12:04 PM, Tom Lane wrote: > Robert Haas writes: >> Here is a new patch addressing (I hope) the above comments and a few >> other things. > > Some more comments: > > * It seems like the initialization of root->parallelModeNeeded

[HACKERS] [sqlsmith] crashes in RestoreSnapshot on hot standby

Running sqlsmith on a streaming slave (master as of f8c5855) is inconspicuous as long as the master is idle. As soon as I start it on the master as well, the standby frequently crashes in RestoreSnapshot. It doesn't seem to be specific to the queries, as they don't trigger a crash when re-run.

Re: [HACKERS] WIP: About CMake v2

On 06/30/2016 03:13 AM, Yury Zhuravlev wrote: Michael Paquier wrote: You have not tested with macOS, and so did I. Thanks! I fixed this typo. But for XCode I see more corrections. I will can fix it today or maybe tomorrow. It would be nice to come as well with simpler steps than all

Re: [HACKERS] WIP: About CMake v2

On 06/30/2016 06:26 AM, Oleg Bartunov wrote: On Wed, Jun 29, 2016 at 7:23 PM, Yury Zhuravlev wrote: Hello Hackers. I decided to talk about the current state of the project: 1. Merge with 9.6 master. 2. plpython2, plpython3, plperl, pltcl, plsql all work correctly

Re: [HACKERS] fixing consider_parallel for upper planner rels

BTW, I just had another thought about reducing the cost of has_parallel_hazard checks, to wit: you already made one pass over the entire query to verify that there's no PARALLEL UNSAFE functions anywhere. If that pass were to also track whether there are any PARALLEL RESTRICTED functions anywhere,

Re: [HACKERS] fixing consider_parallel for upper planner rels

Robert Haas writes: > Here is a new patch addressing (I hope) the above comments and a few > other things. Some more comments: * It seems like the initialization of root->parallelModeNeeded is still overcomplicated and/or underexplained. Why do you not merely set it

Re: [HACKERS] Reviewing freeze map code

On Thu, Jun 30, 2016 at 3:12 PM, Amit Kapila wrote: > On Thu, Jun 30, 2016 at 9:13 AM, Andres Freund wrote: >> On 2016-06-30 08:59:16 +0530, Amit Kapila wrote: >>> On Wed, Jun 29, 2016 at 10:30 PM, Andres Freund wrote: >>> > On

Re: [HACKERS] primary_conninfo missing from pg_stat_wal_receiver

Fujii Masao wrote: > On Thu, Jun 30, 2016 at 10:12 PM, Michael Paquier > wrote: > > On Thu, Jun 30, 2016 at 9:41 PM, Alvaro Herrera > > wrote: > >> Fujii Masao wrote: > >>> On Thu, Jun 30, 2016 at 9:30 PM, Michael Paquier > >>>

Re: [HACKERS] pg_replication_origin_xact_reset() and its argument variables

Fujii Masao writes: > The document explains that pg_replication_origin_xact_reset() doesn't have > any argument variables. But it's been actually defined so as to have two > argument variables with pg_lsn and timestamptz data types, as follows. > =# \df

Re: [HACKERS] primary_conninfo missing from pg_stat_wal_receiver

On Thu, Jun 30, 2016 at 10:12 PM, Michael Paquier wrote: > On Thu, Jun 30, 2016 at 9:41 PM, Alvaro Herrera > wrote: >> Fujii Masao wrote: >>> On Thu, Jun 30, 2016 at 9:30 PM, Michael Paquier >>> wrote: >>> > On Thu,

[HACKERS] pg_replication_origin_xact_reset() and its argument variables

Hi, The document explains that pg_replication_origin_xact_reset() doesn't have any argument variables. But it's been actually defined so as to have two argument variables with pg_lsn and timestamptz data types, as follows. =# \df pg_replication_origin_xact_reset

Re: [HACKERS] primary_conninfo missing from pg_stat_wal_receiver

On Thu, Jun 30, 2016 at 9:41 PM, Alvaro Herrera wrote: > Fujii Masao wrote: >> On Thu, Jun 30, 2016 at 9:30 PM, Michael Paquier >> wrote: >> > On Thu, Jun 30, 2016 at 8:59 PM, Fujii Masao wrote: > >> >> ISTM that we

Re: [HACKERS] primary_conninfo missing from pg_stat_wal_receiver

Fujii Masao wrote: > On Thu, Jun 30, 2016 at 9:30 PM, Michael Paquier > wrote: > > On Thu, Jun 30, 2016 at 8:59 PM, Fujii Masao wrote: > >> ISTM that we will never be able to get out of this loop if walreceiver > >> fails to connect to the

Re: [HACKERS] primary_conninfo missing from pg_stat_wal_receiver

On Thu, Jun 30, 2016 at 9:35 PM, Fujii Masao wrote: > On Thu, Jun 30, 2016 at 9:30 PM, Michael Paquier > wrote: >> On Thu, Jun 30, 2016 at 8:59 PM, Fujii Masao wrote: >>> (2) >>> +retry: >>> +SpinLockAcquire(>mutex);

Re: [HACKERS] primary_conninfo missing from pg_stat_wal_receiver

On Thu, Jun 30, 2016 at 9:30 PM, Michael Paquier wrote: > On Thu, Jun 30, 2016 at 8:59 PM, Fujii Masao wrote: >> (2) >> +retry: >> +SpinLockAcquire(>mutex); >> +if (!walrcv->ready_to_display) >> +{ >> +SpinLockRelease(>mutex);

Re: [HACKERS] primary_conninfo missing from pg_stat_wal_receiver

Fujii Masao wrote: > On Thu, Jun 30, 2016 at 6:01 AM, Alvaro Herrera > wrote: > > Alvaro Herrera wrote: > > > >> I propose to push this patch, closing the open item, and you can rework > >> on top -- I suppose you would completely remove the original conninfo > >> from

Re: [HACKERS] primary_conninfo missing from pg_stat_wal_receiver

On Thu, Jun 30, 2016 at 8:59 PM, Fujii Masao wrote: > (2) > +retry: > +SpinLockAcquire(>mutex); > +if (!walrcv->ready_to_display) > +{ > +SpinLockRelease(>mutex); > +CHECK_FOR_INTERRUPTS(); > +pg_usleep(1000); > +goto retry; > +

Re: [HACKERS] A couple of cosmetic changes around shared memory code

Robert Haas wrote: > It might be better to document this in bgworker.sgml instead. That > already documents some facts about exiting: > > >If bgw_restart_time for a background worker is >configured as BGW_NEVER_RESTART, or if it exits with an exit >code of 0 or is terminated by

Re: [HACKERS] initdb issue on 64-bit Windows - (Was: [pgsql-packagers] PG 9.6beta2 tarballs are ready)

Craig Ringer wrote: > On 30 June 2016 at 07:21, Tom Lane wrote: > > > Alvaro Herrera writes: > > > Tom Lane wrote: > > >> Thanks for investigating! I'll go commit that change. I wish someone > > >> would put up a buildfarm critter using VS2013,

Re: [HACKERS] 10.0

Gavin Flower wrote: > I hate the rampant inflation associated with numbering schemes like FireFox > - the numbers of no meaning at all, other than something non-trivial has > been changed, with no indication at all about how non-trivial! I thought this horse had already been beaten to death --

Re: [HACKERS] primary_conninfo missing from pg_stat_wal_receiver

On Thu, Jun 30, 2016 at 6:01 AM, Alvaro Herrera wrote: > Alvaro Herrera wrote: > >> I propose to push this patch, closing the open item, and you can rework >> on top -- I suppose you would completely remove the original conninfo >> from shared memory and instead only

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

That didn't cover all the places that needed to be fixed, but I have re-read the docs and believe I've made things good now. I have reviewed this thread and verified that all the cases raised in it now work as desired, so I have marked the open item closed. Thank you very much! -- Teodor

Re: [HACKERS] fixing subplan/subquery confusion

On Tue, Jun 28, 2016 at 5:22 PM, Amit Kapila wrote: > On Tue, Jun 28, 2016 at 8:25 AM, Tom Lane wrote: > >> In the appendrel case, I tend to agree that the easiest solution is to >> scan all the children of the appendrel and just mark the whole thing

Re: [HACKERS] WIP: About CMake v2

On Wed, Jun 29, 2016 at 7:23 PM, Yury Zhuravlev wrote: > Hello Hackers. > > I decided to talk about the current state of the project: > 1. Merge with 9.6 master. 2. plpython2, plpython3, plperl, pltcl, plsql all > work correctly (all tests pass). > 3. Works done for

Re: [HACKERS] WIP: About CMake v2

Michael Paquier wrote: You have not tested with macOS, and so did I. Thanks! I fixed this typo. But for XCode I see more corrections. I will can fix it today or maybe tomorrow. It would be nice to come as well with simpler steps than all this mkdir build, etc stanza. Perhaps with a wrapper

Re: [HACKERS] pgbench unable to scale beyond 100 concurrent connections

Hi All, Sorry for trouble you with small environment setup for testing. I should to test this with large machine. What I was testing were involved multiple things same time so quite confusing . possible reason for this testing failure is : 1. small hardware 2. haproxy not able to balance

Re: [HACKERS] Reviewing freeze map code

On Thu, Jun 30, 2016 at 9:13 AM, Andres Freund wrote: > On 2016-06-30 08:59:16 +0530, Amit Kapila wrote: >> On Wed, Jun 29, 2016 at 10:30 PM, Andres Freund wrote: >> > On 2016-06-29 19:04:31 +0530, Amit Kapila wrote: >> >> There is nothing in this record