Re: Is a modern build system acceptable for older platforms

On 18 May 2018 at 11:10, Andres Freund wrote: > > > On May 17, 2018 7:44:44 PM PDT, Bruce Momjian wrote: > >On Thu, May 3, 2018 at 12:32:39AM +0200, Catalin Iacob wrote: > >> I do have a real concern about the long term attractiveness of the > >> project

Re: Odd procedure resolution

On 5/17/18 16:54, Tom Lane wrote: > TBH, this is several months too late for v11. Maybe, but ... You're talking about a > really fundamental redesign, at least if it's done right and not as a > desperate last-minute hack (which is what this looks like). The points > you make here are just the

Re: Is a modern build system acceptable for older platforms

On Thu, May 3, 2018 at 12:32:39AM +0200, Catalin Iacob wrote: > I do have a real concern about the long term attractiveness of the > project to new developers, especially younger ones as time passes. > It's not a secret that people will just avoid creaky old projects, and > for Postgres old out

Re: Is a modern build system acceptable for older platforms

On May 17, 2018 7:44:44 PM PDT, Bruce Momjian wrote: >On Thu, May 3, 2018 at 12:32:39AM +0200, Catalin Iacob wrote: >> I do have a real concern about the long term attractiveness of the >> project to new developers, especially younger ones as time passes. >> It's not a secret

Re: Problem while updating a foreign table pointing to a partitioned table on foreign server

On Thu, May 17, 2018 at 11:56 PM, Robert Haas wrote: > On Thu, May 17, 2018 at 2:10 AM, Ashutosh Bapat > wrote: >> The second would mean that SELECT * from foreign table reports >> remotetableoid as well, which is awkward. > > No it

Re: Is a modern build system acceptable for older platforms

2018-05-18 5:50 GMT+02:00 Craig Ringer : > On 18 May 2018 at 11:10, Andres Freund wrote: > >> >> >> On May 17, 2018 7:44:44 PM PDT, Bruce Momjian wrote: >> >On Thu, May 3, 2018 at 12:32:39AM +0200, Catalin Iacob wrote: >> >> I do

Re: Transform for pl/perl

On 5/17/18 17:11, Alvaro Herrera wrote: > This is still listed as an open item, though the patch proposed by Peter > upthread has been committed. If I understand correctly, ilmari was > going to propose another patch. Or is the right course of action to set > the open item as resolved? The

Re: SCRAM with channel binding downgrade attack

On Fri, May 18, 2018 at 10:46:46AM +0900, Michael Paquier wrote: > From a security point of view, 1) is important for libpq, but I am not > much enthusiast about 2) as a whole. The backend has proper support for > channel binding, hence other drivers speaking the protocol could have > their own

Re: Possible bug in logical replication.

At Thu, 17 May 2018 13:54:07 +0300, Arseny Sher wrote in <87in7md034.fsf@ars-thinkpad> > > Konstantin Knizhnik writes: > > > I think that using restart_lsn instead of confirmed_flush is not right > > approach. > > If restart_lsn is not

Re: Postgres 11 release notes

H, Bruce! > 11 мая 2018 г., в 20:08, Bruce Momjian написал(а): > > I expect a torrent of feedback. ;-) I'm not sure it is usefull in release notes since it is more about API, and not user-facing change. Just in case. GiST opclasses now can omit compress and decompress

Re: Removing unneeded self joins

On 17.05.2018 05:19, Andres Freund wrote: On 2018-05-16 22:11:22 -0400, Tom Lane wrote: David Rowley writes: On 17 May 2018 at 11:00, Andres Freund wrote: Wonder if we shouldn't just cache an estimated relation size in the relcache entry

Re: [PATCH] Use access() to check file existence in GetNewRelFileNode().

F_OK seems to be better than R_OK because we want to check file existence (not read permission) before creating the relation file with the path later. 2018-05-17 17:09 GMT+08:00 Michael Paquier : > On Thu, May 17, 2018 at 04:09:27PM +0800, Paul Guo wrote: > > Previous code

Possible bug in logical replication.

