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

On Sat, Jan 20, 2018 at 7:08 AM, Tomas Vondra wrote: > On 01/19/2018 03:34 PM, Tomas Vondra wrote: >> Attached is v5, fixing a silly bug in part 0006, causing segfault when >> creating a subscription. >> > > Meh, there was a bug in the sgml docs ( vs. ), > causing another failure. Hopefully v6 wil

Re: A typo in error message

On Wed, Jan 31, 2018 at 08:47:57AM +0300, Alexander Lakhin wrote: > Please consider committing the attached patch to fix a typo in error > message. Yeah.. > if (cxt->ofType) > ereport(ERROR, > (errcode(ERRCODE_FEATURE_NOT_S

A typo in error message

Hello, Please consider committing the attached patch to fix a typo in error message. Best regards, -- Alexander Lakhin Postgres Professional: http://www.postgrespro.com The Russian Postgres Company diff --git a/src/backend/parser/parse_utilcmd.c b/src/backend/parser/parse_utilcmd.c index e0d

Re: [HACKERS] [PATCH] Improve geometric types

At Sun, 21 Jan 2018 21:59:19 +0100, Emre Hasegeli wrote in > New versions are attached including all changes we discussed. Thanks for the new version. # there's many changes from the previous version.. About 0001 and 0002. 1."COPT=-DGEODEBUG make" complains as follows. | geo_ops.c:2445:62

[PATCH] Add missing type conversion functions for PL/Python

Hi All, PL/Python already has different type conversion functions to convert PostgreSQL datum to Python object. However, the conversion functions from Python object to PostgreSQL datum only has Boolean, Bytea and String functions. In this patch, we add rest of Integer and Float related datatype c

Re: Wait for parallel workers to attach

On Wed, Jan 31, 2018 at 8:46 AM, Robert Haas wrote: > On Tue, Jan 30, 2018 at 10:10 PM, Amit Kapila wrote: >> I am not getting what exactly you are suggesting here. The wait loop >> is intended for the case when some workers are not started. We want >> to wait for sometime before checking again

Re: [HACKERS] [PATCH]make pg_rewind to not copy useless WAL files

On Fri, Jan 26, 2018 at 11:36:09AM +0900, Michael Paquier wrote: > In short, it seems really to me that we should reject the approach as > proposed, and replace it with something that prevents the fetching of > any WAL segments from the source server. I think that we could consider > as well removi

Re: Wait for parallel workers to attach

On Tue, Jan 30, 2018 at 10:10 PM, Amit Kapila wrote: >> known_started_workers looks a lot like any_message_received. Perhaps >> any_message_received should be renamed to known_started_workers and >> reused here. > > Sure, that sounds good to me. Do you prefer a separate patch for > renaming any_

Re: Wait for parallel workers to attach

On Mon, Jan 29, 2018 at 8:25 PM, Robert Haas wrote: > On Sat, Jan 27, 2018 at 3:14 AM, Amit Kapila wrote: >> During the recent development of parallel operation (parallel create >> index)[1], a need has been arised for $SUBJECT. The idea is to allow >> leader backend to rely on number of workers

Re: JIT compiling with LLVM v9.0

Hi, On 2018-01-31 15:48:09 +1300, Thomas Munro wrote: > On Wed, Jan 31, 2018 at 3:05 PM, Andres Freund wrote: > > I'm not quite sure I understand. You mean have it display whether > > available? I think my plan is to "just" set jit_expressions=on (or > > whatever we're going to name it) fail if t

Re: JIT compiling with LLVM v9.0

On Wed, Jan 31, 2018 at 3:05 PM, Andres Freund wrote: > On 2018-01-31 14:42:26 +1300, Thomas Munro wrote: >> I'm just starting to look at this (amazing) work, and I don't have a >> strong opinion yet. But certainly, making it easy for packagers to >> put the -jit stuff into a separate package for

Re: [HACKERS] postgres_fdw bug in 9.6

(2018/01/31 4:56), Robert Haas wrote: On Sat, Jan 20, 2018 at 12:20 AM, Tom Lane wrote: It looks like Etsuro-san's proposed patch locks down the choice of plan more tightly, which is probably a reasonable answer. OK, committed. I added a comment along the lines you suggested previously, sinc

Re: JIT compiling with LLVM v9.0

On 2018-01-31 14:42:26 +1300, Thomas Munro wrote: > I'm just starting to look at this (amazing) work, and I don't have a > strong opinion yet. But certainly, making it easy for packagers to > put the -jit stuff into a separate package for the reasons already > given sounds sensible to me. Some sy

Re: [HACKERS] GUC for cleanup indexes threshold.

On Fri, Jan 12, 2018 at 1:05 PM, Masahiko Sawada wrote: > On Wed, Jan 10, 2018 at 11:28 AM, Masahiko Sawada > wrote: >> On Sun, Jan 7, 2018 at 8:40 AM, Peter Geoghegan wrote: >>> On Sat, Jan 6, 2018 at 2:20 PM, Stephen Frost wrote: > > IIRC the patches that makes the cleanup scan skip has

Re: JIT compiling with LLVM v9.0

On Wed, Jan 31, 2018 at 11:57 AM, Andres Freund wrote: > On 2018-01-30 13:46:37 -0500, Robert Haas wrote: >> On Mon, Jan 29, 2018 at 1:40 PM, Andres Freund wrote: >> > It's an optional dependency, and it doesn't increase build time that >> > much... If we were to move the llvm interfacing code to

Re: User defined data types in Logical Replication

On Tue, Jan 30, 2018 at 6:36 PM, atorikoshi wrote: > Hi, > > It seems to be in the middle of discussion, but I became a reviewer of > this problem several days ago so I've tested the latest patch > 'fix_slot_store_error_callback_v12.patch'. > > I reproduced the below ERROR by inserting elog() to I

Re: [Sender Address Forgery]Re: FOR EACH ROW triggers on partitioned tables

On 2018/01/31 9:44, Peter Eisentraut wrote: > On 1/30/18 04:49, Amit Langote wrote: >>> If you are writing a generic >>> trigger function, maybe to dump out all columns, you want to know the >>> physical table and its actual columns. It's easy[citation needed] to >>> get the partition root for a g

Re: [HACKERS] REINDEX CONCURRENTLY 2.0

On 01/26/2018 03:28 AM, Stephen Frost wrote: I'm a big fan of this patch but it doesn't appear to have made any progress in quite a while. Is there any chance we can get an updated patch and perhaps get another review before the end of this CF...? Sorry, as you may have guessed I do not have t

Re: FOR EACH ROW triggers on partitioned tables

On 1/30/18 04:49, Amit Langote wrote: >> If you are writing a generic >> trigger function, maybe to dump out all columns, you want to know the >> physical table and its actual columns. It's easy[citation needed] to >> get the partition root for a given table, if the trigger code needs >> that. Th

Re: Regarding drop index

On 1/30/18 04:12, Abinaya Kajendiran wrote: >     We are building in-memory index extension for postgres. For drop > index query, does postgres notify me through index access methods? No, the access methods just write into blocks for the file they are told about. The deleting of that file is not

Re: [HACKERS] GnuTLS support

On 01/26/2018 03:54 AM, Peter Eisentraut wrote: On 1/25/18 20:10, Michael Paquier wrote: Peter, could you change ssl_version() and ssl_cipher() in sslinfo at the same time please? I think that those should use the generic backend-side APIs as well. sslinfo depends heavily on OpenSSL, OK, but if

RE: Temporary tables prevent autovacuum, leading to XID wraparound

From: Robert Haas [mailto:robertmh...@gmail.com] > Unfortunately, I think a full solution to the problem of allocating AV > workers to avoid wraparound is quite complex. Yes, that easily puts my small brain into an infinite loop... > Given all of the foregoing this seems like a very hard problem.

Re: [HACKERS] MERGE SQL Statement for PG11

On Tue, Jan 30, 2018 at 8:27 AM, Robert Haas wrote: > As far as I am able to understand, the substantive issue here is what > to do when we match an invisible tuple rather than a visible tuple. > The patch currently throws a serialization error on the basis that you > (Simon) thought that's what w

Re: Regarding drop index

Hi Abinaya, Have you seen some benchmarks showing that an in-memory index will fix some bottlenecks? Do you have an idea how much of a gain this will provide? Can you point to a github repo for it? Cheers, Ivan On Tue, Jan 30, 2018 at 1:12 AM, Abinaya Kajendiran wrote: > Hello all, > > W

Re: [HACKERS] GSoC 2017: Foreign Key Arrays

On 01/21/2018 10:36 PM, Mark Rofail wrote: == The @>> operator A previous version of your patch added the "anyelement <<@ anyarray" operator to avoid having to build arrays, but that part was reverted due to a bug. I am not expert on the gin code, but as far as I can tell it

Re: JIT compiling with LLVM v9.0

> On Jan 30, 2018, at 2:08 PM, Andres Freund wrote: > > With things like apt recommends and such I don't think this is a huge problem. I don’t believe there is a similar widely-supported dependency type in yum/rpm, though. rpm 4.12 adds support for Weak Dependencies, which have Recommends/Sug

Re: JIT compiling with LLVM v9.0

On Tue, Jan 30, 2018 at 02:08:30PM -0800, Andres Freund wrote: > Hi, > > On 2018-01-30 22:57:06 +0100, David Fetter wrote: > > On Tue, Jan 30, 2018 at 01:46:37PM -0500, Robert Haas wrote: > > > On Mon, Jan 29, 2018 at 1:40 PM, Andres Freund wrote: > > > > It's an optional dependency, and it doesn

Re: JIT compiling with LLVM v9.0

Hi, On 2018-01-30 13:46:37 -0500, Robert Haas wrote: > On Mon, Jan 29, 2018 at 1:40 PM, Andres Freund wrote: > > It's an optional dependency, and it doesn't increase build time that > > much... If we were to move the llvm interfacing code to a .so, there'd > > not even be a packaging issue, you c

Re: JIT compiling with LLVM v9.0

Hi, On 2018-01-30 22:57:06 +0100, David Fetter wrote: > On Tue, Jan 30, 2018 at 01:46:37PM -0500, Robert Haas wrote: > > On Mon, Jan 29, 2018 at 1:40 PM, Andres Freund wrote: > > > It's an optional dependency, and it doesn't increase build time > > > that much... If we were to move the llvm inter

Re: JIT compiling with LLVM v9.0

On Tue, Jan 30, 2018 at 01:46:37PM -0500, Robert Haas wrote: > On Mon, Jan 29, 2018 at 1:40 PM, Andres Freund wrote: > > It's an optional dependency, and it doesn't increase build time > > that much... If we were to move the llvm interfacing code to a > > .so, there'd not even be a packaging issue

Re: [HACKERS] MERGE SQL Statement for PG11

On Tue, Jan 30, 2018 at 8:56 AM, Simon Riggs wrote: >> Peter is arguing >> that we don't normally issue a serialization error at READ COMMITTED >> (which I think is true) and proposed that we instead try to INSERT. > > Which IMHO is case 4 since it would avoid a concurrent ERROR. It would avoid t

Re: JIT compiling with LLVM v9.0

On 01/30/2018 12:24 AM, Andres Freund wrote: > Hi, > > On 2018-01-30 00:16:46 +0100, Tomas Vondra wrote: >> FWIW I've installed llvm 5.0.1 from distribution package, and now >> everything builds fine (I don't even need the configure tweak). >> >> I think I had to build the other binaries because

Re: JIT compiling with LLVM v9.0

Hi, On 2018-01-30 15:06:02 -0500, Robert Haas wrote: > On Tue, Jan 30, 2018 at 2:08 PM, Andres Freund wrote: > >> That bites, although it's probably tolerable if we expect such errors > >> only in exceptional situations such as a needed shared library failing > >> to load or something. Killing th

Re: JIT compiling with LLVM v9.0

Robert Haas writes: > Unfortunately, that has the pretty significant downside that a lot of > people who actually want the postgresql-server-jit package will not > realize that they need to install it, which sucks. But I think it > might still be the better way to go. Anyway, it's for individua

Re: JIT compiling with LLVM v9.0

On Tue, Jan 30, 2018 at 2:08 PM, Andres Freund wrote: >> That bites, although it's probably tolerable if we expect such errors >> only in exceptional situations such as a needed shared library failing >> to load or something. Killing the session when we run out of memory >> during JIT compilation

Re: [HACKERS] postgres_fdw bug in 9.6

On Sat, Jan 20, 2018 at 12:20 AM, Tom Lane wrote: > It looks like Etsuro-san's proposed patch locks down the choice of > plan more tightly, which is probably a reasonable answer. OK, committed. I added a comment along the lines you suggested previously, since this no longer seems like a generic

Re: [HACKERS] MERGE SQL Statement for PG11

On Tue, Jan 30, 2018 at 8:27 AM, Robert Haas wrote: > As far as I am able to understand, the substantive issue here is what > to do when we match an invisible tuple rather than a visible tuple. > The patch currently throws a serialization error on the basis that you > (Simon) thought that's what w

Re: JIT compiling with LLVM v9.0

Hi, On 2018-01-30 13:57:50 -0500, Robert Haas wrote: > > When a libstdc++ new or LLVM error occurs, the handlers set up by the > > above functions trigger a FATAL error. We have to use FATAL rather than > > ERROR, as we *cannot* reliably throw ERROR inside a foreign library > > without risking cor

Re: [HACKERS] MERGE SQL Statement for PG11

On Tue, Jan 30, 2018 at 11:56 AM, Simon Riggs wrote: > Which IMHO is case 4 since it would avoid a concurrent ERROR. This > meets exactly my original implementation goals as clearly stated on > this thread, so of course I agree with him and have already said I am > happy to change the code, though

Re: JIT compiling with LLVM v9.0

On Wed, Jan 24, 2018 at 2:20 AM, Andres Freund wrote: > == Error handling == > > There's two aspects to error handling. > > Firstly, generated (LLVM IR) and emitted functions (mmap()ed segments) > need to be cleaned up both after a successful query execution and after > an error. I've settled on

Re: JIT compiling with LLVM v9.0

On Mon, Jan 29, 2018 at 1:40 PM, Andres Freund wrote: > It's an optional dependency, and it doesn't increase build time that > much... If we were to move the llvm interfacing code to a .so, there'd > not even be a packaging issue, you can just package that .so separately > and get errors if somebo

Re: Temporary tables prevent autovacuum, leading to XID wraparound

On Mon, Jan 29, 2018 at 1:33 AM, Tsunakawa, Takayuki wrote: >> Since the above idea would be complex a bit, as an >> alternated idea it might be better to specify the number of worker to launch >> per database by a new GUC parameter or something. If the number of worker >> running on the database

Re: [HACKERS] MERGE SQL Statement for PG11

On 30 January 2018 at 16:27, Robert Haas wrote: > As far as I am able to understand, the substantive issue here is what > to do when we match an invisible tuple rather than a visible tuple. > The patch currently throws a serialization error on the basis that you > (Simon) thought that's what was

WINDOW RANGE patch versus leakproofness

I am wondering whether we need to worry about leakproofness in connection with adding in_range support functions to btree opclasses. My initial conclusion is not, but let me lay out the reasoning so people can check it --- I might be missing something. The first question is whether we need to enc

Re: Add RANGE with values and exclusions clauses to the Window Functions

Once more trying to attach the regression.diffs On 2018-01-30 17:31, Erik Rijkers wrote: On 2018-01-30 17:08, Oliver Ford wrote: On Tue, Jan 30, 2018 at 10:48 AM, Oliver Ford wrote: I will send out v10 soon with the desc functions removed and the EXCLUDE_NO_OTHERS define removed. Here it

Re: Add RANGE with values and exclusions clauses to the Window Functions

On 2018-01-30 17:08, Oliver Ford wrote: On Tue, Jan 30, 2018 at 10:48 AM, Oliver Ford wrote: I will send out v10 soon with the desc functions removed and the EXCLUDE_NO_OTHERS define removed. Here it is. Exclude No Others is still in the parser, but does nothing. All desc functions are remov

Re: [HACKERS] MERGE SQL Statement for PG11

On Tue, Jan 30, 2018 at 4:45 AM, Simon Riggs wrote: > "You're introducing a behavior/error"... No, I advocate nothing in the > patch, I am merely following the agreement made here: > > https://www.postgresql.org/message-id/CA%2BTgmoYOyX4nyu9mbMdYTLzT9X-1RptxaTKSQfbSdpVGXgeAJQ%40mail.gmail.com > >

Re: [HACKERS] MERGE SQL Statement for PG11

On Mon, Jan 29, 2018 at 12:03 PM, Simon Riggs wrote: > Partitioning doesn't look too bad, so that looks comfortable for PG11, > assuming it doesn't hit some unhandled complexity. > > Including RLS in the first commit/release turns this into a high risk > patch. Few people use it, but if they do, t

Re: [HACKERS] MERGE SQL Statement for PG11

On Mon, Jan 29, 2018 at 7:15 PM, Michael Paquier wrote: > On Mon, Jan 29, 2018 at 04:34:48PM +, Simon Riggs wrote: >> In terms of timing of commits, I have marked the patch Ready For >> Committer. To me that signifies that it is ready for review by a >> Committer prior to commit. > > My unders

Re: [HACKERS] MERGE SQL Statement for PG11

On Mon, Jan 29, 2018 at 10:32 AM, Simon Riggs wrote: > The code is about 1200 lines and has extensive docs, comments and tests. > > There are no contentious infrastructure changes, so the debate around > concurrency is probably the main one. So it looks to me like > meaningful review has taken pla

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

On Tue, Jan 30, 2018 at 3:37 AM, Yoshimi Ichiyanagi wrote: > Oracle and Microsoft SQL Server suported PMEM [1][2]. > I think it is not too early for PostgreSQL to support PMEM. I agree; it's good to have the option available for those who have access to the hardware. If you haven't added your pa

Re: csv format for psql

2018-01-30 9:31 GMT+01:00 Daniel Verite : > Hi, > > > This patch implements csv as an output format in psql > (\pset format csv). It's quite similar to the unaligned format, > except that it applies CSV quoting rules (obviously!) and that > it prints no footer and no title. > As with unaligned, a

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

2018-01-30 9:06 GMT+01:00 Tatsuro Yamada : > On 2018/01/24 1:08, Pavel Stehule wrote: > >> >> >> 2018-01-22 23:15 GMT+01:00 Stephen Frost > sfr...@snowman.net>>: >> >> Pavel, >> >> >> * Pavel Stehule (pavel.steh...@gmail.com > pavel.steh...@gmail.com>) wrote: >> > here is a GUC based p

Re: [HACKERS] path toward faster partition pruning

Hi Amit, On 01/29/2018 07:57 PM, Amit Langote wrote: This needs a rebase. AFAICS, v22 cleanly applies to HEAD (c12693d8f3 [1]), compiles, and make check passes. It was a rebase error; I should have checked against a clean master. Sorry for the noise. Best regards, Jesper

Re: [HACKERS] path toward faster partition pruning

Hello, let me make some comments. At Tue, 30 Jan 2018 09:57:44 +0900, Amit Langote wrote in <4a7dda08-b883-6e5e-b0bf-f5ce95584...@lab.ntt.co.jp> > Hi Jesper. > > On 2018/01/29 22:13, Jesper Pedersen wrote: > > Hi Amit, > > > > On 01/26/2018 04:17 AM, Amit Langote wrote: > >> I made a few of t

Re: [PATCH] pgbench - refactor some connection finish/null into common function

Hello Doug, This patch refactors all of the connection state PQfinish() and NULL’ing into a single function. Excludes PQfinish() in doConnect(). My 0.02€: The argument could be "PGconn **" instead of a "CState *"? If so, it may be used in a few more places. What is your opinion? I'm fine w

Re: Add RANGE with values and exclusions clauses to the Window Functions

On Tuesday, 30 January 2018, Tom Lane wrote: > Another thing I'm a little confused by is the precise API for the in_range > support functions (the lack of any documentation for it doesn't help). > I wonder why you chose to provide two support functions per datatype > combination rather than one w

