Re: [HACKERS] logical replication deranged sender

On Wed, May 10, 2017 at 3:06 AM, Petr Jelinek wrote: > Okay, then it's the same issue Masahiko Sawada reported in nearby > thread, or at least has same cause. This report is here:

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

On Thu, May 11, 2017 at 11:56 AM, Tom Lane wrote: > It would be hard to reject at the grammar level, and not very friendly > either because you'd only get "syntax error". We could certainly make > the runtime code throw an error if you gave a column list without saying >

Re: [HACKERS] Duplicate usage of tablespace location?

Hello, At Fri, 5 May 2017 21:42:47 +1000, Neha Khatri wrote in > As Kyotaro san pointed out, the commit 22817041 started allowing creation > of multiple "tablespace version directories" in same location.

Re: [HACKERS] SCRAM in the PG 10 release notes

On Thu, May 11, 2017 at 11:50 AM, Bruce Momjian wrote: > I have added this as an open item because we will have to wait to see > where we are with driver support as the release gets closer. As Postgres ODBC now has a hard dependency with libpq, no actions is taken from there.

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

On 5/10/17, 8:10 PM, "Masahiko Sawada" wrote: > I agree to report per-table information. Especially In case of one of > tables specified failed during vacuuming, I think we should report at > least information of tables that is done successfully so far. +1 I believe you

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

On Thu, May 11, 2017 at 11:13 AM, Michael Paquier wrote: > On Thu, May 11, 2017 at 6:40 AM, Tom Lane wrote: >> "Bossart, Nathan" writes: >>> Currently, VACUUM commands allow you to specify one table or all of the >>> tables in

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

Michael Paquier writes: > On Thu, May 11, 2017 at 6:40 AM, Tom Lane wrote: >> The column list only matters for ANALYZE (or VACUUM ANALYZE). But yes, >> it should be per-table. > The grammar allows that by the way: > =# VACUUM (full) aa (a); >

Re: [HACKERS] SCRAM in the PG 10 release notes

On Mon, May 1, 2017 at 08:12:51AM -0400, Robert Haas wrote: > On Tue, Apr 25, 2017 at 10:16 PM, Bruce Momjian wrote: > > Well, we could add "MD5 users are encouraged to switch to > > SCRAM-SHA-256". Now whether we want to list this as something on the > > SCRAM-SHA-256

Re: [HACKERS] multi-column range partition constraint

On 2017/05/10 12:08, Robert Haas wrote: > On Mon, May 8, 2017 at 2:59 AM, Amit Langote > wrote: >> Yes, disallowing this in the first place is the best thing to do. >> Attached patch 0001 implements that. With the patch: > > Committed. Thanks. > With regard to

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

On Thu, May 11, 2017 at 6:40 AM, Tom Lane wrote: > "Bossart, Nathan" writes: >> Currently, VACUUM commands allow you to specify one table or all of the >> tables in the current database to vacuum. I’ve recently found myself >> wishing I could specify

Re: [HACKERS] [PATCH v2] Progress command to monitor progression of long running SQL queries

On Thu, May 11, 2017 at 1:40 AM, Remi Colinet wrote: > This is version 2 of the new command name PROGRESS which I wrote in order to > monitor long running SQL queries in a Postgres backend process. It would be a good idea to add this patch to the next commit fest if you

[HACKERS] Race conditions with WAL sender PID lookups