We got the following assertion failure at our buildfarm of master branch of Postgres in contrib/test_decoding regression tests: 2018-05-07 19:50:07.241 MSK [5af083bf.54ae:49] DETAIL: Streaming transactions committing after 0/2A0, reading WAL from 0/29FFF1C. 2018-05-07 19:50:07.241 MSK

[PATCH] Use access() to check file existence in GetNewRelFileNode().

Previous code uses BasicOpenFile() + close(). access() should be faster than BasicOpenFile()+close() and access() should be more correct since BasicOpenFile() could fail for various cases (e.g. due to file permission, etc) even the file exists. access() is supported on Linux/Unix. I do not have

Re: inconsistency and inefficiency in setup_conversion()

On Thu, May 3, 2018 at 12:19 AM, John Naylor wrote: > Attached is a draft patch to do this, along with the conversion script > used to create the entries. In writing this, a few points came up that > are worth bringing up: Hi John, This failed for my patch testing robot on

Re: overhead of expression evaluation

2018-05-17 11:32 GMT+02:00 Pavel Stehule : > Hi > > just for curiosity - I tested simple script > > postgres=# do > $$ > declare s bigint = 0; > begin > for i in 1..10 loop > s := s + i; > end loop; > raise notice '%', s; > end; > $$; > > to see a

Infinite loop on master shutdown

Hello, as in pgsql-bug ML. https://www.postgresql.org/message-id/20180517.170021.24356216.horiguchi.kyot...@lab.ntt.co.jp Master can go into infinite loop on shutdown. But it is caused by a broken database like storage rolled-back one. (The steps to replay this is shown in the above mail.) I

Re: [PATCH] Use access() to check file existence in GetNewRelFileNode().

On Thu, May 17, 2018 at 04:09:27PM +0800, Paul Guo wrote: > Previous code uses BasicOpenFile() + close(). > > access() should be faster than BasicOpenFile()+close() and access() > should be more correct since BasicOpenFile() could fail for various > cases (e.g. due to file permission, etc) even

Re: log_min_messages shows debug instead of debug2

At Wed, 16 May 2018 12:37:48 -0400, Robert Haas wrote in > On Wed, May 16, 2018 at 11:28 AM, Tom Lane wrote: > > Robert Haas writes: > >> On Tue, May 15, 2018

Re: pg_ugprade test failure on data set with column with default value with type bit/varbit

Thanks. I tentatively submitted a patch (See the attachment). By the way, current pg_upgrade test script depends on the left data on test database, but it seems that a lot of tables are dropped in those test SQL files so this affects the pg_upgrade test coverage much. Maybe this needs to be

overhead of expression evaluation

Hi just for curiosity - I tested simple script postgres=# do $$ declare s bigint = 0; begin for i in 1..10 loop s := s + i; end loop; raise notice '%', s; end; $$; to see a overhead of some components 5,72% plpgsql.so [.] exec_assign_value

Re: Possible bug in logical replication.

On 17.05.2018 10:45, Konstantin Knizhnik wrote: We got the following assertion failure at our buildfarm of master branch of Postgres in contrib/test_decoding regression tests: 2018-05-07 19:50:07.241 MSK [5af083bf.54ae:49] DETAIL: Streaming transactions committing after 0/2A0, reading

RE: NaNs in numeric_power (was Re: Postgres 11 release notes)

Hi, > From: Tom Lane [mailto:t...@sss.pgh.pa.us] > David Rowley writes: > > On 16 May 2018 at 02:01, Tom Lane wrote: > >> I'm not particularly fussed about getting credit for that. However, > >> looking again at how that patch series turned

Re: pg_ugprade test failure on data set with column with default value with type bit/varbit

On Thu, May 17, 2018 at 4:20 AM, Paul Guo wrote: > Thanks. I tentatively submitted a patch (See the attachment). You probably want to add this to the next Commitfest. > By the way, current pg_upgrade test script depends on the left data on test > database, but it seems that >

Re: log_min_messages shows debug instead of debug2

On Thu, May 17, 2018 at 4:58 AM, Kyotaro HORIGUCHI wrote: > It's not about me, but without knowing the history, "debug" can > look as if it is less chatty than "debug2" or even "debug1". All > log level of "debugN" are seen as DEBUG in log lines. Thus > showing

Re: lazy detoasting

On 5/12/18 17:25, Tom Lane wrote: > Anyway, attached is a revised patch. I found a test case for > expanded_record_set_fields(), too. Thank you for fixing this up. In reviewing the committed patch, I noticed that in ER_get_flat_size() you have removed the PG_DETOAST_DATUM() call and let

Re: [PROPOSAL] Shared Ispell dictionaries

On Wed, May 16, 2018 at 4:42 PM, Arthur Zakirov wrote: > I haven't deep knowledge about guts of invalidation callbacks. It seems > that there is problem with it. Tom pointed above: > >> > I'm not sure that I understood the second case correclty. Can cache >> >

Re: lazy detoasting

Peter Eisentraut writes: > In reviewing the committed patch, I noticed that in ER_get_flat_size() > you have removed the PG_DETOAST_DATUM() call and let > expanded_record_set_field_internal() do the de-toasting work. I had > considered that too, but my

Re: Expression errors with "FOR UPDATE" and postgres_fdw with partition wise join enabled.

(2018/05/16 22:49), Ashutosh Bapat wrote: On Wed, May 16, 2018 at 4:01 PM, Etsuro Fujita wrote: However, considering that pull_var_clause is used in many places where partitioning is *not* involved, I still think it's better to avoid spending extra cycles needed

Re: postgres_fdw: Oddity in pushing down inherited UPDATE/DELETE joins to remote servers

(2018/05/17 14:19), Amit Langote wrote: Looking at this for a bit, I wondered if this crash wouldn't have occurred if the "propagation" had also considered join relations in addition to simple relations. For example, if I changed inheritance_planner like the attached (not proposing that we

Re: Incorrect comment in get_partition_dispatch_recurse

On Wed, May 16, 2018 at 3:20 PM, Robert Haas wrote: > On Wed, May 16, 2018 at 2:28 PM, David Rowley > wrote: >> Thanks for committing. Although, I disagree with your tweak: >> >> +* 1-based index into the *pds list. >> >> I think that's

Re: Postgres 11 release notes

On Wed, May 16, 2018 at 09:09:22PM -0400, Bruce Momjian wrote: > On Thu, May 17, 2018 at 09:56:49AM +0900, Michael Paquier wrote: >> On Wed, May 16, 2018 at 08:20:49PM -0400, Bruce Momjian wrote: >>> SCRAM-with-binding is the first password method that attempts to avoid >>> man-in-the-middle

Re: Postgres 11 release notes

On Thu, May 17, 2018 at 2:56 AM, Michael Paquier wrote: > On Wed, May 16, 2018 at 08:20:49PM -0400, Bruce Momjian wrote: > > SCRAM-with-binding is the first password method that attempts to avoid > > man-in-the-middle attacks, and therefore is much less likely to be able > >

Re: [PROPOSAL] Shared Ispell dictionaries

Robert Haas writes: > ... Assuming that we can > convince ourselves that that much is OK, I don't see why using a > syscache callback to help ensure that the mappings are blown away in > an at-least-somewhat-timely fashion is worse than any other approach. I think the

Re: [PATCH] Use access() to check file existence in GetNewRelFileNode().

On Thu, May 17, 2018 at 05:23:28PM +0800, Paul Guo wrote: > F_OK seems to be better than R_OK because we want to check file existence > (not read permission) before creating the relation file with the path > later. Please do not top-post, this breaks the discussion logic of the thread. Perhaps

Re: Incorrect comment in get_partition_dispatch_recurse

Robert Haas writes: > Hang on, I can't be wrong (famous last words). If the negative > indexes were 0-based, that would mean that the first element of the > list was referenced by -0, which obviously can't be true, because 0 = > -0. In other words, we can't be using

Re: Expression errors with "FOR UPDATE" and postgres_fdw with partition wise join enabled.

On Thu, May 17, 2018 at 4:50 PM, Etsuro Fujita wrote: > (2018/05/16 22:49), Ashutosh Bapat wrote: >> >> On Wed, May 16, 2018 at 4:01 PM, Etsuro Fujita >> wrote: >>> >>> However, considering that >>> pull_var_clause is used in many places

Re: Postgres 11 release notes

Hi Bruce, Here is some bonus feedback. On Fri, May 11, 2018 at 11:08:52AM -0400, Bruce Momjian wrote: > I expect a torrent of feedback. ;-) I have just noticed that this entry does not have the correct author (guess who?): Add libpq option to support channel binding when using SCRAM

Re: Possible bug in logical replication.

Konstantin Knizhnik writes: > I think that using restart_lsn instead of confirmed_flush is not right > approach. > If restart_lsn is not available and confirmed_flush is pointing to page > boundary, then in any case we should somehow handle this case and adjust >

Fwd: Question about xmloption and pg_restore

Hi all, I've got some question about XML OPTION and pg_restore. In a xml type column are stored documents. When restoring a plain SQL dump, we got the message : /ERROR:  invalid XML content// //DETAIL:  line 1: StartTag: invalid element name// //http://mrcc.com/qgis.dtd' 'SYSTEM'>// // ^//

'tuple concurrently updated' error w/o visible catalog updates

Hello, Earlier this week we have split our Postgres 9.6.8 shards, each having two databases, into one database per shard setup. This was done by promoting replicas and subsequently removing unused databases. Immediately afterwards we have discovered repeated 'tuple concurrently updated' errors

Re: Postgres 11 release notes

On Wed, May 16, 2018 at 09:09:22PM -0400, Bruce Momjian wrote: > > > FYI, I think the server could also require channel binding for SCRAM. We > > > already have scram-sha-256 in pg_hba.conf, and I think > > > scram-sha-256-plus would be reasonable. > > > > Noted as well. There is of course the

Re: Postgres 11 release notes

On Thu, May 17, 2018 at 09:48:54PM +0900, Michael Paquier wrote: > On Wed, May 16, 2018 at 09:09:22PM -0400, Bruce Momjian wrote: > > On Thu, May 17, 2018 at 09:56:49AM +0900, Michael Paquier wrote: > >> On Wed, May 16, 2018 at 08:20:49PM -0400, Bruce Momjian wrote: > >>> SCRAM-with-binding is the

SCRAM with channel binding downgrade attack

On Thu, May 17, 2018 at 03:38:36PM +0200, Magnus Hagander wrote: > What's the take of others?  Magnus, Stephen or Heikki perhaps (you've > been the most involved with SCRAM early talks)? > > Saw it by luck. It would probably be better if it wasn't hidden deep in a > thread about release

Re: Should we add GUCs to allow partition pruning to be disabled?

On Thu, May 17, 2018 at 12:04 AM, David Rowley wrote: >> Append >> Execution-Time Pruning: order_lines (at executor startup) >> -> Index Scan ... > > Perhaps Append should be shown as "Unordered Partitioned Table Scan on > ". That seems more aligned to how else

Re: [BUGFIX] amcanbackward is not checked before building backward index paths

Andrew Gierth writes: > Ugh, so the docs for amutils get this wrong, and if I'd looked at this > more carefully when doing them to begin with I'd have given the > 'backwards_scan' property a better name or omitted it entirely. Ooops. > I'll fix the docs accordingly.

Re: [BUGFIX] amcanbackward is not checked before building backward index paths

"David G. Johnston" writes: > On Thu, May 17, 2018 at 8:46 AM, Tom Lane wrote: >> Maybe "Can the scan direction be reversed in mid-scan?". I'm not >> absolutely sure that that's better ... > ​A cursory read might conclude that "reversing" can

Re: Incorrect comment in get_partition_dispatch_recurse

On Thu, May 17, 2018 at 10:29 PM, Robert Haas wrote: > Unless the indexing system actually can't reference the first element > of *pds, and -1 means the second element. But then I think we need a > more verbose explanation here. First element in *pds list (and the array

Re: NaNs in numeric_power (was Re: Postgres 11 release notes)

Huong Dangminh writes: > Thank you. The patch looks fine to me. > Also, I have done the "make check" in Windows and Linux environment with no > problem. Pushed, thanks for reviewing/testing. regards, tom lane

Re: [BUGFIX] amcanbackward is not checked before building backward index paths

> "Tom" == Tom Lane writes: Tom> What amcanbackward is about is whether the index can support Tom> reversing direction mid-scan, as would be required to support Tom> FETCH FORWARD followed by FETCH BACKWARD in a cursor. That's Tom> actually independent of whether the

Re: [BUGFIX] amcanbackward is not checked before building backward index paths

On Thu, May 17, 2018 at 8:46 AM, Tom Lane wrote: > Andrew Gierth writes: > > I'll fix the docs accordingly. I'm referring specifically to this bit: > > https://www.postgresql.org/docs/current/static/functions- >

Re: Infinite loop on master shutdown

Hi, On 2018-05-17 17:19:00 +0900, Kyotaro HORIGUCHI wrote: > Hello, as in pgsql-bug ML. > > https://www.postgresql.org/message-id/20180517.170021.24356216.horiguchi.kyot...@lab.ntt.co.jp > > Master can go into infinite loop on shutdown. But it is caused by > a broken database like storage

Re: [PROPOSAL] Shared Ispell dictionaries

Robert Haas writes: > On Thu, May 17, 2018 at 10:18 AM, Tom Lane wrote: >> I think the point you've not addressed is that "syscache callback >> occurred" does not equate to "object was dropped". Can the code >> survive having this occur at any

Re: Problem while updating a foreign table pointing to a partitioned table on foreign server

On Thu, May 17, 2018 at 2:10 AM, Ashutosh Bapat wrote: > The second would mean that SELECT * from foreign table reports > remotetableoid as well, which is awkward. No it wouldn't. You'd just make the additional column resjunk, same as we do for wholerow. >

Re: [BUGFIX] amcanbackward is not checked before building backward index paths

On 2018-May-17, Tom Lane wrote: > "David G. Johnston" writes: > > On Thu, May 17, 2018 at 8:46 AM, Tom Lane wrote: > >> Maybe "Can the scan direction be reversed in mid-scan?". I'm not > >> absolutely sure that that's better ... > > > ​A cursory

Re: [BUGFIX] amcanbackward is not checked before building backward index paths

> "Alvaro" == Alvaro Herrera writes: >> "Can the scan direction be changed in mid-scan (to support FETCH >> FORWARD and FETCH BACKWARD on a cursor)?" How about, "Can the scan direction be changed in mid-scan (to support FETCH BACKWARD on a cursor without needing

Re: Postgres, fsync, and OSs (specifically linux)

On Thu, May 17, 2018 at 12:44 PM, Andres Freund wrote: > Hi, > > On 2018-05-10 09:50:03 +0800, Craig Ringer wrote: >> while ((src = (RewriteMappingFile *) hash_seq_search(_status)) != >> NULL) >> { >> if (FileSync(src->vfd,

Re: Postgres, fsync, and OSs (specifically linux)

Hi, On 2018-05-10 09:50:03 +0800, Craig Ringer wrote: > while ((src = (RewriteMappingFile *) hash_seq_search(_status)) != > NULL) > { > if (FileSync(src->vfd, WAIT_EVENT_LOGICAL_REWRITE_SYNC) != 0) > - ereport(ERROR, > +

Re: Incorrect comment in get_partition_dispatch_recurse

On Thu, May 17, 2018 at 10:36 AM, Amit Langote wrote: > On Thu, May 17, 2018 at 10:29 PM, Robert Haas wrote: >> Unless the indexing system actually can't reference the first element >> of *pds, and -1 means the second element. But then I think we

Re: [PROPOSAL] Shared Ispell dictionaries

On Thu, May 17, 2018 at 10:18 AM, Tom Lane wrote: > Robert Haas writes: >> ... Assuming that we can >> convince ourselves that that much is OK, I don't see why using a >> syscache callback to help ensure that the mappings are blown away in >> an

Re: [BUGFIX] amcanbackward is not checked before building backward index paths

Alvaro Herrera writes: > To make matters worse, IIUC it's actually fine to read the cursor in one > direction to completion, then in the other direction to completion, > without this flag, right? In principle that'd be possible without amcanbackward if you were to shut

Re: [PROPOSAL] Shared Ispell dictionaries

On Thu, May 17, 2018 at 09:57:59AM -0400, Robert Haas wrote: > I think you and Tom have misunderstood each other somehow. If you > look at CommitTransaction(), you will see a comment that says: Oh, I understood. You are right. > Also, there is no absolute prohibition on kernel calls in

Re: [PROPOSAL] Shared Ispell dictionaries

On Thu, May 17, 2018 at 1:52 PM, Tom Lane wrote: > Robert Haas writes: >> On Thu, May 17, 2018 at 10:18 AM, Tom Lane wrote: >>> I think the point you've not addressed is that "syscache callback >>> occurred" does not equate to

Re: Postgres 11 release notes

On Thu, May 17, 2018 at 10:35:53PM +0900, Michael Paquier wrote: > Hi Bruce, > > Here is some bonus feedback. > > On Fri, May 11, 2018 at 11:08:52AM -0400, Bruce Momjian wrote: > > I expect a torrent of feedback. ;-) > > I have just noticed that this entry does not have the correct author >

Re: Incorrect comment in get_partition_dispatch_recurse

On 2018/05/18 6:14, David Rowley wrote: > On 18 May 2018 at 02:13, Tom Lane wrote: >> Maybe what you need is a redesign. This convention seems impossibly >> confusing and hence error-prone. What about using a separate bool to >> indicate which list the index refers to? > >

Re: Postgres 11 release notes

On Thu, May 17, 2018 at 02:23:00PM -0400, Bruce Momjian wrote: > On Thu, May 17, 2018 at 10:35:53PM +0900, Michael Paquier wrote: > > Hi Bruce, > > > > Here is some bonus feedback. > > > > On Fri, May 11, 2018 at 11:08:52AM -0400, Bruce Momjian wrote: > > > I expect a torrent of feedback. ;-) >

Re: Incorrect comment in get_partition_dispatch_recurse

On 2018/05/18 5:56, David Rowley wrote: > On 18 May 2018 at 06:21, Robert Haas wrote: >> All right, so let's just say that explicitly. Maybe something like >> the attached. > > That looks fine to me. Me too, except: +* *pds list is the root partition, so 0

Re: Problem while updating a foreign table pointing to a partitioned table on foreign server

Robert Haas writes: > Yeah, but I'm not sure I like that solution very much. I don't think > abusing the tableoid to store a remote table OID is very nice. I'd say it's totally unacceptable. Tableoid *has to* be something that you can look up in the local pg_class

Re: Incorrect comment in get_partition_dispatch_recurse

On 18 May 2018 at 02:13, Tom Lane wrote: > Maybe what you need is a redesign. This convention seems impossibly > confusing and hence error-prone. What about using a separate bool to > indicate which list the index refers to? While I agree that the coding is a bit unusual, I

Re: Transform for pl/perl

Hello This is still listed as an open item, though the patch proposed by Peter upthread has been committed. If I understand correctly, ilmari was going to propose another patch. Or is the right course of action to set the open item as resolved? On 2018-May-02, Dagfinn Ilmari Mannsåker wrote:

Re: Problem while updating a foreign table pointing to a partitioned table on foreign server

Alvaro Herrera writes: > Can we just add a new junk attr, with its own fixed system column > number? I think that's what Robert was proposing. Junk attr yes, "fixed system column number" no. That's not how junk attrs work. What it'd need is a convention for the name

Re: Transform for pl/perl

Alvaro Herrera writes: > This is still listed as an open item, though the patch proposed by Peter > upthread has been committed. If I understand correctly, ilmari was > going to propose another patch. Or is the right course of action to set > the open item as resolved?

Re: Incorrect comment in get_partition_dispatch_recurse

On 2018-May-17, Tom Lane wrote: > Robert Haas writes: > > Hang on, I can't be wrong (famous last words). If the negative > > indexes were 0-based, that would mean that the first element of the > > list was referenced by -0, which obviously can't be true, because 0 = > >

Re: [GSoC] Question about returning bytea array

> "Charles" == Charles Cui writes: Charles> I have the requirements to return a bytea array for some Charles> functions in pg_thrift plugin. If you mean you want the return value to be of type bytea[], i.e. an SQL array of bytea values, then you need to be using

Re: Incorrect comment in get_partition_dispatch_recurse

On 18 May 2018 at 06:21, Robert Haas wrote: > All right, so let's just say that explicitly. Maybe something like > the attached. That looks fine to me. -- David Rowley http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training &

Re: Odd procedure resolution

Peter Eisentraut writes: > I think I have made a mistake here. I was reading in between the lines > of a competitor's documentation that they have functions and procedures > in different name spaces, which made me re-read the SQL standard, which > appears to

Re: Problem while updating a foreign table pointing to a partitioned table on foreign server

On Wed, May 16, 2018 at 11:31 PM, Robert Haas wrote: > On Mon, Apr 16, 2018 at 7:35 AM, Ashutosh Bapat > wrote: >> It does fix the problem. But the patch as is interferes with the way >> we handle tableoid currently. That can be seen from

PG 11 feature count

I regularly track the number of items documented in each major release. I use the attached script. You might be surprised to learn that PG 11 has the lowest feature count of any release back through 7.4: 7.4 280 8.0 238 8.1 187 8.2 230 8.3

Re: PG 11 feature count

On 18 May 2018 at 11:29, Bruce Momjian wrote: > I regularly track the number of items documented in each major release. > I use the attached script. You might be surprised to learn that PG 11 > has the lowest feature count of any release back through 7.4: Interesting. I

Re: Infinite loop on master shutdown

At Thu, 17 May 2018 09:20:01 -0700, Andres Freund wrote in <20180517162001.rzd7l6g2h66hv...@alap3.anarazel.de> > Hi, > > On 2018-05-17 17:19:00 +0900, Kyotaro HORIGUCHI wrote: > > Hello, as in pgsql-bug ML. > > > >

Re: PG 11 feature count

David Rowley writes: > On 18 May 2018 at 11:29, Bruce Momjian wrote: >> I regularly track the number of items documented in each major release. >> I use the attached script. You might be surprised to learn that PG 11 >> has the lowest feature

Re: PG 11 feature count

On 2018-05-17 19:56:43 -0400, Tom Lane wrote: > David Rowley writes: > > On 18 May 2018 at 11:29, Bruce Momjian wrote: > >> I regularly track the number of items documented in each major release. > >> I use the attached script. You might be

Re: PG 11 feature count

On 18/05/18 11:29, Bruce Momjian wrote: I regularly track the number of items documented in each major release. I use the attached script. You might be surprised to learn that PG 11 has the lowest feature count of any release back through 7.4: 7.4 280 8.0 238

Re: PG 11 feature count

On Thu, May 17, 2018 at 05:01:17PM -0700, Andres Freund wrote: > On 2018-05-17 19:56:43 -0400, Tom Lane wrote: > > David Rowley writes: > > > On 18 May 2018 at 11:29, Bruce Momjian wrote: > > >> I regularly track the number of items documented in

RE: log_min_messages shows debug instead of debug2

>-Original Message- >From: Robert Haas [mailto:robertmh...@gmail.com] >OK, I'm happy enough to commit it then, barring other objections. I was just >going to >just do that but then I realized we're in feature freeze right now, so I >suppose this >should go into the next CommitFest.

Re: Built-in connection pooling

On Fri, May 4, 2018 at 03:25:15PM -0400, Robert Haas wrote: > On Fri, May 4, 2018 at 11:22 AM, Merlin Moncure wrote: > > If we are breaking 1:1 backend:session relationship, what controls > > would we have to manage resource consumption? > > I mean, if you have a large