Re: [HACKERS] [POC] hash partitioning

On Fri, Sep 8, 2017 at 6:45 AM, Robert Haas wrote: > On Mon, Sep 4, 2017 at 6:38 AM, amul sul wrote: > > I've updated patch to use an extended hash function (Commit # > > 81c5e46c490e2426db243eada186995da5bb0ba7) for the partitioning. > > Committed 0001

Re: [HACKERS] UPDATE of partition key

On Thu, May 18, 2017 at 9:13 AM, Amit Kapila wrote: > On Wed, May 17, 2017 at 5:17 PM, Robert Haas > wrote: > > On Wed, May 17, 2017 at 6:29 AM, Amit Kapila > wrote: > >> I think we can do this even without using an

Re: [HACKERS] WIP: Aggregation push-down

Ashutosh Bapat wrote: > On Thu, Aug 17, 2017 at 8:52 PM, Antonin Houska wrote: > > Antonin Houska wrote: > > > >> Antonin Houska wrote: > >> > >> > This is a new version of the patch I presented in [1]. >

Re: [HACKERS] pgbench tap tests & minor fixes.

Fabien COELHO writes: > [ pgbench-tap-12.patch ] Pushed, with some minor fooling with comments and after running it through perltidy. (I have no opinions about Perl code formatting, but perltidy does ...) The only substantive change I made was to drop the test that

[HACKERS] Reminder: 10rc1 wraps Monday

see subject. regards, tom lane -- 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] Partition-wise aggregation/grouping

On Wed, Aug 23, 2017 at 4:43 PM, Jeevan Chalke < jeevan.cha...@enterprisedb.com> wrote: > Hi, > > Attached is the patch to implement partition-wise aggregation/grouping. > > As explained earlier, we produce a full aggregation for each partition when > partition keys are leading group by clauses

Re: [HACKERS] WIP: Aggregation push-down

Jeevan Chalke wrote: > 1. > + if (aggref->aggvariadic || > + aggref->aggdirectargs || aggref->aggorder || > + aggref->aggdistinct || aggref->aggfilter) > > I did not understand, why you are not pushing aggregate in above cases? > Can you please explain?

Re: [HACKERS] Red-Black tree traversal tests

On Fri, Sep 8, 2017 at 9:03 PM, Victor Drobny wrote: > Thank you very much for your review. In the attachment you can find v2 of > the patch. FYI this version crashes for me: test test_rbtree ... FAILED (test process exited with exit code 2) It's trying to

Re: [HACKERS] Parallel Append implementation

