Re: [HACKERS] [PATCH] Improve geometric types

> 0001: > > - You removed the check of parallelity check of > line_interpt_line(old line_interpt_internal) but line_parallel > is not changed so the consistency between the two functions are > lost. It is better to be another patch file (maybe 0004?). I am making line_parallel() use

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

On 1/12/18 23:19, Tomas Vondra wrote: > Wouldn't the 'toplevel_by_lsn' be suitable for this? Subtransactions > don't really commit independently, but as part of the toplevel xact. And > that list is ordered by LSN, which is pretty much exactly the order in > which we see the transactions. Yes

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

On 18 January 2018 at 23:56, Amit Langote wrote: >> I've not fully worked out how run-time pruning >> will use this as it'll need another version of >> get_partitions_from_clauses but passes in a PartScanClauseInfo >> instead, and does not call

Re: master make check fails on Solaris 10

On Thu, 18 Jan 2018 01:47:46 -0500 Tom Lane wrote: > Victor Wagner writes: > > Tom Lane wrote: > > checking for __int128 alignment bug... ok > > As far as I understand your patch, there should be: > > checking for __int128 alignment

Re: Built-in connection pooling

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, but after reading your message I have a simple question - gow iss this going to work with SSL? If you're only passing

Re: [HACKERS] REL9_6_STABLE - a minor bug in src/common/exec.c

After checking some code from REL9_6_STABLE with a static analyzer, I've found this bit: src/common/exec.c:586 putenv(strdup(env_path)); ... src/common/exec.c:597 putenv(strdup(env_path)); Theoretically, strdup might return NULL, and we'll send NULL as an argument to

Re: Built-in connection pooling

On Thu, Jan 18, 2018 at 11:48 AM, Konstantin Knizhnik < k.knizh...@postgrespro.ru> wrote: > > Attached please find new version of the patch with few fixes. > And more results at NUMA system with 144 cores and 3Tb of RAM. > > Read-only pgbench (-S): > > > #Connections\kTPS > Vanilla Postgres >

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

On Thu, Jan 18, 2018 at 4:19 PM, Thomas Munro wrote: > Hi, > > I'm mostly away from my computer this week -- sorry about that, but > here are a couple of quick answers to questions directed at me: > > On Thu, Jan 18, 2018 at 4:22 PM, Peter Geoghegan

Re: [HACKERS] WIP: Covering + unique indexes.

Hi! > 18 янв. 2018 г., в 18:57, Anastasia Lubennikova > написал(а): > > What is amcheck_next ? amcheck_next is external version of amcheck, maintained by Peter G. on his github. It checks one more thing: that every heap tuple has twin in B-tree, so called

Re: Add default role 'pg_access_server_files'

Just circling back on this. I did have a question that came up about the behavior of the server as it is without the patch. I logged into psql with my superuser "postgres": postgres=# select pg_read_file('/Users/postgres/temp'); ERROR: absolute path not allowed I had not tried this

Re: master make check fails on Solaris 10

Marina Polyakova writes: > On 18-01-2018 19:53, Tom Lane wrote: >> So basically, we're outta luck and we have to consider __int128 as >> unsupportable on SPARC. I'm inclined to mechanize that as a test on >> $host_cpu. At least that means we don't need an AC_RUN test

Re: [HACKERS] Possible gaps/garbage in the output of XLOG reader

Michael Paquier wrote: > On Thu, Apr 9, 2015 at 7:05 PM, Antonin Houska wrote: > > While playing with xlogreader, I was lucky enough to see one of the many > > record validations to fail. After having some fun with gdb, I found out that > > in some

Re: Unnecessary static variable?

Tom Lane wrote: > Antonin Houska writes: > > Tom Lane wrote: > >> At one time, I think, readLen told how much data in readBuf was > >> actually valid. It seems not to be used for that anymore, but > >> I don't much like the idea that

Re: master make check fails on Solaris 10

Marina Polyakova writes: > On 18-01-2018 17:56, Tom Lane wrote: >> Weird. Maybe the gcc bug only manifests with certain optimization >> flags? That's not what I'd have expected from Victor's theory about >> why the code is wrong, but if it only shows up some of the