Hi all, I had my eyes on the WAL sender code this morning, and I have noticed that walsender.c is not completely consistent with the PID lookups it does in walsender.c. In two code paths, the PID value is checked without holding the WAL sender spin lock (WalSndRqstFileReload and

Re: [HACKERS] Removal of plaintext password type references

On Wed, May 10, 2017 at 10:22 PM, Michael Paquier wrote: > On Wed, May 10, 2017 at 10:01 PM, Tom Lane wrote: >> Heikki Linnakangas writes: >>> Also note that changing the signature check_password_hook_type would >>> break any

Re: [HACKERS] Removal of plaintext password type references

On Wed, May 10, 2017 at 5:58 PM, Heikki Linnakangas wrote: > On 05/10/2017 08:01 AM, Michael Paquier wrote: > >> On Wed, May 10, 2017 at 10:51 AM, Vaishnavi Prabakaran >> wrote: >> >>> Following recent removal of support to store password in plain

Re: [HACKERS] Should pg_current_wal_location() become pg_current_wal_lsn()

On Thu, May 11, 2017 at 9:15 AM, Bruce Momjian wrote: > On Wed, May 10, 2017 at 01:09:36PM -0700, Joe Conway wrote: >> On 05/10/2017 12:22 PM, Tom Lane wrote: >> > Robert Haas writes: >> >> On Wed, May 10, 2017 at 1:13 PM, Tom Lane

[HACKERS] Moving relation extension locks out of heavyweight lock manager

Hi all, Currently, the relation extension lock is implemented using heavyweight lock manager and almost functions (except for brin_page_cleanup) using LockRelationForExntesion use it with ExclusiveLock mode. But actually it doesn't need multiple lock modes or deadlock detection or any of the

Re: [HACKERS] Should pg_current_wal_location() become pg_current_wal_lsn()

On Wed, May 10, 2017 at 01:09:36PM -0700, Joe Conway wrote: > On 05/10/2017 12:22 PM, Tom Lane wrote: > > Robert Haas writes: > >> On Wed, May 10, 2017 at 1:13 PM, Tom Lane wrote: > >>> In terms of the alternatives I listed previously, it seems like >

Re: Fwd: Re: [HACKERS] MSVC odd TAP test problem

On Thu, May 11, 2017 at 7:29 AM, Andrew Dunstan wrote: > This isn't going to work. If you look at the code in IPC/Run.pm you see > that the coup_d_grace signal is only used after it has first sent the > hardcoded SIGTERM. It might be tempting to play with using

Re: Fwd: Re: [HACKERS] MSVC odd TAP test problem

On 05/10/2017 01:53 AM, Andrew Dunstan wrote: > >> Does it make a different if you use for example coup_d_grace => >> "QUIT"? Per the docs of IPC::Run SIGTERM is used for kills on Windows. > > No idea. I'll try. > > > This isn't going to work. If you look at the code in IPC/Run.pm you see that

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

Great, I’ll keep working on this patch and will update this thread with a more complete implementation. Nathan -- 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] pg_dump / copy bugs with "big lines" ?

FWIW I ended up reverting the whole thing, even from master. A more complete solution would have to be researched. -- Álvaro Herrerahttps://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services -- Sent via pgsql-hackers mailing list

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

"Bossart, Nathan" writes: > Currently, VACUUM commands allow you to specify one table or all of the > tables in the current database to vacuum. I’ve recently found myself wishing > I could specify multiple tables in a single VACUUM statement. For example, > this would be

Re: [HACKERS] Bug in pg_dump --table and --exclude-table for declarative partition table handling.

Robert Haas writes: > On Tue, May 9, 2017 at 4:21 AM, Jeevan Ladhe > wrote: >> Also, I can see similar issue exists with inheritance. > That's a pretty insightful comment which makes me think that this > isn't properly categorized as a bug.

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

On Wed, May 10, 2017 at 08:10:48PM +, Bossart, Nathan wrote: > Hi Hackers, > > Currently, VACUUM commands allow you to specify one table or all of > the tables in the current database to vacuum. I’ve recently found > myself wishing I could specify multiple tables in a single VACUUM >

Re: [HACKERS] Should pg_current_wal_location() become pg_current_wal_lsn()

On 10/05/17 21:22, Tom Lane wrote: > Robert Haas writes: >> On Wed, May 10, 2017 at 1:13 PM, Tom Lane wrote: >>> In terms of the alternatives I listed previously, it seems like >>> nobody liked alternatives #3, #4, or #5, leaving us with #1 (do >>>

Re: [HACKERS] Function to move the position of a replication slot

On 10/05/17 22:17, Dmitry Dolgov wrote: >> On 4 May 2017 at 20:05, Magnus Hagander > wrote: >> >> PFA a patch that adds a new function, pg_move_replication_slot, that > makes it >> possible to move the location of a replication slot without

Re: [HACKERS] Bug in pg_dump --table and --exclude-table for declarative partition table handling.

On Tue, May 9, 2017 at 4:21 AM, Jeevan Ladhe wrote: >> Current pg_dump --exclude-table option excludes partitioned relation >> and dumps all its child relations and vice versa for --table option, which >> I think is incorrect. >> >> In this case we might need to

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

On 10.05.2017 17:59, Robert Haas wrote: Well, I don't think it would be a HUGE problem, but I think the fact that Amit chose to implement this with syntax similar to that of Oracle is probably not a coincidence, but rather a goal, and I think the readability problem that you're worrying about is

Re: [HACKERS] Transaction held open by autoanalyze can be a bottleneck

Hi, On 2017-05-10 13:09:38 -0700, Jeff Janes wrote: > Autovacuum's analyze starts a transaction when it starts on a table, and > holds it for the duration. This holds back the xmin horizon. Yea, I also complained about this:

Re: [HACKERS] Function to move the position of a replication slot

> On 4 May 2017 at 20:05, Magnus Hagander wrote: > > PFA a patch that adds a new function, pg_move_replication_slot, that makes it > possible to move the location of a replication slot without actually > consuming all the WAL on it. Just a few questions just a few questions

[HACKERS] Transaction held open by autoanalyze can be a bottleneck

Autovacuum's analyze starts a transaction when it starts on a table, and holds it for the duration. This holds back the xmin horizon. On a TPC-B-like benchmark, this can be a problem. While it is autoanalyzing pgbench_accounts and pgbench_history, dead-but-for-analyze tuples accumulate rapidly

Re: [HACKERS] Should pg_current_wal_location() become pg_current_wal_lsn()

On 05/10/2017 12:22 PM, Tom Lane wrote: > Robert Haas writes: >> On Wed, May 10, 2017 at 1:13 PM, Tom Lane wrote: >>> In terms of the alternatives I listed previously, it seems like >>> nobody liked alternatives #3, #4, or #5, leaving us with #1 (do >>>

Re: [HACKERS] [PATCH v2] Progress command to monitor progression of long running SQL queries

Hi 2017-05-10 18:40 GMT+02:00 Remi Colinet : > Hello, > > This is version 2 of the new command name PROGRESS which I wrote in order > to monitor long running SQL queries in a Postgres backend process. > This patch introduce lot of reserved keyword. Why? It can breaks lot

Re: [HACKERS] Issues with replication slots(which created manually) against logical replication

On Tue, May 9, 2017 at 5:59 AM, tushar wrote: > I think -we should throw an error while creating subscription. I don't really think it's worth complicating the code to check for this. If you work hard enough, you can create up a configuration that doesn't work.

Re: [HACKERS] [PATCH v2] Progress command to monitor progression of long running SQL queries

On Wed, May 10, 2017 at 06:40:31PM +0200, Remi Colinet wrote: > Hello, > > This is version 2 of the new command name PROGRESS which I wrote in > order to monitor long running SQL queries in a Postgres backend > process. Perhaps I missed something important in the discussion, but was there a good

Re: [HACKERS] Should pg_current_wal_location() become pg_current_wal_lsn()

Robert Haas writes: > On Wed, May 10, 2017 at 1:13 PM, Tom Lane wrote: >> In terms of the alternatives I listed previously, it seems like >> nobody liked alternatives #3, #4, or #5, leaving us with #1 (do >> nothing) or #2 (apply this patch). By my

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

On Wed, May 10, 2017 at 12:12 PM, Alvaro Herrera wrote: > I'm surprised that there is so much activity in this thread. Is this > patch being considered for pg10? Of course not. Feature freeze was a month ago. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com

Re: [HACKERS] Should pg_current_wal_location() become pg_current_wal_lsn()

On Wed, May 10, 2017 at 1:13 PM, Tom Lane wrote: > David Steele writes: >> If I read this correctly, we won't change the names of any functions >> that we haven't *already* changed the names of, and only one view would >> be changed to bring it into line

Re: [HACKERS] [POC] hash partitioning