Re: [HACKERS] Subscription code improvements

On Fri, Jan 26, 2018 at 11:41 AM, Peter Eisentraut wrote: > On 1/24/18 02:33, Masahiko Sawada wrote: >> Thank you for notification. Since it seems to me that no one is >> interested in this patch, it would be better to close out this patch. >> This patch is a refactoring patch but subscription cod

Re: non-bulk inserts and tuple routing

(2018/01/30 18:39), Amit Langote wrote: Will wait for your comments before sending a new version then. Ok, I'll post my comments as soon as possible. Best regards, Etsuro Fujita

Re: FOR EACH ROW triggers on partitioned tables

On 2018/01/30 5:30, Peter Eisentraut wrote: > On 1/23/18 17:10, Alvaro Herrera wrote: >> The main question is this: when running the trigger function, it is >> going to look as it is running in the context of the partition, not in >> the context of the parent partitioned table (TG_RELNAME etc). Th

Re: [HACKERS] MERGE SQL Statement for PG11

On 29 January 2018 at 22:31, Peter Geoghegan wrote: > I don't think that there should be any error, so I can't say. >> I argued that was possible and desirable, but you argued it was not >> and got everybody else to agree with you. I'm surprised to see you >> change your mind on that. > > You're

Re: non-bulk inserts and tuple routing

Fujita-san, On 2018/01/30 18:22, Etsuro Fujita wrote: > (2018/01/25 18:52), Amit Langote wrote: >> On 2018/01/25 18:30, Etsuro Fujita wrote: >>> The patches apply cleanly and compile successfully, but make check fails >>> in an assert-enabled build. >> >> Hmm, I can't seem to reproduce the failure

Re: User defined data types in Logical Replication

Hi, It seems to be in the middle of discussion, but I became a reviewer of this problem several days ago so I've tested the latest patch 'fix_slot_store_error_callback_v12.patch'. I reproduced the below ERROR by inserting elog() to INPUT function of CREATE TYPE, and confirmed that above patch so

Re: [HACKERS] PoC: full merge join on comparison clause

On 29.01.2018 08:40, Ashutosh Bapat wrote: Maybe it's better to separate these two into separate patches so that it's easy to review patches. OK, I'll try doing this. For now, moving the patch entry to the next commitfest. -- Alexander Kuzmenkov Postgres Professional: http://www.postgrespro.

Re: non-bulk inserts and tuple routing

(2018/01/25 18:52), Amit Langote wrote: On 2018/01/25 18:30, Etsuro Fujita wrote: The patches apply cleanly and compile successfully, but make check fails in an assert-enabled build. Hmm, I can't seem to reproduce the failure with v4 patches I posted earlier today. Can you please post the e

