Re: [PATCH] session_replication_role = replica with TRUNCATE

Hi Peter, Il 18/01/18 17:30, Peter Eisentraut ha scritto: > On 1/17/18 11:33, Petr Jelinek wrote: >>> P.S: I'm struggling to understand why we have two possible values of >>> session_replication_role settings that behave identically (origin and >>> local). I'm unable to see any difference

Re: Bug in Physical Replication Slots (at least 9.5)?

On 19 January 2017 at 09:37, Kyotaro HORIGUCHI wrote: > > Though I haven't look closer to how a modification is splitted > into WAL records. A tuple cannot be so long. As a simple test, I > observed rechder->xl_tot_len at the end of XLogRecordAssemble > inserting

Re: MCV lists for highly skewed distributions

>> [1] Occasionally it will store a much longer MCV list, because no values >> was >> sampled exactly once, which triggers a different code path in which all >> seen >> values are put in the MCV and the histogram is NULL. This is not >> reliable, >> as whether the least-sample value is present in

Re: Package version in PG_VERSION and version()

Re: Peter Eisentraut 2018-01-17 > On 1/17/18 10:14, Christoph Berg wrote: > > The difference is that when parsing version() (which is all my variant > > is changing), people already have to deal with extra stuff at the end > > (gcc version),

Re: [HACKERS] Secondary index access optimizations

Konstantin Knizhnik wrote: > On 11.01.2018 12:34, Antonin Houska wrote: > > Konstantin Knizhnik wrote: > > I haven't thought that much about details, so just one comment: you > > shouldn't > > need the conversion to text and back to

Re: [HACKERS] Transaction control in procedures

On 6 December 2017 at 22:34, Merlin Moncure wrote: > On Wed, Dec 6, 2017 at 8:41 AM, Peter Eisentraut > wrote: >> On 12/5/17 13:33, Robert Haas wrote: >>> On Tue, Dec 5, 2017 at 1:25 PM, Peter Eisentraut >>>

Re: [PATCH][PROPOSAL] Refuse setting toast.* reloptions when TOAST table does not exist

В письме от 18 января 2018 18:42:01 пользователь Tom Lane написал: > >> This patch raises error if user tries o set or change toast.* option for > >> a > >> table that does not have a TOST relation. > > > > I think there is a problem with this idea, which is that the rules for > > whether or not

Re: [HACKERS] Parallel tuplesort (for parallel B-Tree index creation)

On Thu, Jan 18, 2018 at 2:05 PM, Peter Geoghegan wrote: > Review of your patch: > > * SerializedReindexState could use some comments. At least a one liner > stating its basic purpose. Added a comment. > * The "System index reindexing support" comment block could do with a >

Re: [HACKERS] Transaction control in procedures

On 16 January 2018 at 20:24, Andrew Dunstan wrote: > Looks good. Marking ready for committer. Few questions/points for the docs. Docs say: "A new transaction is started automatically after a transaction is ended using these commands" Presumably this would have

Re: Add default role 'pg_access_server_files'

Michael, all, * Michael Paquier (michael.paqu...@gmail.com) wrote: > On Thu, Jan 18, 2018 at 02:04:45PM +, Ryan Murphy wrote: > > I had not tried this before with my unpatched build of postgres. (In > > retrospect of course I should have). I expected my superuser to be > > able to perform

Re: [HACKERS] Refactor handling of database attributes between pg_dump and pg_dumpall

On Thu, Jan 18, 2018 at 6:35 PM, Tom Lane wrote: > If we did it like that, the rationale for an actual --set-db-properties > switch would vanish, at least so far as pg_dumpall is concerned -- we > could just make all that behavior an integral part of --create. And > this

Re: [PATCH] Logical decoding of TRUNCATE

Hi All, Il 18/01/18 17:48, Simon Riggs ha scritto: > On 17 January 2018 at 17:07, Petr Jelinek > wrote: > >> Things I am less convinced about: >> >> The patch will cascade truncation on downstream if cascade was specified >> on the upstream, that can potentially

Re: [HACKERS] Proposal: Local indexes for partitioned table

Hi Jesper Jesper Pedersen wrote: > I get > > pg_restore: creating INDEX "pg_catalog.pg_authid_oid_index" > pg_restore: [archiver (db)] Error while PROCESSING TOC: > pg_restore: [archiver (db)] Error from TOC entry 5493; 1259 2677 INDEX > pg_authid_oid_index jpedersen > pg_restore: [archiver

Re: [HACKERS] postgres_fdw bug in 9.6

On Fri, Jan 19, 2018 at 1:53 AM, Etsuro Fujita wrote: > I noticed that this test case added by the patch is not appropriate: > > +-- multi-way join involving multiple merge joins > +EXPLAIN (VERBOSE, COSTS OFF) > +SELECT * FROM ft1, ft2, ft4, ft5 WHERE ft1.c1 = ft2.c1

Re: Built-in connection pooling

On 18.01.2018 18:00, Claudio Freire wrote: On Thu, Jan 18, 2018 at 11:48 AM, Konstantin Knizhnik > wrote: Attached please find new version of the patch with few fixes. And more results at NUMA system with 144 cores and

Re: [HACKERS] Secondary index access optimizations

On 19.01.2018 16:14, Antonin Houska wrote: Konstantin Knizhnik wrote: On 11.01.2018 12:34, Antonin Houska wrote: Konstantin Knizhnik wrote: I haven't thought that much about details, so just one comment: you shouldn't need the

Re: Built-in connection pooling

On 19.01.2018 19:59, Tomas Vondra wrote: The problem can be much easily solved in case of using pthread version of Postgres. In this case reassigning session to another executor (thread) can be don much easily. And there is no need to use unportable trick with passing fiel descriptor to other

Re: Logical Decoding and HeapTupleSatisfiesVacuum assumptions

On 26 December 2017 at 14:21, Nikhil Sontakke wrote: > With logical decoding, there might arise a case that such a row, if it > belongs to a system catalog table or even a user catalog table >

Re: [HACKERS] Refactor handling of database attributes between pg_dump and pg_dumpall

Robert Haas writes: > On Thu, Jan 18, 2018 at 6:35 PM, Tom Lane wrote: >> If we did it like that, the rationale for an actual --set-db-properties >> switch would vanish, at least so far as pg_dumpall is concerned -- we >> could just make all that

Re: Fwd: [BUGS] pg_trgm word_similarity inconsistencies or bug

Hello everyone, I would like to contribute to documentation review of the patches discussed in thread https://www.postgresql.org/message-id/flat/cy4pr17mb13207ed8310f847cf117eed0d8...@cy4pr17mb1320.namprd17.prod.outlook.com (https://commitfest.postgresql.org/16/1403/). Unfortunately, I was

Re: [PATCH] make check with Apple's SIP enabled

=?iso-8859-1?Q?J=F6rg?= Westheide writes: > When doing a "make check" on Mac OS X with SIP (aka rootless mode) > enabled it will fail like this: > ... Yeah, well-known problem. AFAIK, all PG developers who use Macs just disable SIP immediately. > The problem is

Re: [HACKERS] postgres_fdw bug in 9.6

Robert Haas writes: > On Fri, Jan 19, 2018 at 1:53 AM, Etsuro Fujita > wrote: >> I noticed that this test case added by the patch is not appropriate: >> because it doesn't inject extra Sort nodes into EPQ recheck plans, so it >> works well

Re: Built-in connection pooling

On 19.01.2018 18:53, Tomas Vondra wrote: On 01/19/2018 10:52 AM, Konstantin Knizhnik wrote: On 18.01.2018 18:02, Tomas Vondra wrote: Hi Konstantin, On 01/18/2018 03:48 PM, Konstantin Knizhnik wrote: On 17.01.2018 19:09, Konstantin Knizhnik wrote: Hi hackers, ... I haven't looked at

Re: Built-in connection pooling

On Fri, Jan 19, 2018 at 2:07 PM, Konstantin Knizhnik < k.knizh...@postgrespro.ru> wrote: > > > >> Well, I haven't said it has to be single-threaded like pgbouncer. I >> don't see why the bgworker could not use multiple threads internally (of >> course, it'd need to be not to mess the stuff that

Re: Built-in connection pooling

On 19.01.2018 20:01, Pavel Stehule wrote: 2018-01-19 17:53 GMT+01:00 Konstantin Knizhnik >: On 19.01.2018 19:28, Pavel Stehule wrote: When I've been thinking about adding a built-in connection

Re: [HACKERS][PATCH] Applying PMDK to WAL operations for persistent memory

On Fri, Jan 19, 2018 at 4:56 AM, Yoshimi Ichiyanagi wrote: >>Was the only non-default configuration setting wal_sync_method? i.e. >>synchronous_commit=on? No change to max_wal_size? > No, I used the following parameter in postgresql.conf to prevent >

[PATCH] make check with Apple's SIP enabled

Hi! When doing a "make check" on Mac OS X with SIP (aka rootless mode) enabled it will fail like this: - >8 snip 8< - rm -rf ./testtablespace mkdir ./testtablespace PATH="/Volumes/Home/arbeit/port25/postgresql-clean/tmp_install/usr/local/pgsql/bin:$PATH"

Re: [HACKERS] Refactor handling of database attributes between pg_dump and pg_dumpall

On Fri, Jan 19, 2018 at 10:00 AM, Tom Lane wrote: > Robert Haas writes: >> On Fri, Jan 19, 2018 at 9:45 AM, Tom Lane wrote: >>> Well, we could say that the properties of template1 and postgres >>> are only restored if you use

Re: [HACKERS] postgres_fdw bug in 9.6

On Fri, Jan 19, 2018 at 10:40 AM, Tom Lane wrote: > Robert Haas writes: >> On Fri, Jan 19, 2018 at 1:53 AM, Etsuro Fujita >> wrote: >>> I noticed that this test case added by the patch is not appropriate: >>> because it

Re: Add default role 'pg_access_server_files'

Ok great. Thanks Michael and Stephen for the explanations.

Re: Built-in connection pooling

On 19.01.2018 19:28, Pavel Stehule wrote: When I've been thinking about adding a built-in connection pool, my rough plan was mostly "bgworker doing something like pgbouncer" (that is, listening on a separate port and proxying everything to

Re: PATCH: logical_work_mem and logical streaming of large in-progress transactions

Attached is v5, fixing a silly bug in part 0006, causing segfault when creating a subscription. regards -- Tomas Vondra http://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Re: Built-in connection pooling

On 01/19/2018 05:53 PM, Konstantin Knizhnik wrote: > > > On 19.01.2018 19:28, Pavel Stehule wrote: >> >> >> When I've been thinking about adding a built-in connection >> pool, my >> rough plan was mostly "bgworker doing something like >> pgbouncer" (that >>

Re: Built-in connection pooling

On Fri, Jan 19, 2018 at 1:53 PM, Konstantin Knizhnik < k.knizh...@postgrespro.ru> wrote: > > > On 19.01.2018 19:28, Pavel Stehule wrote: > > > > When I've been thinking about adding a built-in connection pool, my >>> rough plan was mostly "bgworker doing something like pgbouncer" (that >>> is,

Re: [HACKERS] Refactor handling of database attributes between pg_dump and pg_dumpall

Robert Haas writes: > On Fri, Jan 19, 2018 at 9:45 AM, Tom Lane wrote: >> Well, we could say that the properties of template1 and postgres >> are only restored if you use --clean. > True. Would that be a POLA violation, do you think? It seems a bit

Re: [PATCH] make check with Apple's SIP enabled

On Fri, Jan 19, 2018 at 9:54 AM, Jörg Westheide wrote: > When doing a "make check" on Mac OS X with SIP (aka rootless mode) enabled > it will fail like this: I don't know whether this fix is any good, but thanks for working on the problem. It's a very annoying

Re: Built-in connection pooling

On 01/19/2018 10:52 AM, Konstantin Knizhnik wrote: > > > On 18.01.2018 18:02, Tomas Vondra wrote: >> Hi Konstantin, >> >> On 01/18/2018 03:48 PM, Konstantin Knizhnik wrote: >>> On 17.01.2018 19:09, Konstantin Knizhnik wrote: Hi hackers, ... >> I haven't looked at the code yet,

Re: Built-in connection pooling

When I've been thinking about adding a built-in connection pool, my >> rough plan was mostly "bgworker doing something like pgbouncer" (that >> is, listening on a separate port and proxying everything to regular >> backends). Obviously, that has pros and cons, and probably would not >> work serve

Re: [HACKERS] Refactor handling of database attributes between pg_dump and pg_dumpall

Robert Haas writes: > On Fri, Jan 19, 2018 at 10:00 AM, Tom Lane wrote: >> Robert Haas writes: >>> On Fri, Jan 19, 2018 at 9:45 AM, Tom Lane wrote: Well, we could say that the properties of template1 and

Re: Built-in connection pooling

On Fri, Jan 19, 2018 at 2:06 PM, Tomas Vondra wrote: > > > On 01/19/2018 06:03 PM, Claudio Freire wrote: > > > > > > On Fri, Jan 19, 2018 at 1:53 PM, Konstantin Knizhnik > > > wrote: > > > > > > > > On

Re: Built-in connection pooling

On Fri, Jan 19, 2018 at 2:22 PM, Tomas Vondra wrote: > > > On 01/19/2018 06:13 PM, Claudio Freire wrote: > > > > > > On Fri, Jan 19, 2018 at 2:07 PM, Konstantin Knizhnik > > > wrote: > > > > > > > > > >

Re: Logical Decoding and HeapTupleSatisfiesVacuum assumptions

On Fri, Jan 19, 2018 at 2:16 PM, Tomas Vondra wrote: > I think an important piece of this puzzle is that we only really care > about catalog changes made in a transaction that aborts after doing some > additional changes, with that catalog tuple in place. Because

Re: Built-in connection pooling

On 19.01.2018 20:03, Claudio Freire wrote: On Fri, Jan 19, 2018 at 1:53 PM, Konstantin Knizhnik > wrote: On 19.01.2018 19:28, Pavel Stehule wrote: When I've been thinking about adding a built-in

Re: Built-in connection pooling

On 01/19/2018 06:07 PM, Konstantin Knizhnik wrote: > > ... > 3) Is there any sort of shrinking the pools? I mean, if the backend is idle for certain period of time (or when we need backends for other databases), does it get closed automatically? >>> When client is

Re: [HACKERS] GnuTLS support

Comparing the existing {be,fe}-secure-openssl.c with the proposed {be,fe}-secure-gnutls.c, and with half an eye on the previously proposed Apple Secure Transport implementation, I have identified a few more areas of refactoring that should be done in order to avoid excessive copy-and-pasting in

Re: [HACKERS] Parallel tuplesort (for parallel B-Tree index creation)

On Fri, Jan 19, 2018 at 4:52 AM, Robert Haas wrote: >> Other than that, looks good to me. It's a simple patch with a clear purpose. > > Committed. Cool. Clarity on what I should do about parallel_leader_participation in the next revision would be useful at this point. You

Re: Built-in connection pooling

On 01/19/2018 07:35 PM, Claudio Freire wrote: > > > On Fri, Jan 19, 2018 at 2:22 PM, Tomas Vondra > > wrote: > > > > On 01/19/2018 06:13 PM, Claudio Freire wrote: > > > > > > On Fri, Jan 19, 2018 at 2:07 PM,

Re: Logical Decoding and HeapTupleSatisfiesVacuum assumptions

On 01/19/2018 06:54 PM, Robert Haas wrote: > On Tue, Dec 26, 2017 at 9:21 AM, Nikhil Sontakke > wrote: >> The main issue here is that HeapTupleSatisfiesVacuum *assumes* that >> rows belonging to an aborted transaction are not visible to anyone >> else. > > One problem

Re: [HACKERS] UPDATE of partition key

On Fri, Jan 19, 2018 at 4:37 AM, Amit Khandekar wrote: > Attached rebased patch. Committed with a bunch of mostly-cosmetic revisions. I removed the macro you added, which has a multiple evaluation hazard, and just put that logic back into the function. I don't think

Re: PATCH: Configurable file mode mask

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

Re: [HACKERS] Refactor handling of database attributes between pg_dump and pg_dumpall

On Fri, Jan 19, 2018 at 2:54 PM, Tom Lane wrote: > Hmm ... so there's a small problem with this idea of dropping and > recreating template1: > > pg_restore: connecting to database for restore > pg_restore: dropping DATABASE template1 > pg_restore: [archiver (db)] Error while

Re: PATCH: Configurable file mode mask

On 1/19/18 14:07, David Steele wrote: > I have yet to add tests for pg_rewindwal and pg_upgrade. pg_rewindwal > doesn't *have* any tests as far as I can tell and pg_upgrade has tests > in a shell script -- it's not clear how I would extend it or reuse the > Perl code for perm testing. > > Does

Re: non-bulk inserts and tuple routing

On Fri, Jan 19, 2018 at 3:56 AM, Amit Langote wrote: > I rebased the patches, since they started conflicting with a recently > committed patch [1]. I think that my latest commit has managed to break this pretty thoroughly. -- Robert Haas EnterpriseDB:

Re: [HACKERS] Refactor handling of database attributes between pg_dump and pg_dumpall

Hmm ... so there's a small problem with this idea of dropping and recreating template1: pg_restore: connecting to database for restore pg_restore: dropping DATABASE template1 pg_restore: [archiver (db)] Error while PROCESSING TOC: pg_restore: [archiver (db)] Error from TOC entry 3024; 1262 1

Re: [HACKERS] Refactor handling of database attributes between pg_dump and pg_dumpall

Robert Haas writes: > On Fri, Jan 19, 2018 at 2:54 PM, Tom Lane wrote: >> What do people think of just removing this DROP DATABASE restriction? >> Arguably, superusers should know better than to drop template1 anyway. >> Maybe we should replace it with

Re: PATCH: logical_work_mem and logical streaming of large in-progress transactions

On 01/19/2018 03:34 PM, Tomas Vondra wrote: > Attached is v5, fixing a silly bug in part 0006, causing segfault when > creating a subscription. > Meh, there was a bug in the sgml docs ( vs. ), causing another failure. Hopefully v6 will pass the CI build, it does pass a build with the same

Re: Logical Decoding and HeapTupleSatisfiesVacuum assumptions

On 01/19/2018 08:33 PM, Robert Haas wrote: > On Fri, Jan 19, 2018 at 2:16 PM, Tomas Vondra > wrote: >> I think an important piece of this puzzle is that we only really care >> about catalog changes made in a transaction that aborts after doing some >> additional

Re: Logical Decoding and HeapTupleSatisfiesVacuum assumptions

On Fri, Jan 19, 2018 at 5:19 PM, Tomas Vondra wrote: > Regarding the HOT issue - I have to admit I don't quite see why A2 > wouldn't be reachable through the index, but that's likely due to my > limited knowledge of the HOT internals. The index entries only point to

Re: [HACKERS] [PATCH] Overestimated filter cost and its mitigation

On Thu, Nov 9, 2017 at 12:33 PM, Ashutosh Bapat wrote: > different set, within each set the order is same. FWIW, we can order > all clauses in largest set once and use that order every time. Albeit > we will have to remember the order somewhere OR make the

Re: [HACKERS] [PATCH] Improve geometric types

> I'm fine with the current shape. Thanks. Maybe the same > discussion applies to polygons. (cf. poly_overlap) It indeed does. I am incorporating. > line_closept_point asserts line_interpt_line returns true but it > is hazardous. It is safer if line_closept_point returns NaN if >

Re: [HACKERS] [PATCH] Overestimated filter cost and its mitigation

On Wed, Nov 8, 2017 at 6:48 AM, Tom Lane wrote: > Because (1) up to now there's been no need to consider the qual ordering > till later, and (2) re-doing that sort for each path seemed unduly > expensive. If we're to try to estimate whether later quals will be > reached, then

Re: Rangejoin rebased

On 19 January 2018 at 08:25, Simon Riggs wrote: > On 17 January 2018 at 05:49, Jeff Davis wrote: >> On Wed, Jan 10, 2018 at 7:49 AM, Simon Riggs wrote: >>> Do we optimize for TIMESTAMP <@ RANGE as well? >> >> Not currently. It

Re: [HACKERS] [PATCH] Improve geometric types

Hello, At Thu, 18 Jan 2018 16:01:01 +0100, Emre Hasegeli wrote in

Re: Typo in slotfuncs.c

On Fri, Jan 19, 2018 at 3:39 PM, Simon Riggs wrote: > On 19 January 2018 at 05:38, Masahiko Sawada wrote: >> Hi, >> >> Attached patch for fixing a typo in slotfuncs.c >> >> s/possition/position/ > > Fixed, thanks. > Thank you! Regards, -- Masahiko

Re: [Sender Address Forgery]Re: [Sender Address Forgery]Re: [Sender Address Forgery]Re: [HACKERS] path toward faster partition pruning

On 19 January 2018 at 16:00, Kyotaro HORIGUCHI wrote: > And I'd like to ask David to check out his mail environment so > that SPF record is available for his message. Will investigate -- David Rowley http://www.2ndQuadrant.com/ PostgreSQL

Re: [HACKERS] Function to move the position of a replication slot

On Wed, Nov 29, 2017 at 7:48 AM, Michael Paquier wrote: > On Tue, Sep 5, 2017 at 11:51 AM, Andres Freund wrote: > > On 2017-09-05 11:36:47 +0900, Michael Paquier wrote: > >> On Thu, Aug 31, 2017 at 9:19 PM, Magnus Hagander >

Re: [Sender Address Forgery]Re: pg_(total_)relation_size and partitioned tables

Thanks for taking a look. On 2018/01/19 14:39, Michael Paquier wrote: > On Thu, Jan 18, 2018 at 06:54:18PM +0900, Amit Langote wrote: >> I think having pg_partition_root() and pg_partition_parent() will give >> users enough to get useful views as follows: > > So... pg_partition_root() gives you

Re: [HACKERS] [BUGS] Bug in Physical Replication Slots (at least 9.5)?

On Fri, Jan 19, 2018 at 10:54:53AM +0900, Kyotaro HORIGUCHI wrote: > On the other hand if one logical record must be read from single > source, we need any means to deterrent wal-recycling on the > primary side. Conducting that within the primary side is rejected > by consensus. There is this

Re: [HACKERS] Useless code in ExecInitModifyTable

FYI ... For the pending update-partition-key patch, we would again require the rel variable for UPDATE. So in the rebased update-partition-key patch [1], 'rel' is assigned the root partitioned table. But this time, I have used the already opened node->rootResultRelInfo to get the root partitioned

Re: [HACKERS] Useless code in ExecInitModifyTable

On 2018/01/19 18:50, Amit Khandekar wrote: > FYI ... > > For the pending update-partition-key patch, we would again require the > rel variable for UPDATE. So in the rebased update-partition-key patch > [1], 'rel' is assigned the root partitioned table. But this time, I > have used the already

Re: PATCH: Configurable file mode mask

On Wed, Jan 10, 2018 at 03:19:46PM -0300, Alvaro Herrera wrote: > David Steele wrote: > > On 1/8/18 8:58 PM, Peter Eisentraut wrote: > > > > Yeah, I didn't like this aspect when this patch was originally > > > submitted. We want to keep the code legible for future new > > > contributors. Having

Re: Rangejoin rebased

On 17 January 2018 at 05:49, Jeff Davis wrote: > On Wed, Jan 10, 2018 at 7:49 AM, Simon Riggs wrote: >> Do we optimize for TIMESTAMP <@ RANGE as well? > > Not currently. It requires a little extra complexity because empty > ranges will match anything and

Re: [HACKERS] Parallel tuplesort (for parallel B-Tree index creation)

On Sat, Jan 20, 2018 at 2:57 AM, Thomas Munro wrote: > On Sat, Jan 20, 2018 at 6:32 AM, Robert Haas wrote: >> On Fri, Jan 19, 2018 at 12:16 PM, Peter Geoghegan wrote: >>> Clarity on what I should do about

Re: [HACKERS] Parallel tuplesort (for parallel B-Tree index creation)

On Fri, Jan 19, 2018 at 8:44 PM, Amit Kapila wrote: > Right, but I think using parallel_leader_participation, you can do it > reliably and probably write some regression tests which can complete > in a predictable time. Do what reliably? Guarantee that the leader will

Re: MCV lists for highly skewed distributions

I wrote: > FWIW, I suspect that a solution > that doesn't take into account a metric like coefficient of variation > will have the wrong behavior sometimes, whether for highly uniform or > highly non-uniform distributions. By this I meant the coefficient of variation of the class size in the

Re: [HACKERS] postgres_fdw bug in 9.6

Robert Haas writes: > Well, I'm a little stumped. When I do it the way you did it, it fails > with the same error you got: > contrib_regression=# EXPLAIN (VERBOSE, COSTS OFF) > SELECT * FROM ft1, ft2, ft4, ft5 WHERE ft1.c1 = ft2.c1 AND ft1.c1 = ft4.c1 > AND ft1.c1 =

Re: Test-cases for exclusion constraints is missing in alter_table.sql file

On Wed, Jan 17, 2018 at 1:04 PM, Ashutosh Sharma wrote: > Hi All, > > While working on exclusion constraints for one of our internal > project, I noticed that there is no test-case for exclusion > constraints in alter_table.sql file. However, for other constraints i > could

Re: [HACKERS] parallel.c oblivion of worker-startup failures

On Thu, Jan 18, 2018 at 8:53 PM, Robert Haas wrote: > On Thu, Dec 21, 2017 at 9:13 AM, Amit Kapila wrote: >> I am not against using the way specific to parallel context layer as >> described by you above. However, I was trying to see if there is

Re: [HACKERS] Moving relation extension locks out of heavyweight lock manager

On Sun, Jan 7, 2018 at 11:26 PM, Masahiko Sawada wrote: > On Fri, Jan 5, 2018 at 1:39 AM, Robert Haas wrote: >> On Tue, Jan 2, 2018 at 1:09 AM, Mithun Cy wrote: >>> So in case of N_RELEXTLOCK_ENTS = 1 we can see

Re: [HACKERS] Parallel tuplesort (for parallel B-Tree index creation)

On Sat, Jan 20, 2018 at 8:33 AM, Peter Geoghegan wrote: > On Fri, Jan 19, 2018 at 6:52 PM, Amit Kapila wrote: > >> BTW, is there any other way for "parallel create index" to force that >> the work is done by workers? I am insisting on having something

Re: [HACKERS] Parallel tuplesort (for parallel B-Tree index creation)

On Sat, Jan 20, 2018 at 7:03 AM, Peter Geoghegan wrote: > On Thu, Jan 18, 2018 at 5:53 PM, Peter Geoghegan wrote: > > Attached patch details: > > * The patch synchronizes processes used the approach just described. > Note that this allowed me to remove several