On Wed, May 3, 2017 at 9:09 AM, amul sul wrote: > Fixed in the attached version. +[ PARTITION BY { HASH | RANGE | LIST } ( { column_name | ( expression ) } [ COLLATE value, REMAINDER value ) } Maybe value -> modulus and value -> remainder? + When creating a hash

Re: [HACKERS] [BUGS] Concurrent ALTER SEQUENCE RESTART Regression

Andres Freund writes: > On 2017-05-10 10:29:02 -0400, Tom Lane wrote: >> As long as it doesn't block, the change in lock strength doesn't actually >> make any speed difference does it? > The issue isn't the strength, but that we currently have this weird > hackery around

Re: [HACKERS] Should pg_current_wal_location() become pg_current_wal_lsn()

David Steele writes: > If I read this correctly, we won't change the names of any functions > that we haven't *already* changed the names of, and only one view would > be changed to bring it into line with the rest. I have now looked through the patch more carefully, and

Re: [HACKERS] [POC] hash partitioning

On Wed, May 10, 2017 at 8:34 AM, Ashutosh Bapat wrote: > Hash partitioning will partition the data based on the hash value of the > partition key. Does that require collation? Should we throw an error/warning > if > collation is specified in PARTITION BY clause?

Re: [HACKERS] [POC] hash partitioning

On Thu, May 4, 2017 at 1:44 AM, Jeff Davis wrote: >> Hmm, that could be a problem in some cases. I think there's probably >> much less of a problem if the modulus isn't a power of two? > > That's true, but it's awkward to describe that to users. And I think > most people would

Re: [HACKERS] [BUGS] Concurrent ALTER SEQUENCE RESTART Regression

On 2017-05-10 10:29:02 -0400, Tom Lane wrote: > Petr Jelinek writes: > > On 10/05/17 07:09, Peter Eisentraut wrote: > >> I think the correct fix is to have nextval() and ALTER SEQUENCE use > >> sensible lock levels so that they block each other. Since > >> nextval()

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

I'm surprised that there is so much activity in this thread. Is this patch being considered for pg10? -- Álvaro Herrerahttps://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services -- Sent via pgsql-hackers mailing list

Re: [HACKERS] Cached plans and statement generalization

On 02.05.2017 21:26, Robert Haas wrote: I am sympathetic to the fact that this is a hard problem to solve. I'm just telling you that the way you've got it is not acceptable and nobody's going to commit it like that (or if they do, they will end up having to revert it). If you want to have a

Re: [HACKERS] WIP Patch: Precalculate stable functions, infrastructure v1

Hello, Aleksander! I've noticed that this patch needs a review and decided to take a look. Thank you very much! There are a trailing whitespaces, though. Oh, sorry, I'll check them. I see 8-10% performance improvement on full text search queries. Glad to hear it =) It seems that

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

On Wed, May 10, 2017 at 10:59 AM, Sven R. Kunze wrote: > You are definitely right. Changing it here would require to change it > everywhere AND thus to loose syntax parity with Oracle. Right. > I am not in a position to judge this properly whether this would be a huge >

Re: [HACKERS] WIP Patch: Precalculate stable functions, infrastructure v1

Hi Marina, I've noticed that this patch needs a review and decided to take a look. Here is a short summary: * Patches apply to the master branch. There are a trailing whitespaces, though. * All tests pass. * I see 8-10% performance improvement on full text search queries. * It seems that there

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

On 09.05.2017 09:19, Rahila Syed wrote: +1 for AS DEFAULT syntax if it helps in improving readability specially in following case CREATE TABLE p1 PARTITION OF test AS DEFAULT PARTITION BY LIST(a); Thank you, Rahila Syed On Tue, May 9, 2017 at 1:13 AM, Robert Haas

Re: [HACKERS] idea: custom log_line_prefix components besides application_name

On 05/10/2017 03:56 AM, Craig Ringer wrote: > On 10 May 2017 10:44 am, "Chapman Flack" wrote: >> On 05/09/17 18:48, Mark Dilger wrote: >>> SET SESSION ON BEHALF OF 'joe user' > > No need to do anything they custom and specific. No need for new syntax > either. > SET