On Fri, Sep 8, 2017 at 3:59 PM, Amit Khandekar wrote: > On 7 September 2017 at 11:05, Amit Kapila wrote: >> On Thu, Aug 31, 2017 at 12:47 PM, Amit Khandekar >> wrote: >> 3. >> +/*

Re: [HACKERS] Support to COMMENT ON DATABASE CURRENT_DATABASE

On Fri, Aug 25, 2017 at 11:16 AM, Jing Wang wrote: > Hi all, > > Enclosed please find the updated patch with covering security labels on > database. > > The patch cover the following commands: > i can't apply your patch cleanly i think it needs rebase Regards Surafel

Re: [HACKERS] WAL logging problem in 9.4.3?

Thank you for your notification. At Tue, 5 Sep 2017 12:05:01 +0200, Daniel Gustafsson wrote in > > On 13 Apr 2017, at 11:42, Kyotaro HORIGUCHI > > wrote: > > > > At Thu, 13 Apr 2017 13:52:40

Re: [HACKERS] Hash Functions

On Fri, Sep 1, 2017 at 8:01 AM, Robert Haas wrote: > On Thu, Aug 31, 2017 at 8:40 AM, amul sul wrote: > > Fixed in the attached version. > > I fixed these up a bit and committed them. Thanks. > > I think this takes care of adding not only the

Re: [HACKERS] Red-Black tree traversal tests

Dear Tom, Thank you very much for your review. In the attachment you can find v2 of the patch. On 2017-09-07 01:38, Tom Lane wrote: [ btw, please don't cc pgsql-hackers-owner, the list moderators don't need the noise ] Aleksander Alekseev writes: I would say

Re: [HACKERS] log_destination=file

> On 8 September 2017 at 01:32, Magnus Hagander wrote: > > 1. where was stderr actually sent? To the console, to /dev/null or to a file? To the console (but I can also try other options, although I'm not sure if it would have any impact). > 2. Could you run the same thing

Re: [HACKERS] CLUSTER command progress monitor

On Wed, Aug 30, 2017 at 10:12 PM, Tatsuro Yamada wrote: > 1. scanning heap > 2. sort tuples These two phases overlap, though. I believe progress reporting for sorts is really hard. In the simple case where the data fits in work_mem, none of the work of the sort

Re: [HACKERS] Parallel Append implementation

On 7 September 2017 at 11:05, Amit Kapila wrote: > On Thu, Aug 31, 2017 at 12:47 PM, Amit Khandekar > wrote: >> The last updated patch needs a rebase. Attached is the rebased version. >> > > Few comments on the first read of the patch: Thanks !

Re: [HACKERS] Partition-wise join for join between (declaratively) partitioned tables

On Fri, Sep 8, 2017 at 12:34 AM, Robert Haas wrote: > On Tue, Sep 5, 2017 at 7:01 AM, Ashutosh Bapat > wrote: >> accumulate_append_subpath() is executed for every path instead of >> every relation, so changing it would collect the same list

Re: [HACKERS] Parallel Append implementation

On Wed, Aug 30, 2017 at 5:32 PM, Amit Khandekar wrote: > Hi Rafia, > > On 17 August 2017 at 14:12, Amit Khandekar wrote: >> But for all of the cases here, partial >> subplans seem possible, and so even on HEAD it executed Partial >> Append. So

Re: [HACKERS] code cleanup empty string initializations

The following review has been posted through the commitfest application: make installcheck-world: tested, passed Implements feature: tested, passed Spec compliant: tested, passed Documentation:tested, passed Hi Peter, I looked through your patches and its look good

Re: [HACKERS] Partition-wise join for join between (declaratively) partitioned tables

On Fri, Sep 8, 2017 at 1:47 AM, Amit Langote wrote: > When I tried the attached patch, it doesn't seem to expand partitioning > inheritance in step-wise manner as the patch's title says. I think the > rewritten patch forgot to include Ashutosh's changes to >

Re: [HACKERS] Re: proposal - using names as primary names of plpgsql function parameters instead $ based names

Hi Pavel, On Sat, May 20, 2017 at 11:55 AM, Pavel Stehule wrote: > > > > 2017-05-19 5:48 GMT+02:00 Pavel Stehule : > >> >> >> 2017-05-19 3:14 GMT+02:00 Peter Eisentraut > com>: >> >>> On 5/15/17 14:34, Pavel

Re: [HACKERS] GnuTLS support

On Thu, Sep 7, 2017 at 10:35 PM, Tom Lane wrote: > I think we might be best off just playing it straight and providing > a config file that contains a section along these lines: > > # Parameters for OpenSSL. Leave these commented out if not using OpenSSL. > # > #ssl_ciphers =

Re: [HACKERS] UPDATE of partition key

On Thu, Sep 7, 2017 at 6:17 AM, Amit Khandekar wrote: > On 3 September 2017 at 17:10, Amit Khandekar wrote: >> After recent commit 30833ba154, now the partitions are expanded in >> depth-first order. It didn't seem worthwhile rebasing my partition

Re: [HACKERS] expanding inheritance in partition bound order

On 2017/09/05 14:11, Amit Khandekar wrote: > Great, thanks. Just wanted to make sure someone is working on that, > because, as you said, it is no longer an EIBO patch. Since you are > doing that, I won't work on that. Here is that patch (actually two patches). Sorry it took me a bit.

Re: [HACKERS] Block level parallel vacuum WIP

On Tue, Aug 15, 2017 at 10:13 AM, Masahiko Sawada wrote: > On Wed, Jul 26, 2017 at 5:38 PM, Masahiko Sawada > wrote: >> On Sun, Mar 5, 2017 at 4:09 PM, Masahiko Sawada >> wrote: >>> On Sun, Mar 5, 2017 at 12:14 PM, David

Re: [HACKERS] Parallel worker error

On Fri, Sep 8, 2017 at 1:17 AM, Amit Kapila wrote: > You are right. I have changed the ordering and passed OuterUserId via > FixedParallelState. This looks a little strange: +SetCurrentRoleId(fps->outer_user_id, fps->is_current_user_superuser); The first argument

Re: [HACKERS] UPDATE of partition key

On 2017/09/08 18:57, Robert Haas wrote: >> As mentioned by Amit Langote in the above mail thread, he is going to >> do changes for making RelationGetPartitionDispatchInfo() return the >> leaf partitions in depth-first order. Once that is done, I will then >> remove the hash table method for

Re: [HACKERS] More flexible LDAP auth search filters?

A couple of comments on this patch. I have attached a "fixup" patch on top of your v4 that should address them. - I think the bracketing of the LDAP URL synopsis is wrong. - I have dropped the sentence that LDAP URL extensions are not supported. That sentence was written mainly to point out

Re: [HACKERS] Fix performance degradation of contended LWLock on NUMA

Hi, On 07/18/2017 01:20 PM, Sokolov Yura wrote: I'm sending rebased version with couple of one-line tweaks. (less skip_wait_list on shared lock, and don't update spin-stat on aquiring) I have been running this patch on a 2S/28C/56T/256Gb w/ 2 x RAID10 SSD setup (1 to 375 clients on logged

Re: [HACKERS] Red-Black tree traversal tests

On 2017-09-08 15:23, Thomas Munro wrote: On Fri, Sep 8, 2017 at 9:03 PM, Victor Drobny wrote: Thank you very much for your review. In the attachment you can find v2 of the patch. FYI this version crashes for me: test test_rbtree ... FAILED (test

Re: [HACKERS] pgbench tap tests & minor fixes.

Hello Tom, Pushed, with some minor fooling with comments and after running it through perltidy. (I have no opinions about Perl code formatting, but perltidy does ...) Why not. I do not like the result much, but it homogeneity is not a bad thing. The only substantive change I made was to

Re: [HACKERS] More flexible LDAP auth search filters?

For additional entertainment I have written a test suite for this LDAP authentication functionality. It's not quite robust enough to be run by default, because it needs a full OpenLDAP installation, but it's been very helpful for reviewing this patch. Here it is. -- Peter Eisentraut

[HACKERS] Commitfest 201709 Progress

We are now a few days in on Commitfest 201709 and there has been lots of activity on the patches. 22% of the patches have been committed* with another 10% being marked Ready for Committer. Thank you all for the hard work! There is still a lot to do though, this fest has a recordbreaking 256

Re: [HACKERS] Adding support for Default partition in partitioning

On Fri, Sep 8, 2017 at 6:46 AM, Robert Haas wrote: > On Thu, Sep 7, 2017 at 8:13 AM, Jeevan Ladhe > wrote: > > The fix would be much easier if the refactoring patch 0001 by Amul in > hash > > partitioning thread[2] is committed. > > Done. >

Re: [HACKERS] code cleanup empty string initializations

On 9/8/17 03:45, Aleksandr Parfenov wrote: > The following review has been posted through the commitfest application: > make installcheck-world: tested, passed > Implements feature: tested, passed > Spec compliant: tested, passed > Documentation:tested, passed > > Hi

Re: [HACKERS] [bug fix] Savepoint-related statements terminates connection

Catalin Iacob writes: > When reading this I also realized that the backend does send responses for > every individual query in a multi-query request, it's only libpq's PQexec > that throws away the intermediate results and only provides access to the > last one. If you

Re: [HACKERS] [POC] Faster processing at Gather node

Hi Rafia, I like the idea of reducing locking overhead by sending tuples in bulk. The implementation could probably be simpler: you could extend the API of shm_mq to decouple notifying the sender from actually putting data into the queue (i.e., make shm_mq_notify_receiver public and make a

[HACKERS] SAP Application deployment on PostgreSQL

Hi All, We have multiple SAP applications running on Oracle as backend and looking for an opportunity to migrate from Oracle to PostgreSQL. Has anyone ever deployed SAP on PostgreSQL community edition? Is PostgreSQL community involved in any future road-map of SAP application deployment on

Re: [HACKERS] pgbench - allow to store select results into variables

Here is a v12. There is no changes in the code or documentation, only TAP tests are added. -- Fabien.diff --git a/doc/src/sgml/ref/pgbench.sgml b/doc/src/sgml/ref/pgbench.sgml index f5db8d1..9ad82d4 100644 --- a/doc/src/sgml/ref/pgbench.sgml +++ b/doc/src/sgml/ref/pgbench.sgml @@ -818,6

Re: [HACKERS] PoC plpgsql - possibility to force custom or generic plan

2017-09-08 21:21 GMT+02:00 Daniel Gustafsson : > > On 08 Sep 2017, at 19:14, Simon Riggs wrote: > > > > On 6 September 2017 at 07:43, Robert Haas wrote: > > > >> LET custom_plan_tries = 0 IN SELECT ... > > > > Tom has pointed me at

Re: [HACKERS] More flexible LDAP auth search filters?

On 08/09/17 16:33, Peter Eisentraut wrote: > A couple of comments on this patch. I have attached a "fixup" patch on > top of your v4 that should address them. > > - I think the bracketing of the LDAP URL synopsis is wrong. > > - I have dropped the sentence that LDAP URL extensions are not >

Re: [HACKERS] additional contrib test suites

On 9/6/17 07:11, Thomas Munro wrote: > After applying these patches cleanly on top of > 0b554e4e63a4ba4852c01951311713e23acdae02 and running "./configure > --enable-tap-tests --with-tcl --with-python --with-perl --with-ldap > --with-icu && make && make check-world" I saw this failure: Yes, some

Re: [HACKERS] PoC plpgsql - possibility to force custom or generic plan

On 6 September 2017 at 07:43, Robert Haas wrote: > LET custom_plan_tries = 0 IN SELECT ... Tom has pointed me at this proposal, since on another thread I asked for something very similar. (No need to reprise that discussion, but I wanted prepared queries to be able to do

Re: [HACKERS] PoC plpgsql - possibility to force custom or generic plan

On 6 September 2017 at 07:43, Robert Haas wrote: > LET custom_plan_tries = 0 IN SELECT ... Tom has pointed me at this proposal, since on another thread I asked for something very similar. (No need to reprise that discussion, but I wanted prepared queries to be able to do

Re: [HACKERS] [bug fix] Savepoint-related statements terminates connection

On Thu, Sep 7, 2017 at 8:07 PM, Tom Lane wrote: > I've pushed up an attempt at this: > > https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=b976499480bdbab6d69a11e47991febe53865adc > > Feel free to suggest improvements. Thank you, this helps a lot. Especially

Re: [HACKERS] PoC plpgsql - possibility to force custom or generic plan

2017-09-08 19:14 GMT+02:00 Simon Riggs : > On 6 September 2017 at 07:43, Robert Haas wrote: > > > LET custom_plan_tries = 0 IN SELECT ... > > Tom has pointed me at this proposal, since on another thread I asked > for something very similar. (No need

Re: [HACKERS] PoC plpgsql - possibility to force custom or generic plan

> On 08 Sep 2017, at 19:14, Simon Riggs wrote: > > On 6 September 2017 at 07:43, Robert Haas wrote: > >> LET custom_plan_tries = 0 IN SELECT ... > > Tom has pointed me at this proposal, since on another thread I asked > for something very similar.

Re: [HACKERS] The case for removing replacement selection sort

On Thu, Sep 7, 2017 at 2:49 PM, Robert Haas wrote: > On Thu, Sep 7, 2017 at 5:38 PM, Tomas Vondra > wrote: >> Do we need/want to repeat some of that benchmarking on these patches? I >> don't recall how much this code changed since those

Re: [HACKERS] Create replication slot in pg_basebackup if requested and not yet present

On Wed, Sep 6, 2017 at 9:22 AM, Peter Eisentraut < peter.eisentr...@2ndquadrant.com> wrote: > On 8/18/17 05:28, Michael Banck wrote: > >>> Rebased, squashed and slighly edited version attached. I've added this > >>> to the 2017-07 commitfest now as well: > >>> > >>>

Re: [HACKERS] Fix performance degradation of contended LWLock on NUMA

Hi, Jesper Thank you for reviewing. On 2017-09-08 18:33, Jesper Pedersen wrote: Hi, On 07/18/2017 01:20 PM, Sokolov Yura wrote: I'm sending rebased version with couple of one-line tweaks. (less skip_wait_list on shared lock, and don't update spin-stat on aquiring) I have been running

[HACKERS] Re: [COMMITTERS] pgsql: Fix assorted portability issues in new pgbench TAP tests.

Hello, Please find attached "blind" additional fixes for Windows & AIX. - more nan/inf variants - different message on non existing user - illegal vs unrecognized options I suspect that $windows_os is not true on "bowerbird", in order to fix it the value of "$Config{osname}" is needed...

Re: [HACKERS] PoC plpgsql - possibility to force custom or generic plan

Pavel Stehule writes: > personally I prefer syntax without FOR keyword - because following keyword > must be reserved keyword > SET x = .., y = .. SELECT ... ; Nope. Most of the statement-starting keywords are *not* fully reserved; they don't need to be as long as they

Re: [HACKERS] PoC plpgsql - possibility to force custom or generic plan

On Fri, Sep 8, 2017 at 2:09 PM, Tom Lane wrote: > Pavel Stehule writes: > > personally I prefer syntax without FOR keyword - because following > keyword > > must be reserved keyword > > > SET x = .., y = .. SELECT ... ; > > Nope. Most of the

Re: [HACKERS] SAP Application deployment on PostgreSQL

On 8 September 2017 at 15:34, chiru r wrote: > We have multiple SAP applications running on Oracle as backend and looking > for an opportunity to migrate from Oracle to PostgreSQL. Has anyone ever > deployed SAP on PostgreSQL community edition? > > Is PostgreSQL community

Re: [HACKERS] tupconvert.c API change in v10 release notes

Bruce Momjian writes: > On Wed, Jul 19, 2017 at 12:39:07PM -0400, Tom Lane wrote: >> Yeah, I see nothing about 3f902354b in release-10.sgml either. >> We've had varying policies over the years about whether to mention >> internal API changes in the release notes or not, but this

Re: [HACKERS] PoC plpgsql - possibility to force custom or generic plan

Merlin Moncure writes: > We already have 'SET LOCAL', which manages scope to the current > transaction. How about SET BLOCK which would set until you've left > the current statement block? (1) I do not think this approach will play terribly well in any of the PLs; their

Re: [HACKERS] Adding support for Default partition in partitioning

On Fri, Sep 8, 2017 at 10:08 AM, Jeevan Ladhe wrote: > Thanks Robert for taking care of this. > My V29 patch series[1] is based on this commit now. Committed 0001-0003, 0005 with assorted modifications, mostly cosmetic, but with some actual changes to

Re: [HACKERS] PoC plpgsql - possibility to force custom or generic plan

On Fri, Sep 8, 2017 at 2:48 PM, Pavel Stehule wrote: > > > 2017-09-08 21:21 GMT+02:00 Daniel Gustafsson : >> >> > On 08 Sep 2017, at 19:14, Simon Riggs wrote: >> > >> > On 6 September 2017 at 07:43, Robert Haas

Re: [HACKERS] psql: new help related to variables are not too readable

Hi, On 09/08/2017 07:25 AM, Fabien COELHO wrote: > > Hello, > >>>   PSQL_HISTORY   alternative location for the command history file >>> >>> I would prefer to revert to that more compact 9.6-formatting. >> >> There was a problem with line width .. its hard to respect 80 chars > > Yes. > >

Re: [HACKERS] Partition-wise join for join between (declaratively) partitioned tables

On Fri, Sep 8, 2017 at 1:38 PM, Ashutosh Bapat wrote: >> I also confirmed that the partition-pruning patch set works fine with this >> patch instead of the patch on that thread with the same functionality, >> which I will now drop from that patch set. Sorry about

Re: [HACKERS] More flexible LDAP auth search filters?

On Sat, Sep 9, 2017 at 3:36 AM, Peter Eisentraut wrote: > For additional entertainment I have written a test suite for this LDAP > authentication functionality. It's not quite robust enough to be run by > default, because it needs a full OpenLDAP installation,

Re: [HACKERS] More flexible LDAP auth search filters?

On Sat, Sep 9, 2017 at 3:33 AM, Peter Eisentraut wrote: > A couple of comments on this patch. I have attached a "fixup" patch on > top of your v4 that should address them. > > - I think the bracketing of the LDAP URL synopsis is wrong. +1 > - I have dropped

Re: [HACKERS] Parallel worker error

On Fri, Sep 8, 2017 at 3:13 PM, Robert Haas wrote: > On Fri, Sep 8, 2017 at 1:17 AM, Amit Kapila wrote: >> You are right. I have changed the ordering and passed OuterUserId via >> FixedParallelState. > > This looks a little strange: > > +

Re: [HACKERS] psql: new help related to variables are not too readable

Tomas Vondra writes: > The translator has exactly the same context in both cases, and the > struggle to wrap it at 80 characters will be pretty much the same too. Really? With the old way, you had something under 60 characters to work in, now it's nearly 80. I

Re: [HACKERS] path toward faster partition pruning

On 2017/09/08 4:41, Robert Haas wrote: > On Thu, Sep 7, 2017 at 7:16 AM, Amit Langote > wrote: >> There is a patch in the Ashutosh's posted series of patches, which does >> more or less the same thing that this patch does. He included it in his >> series of

Re: [HACKERS] Create replication slot in pg_basebackup if requested and not yet present

Hi, Am Mittwoch, den 06.09.2017, 12:22 -0400 schrieb Peter Eisentraut: > On 8/18/17 05:28, Michael Banck wrote: > > > > Rebased, squashed and slighly edited version attached. I've added this > > > > to the 2017-07 commitfest now as well: > > > > > > > > https://commitfest.postgresql.org/14/1112/

Re: [HACKERS] PoC plpgsql - possibility to force custom or generic plan

> > > > SET x = .., y = .. SELECT ... ; > > This seems pretty ugly from a syntax perspective. > > We already have 'SET LOCAL', which manages scope to the current > transaction. How about SET BLOCK which would set until you've left > the current statement block? > This is reason why PRAGMA was

Re: [HACKERS] new function for tsquery creartion

On Thu, Jul 20, 2017 at 4:58 AM, Robert Haas wrote: > On Wed, Jul 19, 2017 at 12:43 PM, Victor Drobny > wrote: >> Let me introduce new function for full text search query creation(which is >> called 'queryto_tsquery'). It takes 'google like' query

Re: [HACKERS] Adding support for Default partition in partitioning

On Sat, Sep 9, 2017 at 3:05 AM, Robert Haas wrote: > On Fri, Sep 8, 2017 at 10:08 AM, Jeevan Ladhe > wrote: > > Thanks Robert for taking care of this. > > My V29 patch series[1] is based on this commit now. > > Committed 0001-0003, 0005 with

Re: [HACKERS] Cached plans and statement generalization

On Fri, May 26, 2017 at 3:54 AM, Konstantin Knizhnik wrote: > Attached please find rebased version of the autoprepare patch based on Tom's > proposal (perform analyze for tree with constant literals and then replace > them with parameters). > Also I submitted this patch

Re: [HACKERS] Still another race condition in recovery TAP tests

On Sat, Sep 9, 2017 at 11:32 AM, Tom Lane wrote: > In a moment of idleness I tried to run the TAP tests on pademelon, > which is a mighty old and slow machine. How long did it take? Just wondering if that's actually the slowest one or not to run the full set of recovery

[HACKERS] Still another race condition in recovery TAP tests

In a moment of idleness I tried to run the TAP tests on pademelon, which is a mighty old and slow machine. Behold, src/test/recovery/t/010_logical_decoding_timelines.pl fell over, with the relevant section of its log contents being: # testing logical timeline following with a filesystem-level

Re: [HACKERS] [POC] Faster processing at Gather node

On Fri, Sep 8, 2017 at 11:07 PM, Alexander Kuzmenkov wrote: > Hi Rafia, > > I like the idea of reducing locking overhead by sending tuples in bulk. The > implementation could probably be simpler: you could extend the API of shm_mq > to decouple notifying the sender

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

On Fri, Sep 8, 2017 at 10:24 AM, Thomas Munro wrote: > On Mon, Aug 21, 2017 at 4:35 PM, Haribabu Kommi > wrote: > > On Tue, Aug 15, 2017 at 7:29 AM, Peter Eisentraut > > wrote: > >> On 4/4/17 01:06,

Re: [HACKERS] Patch: add --if-exists to pg_recvlogical

On Sat, Sep 2, 2017 at 5:22 AM, Peter Eisentraut wrote: > > + --if-exists > + > + > +Do not error out when --drop-slot or > --start are > +specified and a slot with the specified name does not exist. > + > + >

Re: [HACKERS] Still another race condition in recovery TAP tests

Michael Paquier writes: > On Sat, Sep 9, 2017 at 11:32 AM, Tom Lane wrote: >> In a moment of idleness I tried to run the TAP tests on pademelon, >> which is a mighty old and slow machine. > How long did it take? The last time I tried it, make

Re: [HACKERS] [Proposal] Allow users to specify multiple tables in VACUUM commands

On Fri, Sep 8, 2017 at 7:27 AM, Bossart, Nathan wrote: > On 9/7/17, 2:33 AM, "Michael Paquier" wrote: >> Using the patch checking for duplicate columns: >> =# create table aa (a int); >> CREATE TABLE >> =# vacuum ANALYZE aa(z, z); >> ERROR: 0A000: