Re: [HACKERS] Creation of "Future" commit fest, named 2017-07

On Mon, Feb 27, 2017 at 12:23 PM, Michael Paquier wrote: > On Mon, Feb 27, 2017 at 3:46 PM, Robert Haas wrote: >> Do we, ah, have a CommitFest manager for this final CommitFest? > > No, victims found yet. > >> /me takes two quick steps backward.

Re: [HACKERS] Documentation improvements for partitioning

On 2017/02/27 3:18, Petr Jelinek wrote: > On 24/02/17 07:15, Robert Haas wrote: >> On Fri, Feb 24, 2017 at 9:53 AM, Simon Riggs wrote: >>> The good news is that logical replication DOES work with partitioning, >>> but only for a Publication with PUBLISH INSERT, pushing from

[HACKERS] Logical replication and inheritance

I see that if the table is a inheritance parent, and ONLY is not specified, the child tables are also added to the publication. create table parent (a int); create table child () inherits (parent); create publication parent_pub for table parent; \d parent Table "public.parent"

Re: [HACKERS] pg_dump does not refresh matviews from extensions

On Thu, Feb 23, 2017 at 5:11 AM, Jim Nasby wrote: > Now that I know that, I guess I'm kinda on the fence about doing it > automatically, because AFAIK there'd be no way to override that automatic > behavior. I can't really conceive of any reason you wouldn't want the >

Re: [HACKERS] Creation of "Future" commit fest, named 2017-07

On Mon, Feb 27, 2017 at 3:46 PM, Robert Haas wrote: > Do we, ah, have a CommitFest manager for this final CommitFest? No, victims found yet. > /me takes two quick steps backward. Which means that you are volunteering? This takes you out of the crowd :D -- Michael --

Re: [HACKERS] I propose killing PL/Tcl's "modules" infrastructure

On Mon, Feb 27, 2017 at 1:24 AM, Tom Lane wrote: > * I'm not terribly comfortable about what the permissions levels of the > GUCs ought to be. The call permissions check means that you can't use > either GUC to call a function you couldn't have called anyway. However >

Re: [HACKERS] Enabling parallelism for queries coming from SQL or other PL functions

On Mon, Feb 27, 2017 at 8:33 AM, Amit Kapila wrote: > Is there any easy way to find out which way is less expensive? No. But that's a separate problem. I'm just saying we shouldn't arbitrarily prohibit parallelism for parallel-safe functions. > Even > if we find some

Re: [HACKERS] DROP FUNCTION of multiple functions

On Sat, Feb 25, 2017 at 10:27 PM, Peter Eisentraut wrote: > Here is a new patch set that addresses your comments. The structure is > still the same, just a bunch of things have been renamed based on > suggestions. + + Drop multiple functions in one command:

Re: [HACKERS] Creation of "Future" commit fest, named 2017-07

On Mon, Feb 27, 2017 at 11:17 AM, Michael Paquier wrote: > As the next commit fest beginning soon, there will be no place where > hackers can park future patches for PG11~. So I have created a Future > CF named 2017-07 where you can do that. > Feel free to use it to

Re: [HACKERS] Parallel bitmap heap scan

On Mon, Feb 27, 2017 at 10:30 AM, Dilip Kumar wrote: > On Sun, Feb 26, 2017 at 9:26 PM, Robert Haas wrote: >> tbm_free_shared_area because the two iterators share one copy of the >> underlying iteration arrays, and the TBM code isn't smart enough to

Re: [HACKERS] SerializedSnapshotData alignment

On Mon, Feb 27, 2017 at 5:13 AM, Noah Misch wrote: > Dear 7b4ac19 authors, > > Field ps_snapshot_data usually receives four-byte alignment within > ParallelIndexScanDescData, but it contains the eight-byte whenTaken field. > The select_parallel test dies with SIGBUS on "Oracle

Re: [HACKERS] pg_serial early wraparound

On Mon, Feb 27, 2017 at 7:28 PM, Thomas Munro wrote: > On Wed, Nov 9, 2016 at 11:07 AM, Thomas Munro > wrote: >> The SLRU managed by predicate.c can wrap around and overwrite data if >> you have more than 1 billion active XIDs.

Re: [HACKERS] pg_serial early wraparound