Re: master make check fails on Solaris 10

I wrote: > Marina Polyakova writes: >> On 18-01-2018 19:53, Tom Lane wrote: >>> So basically, we're outta luck and we have to consider __int128 as >>> unsupportable on SPARC. I'm inclined to mechanize that as a test on >>> $host_cpu. At least that means we don't need

Re: PATCH: psql tab completion for SELECT

On 01/18/2018 01:07 AM, Tom Lane wrote: > Edmund Horner writes: >> On 15 January 2018 at 15:45, Andres Freund wrote: >>> All worries like this are supposed to check the server version. > >> In psql there are around 200 such tab completion queries, none of

Re: Faster inserts with mostly-monotonically increasing values

On 31 December 2017 at 11:06, Peter Geoghegan wrote: > On Sun, Dec 31, 2017 at 6:44 AM, Pavan Deolasee > wrote: >> Here is a patch that implements the idea. If the last insert happens to be >> in the rightmost block of an index, then we cache the block and

Re: master make check fails on Solaris 10

On 18-01-2018 20:34, Tom Lane wrote: I wrote: ... But ... let's not panic, but wait and see the final result of the discussion on the gcc PR. Jakub at least seems to think it ought to be a supportable case. What you could do in the meantime is work on finding a variation of Victor's test that

Re: master make check fails on Solaris 10

On 18-01-2018 19:53, Tom Lane wrote: Marina Polyakova writes: On 18-01-2018 17:56, Tom Lane wrote: Weird. Maybe the gcc bug only manifests with certain optimization flags? That's not what I'd have expected from Victor's theory about why the code is wrong, but if

Re: GSoC 2018 Project Ideas & Mentors - Last Call

I can help with the Sorting project. On Thu, Jan 18, 2018 at 10:29 PM, Stephen Frost wrote: > Greetings! > > I've gone through and cleaned up our GSoC 2018 Wiki page: > > https://wiki.postgresql.org/wiki/GSoC_2018 > > Please review! If you have any last-minute items, please

Re: [PATCH] session_replication_role = replica with TRUNCATE

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 according to the code or the >> documentation, so I'm wondering if we

Re: PATCH: psql tab completion for SELECT

On 01/12/2018 06:59 AM, Edmund Horner wrote: > Hi, here's a new patch. Thanks, and sorry for the delay. I have reviewed this patch, but haven't had time to put my thoughts together in a coherent message yet. I will be able to do that tomorrow. Thank you for your patience. -- Vik Fearing

GSoC 2018 Project Ideas & Mentors - Last Call

Greetings! I've gone through and cleaned up our GSoC 2018 Wiki page: https://wiki.postgresql.org/wiki/GSoC_2018 Please review! If you have any last-minute items, please add them! We could use some more mentors! If you would have some time over the summer to help with mentoring a GSoC project

Re: master make check fails on Solaris 10

On 18-01-2018 17:56, Tom Lane wrote: Marina Polyakova writes: Applying your patch on commit f033462d8f77c40b7d6b33c5116e50118fb4699d and using the configuration command from [1], I got: checking for __int128... yes checking for __int128 alignment bug... broken ...

Re: Logical decoding fast-forward and slot advance

On 14 January 2018 at 23:15, Petr Jelinek wrote: > Updated version attached. Applied, thanks -- Simon Riggshttp://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Re: [PATCH] Logical decoding of TRUNCATE

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 be dangerous and we either should > not do it and only truncate

Re: [PATCH] session_replication_role = replica with TRUNCATE

On 12/29/17 07:01, Marco Nenciarini wrote: > The current behavior of session_replication_role = replica with TRUNCATE > is not the same of with the other commands. > It does not check FKs for INSERT/UPDATE/DELETE but it does for TRUNCATE, > so one cannot execute TRUNCATE on a table when it is

Re: GSoC 2018 Project Ideas & Mentors - Last Call

Greetings, * Atri Sharma (atri.j...@gmail.com) wrote: > I can help with the Sorting project. Great! I've added you as a mentor. Thanks! Stephen signature.asc Description: PGP signature

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