Re: [HACKERS] [BUGS] Concurrent ALTER SEQUENCE RESTART Regression

Petr Jelinek writes: > On 10/05/17 07:09, Peter Eisentraut wrote: >> I think the correct fix is to have nextval() and ALTER SEQUENCE use >> sensible lock levels so that they block each other. Since >> nextval() currently uses AccessShareLock, the suggestion was for

Re: [HACKERS] 'nocopy data' option is set in SUBSCRIPTION but still data is getting migrated

On 10/05/17 15:27, tushar wrote: > Hi, > > Please refer this scenario -where 'nocopy data' option is set in > SUBSCRIPTION but still data is getting migrated > > Publication - (X) > create table t(n int); > insert into t values (generate_series(1,99)); > create publication pub for table t; > >

Re: [HACKERS] [BUGS] Concurrent ALTER SEQUENCE RESTART Regression

On 10/05/17 07:09, Peter Eisentraut wrote: > On 5/7/17 19:43, Andres Freund wrote: >> 3. Keep the catalog, make ALTER properly transactional, blocking >>concurrent nextval()s. This resolves the issue that nextval() can't >>see the changed definition of the sequence. > > This was the

[HACKERS] 'nocopy data' option is set in SUBSCRIPTION but still data is getting migrated

Hi, Please refer this scenario -where 'nocopy data' option is set in SUBSCRIPTION but still data is getting migrated Publication - (X) create table t(n int); insert into t values (generate_series(1,99)); create publication pub for table t; Subscription (Y) create table t(n int); CREATE

Re: [HACKERS] Removal of plaintext password type references

On Wed, May 10, 2017 at 10:01 PM, Tom Lane wrote: > Heikki Linnakangas writes: >> Also note that changing the signature check_password_hook_type would >> break any external modules that use the hook. Removing >> PASSWORD_TYPE_PLAINTEXT will do that too,

Re: [HACKERS] Declarative partitioning - another take

On Wed, May 10, 2017 at 6:50 AM, Etsuro Fujita wrote: > I started working on this. I agree that the changes made in > make_modifytable would be unacceptable, but I'd vote for Amit's idea of > passing a modified PlannerInfo to PlanForeignModify so that the FDW can do

Re: [HACKERS] transition table behavior with inheritance appears broken (was: Declarative partitioning - another take)

On Wed, May 10, 2017 at 8:02 AM, Thomas Munro wrote: > On Wed, May 10, 2017 at 11:10 PM, Thomas Munro > wrote: >> 2. If you attach a row-level trigger with transition tables to any >> inheritance child, it will see transition tuples

Re: [HACKERS] [BUGS] Concurrent ALTER SEQUENCE RESTART Regression

On Wed, May 10, 2017 at 2:09 PM, Peter Eisentraut wrote: > I think I have more clarity about the different, overlapping issues: > > 1. Concurrent ALTER SEQUENCE causes "tuple concurrently updated" >error, caused by updates to pg_sequence catalog. This can be

Re: [HACKERS] Removal of plaintext password type references