On Wed, Nov 9, 2016 at 11:07 AM, Thomas Munro wrote: > The SLRU managed by predicate.c can wrap around and overwrite data if > you have more than 1 billion active XIDs. That's because when SSI was > implemented, slru.c was limited to four digit segment names, which

Re: [HACKERS] increasing the default WAL segment size

Hello, Since the following commit, does not enable us to apply the patch cleanly, I have attached a rebased patch 02. patch 01 does not have any problems. commit 9e3755ecb2d058f7d123dd35a2e1784006190962 Author: Tom Lane Date: Sat Feb 25 16:12:24 2017 -0500 Remove

Re: [HACKERS] PGSERVICEFILE as a connection string parameter

On Sun, Feb 26, 2017 at 10:03:40PM -0800, Andres Freund wrote: > Hi, > > On 2017-02-27 14:43:49 +0900, Michael Paquier wrote: > > I bumped into a case where it would have been rather useful to > > specify a service file path in a connection string with a service > > name. In my case, I have

Re: [HACKERS] PGSERVICEFILE as a connection string parameter

Hi, On 2017-02-27 14:43:49 +0900, Michael Paquier wrote: > I bumped into a case where it would have been rather useful to specify > a service file path in a connection string with a service name. In my > case, I have finished by setting up PGSERVICEFILE, but now like > PGPASSFILE I think that

Re: [HACKERS] SerializedSnapshotData alignment

On Mon, Feb 27, 2017 at 5:13 AM, Noah Misch wrote: > Dear 7b4ac19 authors, > > Field ps_snapshot_data usually receives four-byte alignment within > ParallelIndexScanDescData, but it contains the eight-byte whenTaken field. > The select_parallel test dies with SIGBUS on "Oracle

[HACKERS] Creation of "Future" commit fest, named 2017-07

Hi all, As the next commit fest beginning soon, there will be no place where hackers can park future patches for PG11~. So I have created a Future CF named 2017-07 where you can do that. Feel free to use it to park your future patches. The next development schedule is undecided, so the name of

[HACKERS] PGSERVICEFILE as a connection string parameter

Hi all, I bumped into a case where it would have been rather useful to specify a service file path in a connection string with a service name. In my case, I have finished by setting up PGSERVICEFILE, but now like PGPASSFILE I think that being able to define the service file available as well as a

Re: [HACKERS] Automatic cleanup of oldest WAL segments with pg_receivexlog

On Sun, Feb 26, 2017 at 8:24 AM, Michael Paquier wrote: > To be consistent with archive_command and restore_command I'd rather > not do that. The command called can decide by itself what to do by > looking at the shape of the argument string. Just before the CF begins,

Re: [HACKERS] Logical Replication and Character encoding

Sorry for the abesnse. At Fri, 24 Feb 2017 02:43:14 +, "Shinoda, Noriyoshi" wrote in > >From: Peter Eisentraut [mailto:peter.eisentr...@2ndquadrant.com] > >Sent: Friday, February

Re: [HACKERS] Speedup twophase transactions

Hi Michael, Thanks for taking a look at the patch. > twophase.c: In function ‘PrepareRedoAdd’: > twophase.c:2539:20: warning: variable ‘gxact’ set but not used > [-Wunused-but-set-variable] > GlobalTransaction gxact; > There is a warning at compilation. > > Will fix. > The comment at the

Re: [HACKERS] Parallel bitmap heap scan

On Sun, Feb 26, 2017 at 9:26 PM, Robert Haas wrote: Thanks for the review, I will work on these. There are some comments I need suggestions. > tbm_free_shared_area because the two iterators share one copy of the > underlying iteration arrays, and the TBM code isn't smart

Re: [HACKERS] dropping partitioned tables without CASCADE

On 2017/02/27 13:35, Ashutosh Bapat wrote: > On Mon, Feb 27, 2017 at 8:08 AM, Amit Langote > wrote: >> On 2017/02/26 5:30, Simon Riggs wrote: >>> On 23 February 2017 at 16:33, Simon Riggs wrote: >>> I'll be happy to review >>> >>> Patch

Re: [HACKERS] Proposal : Parallel Merge Join

On Sun, Feb 26, 2017 at 12:01 PM, Robert Haas wrote: > On Fri, Feb 24, 2017 at 3:54 PM, Amit Kapila wrote: >> I agree in some cases it could be better, but I think benefits are not >> completely clear, so probably we can leave it as of now and if