On Thu, Jan 18, 2018 at 5:49 AM, Thomas Munro wrote: > I'm mostly away from my computer this week -- sorry about that, Yeah, seriously. Since when it is OK for hackers to ever be away from their computers? :-) > The idea I mentioned would only work if

Re: [PATCH] session_replication_role = replica with TRUNCATE

Peter Eisentraut writes: > So I'm proposing the attached alternative patch, which creates > constraint triggers to be TRIGGER_FIRES_ALWAYS by default. > Thoughts? Hm, the general idea seems attractive, but I'm not sure we want this behavioral change for

Re: master make check fails on Solaris 10

On 18-01-2018 20:24, Tom Lane wrote: Marina Polyakova writes: On 18-01-2018 19:53, Tom Lane wrote: So basically, we're outta luck and we have to consider __int128 as unsupportable on SPARC. I'm inclined to mechanize that as a test on $host_cpu. At least that

Re: master make check fails on Solaris 10

On Thu, Jan 18, 2018 at 12:24 PM, Tom Lane wrote: > Marina Polyakova writes: >> On 18-01-2018 19:53, Tom Lane wrote: >>> So basically, we're outta luck and we have to consider __int128 as >>> unsupportable on SPARC. I'm inclined to mechanize that

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

On Wed, Jan 17, 2018 at 10:22 PM, Peter Geoghegan wrote: > If you think it's worth the cycles, then I have no objection. I will > point out that this means that everything that I say about > ReindexIsProcessingIndex() no longer applies, because the relevant > state will now be

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

On Thu, Jan 18, 2018 at 6:14 AM, Amit Kapila wrote: > I see your point. OTOH, I think we should have something for testing > purpose as that helps in catching the bugs and makes it easy to write > tests that cover worker part of the code. This is about the question of

Re: GSoC 2018 Project Ideas & Mentors - Last Call

Stephen Frost wrote: > Greetings! > > I've gone through and cleaned up our GSoC 2018 Wiki page: > > https://wiki.postgresql.org/wiki/GSoC_2018 > > Please review! If you have any last-minute items, please add them! > > We could use some more mentors! I'm staying away this time. Last year I

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

On Thu, Jan 18, 2018 at 10:17 AM, Robert Haas wrote: >> Should I go ahead and restore builds on catalogs, and remove those >> comments, on the assumption that your patch will be committed before >> mine? Obviously parallel index builds on catalogs don't matter. OTOH, >> why

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

On Thu, Jan 18, 2018 at 10:27 AM, Robert Haas wrote: > On Thu, Jan 18, 2018 at 1:14 PM, Peter Geoghegan wrote: >> That seems pretty far fetched. > > I don't think it is, and there are plenty of other examples. All you > need is a query plan that involves

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

On Thu, Jan 18, 2018 at 6:21 AM, Robert Haas wrote: > Amit's reply to this part drew my attention to it. I think this is > entirely false. Consider an aggregate that doesn't support partial > aggregation, and a plan that looks like this: > > Aggregate > -> Gather > ->

Re: master make check fails on Solaris 10

Robert Haas writes: > Anyway, that's really an academic debate. My real point is: I do not > think we should reject out of hand the idea that a patch introducing > some new notation to deal with this might be acceptable. I am not > volunteering to write such a patch, and

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

On Thu, Jan 18, 2018 at 1:14 PM, Peter Geoghegan wrote: > That seems pretty far fetched. I don't think it is, and there are plenty of other examples. All you need is a query plan that involves significant CPU work both below the Gather node and above the Gather node. It's not

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

Hi Amit, It seems your mail system continually adds "[Sender Address Forgery]" prefixes to messages. E.g. this mail now has Subject: Re: [Sender Address Forgery]Re: [Sender Address Forgery]Re: [Sender Address Forgery]Re: [HACKERS] path toward faster partition pruning as its subject, whereas the

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

Robert Haas writes: > On Wed, Jan 17, 2018 at 3:50 PM, Nikolay Shaplov wrote: >> 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

