Re: [HACKERS] pg_background contrib module proposal

Hi all, Attaching latest pg_background patch for review as per design proposed on 22 Dec '16 with following minor changes in the api. Changes: 1. pg_background_launch renamed to pg_background_start 2. pg_background_detach renamed to pg_background_close 3. Added new api to display previously

Re: [HACKERS] rewrite HeapSatisfiesHOTAndKey

On Sat, Jan 7, 2017 at 11:27 AM, Mithun Cy wrote: > On Thu, Jan 5, 2017 at 6:15 PM, Amit Kapila wrote: >> >> Your test and results look good, what kind of m/c you have used to >> test this. Let me see if I or one of my colleague can do this

Re: [HACKERS] rewrite HeapSatisfiesHOTAndKey

On Sat, Jan 7, 2017 at 11:27 AM, Mithun Cy wrote: Sorry Auto plain text setting has disturbed the table indentation. Attaching the spreadsheet for same. -- Thanks and Regards Mithun C Y EnterpriseDB: http://www.enterprisedb.com

Re: [HACKERS] rewrite HeapSatisfiesHOTAndKey

On Thu, Jan 5, 2017 at 6:15 PM, Amit Kapila wrote: > > Your test and results look good, what kind of m/c you have used to > test this. Let me see if I or one of my colleague can do this and > similar test on some high-end m/c. As discussed with Amit, I have tried to run

Re: [HACKERS] Block level parallel vacuum WIP

On Fri, Jan 6, 2017 at 11:08 PM, Masahiko Sawada wrote: > On Mon, Oct 3, 2016 at 11:00 AM, Michael Paquier > wrote: >> On Fri, Sep 16, 2016 at 6:56 PM, Masahiko Sawada >> wrote: >>> Yeah, I don't have a good solution for

Re: [HACKERS] _hash_addovflpage has a bug

On Sat, Jan 7, 2017 at 2:33 AM, Robert Haas wrote: > It looks to to me like the recent hash index changes have left > _hash_addovflpage slightly broken. I think that if that function > reaches the point where it calls _hash_getbuf() to fetch the next page > in the bucket

Re: [HACKERS] [PATCH] Rename pg_switch_xlog to pg_switch_wal

On Wed, Jan 4, 2017 at 09:38:42AM -0500, Stephen Frost wrote: > > I think we've been far to cavalier lately about unnecessarily breaking > > admin and monitoring tools. There's been pg_stat_activity backward > > incompat changes in most of the last releases. It's a *PAIN* to develop > >

Re: [HACKERS] Add support to COMMENT ON CURRENT DATABASE

On 1/3/17 11:52 PM, Ashutosh Bapat wrote: > We will need to make CURRENT_DATABASE a reserved keyword. But I like > this idea more than COMMENT ON CURRENT DATABASE. We already have the reserved key word CURRENT_CATALOG, which is the standard spelling. But I wouldn't be bothered if we made

Re: [HACKERS] Replication/backup defaults

On 1/5/17 12:01 PM, Andres Freund wrote: > On 2017-01-05 08:38:32 -0500, Peter Eisentraut wrote: >> I also suggest making the defaults for both 20 instead of 10. That >> leaves enough room that almost nobody ever has to change them, whereas >> 10 can be a bit tight for some not-outrageous

Re: [HACKERS] Replication/backup defaults

On 1/5/17 4:56 PM, Michael Banck wrote: >> You can't actually change the other two without changing wal_level. > That actually goes both ways: I recently saw a server not start cause we > were experimenting with temporarily setting wal_level to minimal for > initial bulk loading, but did not

Re: [HACKERS] merging some features from plpgsql2 project

On Thu, Jan 5, 2017 at 7:03 AM, Robert Haas wrote: > > I think it would be a good idea to lock all the people who really care > about PL/pgsql in a room until they agree on what changes should be > made for the next version of the language. If they don't agree > quickly

Re: [HACKERS] Support for pg_receivexlog --format=plain|tar

On Fri, Jan 6, 2017 at 11:07 PM, Magnus Hagander wrote: > A few further notes: Thanks for the review. > You are using the filemode to gzopen and the mode_compression variable to > set the compression level. The pre-existing code in pg_basebackup uses > gzsetparams(). Is

[HACKERS] Subtle bug in "Simplify tape block format" commit

It seems that commit 01ec2563 has a subtle bug, which stems from the fact that logtape.c no longer follows the rule described above ltsGetFreeBlock(): /* * Select a currently unused block for writing to. * * NB: should only be called when writer is ready to write immediately, * to ensure that

Re: [HACKERS] Block level parallel vacuum WIP

On Fri, Jan 6, 2017 at 2:38 PM, Masahiko Sawada wrote: > table_size | indexes | parallel_degree | time > +-+-+-- > 6.5GB | 0 | 1 | 00:00:14 > 6.5GB | 0 | 2 | 00:00:02 > 6.5GB

Re: [HACKERS] ALTER TABLE .. ALTER COLUMN .. ERROR: attribute .. has wrong type

Alvaro Herrera writes: > Tom Lane wrote: >> Hmm. The bespoke code for constructing the attno map bothers me; >> surely there is existing code that does that? If not, it'd still >> make more sense to factor it out, I think, because there will be >> other needs for it in

Re: [HACKERS] Cluster wide option to control symbol case folding

On Mon, Jan 2, 2017 at 01:25:35PM -0500, Robert Haas wrote: > > But, I can easily imagine a good number of people deciding they want > > mixed case on the server, and so quoting their identifiers. And, then > > deciding PostgreSQL is defective, rather than deciding their favorite > >

Re: [HACKERS] ALTER TABLE .. ALTER COLUMN .. ERROR: attribute .. has wrong type

Tom Lane wrote: > Alvaro Herrera writes: > > Alvaro Herrera wrote: > >> Here's a first attempt at fixing this. It makes the test pass, but I > >> have the feeling that more complex ones might need more work. > > > Here's another one with three main differences: > >

[HACKERS] _hash_addovflpage has a bug

It looks to to me like the recent hash index changes have left _hash_addovflpage slightly broken. I think that if that function reaches the point where it calls _hash_getbuf() to fetch the next page in the bucket chain, we also need to clear retain_pin. Otherwise, we'll erroneously think that

Re: [HACKERS] Add support for SRF and returning composites to pl/tcl

Jim Nasby writes: > On 11/8/16 8:33 AM, Tom Lane wrote: >> As things stand in HEAD, the behavior is about the same, but the error >> messages are not --- in one case they mention triggers and of course the >> other doesn't. There are a couple of other minor things in

Re: [HACKERS] Logical Replication WIP

0005-Add-separate-synchronous-commit-control-for-logical--v16.patch.gz This looks a little bit hackish. I'm not sure how this would behave properly when either synchronous_commit or logical_replication_synchronous_commit is changed at run time with a reload. I'm thinking maybe this and perhaps

Re: [HACKERS] Logical Replication WIP

Comments on 0004-Add-logical-replication-workers-v16.patch.gz: I didn't find any major problems. At times while I was testing strange things it was not clear why "nothing is happening". I'll do some more checking in that direction. Fixup patch attached that enhances some error messages, fixes

Re: [HACKERS] Increase pltcl test coverage

Jim Nasby writes: > On 10/31/16 3:24 PM, Jim Nasby wrote: >> This patch increases test coverage for pltcl, from 70% to 83%. Aside >> from that, the work on this uncovered 2 new bugs (the trigger return one >> I just submitted, as well as a bug in the SRF/composite

Re: [HACKERS] ALTER TABLE .. ALTER COLUMN .. ERROR: attribute .. has wrong type

Alvaro Herrera writes: > Alvaro Herrera wrote: >> Here's a first attempt at fixing this. It makes the test pass, but I >> have the feeling that more complex ones might need more work. > Here's another one with three main differences: Hmm. The bespoke code for

Re: [HACKERS] WIP: [[Parallel] Shared] Hash

On Sat, Jan 7, 2017 at 9:01 AM, Thomas Munro wrote: > On Tue, Jan 3, 2017 at 10:53 PM, Thomas Munro > wrote: >> I will post a new rebased version soon with that and >> some other nearby problems fixed. > > Here is a new WIP patch. I

Re: [HACKERS] ALTER TABLE .. ALTER COLUMN .. ERROR: attribute .. has wrong type

Alvaro Herrera wrote: > Tom Lane wrote: > > > We could probably fix the specific issue being seen here by passing the > > expression tree through a suitable attno remapping, > > Here's a first attempt at fixing this. It makes the test pass, but I > have the feeling that more complex ones might

Re: [HACKERS] WIP: Barriers

On Wed, Nov 23, 2016 at 2:28 PM, Robert Haas wrote: > The code here looks OK. A few thoughts: > > - I'm a little unsure whether it's a good idea to remove the existing > barrier.h and immediately add a new barrier.h that does something > totally different. It's tempting

Re: [HACKERS] Odd behavior with PG_TRY

Kevin Grittner writes: > On Fri, Jan 6, 2017 at 5:43 AM, Michael Paquier > wrote: >> If a variable is modified within PG_TRY and then referenced in >> PG_CATCH it needs to be marked as volatile to be strictly in >> conformance with POSIX. This also

Re: [HACKERS] postgres_fdw : altering foreign table not invalidating prepare statement execution plan.

Etsuro Fujita writes: > On 2017/01/06 21:25, Ashutosh Bapat wrote: >> On Thu, Jan 5, 2017 at 2:49 PM, Etsuro Fujita >> wrote: >>> On 2017/01/03 15:57, Ashutosh Bapat wrote: The patch looks good to me, but I feel there are too many

[HACKERS] Off-by-one oddity in minval for decreasing sequences

Hi, When testing the patch at https://commitfest.postgresql.org/12/768/ ("sequence data type" by Peter E.), I notice that there's a preexisting oddity in the fact that sequences created with a negative increment in current releases initialize the minval to -(2^63)+1 instead of -2^63, the actual

Re: [HACKERS] Odd behavior with PG_TRY

On Fri, Jan 6, 2017 at 5:43 AM, Michael Paquier wrote: > If a variable is modified within PG_TRY and then referenced in > PG_CATCH it needs to be marked as volatile to be strictly in > conformance with POSIX. This also ensures that any compiler does not > do any stupid

Re: [HACKERS] merging some features from plpgsql2 project

Hi > > > > > some examples based on Ada doc > > > > FUNCTION xxx RETURN int AS > > PRAGMA yyy -- pragma has function scope > > BEGIN > > > > FUNCTION xxx RETURN int AS > > BEGIN > > DECLARE > > PRAGMA yyy -- pragma has block scope > > ok, sub-block makes sense over statement level IMO. >

[HACKERS] Placement of InvokeObjectPostAlterHook calls

While reviewing Etsuro-san's patch to force replanning after FDW option changes, I noticed that there is a great lack of consistency about where InvokeObjectPostAlterHook calls have been placed relative to other actions such as forced relcache invals. I wonder exactly what expectations a

Re: [HACKERS] Block level parallel vacuum WIP

On Mon, Oct 3, 2016 at 11:00 AM, Michael Paquier wrote: > On Fri, Sep 16, 2016 at 6:56 PM, Masahiko Sawada > wrote: >> Yeah, I don't have a good solution for this problem so far. >> We might need to improve group locking mechanism for the

Re: [HACKERS] Performance degradation in Bitmapscan (commit 75ae538bc3168bf44475240d4e0487ee2f3bb376)

On Fri, Jan 6, 2017 at 11:06 AM, Andres Freund wrote: > On 2017-01-06 11:01:32 -0500, Robert Haas wrote: >> On Fri, Jan 6, 2017 at 10:43 AM, Andres Freund wrote: >> > On 2016-12-16 09:34:31 -0800, Andres Freund wrote: >> >> > To fix his issue, we need

Re: [HACKERS] Performance degradation in Bitmapscan (commit 75ae538bc3168bf44475240d4e0487ee2f3bb376)

On 2017-01-06 11:01:32 -0500, Robert Haas wrote: > On Fri, Jan 6, 2017 at 10:43 AM, Andres Freund wrote: > > On 2016-12-16 09:34:31 -0800, Andres Freund wrote: > >> > To fix his issue, we need something like your 0001. Are you going to > >> > polish that up soon here? > >> >

Re: [HACKERS] Performance degradation in Bitmapscan (commit 75ae538bc3168bf44475240d4e0487ee2f3bb376)

On Fri, Jan 6, 2017 at 10:43 AM, Andres Freund wrote: > On 2016-12-16 09:34:31 -0800, Andres Freund wrote: >> > To fix his issue, we need something like your 0001. Are you going to >> > polish that up soon here? >> >> Yes. > > I've two versions of a fix for this. One of them

Re: [HACKERS] Indirect indexes

On Fri, Dec 30, 2016 at 5:35 PM, Alvaro Herrera wrote: > Also, vacuuming: my answer continues to be that the killtuple > interface should be good enough, ... How deeply do you believe in that answer? I mean, I grant you that there are many use cases for which that will

Re: [HACKERS] pg_stat_activity.waiting_start

On 2017-01-06 10:43:32 -0500, Bruce Momjian wrote: > On Thu, Jan 5, 2017 at 06:48:17PM -1000, Joel Jacobson wrote: > > On Thu, Jan 5, 2017 at 4:59 PM, Bruce Momjian wrote: > > > Agreed. No need in adding overhead for short-lived locks because the > > > milli-second values are

Re: [HACKERS] pg_stat_activity.waiting_start

On Thu, Jan 5, 2017 at 06:48:17PM -1000, Joel Jacobson wrote: > On Thu, Jan 5, 2017 at 4:59 PM, Bruce Momjian wrote: > > Agreed. No need in adding overhead for short-lived locks because the > > milli-second values are going to be meaningless to users. I would be > > happy if

Re: [HACKERS] Performance degradation in Bitmapscan (commit 75ae538bc3168bf44475240d4e0487ee2f3bb376)

On 2016-12-16 09:34:31 -0800, Andres Freund wrote: > > To fix his issue, we need something like your 0001. Are you going to > > polish that up soon here? > > Yes. I've two versions of a fix for this. One of them basically increases the "spread" of buckets when the density goes up too much. It

Re: [HACKERS] Questionable tag usage

Magnus Hagander writes: > On Thu, Jan 5, 2017 at 5:50 AM, Tom Lane wrote: >> Well ... that will read nicely in output formats that have hyperlinks, >> but not so well on plain dead trees where the cross-reference is either >> invisible or an explicit

Re: [HACKERS] Support for pg_receivexlog --post-segment command

On 1/6/17 10:15 AM, Feike Steenbergen wrote: On 6 January 2017 at 15:42, Magnus Hagander > wrote: Is there actual value in providing both %p and %f? It's not like it's really hard to do, but since the path will be specified on the same

Re: [HACKERS] Support for pg_receivexlog --post-segment command

On 6 January 2017 at 15:42, Magnus Hagander wrote: > Is there actual value in providing both %p and %f? It's not like it's really hard to do, but since the path will be specified on the same commandline, you could just put it in the command? As %f can be determined from %p

Re: [HACKERS] Make pg_basebackup -x stream the default

On Wed, Jan 4, 2017 at 10:43 AM, Magnus Hagander wrote: > > > On Sun, Jan 1, 2017 at 12:47 AM, Michael Paquier < > michael.paqu...@gmail.com> wrote: > >> On Sat, Dec 31, 2016 at 9:24 PM, Magnus Hagander >> wrote: >> > On Tue, Dec 20, 2016 at 11:53 PM,

Re: [HACKERS] [PATCH] guc-ify the formerly hard-coded MAX_SEND_SIZE to max_wal_send

On Fri, Jan 6, 2017 at 8:52 AM, Kevin Grittner wrote: > On Thu, Jan 5, 2017 at 7:32 PM, Jonathon Nelson wrote: > > On Thu, Jan 5, 2017 at 1:01 PM, Andres Freund > wrote: > >> On 2017-01-05 12:55:44 -0600, Jonathon Nelson wrote: > > >>>

Re: [HACKERS] [PATCH] guc-ify the formerly hard-coded MAX_SEND_SIZE to max_wal_send

On Thu, Jan 5, 2017 at 7:32 PM, Jonathon Nelson wrote: > On Thu, Jan 5, 2017 at 1:01 PM, Andres Freund wrote: >> On 2017-01-05 12:55:44 -0600, Jonathon Nelson wrote: >>> In our lab environment and with a 16MiB setting, we saw substantially >>> better

Re: [HACKERS] Support for pg_receivexlog --post-segment command

On Fri, Jan 6, 2017 at 2:55 PM, David Steele wrote: > On 1/6/17 8:49 AM, Feike Steenbergen wrote: > >> >> On Fri, Jan 6, 2017 at 2:30 PM, David Steele > > wrote: >> >>> For my part I still prefer an actual command to be

Re: [HACKERS] Support for pg_receivexlog --format=plain|tar

On 1/6/17 9:07 AM, Magnus Hagander wrote: On Fri, Dec 30, 2016 at 6:41 AM, Michael Paquier > wrote: Attached is a simplified new version, I have kept the file descriptor as originally done. Note that tests are actually

Re: [HACKERS] use strict in all Perl programs

On Fri, Jan 6, 2017 at 11:13 PM, David Steele wrote: > With regard to warnings, I prefer to use: > > use warnings FATAL => qw(all); > > This transforms all warnings into errors rather than just printing a message > to stderr, which is very easy to miss among the other output.

Re: [HACKERS] use strict in all Perl programs

On 1/5/17 12:37 PM, Peter Eisentraut wrote: On 12/31/16 1:34 AM, Michael Paquier wrote: On Sat, Dec 31, 2016 at 3:07 PM, Peter Eisentraut wrote: Here is a patch to add 'use strict' to all Perl programs (that I could find), or move it to the right place where

Re: [HACKERS] UNDO and in-place update

On Fri, Jan 6, 2017 at 6:28 AM, Amit Kapila wrote: >> Also, I'm thinking the bit could be stored in the line pointer rather >> than the tuple, because with this design we don't need >> LP_UNUSED/LP_NORMAL/LP_REDIRECT/LP_DEAD any more. We could use one >> bit to indicate

Re: [HACKERS] Support for pg_receivexlog --format=plain|tar

On Fri, Dec 30, 2016 at 6:41 AM, Michael Paquier wrote: > On Thu, Dec 29, 2016 at 6:13 PM, Magnus Hagander > wrote: > > On Thu, Dec 29, 2016 at 12:35 AM, Michael Paquier > > wrote: > >> On Wed, Dec 28, 2016 at 9:31 PM,

Re: [HACKERS] Questionable tag usage

On Thu, Jan 5, 2017 at 5:50 AM, Tom Lane wrote: > Tatsuo Ishii writes: > > In: > > https://www.postgresql.org/docs/devel/static/runtime- > config-file-locations.html > > "Specifies the configuration file for Section 20.2, $B!H (BUser Name > Maps $B!I (B

Re: [HACKERS] Support for pg_receivexlog --post-segment command

On 1/6/17 8:49 AM, Feike Steenbergen wrote: On Fri, Jan 6, 2017 at 2:30 PM, David Steele > wrote: For my part I still prefer an actual command to be executed so it will start/restart the archiver if it is not already running or died. This

Re: [HACKERS] Support for pg_receivexlog --post-segment command

On Fri, Jan 6, 2017 at 2:30 PM, David Steele wrote: > For my part I still prefer an actual command to be executed so it will start/restart the archiver if it is not already running or died. This reduces the number of processes that I need to ensure are running. > > If the

Re: [HACKERS] Support for pg_receivexlog --post-segment command

On Fri, Jan 6, 2017 at 2:30 PM, David Steele wrote: > On 1/6/17 8:09 AM, Feike Steenbergen wrote: > >> On 6 January 2017 at 13:50, Magnus Hagander > > wrote: >> >>> I think we're better off clearly documenting that we don't

Re: [HACKERS] Support for pg_receivexlog --post-segment command

On 1/6/17 8:09 AM, Feike Steenbergen wrote: On 6 January 2017 at 13:50, Magnus Hagander > wrote: I think we're better off clearly documenting that we don't care about it. And basically let the external command be responsible for that part. So

Re: [HACKERS] Add pgstathashindex() to get hash index table statistics.

Hi, > I think the calculation for max available spcae is wrong here. You > should subtract the page header and special area from the total page size. > A check for non-zero denominator should be added while calculating the > percentage. > There can be multiple bitmap pages. Right? Yes, we can

Re: [HACKERS] Support for pg_receivexlog --post-segment command

On 6 January 2017 at 13:50, Magnus Hagander wrote: > I think we're better off clearly documenting that we don't care about it. And basically let the external command be responsible for that part. > So for example, your typical backup manager would listen to this signal or

Re: [HACKERS] postgres_fdw bug in 9.6

On 2017/01/05 12:10, Etsuro Fujita wrote: On 2016/12/28 17:34, Ashutosh Bapat wrote: Hmm. If I understand the patch correctly, it does not return any path when merge join is allowed and there are merge clauses but no hash clauses. In this case we will not create a foreign join path, loosing

Re: [HACKERS] postgres_fdw : altering foreign table not invalidating prepare statement execution plan.

On 2017/01/06 21:25, Ashutosh Bapat wrote: On Thu, Jan 5, 2017 at 2:49 PM, Etsuro Fujita wrote: On 2017/01/03 15:57, Ashutosh Bapat wrote: The patch looks good to me, but I feel there are too many testscases. Now that we have changed the approach to invalidate

Re: [HACKERS] Support for pg_receivexlog --post-segment command

On Fri, Jan 6, 2017 at 1:45 PM, Feike Steenbergen < feikesteenber...@gmail.com> wrote: > Hi all, > > When reading through "Support for pg_receivexlog --format=plain|tar"[1], I > came across a notion from Magnus Hagander that has crossed my mind a few > times as well in the past years. As the

Re: [HACKERS] [COMMITTERS] pgsql: Fix possible crash reading pg_stat_activity.

On Thu, Jan 5, 2017 at 5:07 PM, Tom Lane wrote: > Robert Haas writes: >> On Thu, Jan 5, 2017 at 4:33 PM, Tom Lane wrote: >>> Better documentation seems required, but really the whole design seems >>> rather wacko. Backends must

[HACKERS] Support for pg_receivexlog --post-segment command

Hi all, When reading through "Support for pg_receivexlog --format=plain|tar"[1], I came across a notion from Magnus Hagander that has crossed my mind a few times as well in the past years. As the feature proposed here is not directly related to that thread, I thought it best to start a new thread

Re: [HACKERS] Potential data loss of 2PC files

Marking this as ready for committer. On Wed, Jan 4, 2017 at 12:16 PM, Michael Paquier wrote: > On Wed, Jan 4, 2017 at 1:23 PM, Ashutosh Bapat > wrote: >> I don't have anything more to review in this patch. I will leave that >>

Re: [HACKERS] postgres_fdw : altering foreign table not invalidating prepare statement execution plan.

On Thu, Jan 5, 2017 at 2:49 PM, Etsuro Fujita wrote: > On 2017/01/03 15:57, Ashutosh Bapat wrote: >> >> The patch looks good to me, but I feel there are too many testscases. >> Now that we have changed the approach to invalidate caches in all >> cases, should we just

Re: [HACKERS] Odd behavior with PG_TRY

On Thu, Jan 5, 2017 at 7:10 PM, Amit Kapila wrote: > Memory contexts used in catch block also doesn't seem to be marked as > volatile, you might want to try by marking them as volatile. Also, it > might worth trying it on some other system to see if you are by any >

Re: [HACKERS] Parallel Append implementation

On Fri, Dec 23, 2016 at 10:51 AM, Amit Khandekar wrote: > Currently an Append plan node does not execute its subplans in > parallel. There is no distribution of workers across its subplans. The > second subplan starts running only after the first subplan finishes, >

Re: [HACKERS] UNDO and in-place update

On Thu, Jan 5, 2017 at 9:25 PM, Robert Haas wrote: > On Wed, Jan 4, 2017 at 6:05 AM, Amit Kapila wrote: >> Okay, so this optimization can work only after all the active >> transactions operating on a page are finished. If that is true, in >> some

Re: [HACKERS] Declarative partitioning - another take

On 2017/01/05 3:26, Robert Haas wrote: > On Tue, Dec 27, 2016 at 8:41 PM, Amit Langote > wrote: >> On 2016/12/27 19:07, Amit Langote wrote: >>> Attached should fix that. >> >> Here are the last two patches with additional information like other >> patches. Forgot

Re: [HACKERS] logical decoding of two-phase transactions

On 5 January 2017 at 12:43, Stas Kelvich wrote: > >> On 5 Jan 2017, at 13:49, Simon Riggs wrote: >> >> Surely in this case the master server is acting as the Transaction >> Manager, and it knows the mapping, so we are good? >> >> I guess if you

Re: [HACKERS] increasing the default WAL segment size

On Fri, Jan 6, 2017 at 6:32 PM, Beena Emerson wrote: > I see the point. I will change the SHOW_WAL_SEGSZ to a general SHOW command > in the next version of the patch. Could you split things? There could be one patch to introduce the SHOW command, and one on top of it for

Re: [HACKERS] increasing the default WAL segment size

On Fri, Jan 6, 2017 at 11:36 AM, Michael Paquier wrote: > On Thu, Jan 5, 2017 at 8:39 PM, Beena Emerson > wrote: > > On Tue, Jan 3, 2017 at 5:46 PM, Michael Paquier < > michael.paqu...@gmail.com> > > wrote: > >> Actually, why not just having