Re: [HACKERS] A typo in mcxt.c

I'm happy to know such a thing. mcxt.c is very stable part of the code so those who don't know such things like me rarely comes. At Thu, 23 Feb 2017 22:59:51 -0500, Tom Lane wrote in <31880.1487908...@sss.pgh.pa.us> > Andres Freund writes: > > On

Re: [HACKERS] dropping partitioned tables without CASCADE

On Mon, Feb 27, 2017 at 8:08 AM, Amit Langote wrote: > On 2017/02/26 5:30, Simon Riggs wrote: >> On 23 February 2017 at 16:33, Simon Riggs wrote: >> >>> I'll be happy to review >> >> Patch looks OK so far, but fails on a partition that has

Re: [HACKERS] IF (NOT) EXISTS in psql-completion

At Mon, 27 Feb 2017 10:43:39 +0900, Michael Paquier wrote in > On Mon, Feb 27, 2017 at 10:20 AM, Tom Lane wrote: > > Michael Paquier writes: > >> On

Re: [HACKERS] error detail when partition not found

Thanks for the review. On 2017/02/27 2:39, Robert Haas wrote: > On Tue, Feb 21, 2017 at 7:28 AM, Amit Langote > wrote: >> Simon pointed out in a nearby thread [0] that the detail part of >> partition-not-found error should show just the partition keys. I posted a

Re: [HACKERS] Enabling parallelism for queries coming from SQL or other PL functions

On Sun, Feb 26, 2017 at 4:14 PM, Robert Haas wrote: > On Sun, Feb 26, 2017 at 6:34 AM, Amit Kapila wrote: >> On Sat, Feb 25, 2017 at 9:47 PM, Dilip Kumar wrote: >>> On Sat, Feb 25, 2017 at 5:12 PM, Amit Kapila

Re: [HACKERS] dropping partitioned tables without CASCADE

On 2017/02/26 5:30, Simon Riggs wrote: > On 23 February 2017 at 16:33, Simon Riggs wrote: > >> I'll be happy to review > > Patch looks OK so far, but fails on a partition that has partitions, > probably because of the way we test relkind in the call to >

Re: [HACKERS] Instability in select_parallel regression test

On Sun, Feb 26, 2017 at 11:15 PM, Robert Haas wrote: > On Mon, Feb 20, 2017 at 7:52 AM, Amit Kapila wrote: > >> The main point is if we >> keep any loose end in this area, then there is a chance that the >> regression test select_parallel can still

Re: [HACKERS] timeouts in PostgresNode::psql

Amended patch attached after a few Perl-related comments I got on private mail. Instead of $exc_save !~ /^$timeout_exception.*/ I've updated to: $exc_save !~ /^\Q$timeout_exception\E/ i.e. don't do an unnecessary wildcard match at the end, and disable metachar interpretation in the substituted

Re: [HACKERS] SerializedSnapshotData alignment

On Mon, Feb 27, 2017 at 2:18 PM, Noah Misch wrote: > I wondered the same thing; if nothing else, why don't protosciurus and > castoroides fail the same way? They do use older compilers, "Sun C 5.10 > SunOS_sparc 2009/06/03" and gcc 3.4.3. I have "Sun C 5.12 SunOS_sparc >

Re: [HACKERS] IF (NOT) EXISTS in psql-completion

On Mon, Feb 27, 2017 at 10:20 AM, Tom Lane wrote: > Michael Paquier writes: >> On Mon, Feb 27, 2017 at 10:12 AM, Tom Lane wrote: >>> BTW ... can anyone explain to me the reason why we offer to complete >>> CREATE OBJECT with the

Re: [HACKERS] IF (NOT) EXISTS in psql-completion

Michael Paquier writes: > On Mon, Feb 27, 2017 at 10:12 AM, Tom Lane wrote: >> BTW ... can anyone explain to me the reason why we offer to complete >> CREATE OBJECT with the names of existing objects of that kind? > Isn't that to facilitate

Re: [HACKERS] SerializedSnapshotData alignment

On Sun, Feb 26, 2017 at 07:53:15PM -0500, Tom Lane wrote: > Noah Misch writes: > > Dear 7b4ac19 authors, > > Field ps_snapshot_data usually receives four-byte alignment within > > ParallelIndexScanDescData, but it contains the eight-byte whenTaken field. > > The select_parallel

Re: [HACKERS] IF (NOT) EXISTS in psql-completion

On Mon, Feb 27, 2017 at 10:12 AM, Tom Lane wrote: > Michael Paquier writes: >> On Mon, Feb 27, 2017 at 5:21 AM, Tom Lane wrote: >>> So I'd be a whole lot happier if it didn't do that. Can we really not >>> add the desired

Re: [HACKERS] IF (NOT) EXISTS in psql-completion

Michael Paquier writes: > On Mon, Feb 27, 2017 at 5:21 AM, Tom Lane wrote: >> So I'd be a whole lot happier if it didn't do that. Can we really not >> add the desired features in a more localized fashion? > As "if not exists" is defined after the

Re: [HACKERS] Proposal for changes to recovery.conf API

On Sun, Feb 26, 2017 at 5:56 PM, Robert Haas wrote: > On Sat, Feb 25, 2017 at 7:28 PM, Michael Paquier > wrote: >> - pg_basebackup -R generates recovery.conf.auto. > > Does anything cause that file to get read? > > Wouldn't it be better to just

Re: [HACKERS] SerializedSnapshotData alignment

Noah Misch writes: > Dear 7b4ac19 authors, > Field ps_snapshot_data usually receives four-byte alignment within > ParallelIndexScanDescData, but it contains the eight-byte whenTaken field. > The select_parallel test dies with SIGBUS on "Oracle Solaris 10 1/13 > s10s_u11wos_24a

Re: [HACKERS] IF (NOT) EXISTS in psql-completion

On Mon, Feb 27, 2017 at 5:21 AM, Tom Lane wrote: > Robert Haas writes: >> Yeah, maybe, but we'd need a committer to take more of an interest in >> this patch series. Personally, I'm wondering why we need a series of >> 19 patches to add tab completion

Re: [HACKERS] Statement timeout behavior in extended queries

> On Wed, Feb 22, 2017 at 11:50:44AM +0900, Tatsuo Ishii wrote: >> Last year I have proposed an enhancement regarding behavior of the >> statement timeout in extended queries. >> >> https://www.postgresql.org/message-id/20160528.220442.1489791680347556026.t-ishii%40sraoss.co.jp >> >> IMO the

[HACKERS] SerializedSnapshotData alignment

Dear 7b4ac19 authors, Field ps_snapshot_data usually receives four-byte alignment within ParallelIndexScanDescData, but it contains the eight-byte whenTaken field. The select_parallel test dies with SIGBUS on "Oracle Solaris 10 1/13 s10s_u11wos_24a SPARC", building with gcc 4.9.2. Some credible

Re: [HACKERS] Proposal for changes to recovery.conf API

On 02/26/2017 12:55 AM, Robert Haas wrote: > On Wed, Jan 11, 2017 at 11:23 PM, Simon Riggs wrote: >>> I think the issue was that some people didn't want configuration files >>> in the data directory. By removing recovery.conf we accomplish that. >>> Signal/trigger files

Re: [HACKERS] [Bug fix] PQsendQuery occurs error when target_session_attrs is set to read-write

On Mon, Feb 27, 2017 at 3:12 AM, Robert Haas wrote: > Thanks! Committed. Thanks. -- Michael -- 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] Automatic cleanup of oldest WAL segments with pg_receivexlog