Re: Index-only scan returns incorrect results when using a composite GIST index with a gist_trgm_ops column.

Hello. At Thu, 18 Jan 2018 17:25:05 +0900, Michael Paquier wrote in <20180118082505.ga84...@paquier.xyz> > On Thu, Jan 18, 2018 at 12:57:38PM +0500, Andrey Borodin wrote: > >> Please find the attached patch. > > I agree with you that current behavior is a bug and your

Re: [HACKERS] [PATCH] Improve geometric types

Hello, I played more around geometric types and recalled that geometric types don't have orderings. Also have corrected some other misunderstanding. Sorry for my confusion and I think I returned on the way. At Wed, 17 Jan 2018 18:59:30 +0100, Emre Hasegeli wrote in

Re: [HACKERS] REL9_6_STABLE - a minor bug in src/common/exec.c

On Thu, Jan 18, 2018 at 03:27:43PM +0300, Anna Akenteva wrote: > Would it be possible to fix it the same way in REL9_6_STABLE and maybe other > older versions too? Yes, this was part of an investigation that led to 052cc223 to improve OOM handling, which involved way more code paths than just

Re: master make check fails on Solaris 10

On 17-01-2018 18:50, Marina Polyakova wrote: On 17-01-2018 18:28, Tom Lane wrote: BTW, now that you've demonstrated that the bug exists in a current gcc release, you should definitely file a bug at https://gcc.gnu.org/bugzilla/ I think you can just give them int128test2.c as-is as a test case.

Re: Built-in connection pooling

On 17.01.2018 19:09, Konstantin Knizhnik wrote: Hi hackers, My recent experiments with pthread version of Postgres show that although pthread offers some performance advantages comparing with processes for large number of connections, them still can not eliminate need in connection pooling.

Re: master make check fails on Solaris 10

Marina Polyakova writes: > Applying your patch on commit f033462d8f77c40b7d6b33c5116e50118fb4699d > and using the configuration command from [1], I got: > checking for __int128... yes > checking for __int128 alignment bug... broken > ... > And make check-world passes.

Re: master make check fails on Solaris 10

On Thu, 18 Jan 2018 09:56:48 -0500 Tom Lane wrote: > Marina Polyakova writes: > > Applying your patch on commit > > f033462d8f77c40b7d6b33c5116e50118fb4699d and using the > > configuration command from [1], I got: checking for __int128... yes > >

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

Here's a patch to add pg_dump tests. This verifies that the CREATE INDEX on parent and partition appear, as well as ALTER INDEX .. ATTACH PARTITION. While doing this, I noticed a small bug: the ALTER INDEX would not be dumped when only one of the schemas are specified to pg_dump (schema of

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

Robert Haas writes: > On Wed, Jan 17, 2018 at 6:50 PM, Tom Lane wrote: >> * As the patch stands, --set-db-properties is implicit when you specify >> -C, and in fact the patch goes to the trouble of throwing an error if you >> try to specify both

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

On Wed, Jan 17, 2018 at 3:50 PM, Nikolay Shaplov wrote: > This patch raises error if user tries o set or change toast.* option for a > table that does not have a TOST relation. > > I believe it is the only right thing to do, as now if you set toast reloption > for table that

Re: Re: [HACKERS] pgbench randomness initialization

Here is a rebase, plus some more changes: I have improved the error message to tell from where the value was provided. I have removed the test to the exact values produced from the expression test run. I have added a test which run from the same seed value several times and checks that the

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

On Wed, Jan 17, 2018 at 6:50 PM, Tom Lane wrote: > * As the patch stands, --set-db-properties is implicit when you specify > -C, and in fact the patch goes to the trouble of throwing an error if you > try to specify both switches. I'm inclined to think this might be a bad >

Re: Index-only scan returns incorrect results when using a composite GIST index with a gist_trgm_ops column.

On Thu, Jan 18, 2018 at 8:48 AM, Kyotaro HORIGUCHI < horiguchi.kyot...@lab.ntt.co.jp> wrote: > At Wed, 17 Jan 2018 22:26:15 +0300, Sergei Kornilov > wrote in <412861516217...@web38o.yandex.ru> > > Hello > > I can reproduce on actual 9.6.6, 10.1 and fresh master build > >

Re: Typo in slotfuncs.c

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. -- Simon Riggshttp://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training &

Re: MCV lists for highly skewed distributions

On 28 December 2017 at 01:45, Jeff Janes wrote: > If we stored just a few more values, their inclusion in the MCV would mean > they are depleted from the residual count, correctly lowering the estimate > we would get for very rare values not included in the sample. I agree

Re: [HACKERS] postgres_fdw bug in 9.6

(2018/01/18 15:40), Etsuro Fujita wrote: (2018/01/18 7:09), Robert Haas wrote: On Wed, Jan 17, 2018 at 4:08 PM, Tom Lane wrote: It's debatable perhaps -- I tend to err in the other direction. But likewise, I don't care deeply. Just push it ... Done. I noticed that this

Re: [HACKERS] Surjective functional indexes

On 10 January 2018 at 09:54, Konstantin Knizhnik wrote: > Sorry, issue with documentation is fixed. OK, thanks. Patch appears to work cleanly now. I'm wondering now about automatically inferring "recheck_on_update = true" for certain common datatype/operators. It

Re: Index-only scan returns incorrect results when using a composite GIST index with a gist_trgm_ops column.

On Thu, Jan 18, 2018 at 12:57:38PM +0500, Andrey Borodin wrote: >> 18 янв. 2018 г., в 10:48, Kyotaro HORIGUCHI >> написал(а): >> >> Gist imposes the ninth strategy to perform index only scan but >> planner is not considering that >> >> Please find the

Re: GSoC 2018

Hello everyone! > 5 янв. 2018 г., в 1:36, Stephen Frost написал(а): > > * Stephen Frost (sfr...@snowman.net) wrote: >> The deadline for Mentoring organizations to apply is: January 23. > > We currently only have four (4) projects for 2018 listed on our > projects page here:

Re: [HACKERS] Surjective functional indexes

On 18.01.2018 11:38, Simon Riggs wrote: On 10 January 2018 at 09:54, Konstantin Knizhnik wrote: Sorry, issue with documentation is fixed. OK, thanks. Patch appears to work cleanly now. I'm wondering now about automatically inferring "recheck_on_update = true"

Re: master make check fails on Solaris 10

Thank you! On 17-01-2018 19:33, Tom Lane wrote: Attached is a draft patch to incorporate Victor's slimmed-down test into configure. If you have a chance, could you confirm it does the right thing on your Sparc machine? Victor Wagner writes: It seems that

Re: General purpose hashing func in pgbench

Hello Ildar, Patch v8 applies cleanly and compiles. Global and local "make check ok". Doc build ok. For me "random seed" is what is passed to srandom, so the variable should rather be named hash_seed because there could also be a random seed (actually, there is in another parallel patch:-).

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

On 2018/01/17 22:51, Peter Eisentraut wrote: > I'm setting this patch to Returned with feedback. OK. Sorry that I couldn't reply here since the CF started. I have written some code to implement the pg_partition_root() idea you mentioned upthread earlier this week, but hasn't been able to share

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

On 2018/01/02 22:45, Peter Eisentraut wrote: > On 12/28/17 16:24, David Rowley wrote: >>> select pg_partition_root(c.oid), c.relname, pg_table_size(c.oid) >>> from pg_class c >>> order by 1 >>> >>> select pg_partition_root(c.oid), sum(pg_table_size(c.oid)) >>> from pg_class c >>> group by

Re: [HACKERS] path toward faster partition pruning

Thank you Horiguchi-san! On 2018/01/19 12:00, Kyotaro HORIGUCHI wrote: > At Thu, 18 Jan 2018 11:41:00 -0800, Andres Freund wrote: >> Hi Amit, >> >> It seems your mail system continually adds "[Sender Address Forgery]" >> prefixes to messages. E.g. this mail now has >>

Re: [HACKERS] generated columns