Re: csv format for psql

Hello Daniel, This patch implements csv as an output format in psql (\pset format csv). Would you consider registering it in the next CF? -- Fabien.

Regarding drop index

Hello all, We are building in-memory index extension for postgres. For drop index query, does postgres notify me through index access methods? Currently, we are using event triggers to capture drop index. If there is a better way, please do suggest. Thanks in advance. Regards, Abinaya K

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

Fri, 19 Jan 2018 09:42:25 -0500Robert Haas wrote : > >I think that you really need to include the checkpoints in the tests. >I would suggest setting max_wal_size and/or checkpoint_timeout so that >you reliably complete 2 checkpoints in a 30-minute test, and then do a >comparison on that basis.

Re: [HACKERS] datetime.h defines like PM conflict with external libraries

> Michael, is there any problem including datatype/* headers in ecpg > that > are frontend clean? I see no such usage so far, that's why I'm > asking. When the pgtypes library was created we tried to include only the bits and pieces needed to not create unnecessary hassles, but if it compiles clea

csv format for psql

Hi, This patch implements csv as an output format in psql (\pset format csv). It's quite similar to the unaligned format, except that it applies CSV quoting rules (obviously!) and that it prints no footer and no title. As with unaligned, a header with column names is output unless tuples_only is

Re: [HACKERS] generated columns

On Sat, Jan 27, 2018 at 05:05:14PM -0500, Peter Eisentraut wrote: > This is expanded in the rewriter, so there is no context like that. > This is exactly how views work, e.g., > > create table t1 (id int, length int); > create view v1 as select id, length * 10 as length_in_nanometers > fro

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

On 2018/01/24 1:08, Pavel Stehule wrote: 2018-01-22 23:15 GMT+01:00 Stephen Frost mailto:sfr...@snowman.net>>: Pavel, * Pavel Stehule (pavel.steh...@gmail.com ) wrote: > here is a GUC based patch for plancache controlling. Looks so this code is

Re: PATCH: Configurable file mode mask

On Mon, Jan 29, 2018 at 04:29:08PM -0500, David Steele wrote: > OK, that being the case I have piggy-backed on the current pg_upgrade > tests in the same way that --wal-segsize did. > > There are now three patches: > > 1) 01-pgresetwal-test > > Adds a *very* basic test suite for pg_resetwal. I