On Fri, Feb 24, 2017 at 11:58 AM, Jim Nasby wrote: > Why not provide % replacements that contain that info? pg_receivexlog has a > much better shot at doing that correctly than some random user tool... > > (%f could certainly be useful for other things) (was

Re: [HACKERS] Statement timeout behavior in extended queries

On Wed, Feb 22, 2017 at 11:50:44AM +0900, Tatsuo Ishii wrote: > Last year I have proposed an enhancement regarding behavior of the > statement timeout in extended queries. > > https://www.postgresql.org/message-id/20160528.220442.1489791680347556026.t-ishii%40sraoss.co.jp > > IMO the current

Re: [HACKERS] btree_gin and btree_gist for enums

On 02/26/2017 03:26 PM, Tom Lane wrote: > Andrew Dunstan writes: >> This works for the btree_gin case. However, there's a difficulty for >> btree_gist - in the puicksplit routine the cmp function is passed to >> qsort() so there is no chance to pass it an flinfo

Re: [HACKERS] gitlab post-mortem: pg_basebackup waiting for checkpoint

Magnus Hagander writes: > On Sun, Feb 26, 2017 at 8:27 PM, Michael Banck > wrote: >> ISTM the consensus is that there should be no output in regular mode, >> but a message should be displayed in verbose and progress mode. > Agreed, and applied as

Re: [HACKERS] gitlab post-mortem: pg_basebackup waiting for checkpoint

On Sun, Feb 26, 2017 at 9:53 PM, Michael Banck wrote: > Hi, > > Am Sonntag, den 26.02.2017, 21:32 +0100 schrieb Magnus Hagander: > > > On Sun, Feb 26, 2017 at 8:27 PM, Michael Banck > > wrote: > > > Agreed, and applied as one patch. Except I

Re: [HACKERS] gitlab post-mortem: pg_basebackup waiting for checkpoint

Hi, Am Sonntag, den 26.02.2017, 21:32 +0100 schrieb Magnus Hagander: > On Sun, Feb 26, 2017 at 8:27 PM, Michael Banck > wrote: > Agreed, and applied as one patch. Except I noticed you also fixed a > couple of entries which were missing the progname in the messages --

Re: [HACKERS] gitlab post-mortem: pg_basebackup waiting for checkpoint

On Sun, Feb 26, 2017 at 8:27 PM, Michael Banck wrote: > Hi, > > Am Dienstag, den 14.02.2017, 18:18 -0500 schrieb Robert Haas: > > On Tue, Feb 14, 2017 at 4:06 PM, Alvaro Herrera > > wrote: > > > I'd rather have a --quiet mode instead. If

Re: [HACKERS] btree_gin and btree_gist for enums

Andrew Dunstan writes: > This works for the btree_gin case. However, there's a difficulty for > btree_gist - in the puicksplit routine the cmp function is passed to > qsort() so there is no chance to pass it an flinfo to set up the call to > the real comparison

Re: [HACKERS] IF (NOT) EXISTS in psql-completion

Robert Haas writes: > Yeah, maybe, but we'd need a committer to take more of an interest in > this patch series. Personally, I'm wondering why we need a series of > 19 patches to add tab completion support for IF NOT EXISTS. The > feature which is the subject of this

Re: [HACKERS] btree_gin and btree_gist for enums

On 02/25/2017 01:39 PM, Andrew Dunstan wrote: > > On 02/25/2017 01:34 PM, Tom Lane wrote: >> Andrew Dunstan writes: >>> On 02/25/2017 12:04 PM, Tom Lane wrote: I think it'd be better to leave DirectFunctionCallN alone and just invent a small number of

Re: [HACKERS] \if, \elseif, \else, \endif (was Re: PSQL commands: \quit_if, \quit_unless)

On Sun, Feb 26, 2017 at 2:47 AM, Fabien COELHO wrote: > > Hello Corey, > > About v18: Patch applies, make check ok, psql tap tests ok. > > > ISTM that contrary to the documentation "\elif something" is not evaluated > in all cases, and the resulting code is harder to

Re: [HACKERS] I propose killing PL/Tcl's "modules" infrastructure

Andrew Dunstan writes: > [ we should borrow plv8's start_proc idea for pltcl ] So after thinking about this for awhile, I propose the following concrete spec for replacing pltcl's autoload-unknown behavior: * Invent two GUCs, pltcl.start_proc and

Re: [HACKERS] IF (NOT) EXISTS in psql-completion

2017-02-26 19:43 GMT+01:00 Robert Haas : > On Wed, Feb 22, 2017 at 12:38 AM, Pavel Stehule > wrote: > > Now first patch is broken :( > > > > It is pretty sensitive to any changes. Isn't possible to commit first > four > > patches first and

Re: [HACKERS] gitlab post-mortem: pg_basebackup waiting for checkpoint

Hi, Am Dienstag, den 14.02.2017, 18:18 -0500 schrieb Robert Haas: > On Tue, Feb 14, 2017 at 4:06 PM, Alvaro Herrera > wrote: > > I'd rather have a --quiet mode instead. If you're running it by hand, > > you're likely to omit the switch, whereas when writing the cron

Re: [HACKERS] PUBLICATIONS and pg_dump

On 08/02/17 05:02, Stephen Frost wrote: > Peter, > > On Tue, Feb 7, 2017 at 22:49 Peter Eisentraut > > wrote: > > On 2/7/17 3:19 PM, Stephen Frost wrote: > > I understand that this is a bit complicated, but I

Re: [HACKERS] IF (NOT) EXISTS in psql-completion

On Wed, Feb 22, 2017 at 12:38 AM, Pavel Stehule wrote: > Now first patch is broken :( > > It is pretty sensitive to any changes. Isn't possible to commit first four > patches first and separately maybe out of commitfest window? Yeah, maybe, but we'd need a committer to

Re: [HACKERS] Documentation improvements for partitioning

On 24/02/17 07:15, Robert Haas wrote: > On Fri, Feb 24, 2017 at 9:53 AM, Simon Riggs wrote: >> The good news is that logical replication DOES work with partitioning, >> but only for a Publication with PUBLISH INSERT, pushing from a normal >> table to a partitioned one.

Re: [HACKERS] [Bug fix] PQsendQuery occurs error when target_session_attrs is set to read-write

On Mon, Feb 20, 2017 at 11:52 AM, Michael Paquier wrote: > On Thu, Feb 16, 2017 at 10:55 AM, Michael Paquier > wrote: >> It is possible to get a test easily in this area by abusing of the >> fact that multiple -d switches defined in psql make

Re: [HACKERS] I propose killing PL/Tcl's "modules" infrastructure

I wrote: > Now, we could try to fix this bug, and add the regression test coverage > that the code clearly lacks, and upgrade the documentation about it from > its currently very sad state. But I think the right answer is just to > remove the feature altogether. BTW, I tried to poke into what it

Re: [HACKERS] Should logtape.c blocks be of type long?

On Sun, Feb 26, 2017 at 9:48 AM, Tom Lane wrote: > [ shrug... ] If you're excited enough about it to do the work, I won't > stand in your way. But I don't find it to be a stop-ship issue. I'll add it to my todo list for Postgres 10. I think it's worth being consistent

Re: [HACKERS] Should logtape.c blocks be of type long?

Peter Geoghegan writes: > On Sun, Feb 26, 2017 at 9:07 AM, Tom Lane wrote: >> Having said that, I'm not sure it's worth the trouble of changing. >> The platforms where there's a difference are probably not muscular >> enough that anyone would ever get past 16TB

Re: [HACKERS] Instability in select_parallel regression test

On Mon, Feb 20, 2017 at 7:52 AM, Amit Kapila wrote: > On Sun, Feb 19, 2017 at 8:32 PM, Robert Haas wrote: >> On Sun, Feb 19, 2017 at 6:50 PM, Amit Kapila wrote: >>> To close the remaining gap, don't you think we can check

Re: [HACKERS] Should logtape.c blocks be of type long?

On Sun, Feb 26, 2017 at 10:37 PM, Tom Lane wrote: > Having said that, I'm not sure it's worth the trouble of changing. > The platforms where there's a difference are probably not muscular > enough that anyone would ever get past 16TB in a temp file anyhow. Is this comment a

Re: [HACKERS] error detail when partition not found

On Tue, Feb 21, 2017 at 7:28 AM, Amit Langote wrote: > Simon pointed out in a nearby thread [0] that the detail part of > partition-not-found error should show just the partition keys. I posted a > patch on that thread [1], but to avoid confusion being caused by

Re: [HACKERS] Should logtape.c blocks be of type long?

On Sun, Feb 26, 2017 at 9:07 AM, Tom Lane wrote: > Yeah. This code is far older than our willingness to assume that every > platform can support int64, and I'm pretty sure that use of "long" was > just a compromise to get the widest values we could use portably and > without

Re: [HACKERS] Parallel Append implementation

On Mon, Feb 20, 2017 at 10:54 AM, Ashutosh Bapat wrote: > On Sun, Feb 19, 2017 at 2:33 PM, Robert Haas wrote: >> On Fri, Feb 17, 2017 at 11:44 AM, Ashutosh Bapat >> wrote: >>> That's true for a partitioned

Re: [HACKERS] tab completion for partitioning

On Mon, Feb 20, 2017 at 8:37 AM, Amit Langote wrote: > Thanks for taking a look. Hm, I think the second part seems to be > needless duplication. So, I changed it to match using TailMatches2("FOR", > "VALUES") and kept just one instance of it. The first part is

Re: [HACKERS] [patch] reorder tablespaces in basebackup tar stream for backup_label

Hi, Am Sonntag, den 26.02.2017, 22:25 +0530 schrieb Robert Haas: > On Tue, Feb 21, 2017 at 3:47 PM, Michael Banck > wrote: > > So I am proposing the attached patch, which sends the base tablespace > > first, and then all the other external tablespaces afterwards, thus

Re: [HACKERS] Should logtape.c blocks be of type long?

Peter Geoghegan writes: > logtape.c stores block numbers on disk. These block numbers are > represented in memory as being of type long. Yeah. This code is far older than our willingness to assume that every platform can support int64, and I'm pretty sure that use of "long" was

Re: [HACKERS] [patch] reorder tablespaces in basebackup tar stream for backup_label

On Tue, Feb 21, 2017 at 3:47 PM, Michael Banck wrote: > currently, the backup_label and (I think) the tablespace_map files are > (by design) conveniently located at the beginning of the main tablespace > tarball when making a basebackup. However, (by accident or also by

Re: [HACKERS] mat views stats

On Wed, Feb 22, 2017 at 11:13 AM, Jim Nasby wrote: > Certainly easier, but I don't think it'd be better. Matviews really aren't > the same thing as tables. Off-hand (without reviewing the patch), update and > delete counts certainly wouldn't make any sense. "Insert"

Re: [HACKERS] Proposal : For Auto-Prewarm.

On Wed, Feb 22, 2017 at 11:49 PM, Mithun Cy wrote: > Hi all thanks, > I have tried to fix all of the comments given above with some more > code cleanups. While reading this patch tonight, I realized a serious problem with the entire approach, which is that this patch

Re: [HACKERS] Parallel bitmap heap scan

On Tue, Feb 21, 2017 at 10:20 AM, Dilip Kumar wrote: > 0001: > 1. I have got a new interface, "tbm_free_shared_area(dsa_area *dsa, > dsa_pointer dp)" which will be responsible for freeing all the shared > members (pagetable, ptpage and ptchunk). Actually, we can not do

Re: [HACKERS] Logical replication existing data copy

On 2017-02-26 10:53, Erik Rijkers wrote: Not yet perfect, but we're getting there... Sorry, I made a mistake: I was running the newest patches on master but the older versions on replica (or more precise: I didn't properly shutdown the replica so the older version remained up and running

Re: [HACKERS] Performance degradation in TPC-H Q18

On Wed, Feb 22, 2017 at 11:23 AM, Kuntal Ghosh wrote: > While conducting the experiments for parallelism, Rafia came across a > hang in Q18 when plan uses partial and finalize hash aggregate. This > could be seen on both scale factors - 20 and 300, on setting work_mem

Re: [HACKERS] Index usage for elem-contained-by-const-range clauses

On Thu, Feb 23, 2017 at 4:47 AM, Pritam Baral wrote: > The topic has been previously discussed[0] on the -performance mailing list, > about four years ago. > > In that thread, Tom suggested[0] the planner could be made to "expand > "intcol <@ > 'x,y'::int4range" into

Re: [HACKERS] Enabling parallelism for queries coming from SQL or other PL functions

On Wed, Feb 22, 2017 at 10:25 AM, Rafia Sabih wrote: > 1. Allow parallelism for queries in PL functions by passing > CURSOR_OPT_PARALLEL_OK instead of 0 to exec_prepare_plan called from > exec_stmt_execsql or exec_stmt_dynexecute. Similarly, pass >

Re: [HACKERS] Allow pg_dumpall to work without pg_authid

On 26 February 2017 at 21:37, Robert Haas wrote: > > How's that not a bug? I mean, it's reasonable for someone to want to > restrict the superuser in a cloud environment, but if they restrict it > so much that you can't take a backup with standard tools, I'd say they >

Re: [HACKERS] Enabling parallelism for queries coming from SQL or other PL functions

On Sun, Feb 26, 2017 at 6:34 AM, Amit Kapila wrote: > On Sat, Feb 25, 2017 at 9:47 PM, Dilip Kumar wrote: >> On Sat, Feb 25, 2017 at 5:12 PM, Amit Kapila wrote: >>> Sure, but that should only happen if the function is

Re: [HACKERS] Allow pg_dumpall to work without pg_authid

On Sun, Feb 26, 2017 at 3:43 PM, Robins Tharakan wrote: > To confirm, this did originate by trying to accommodate a fork. But what > I can say is that this doesn't appear to be a bug; what they call > Super-User isn't effectively one. How's that not a bug? I mean, it's

Re: [HACKERS] Make subquery alias optional in FROM clause

On 2017-02-24 07:25, Robert Haas wrote: > I don't think it's only Oracle that allows omitting the > alias; I think there are a number of other systems that behave > similarly. SQLite, for example. Making conversions from SQLite to Postgres easier is a Good Thing. "subquery in FROM must have an

Re: [HACKERS] Allow pg_dumpall to work without pg_authid

On 26 February 2017 at 19:26, Robert Haas wrote: ​​ > I am a little surprised that this patch has gotten such a good > reception. We haven't in the past been all that willing to accept > core changes for the benefit of forks of PostgreSQL; extensions, sure, > but forks?

Re: [HACKERS] bytea_output output of base64

On Sun, Feb 26, 2017 at 5:19 AM, Peter Eisentraut wrote: >> Is there a reason we chose hex over base64? > > The reason we changed from the old format to hex was for performance. > We didn't consider base64 at the time, but hex would probably still have > been

Re: [HACKERS] Logical replication existing data copy

On 2017-02-26 01:45, Petr Jelinek wrote: Again, much better... : -- out_20170226_0724.txt 25 -- pgbench -c 1 -j 8 -T 10 -P 5 -n 25 -- All is well. -- out_20170226_0751.txt 25 -- pgbench -c 4 -j 8 -T 10 -P 5 -n 25 -- All is well. -- out_20170226_0819.txt 25 -- pgbench -c

Re: [HACKERS] Automatic cleanup of oldest WAL segments with pg_receivexlog

On Thu, Feb 23, 2017 at 9:40 PM, Magnus Hagander wrote: > I'm not sure this logic belongs in pg_receivexlog. If we put the decision > making there, then we lock ourselves into one "type of policy". That's not really true. We can add other policies - or extensibility -

Re: [HACKERS] Should logtape.c blocks be of type long?

On Sun, Feb 26, 2017 at 2:44 AM, Peter Geoghegan wrote: > I tend to be suspicious of use of the type "long" in general, because > in general one should assume that it is no wider than "int". This > calls into question why any code that uses "long" didn't just use > "int", at least

Re: [HACKERS] Proposal for changes to recovery.conf API

On Sat, Feb 25, 2017 at 7:28 PM, Michael Paquier wrote: > - pg_basebackup -R generates recovery.conf.auto. Does anything cause that file to get read? Wouldn't it be better to just append to postgresql.conf.auto? -- Robert Haas EnterpriseDB:

Re: [HACKERS] Proposal for changes to recovery.conf API

On Wed, Jan 11, 2017 at 11:23 PM, Simon Riggs wrote: >> I think the issue was that some people didn't want configuration files >> in the data directory. By removing recovery.conf we accomplish that. >> Signal/trigger files are not configuration (or at least it's much

Re: [HACKERS] Patch: Write Amplification Reduction Method (WARM)

On Sat, Feb 25, 2017 at 10:50 AM, Pavan Deolasee wrote: > On Fri, Feb 24, 2017 at 9:47 PM, Robert Haas wrote: >> And there are no bugs, right? :-) > > Yeah yeah absolutely nothing. Just like any other feature committed to > Postgres so far ;-)

Re: [HACKERS] Allow pg_dumpall to work without pg_authid

On Sun, Feb 19, 2017 at 12:24 AM, Robins Tharakan wrote: > I would like to work on a patch to accommodate restricted environments (such > as AWS RDS Postgres) which don't allow pg_authid access since their > definition of Superuser is just a regular user with extra

Re: [HACKERS] Reduce lock levels for reloptions

On Sat, Feb 25, 2017 at 11:24 PM, Simon Riggs wrote: > Patch to reduce lock levels of various relation-level options, > following on from earlier work by Fabrizio, with additional work and > documentation by me. I have reviewed this patch and I think it looks reasonable.

Re: ParallelFinish-hook of FDW/CSP (Re: [HACKERS] Steps inside ExecEndGather)

On Sat, Feb 25, 2017 at 10:00 AM, Kohei KaiGai wrote: > I tried to add a description how custom-scan callbacks performs under the > executor, and when invoked roughly. > However, it is fundamentally not easy for most of people because it assumes > FDW/CSP author understand