On Tue, Jan 16, 2018 at 09:55:16AM -0500, Peter Eisentraut wrote: > Here you go. Those changes actually meant that genbki.pl doesn't need > to be touched by this patch at all, so that's a small win. Thanks for the updated version. I have spent some time looking at what you are proposing here.

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

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 access to the highest relation in the hierarchy, and pg_partition_parent()

Typo in slotfuncs.c

Hi, Attached patch for fixing a typo in slotfuncs.c s/possition/position/ Regards, -- Masahiko Sawada NIPPON TELEGRAPH AND TELEPHONE CORPORATION NTT Open Source Software Center fix_typo_in_slotfuncs_c.patch Description: Binary data

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

Hello, At Thu, 18 Jan 2018 11:41:00 -0800, Andres Freund wrote in <20180118194100.dy3kxdtktsbvm...@alap3.anarazel.de> > Hi Amit, > > It seems your mail system continually adds "[Sender Address Forgery]" > prefixes to messages. E.g. this mail now has > Subject: Re: [Sender

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

... okay, so the reason why --set-db-properties isn't as general-purpose a switch as you might think finally penetrated my thick skull :-( The problem is that, as the patch is currently constituted, that will result in emitting a lot of "ALTER DATABASE foo" type commands. If somebody tries to

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

I wrote: > What I think we should do for the time being is to have pg_dump treat > database tablespace as a property it can't adjust after creation, just > as it can't adjust locale or encoding. That's a loss of functionality > for pg_dumpall/pg_upgrade compared to where we are today, in that if

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

On Wed, Jan 17, 2018 at 07:38:32AM -0500, Stephen Frost wrote: > Thanks for looking at this patch previously. This patch is still in > Needs Review but it's not clear if that's correct or not, but this seems > to be a bug-fix, so it would be great if we could make some progress on > it

Re: make_etags: avoid recursive symbolic creation.

On Thu, Jan 18, 2018 at 03:58:31PM -0800, Ashwin Agrawal wrote: > src/tools/make_etags creates link to TAGS file from each and every > directory in source tree. It works fine without all those links in each and > every directory in source code so remove the extra work and annoyance. > > diff

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

On Thu, Jan 18, 2018 at 9:22 AM, Robert Haas wrote: > I just went back to the thread on "parallel.c oblivion of > worker-startup failures" and refreshed my memory about what's going on > over there. What's going on over there is (1) currently, > nworkers_launched can be

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

Hello, Thank you for the complrehensive explanation, Michael. I happened to see another instance of this failure on one of our client site. The precise steps lead to the situation is not available but it is reported that it had occurred without immediate shutdown. As far as I know just starting

make_etags: avoid recursive symbolic creation.

src/tools/make_etags creates link to TAGS file from each and every directory in source tree. It works fine without all those links in each and every directory in source code so remove the extra work and annoyance. diff --git a/src/tools/make_etags b/src/tools/make_etags index

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

On Fri, Jan 19, 2018 at 10:35 AM, Tom Lane wrote: > I wrote: > > What I think we should do for the time being is to have pg_dump treat > > database tablespace as a property it can't adjust after creation, just > > as it can't adjust locale or encoding. That's a loss of

Re: Add default role 'pg_access_server_files'

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 this task, but it seems that for security reasons we > presently don't allow

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

Hi, I'm mostly away from my computer this week -- sorry about that, but here are a couple of quick answers to questions directed at me: On Thu, Jan 18, 2018 at 4:22 PM, Peter Geoghegan wrote: > On Wed, Jan 17, 2018 at 10:40 AM, Robert Haas wrote: >>> While

Re: Is there a "right" way to test if a database is empty?

On Wed, Jan 17, 2018 at 05:47:16PM +0200, Graham Leggett wrote: > I need to test whether a database is empty, in other words “createdb” > has been executed but no data of any kind appears in that database. > What is the correct postgresql way to do this? There is none, because it highly depends

Re: [HACKERS] Planning counters in pg_stat_statements

On Sat, Jan 13, 2018 at 2:16 PM, Tom Lane wrote: > I wrote: >> Haribabu Kommi writes: >>> I checked the latest patch and it is working fine and I don't have any >>> further comments. Marked the patch as "ready for committer". > >> I started to look