Heikki Linnakangas writes: > Also note that changing the signature check_password_hook_type would > break any external modules that use the hook. Removing > PASSWORD_TYPE_PLAINTEXT will do that too, because any password hook > function would use that constant (see e.g.

Re: [HACKERS] [POC] hash partitioning

On Wed, May 3, 2017 at 6:39 PM, amul sul wrote: > On Thu, Apr 27, 2017 at 1:42 AM, Robert Haas wrote: > >> >> This is not yet a detailed review - I may be missing things, and >> review and commentary from others is welcome. If there is no major >>

Re: [HACKERS] transition table behavior with inheritance appears broken (was: Declarative partitioning - another take)

On Wed, May 10, 2017 at 11:10 PM, Thomas Munro wrote: > 2. If you attach a row-level trigger with transition tables to any > inheritance child, it will see transition tuples from all tables in > the inheritance hierarchy at or below the directly named table that >

Re: [HACKERS] transition table behavior with inheritance appears broken (was: Declarative partitioning - another take)

On Wed, May 10, 2017 at 3:55 PM, Robert Haas wrote: > On Tue, May 9, 2017 at 11:48 PM, Thomas Munro > wrote: >> Hmm. DB2 has transition tables (invented them maybe?) and it allows >> OLD/NEW TABLE on row-level triggers: >> >>

Re: [HACKERS] Declarative partitioning - another take

On 2016/11/18 1:43, Robert Haas wrote: On Thu, Nov 17, 2016 at 6:27 AM, Amit Langote wrote: - The code in make_modifytable() to swap out the rte_array for a fake one looks like an unacceptable kludge. I don't know offhand what a better design would look like,

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

>It seems that adding a new partition at the same level as the default >partition will require scanning it or its (leaf) partitions if >partitioned. Consider that p1, pd are partitions of a list-partitioned >table p accepting 1 and everything else, respectively, and pd is further >partitioned.

Re: [HACKERS] Page Scan Mode in Hash Index

While doing the code coverage testing of v7 patch shared with - [1], I found that there are few lines of code in _hash_next() that are redundant and needs to be removed. I basically came to know this while testing the scenario where a hash index scan starts when a split is in progress. I have

Re: [HACKERS] snapbuild woes

On 09/05/17 22:11, Erik Rijkers wrote: > On 2017-05-09 21:00, Petr Jelinek wrote: >> On 09/05/17 19:54, Erik Rijkers wrote: >>> On 2017-05-09 11:50, Petr Jelinek wrote: >>> >> >> Ah okay, so this is same issue that's reported by both Masahiko Sawada >> [1] and Jeff Janes [2]. >> >> [1] >>

[HACKERS] Documentation about pg_stat_bgwriter

Hi. While I read the documentation I found the following description about some columns in pg_stat_bgwriter. https://www.postgresql.org/docs/devel/static/monitoring-stats.html#pg-stat-bgwriter-view This table shows cluster-global values, not per-backend values. > maxwritten_clean: > Number of

Re: [HACKERS] Removal of plaintext password type references

On 05/10/2017 08:01 AM, Michael Paquier wrote: On Wed, May 10, 2017 at 10:51 AM, Vaishnavi Prabakaran wrote: Following recent removal of support to store password in plain text, modified the code to 1. Remove "PASSWORD_TYPE_PLAINTEXT" macro 2. Instead of using

Re: [HACKERS] idea: custom log_line_prefix components besides application_name

On 10 May 2017 10:44 am, "Chapman Flack" wrote: On 05/09/17 18:48, Mark Dilger wrote: > I don't have any positive expectation that the postgres community will go > along with any of this, but just from my point of view, the cleaner way to > do what you are proposing is

Re: [HACKERS] PQhost may return socket dir for network connection

At Mon, 1 May 2017 15:48:17 -0400, Robert Haas wrote in > On Mon, May 1, 2017 at 1:36 PM, Tom Lane wrote: > > Robert Haas writes: > >> On Mon, May 1, 2017 at

Re: [HACKERS] Time based lag tracking for logical replication

On Mon, May 08, 2017 at 10:30:45PM -0700, Noah Misch wrote: > On Fri, May 05, 2017 at 07:07:26AM +, Noah Misch wrote: > > On Wed, May 03, 2017 at 08:28:53AM +0200, Simon Riggs wrote: > > > On 23 April 2017 at 01:10, Petr Jelinek > > > wrote: > > > > Hi, > > > >

Re: [HACKERS] Remove pre-10 compatibility code in hash index

On Wed, May 10, 2017 at 9:17 AM, Robert Haas wrote: > On Tue, May 9, 2017 at 1:41 AM, Amit Kapila wrote: >> Commit ea69a0dead5128c421140dc53fac165ba4af8520 has bumped the hash >> index version and obviates the need for backward compatibility code

Re: [HACKERS] bumping HASH_VERSION to 3

On Tue, Apr 11, 2017 at 11:53 PM, Bruce Momjian wrote: > On Fri, Mar 31, 2017 at 02:48:05PM -0400, Tom Lane wrote: >> +1, as long as we're clear on what will happen when pg_upgrade'ing >> an installation containing hash indexes. I think a minimum requirement is >> that it