Re: [HACKERS] Quorum commit for multiple synchronous replication.

Postgres 16 eliminate it. I posit that that's better than changing the meaning of the old syntax out from under people. -- Josh Berkus Containers & Databases Oh My! -- 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] Quorum commit for multiple synchronous replication.

sing sync commit without understanding/customizing the setup is going to be sorry regardless, keeping backwards compatibility is acceptable. -- Josh Berkus Containers & Databases Oh My! -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

[HACKERS] Better error message for trying to drop a DB with open subscriptions?

r us to detect that the "user" accessing the target database is actually a logical replication subscription, and give the DBA a better error message (e.g. "database 'bookdata' still has open subscrptions")? -- Josh Berkus Containers & Databases Oh My! -- Sent via pgsql-hack

Re: [HACKERS] Notes on testing Postgres 10b1

On 06/09/2017 07:54 PM, Greg Stark wrote: > On 7 June 2017 at 01:01, Josh Berkus <j...@berkus.org> wrote: >> P3: apparently jsonb_to_tsvector with lang parameter isn't immutable? >> This means that it can't be used for indexing: >> >> libdata=# create index b

[HACKERS] jsonb_to_tsvector should be immutable

to_tsvector | json_to_tsvector_byid | 3734 114| s Both of the _byid functions should be marked immutable, no? Otherwise how can users use the new functions for indexing? -- Josh Berkus Containers & Databases Oh My! -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql

Re: [HACKERS] Notes on testing Postgres 10b1

On 06/07/2017 06:37 PM, Peter Eisentraut wrote: > On 6/7/17 21:19, Josh Berkus wrote: >> The user's first thought is going to be a network issue, or a bug, or >> some other problem, not a missing PK. Yeah, they can find that >> information in the logs, but only

Re: [HACKERS] Notes on testing Postgres 10b1

On 06/07/2017 07:01 PM, Petr Jelinek wrote: > On 08/06/17 03:50, Josh Berkus wrote: >> On 06/07/2017 06:25 PM, Petr Jelinek wrote: >>> On 08/06/17 03:19, Josh Berkus wrote: >>>> >>>> Peter and Petr: >>>> >>>> On 06/07/2017 05:24 PM

Re: [HACKERS] Notes on testing Postgres 10b1

On 06/07/2017 06:25 PM, Petr Jelinek wrote: > On 08/06/17 03:19, Josh Berkus wrote: >> >> Peter and Petr: >> >> On 06/07/2017 05:24 PM, Peter Eisentraut wrote: >>> On 6/7/17 01:01, Josh Berkus wrote: >>>> * Having defaults on the various _workers

Re: [HACKERS] Notes on testing Postgres 10b1

Peter and Petr: On 06/07/2017 05:24 PM, Peter Eisentraut wrote: > On 6/7/17 01:01, Josh Berkus wrote: >> * Having defaults on the various _workers all devolve from max_workers >> is also great. > > I'm not aware of anything like that happening. > >> P1. O

[HACKERS] Notes on testing Postgres 10b1

to_tsvector | jsonb_to_tsvector_byid | 3734 3802 | s to_tsvector | json_to_tsvector_byid | 3734 114| s ... can we fix that? -- Josh Berkus Containers & Databases Oh My! -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

[HACKERS] Missing feature in Phrase Search?

ay for users to indicate that they want a range of word gaps. Like, in the example above, users could search on: 'fix <1:3> error' ... which would search for any phrase where "error" followed "fix" by between 1 and 3 words. Not wedded to any particular syntax for that,

Re: [HACKERS] 2017-03 CF Closed

Seconded. That's a huge amount of generally-underappreciated work. > And only a week over schedule. Good work. -- Josh Berkus Containers & Databases Oh My! -- 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] SQL/JSON in PostgreSQL

mas, curly braces etc. > But that's my own preference maybe. > > (Btw. does "run off" mean like or avoid? At least my dictionaries tend > to the latter.) Yes, but automated tools can easily convert between JSON and newline-delimited YAML and back. -- Josh Berkus

Re: [HACKERS] Proposal for changes to recovery.conf API

our request. >> >> New version coming up. > > Do you have an idea when the new version will be available? Please? Having yet another PostgreSQL release go by without fixing recovery.conf would make me very sad. -- Josh Berkus Containers & Databases Oh My! --

Re: [HACKERS] Possible spelling fixes

0001-spelling-comments.patch Description: Binary data 0002-spelling-strings.patch Description: Binary data 0003-spelling-sgml.patch Description: Binary data 0004-spelling-variables.patch Description: Binary data 0005-spelling-misc.patch Description: Binary data -- Sent via

Re: [HACKERS] Possible spelling fixes

Peter Eisentraut wrote: > Yes, some of that was committed, and some comments were offered. If > there is more to do, please send a rebased patch set. Conflicting comments were offered. And Heikki requested I send along the remainder. Which I did. Only one of those patches would have been

Re: [HACKERS] Possible spelling fixes

I'll include it. -- 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] Possible spelling fixes

I understood that they were git commits. I could have excluded the file but opted not to in case people were willing to take a small drift -- the SHAs are what someone needs to review the commit, and personally, I'd rather read something without typos than with -- especially in a summary. But,

Re: [HACKERS] Possible spelling fixes

I can easily drop the shutdown* items; The reason for rowMarks is consistency with lr_arowMarks. I'll tentatively exclude that from any resubmission I make tonight... -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription:

Re: [HACKERS] Possible spelling fixes

On Mar 1, 2017 9:06 AM, "Peter Eisentraut" wrote: On 2/6/17 06:03, Heikki Linnakangas wrote: > Ah, yes please. Post them over and I'll have a look at those as well. This thread is in the commit fest, but I think there is no current patch. I sent email on the

Re: [HACKERS] Proposal for changes to recovery.conf API

igger file doesn't show up as a problem since, in a containerized environment, they can't. It's either written by postgres itself, or by management software which runs as the postgres user. -- Josh Berkus Containers & Databases Oh My! -- 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] Official adoption of PGXN

tarray. You have to admit that it seems really strange in the eyes of a new user that ISN is packaged with PostgreSQL, whereas better-written and more popular extensions (like plv8, pg_partman or pgq) are not. -- Josh Berkus Containers & Databases Oh My! -- 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] Removal of deprecated views pg_user, pg_group, pg_shadow

ince the final pgAdmin 3 release. How long would you suggest is appropriate? Postgres 11? 12? Let's set a target date; that way we can communicate it more than once. -- Josh Berkus Containers & Databases Oh My! -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make

Re: [HACKERS] removing tsearch2

xtensions (also CUBE, earthdistance, etc.). However, one of the steps in that would be getting the mainstream platforms to package them so that users have a reasonable upgrade path, so I would not propose doing it for 10. -- Josh Berkus Containers & Databases Oh My! -- Sent via pgsql-hacker

Re: [HACKERS] removing tsearch2

e, >> anyone who wants it can maintain a copy elsewhere). Starting a new >> thread to make sure we collect all the relevant votes, but I really, >> really think it's past time for this to go away. The last actual >> change to tsearch2 which wasn't part of a wider cleanup was >> 3ca7eddbb7c48

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

pg_shadow/pg_user. I think Postgres 10 is the right time to break that code (I mean, we have to do it someday, and we're already telling people about breakage in 10), but be aware that there will be shouting and carrying on. -1 on a warning. Very little code today which references the deprecated co

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

On 02/09/2017 12:53 PM, Stephen Frost wrote: > * Josh Berkus (j...@berkus.org) wrote: >> On 02/09/2017 12:42 PM, Stephen Frost wrote: >>> * Josh Berkus (j...@berkus.org) wrote: >>>> On 02/09/2017 11:08 AM, Tom Lane wrote: >>>>> Agreed, let's just g

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

On 02/09/2017 12:42 PM, Stephen Frost wrote: > * Josh Berkus (j...@berkus.org) wrote: >> On 02/09/2017 11:08 AM, Tom Lane wrote: >>> Agreed, let's just get it done. >>> >>> Although this doesn't really settle whether we ought to do 3a (with >>> bac

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

user-chosen names. -- Josh Berkus Containers & Databases Oh My! -- 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] Possible spelling fixes

diff --git a/src/backend/access/transam/xlog.c b/src/backend/access/transam/xlog.c --- a/src/backend/access/transam/xlog.c +++ b/src/backend/access/transam/xlog.c @@ -6083,7 +6083,7 @@ StartupXLOG(void) ereport(LOG, (errmsg("database system was

Re: [HACKERS] Possible spelling fixes

diff --git a/src/test/regress/sql/plpgsql.sql b/src/test/regress/sql/plpgsql.sql --- a/src/test/regress/sql/plpgsql.sql +++ b/src/test/regress/sql/plpgsql.sql @@ -2219,15 +2219,15 @@ drop type eitype cascade; -- SQLSTATE and SQLERRM test -- -create function excpt_test1() returns void as $$

Re: [HACKERS] Possible spelling fixes

diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -3342,7 +3342,7 @@ pg_get_multixact_members(PG_FUNCTION_ARG } mxact; MultiXactId mxid =

Re: [HACKERS] Possible spelling fixes

diff --git a/contrib/ltree/ltxtquery_io.c b/contrib/ltree/ltxtquery_io.c --- a/contrib/ltree/ltxtquery_io.c +++ b/contrib/ltree/ltxtquery_io.c @@ -96,7 +96,7 @@ gettoken_query(QPRS_STATE *state, int32 if (*flag)

Re: [HACKERS] Possible spelling fixes

Heikki wrote: ‎> I pushed most of these. Except for the below: > optimisation -> optimization et al. > Most of our code is written with the American spelling, > but the British spelling isn't wrong, > so I don't want to go around changing them all. Sure As you'll see, my approach is to aim for

Re: [HACKERS] Possible spelling fixes

It's now split more or less to your suggestion: https://github.com/jsoref/postgres/commits/spelling diff --git a/configure b/configure --- a/configure +++ b/configure @@ -7088,7 +7088,7 @@ test -z "$INSTALL_SCRIPT" && INSTALL_SCR test -z "$INSTALL_DATA" && INSTALL_DATA='${INSTALL} -m 644' #

[HACKERS] Possible spelling fixes

Hi. I'm going through project-by-project offering spelling fixes. I have read your submission suggestions [1][2] and am choosing to disregard them. Could someone please review the changes I have [3] and suggest a series of commits that this project might like? It is quite likely that someone

[HACKERS] Retiring from the Core Team

ever hand all of them off). It's been a long, fun ride, and I'm proud of the PostgreSQL we have today: both the database, and the community. Thank you for sharing it with me. -- -- Josh Berkus Red Hat OSAS (any opinions are my own) -- Sent via pgsql-hackers mailing list (pgsql-hackers

Re: [HACKERS] RustgreSQL

core Postgres, being able to write extensions in languages other than C (like, full-featured extensions) would be its own benefit. Why not start there? That is, assuming that Joel has gobs of time to work on this? For that matter, I know that Jeff Davis is quite fond of Rust. -- -- Josh Berk

Re: [HACKERS] Proposal for changes to recovery.conf API

ry_target_type and recovery_target_value > into a single parameter could make sense, never mind the other three. > But I don't really want to argue about it any more. > Either solution works for me. -- -- Josh Berkus Red Hat OSAS (any opinions are my own) -- 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] Migration Docs WAS: Proposal for changes to recovery.conf API

he docs will be hard enough; if I (or anyone else) has to argue about whether or not they're too long, I'm just going to drop the patch and walk away. -- -- Josh Berkus Red Hat OSAS (any opinions are my own) -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes

Re: [HACKERS] Proposal for changes to recovery.conf API

". > I don't see any problem with that, particularly if someone other than > Bruce or me is volunteering to write it ;-) I'm up for writing it (with help from feature owners), provided that I don't have to spend time arguing that it's not too long, or that I should put it somewhere differ

Re: [HACKERS] Proposal for changes to recovery.conf API

docs, and not mention the wiki. My 2c. > > Yes, that is the usual approach. > So where in the docs should these go, then? We don't (currently) have a place for this kind of doc. Appendices? -- -- Josh Berkus Red Hat OSAS (any opinions are my own) -- 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] Proposal for changes to recovery.conf API

On 12/08/2016 04:16 PM, Tom Lane wrote: > Josh Berkus <j...@agliodbs.com> writes: >> On 12/01/2016 05:58 PM, Magnus Hagander wrote: >>> And in fairness, having such a "guide to changes" chapter in each >>> release probably *would* be a good id

Re: [HACKERS] Proposal for changes to recovery.conf API

resources to > make that. The release notes are good, but having a more hand-holding > version explaining incompatible changes in "regular sentences" would > probably be quite useful to users. We will have enough major changes in 10.0 to warrant writing one of these. Maybe not

Re: [HACKERS] Proposal for changes to recovery.conf API

am sure > that a new version will be sent for the next CF. > Please let's make sure this gets done for 10. We're planning on breaking a lot of config things in 10, so it would be MUCH easier on users if we do the recovery.conf changes in that version as well. -- -- Josh Berkus Red Hat OSA

Re: [HACKERS] pg_hba_file_settings view patch

? Sure it is. Ships in PostgreSQL-core. I mean, I'm not particularly in favor of using JSON for this (arrays seem OK), but that seems like an invalid reason not to. -- -- Josh Berkus Red Hat OSAS (any opinions are my own) -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.or

Re: [HACKERS] Default setting for autovacuum_freeze_max_age

On 10/21/2016 10:29 AM, Robert Haas wrote: > On Fri, Oct 21, 2016 at 1:17 PM, Josh Berkus <j...@agliodbs.com> wrote: >> Particularly, with 9.6's freeze map, point (2) is even stronger reason >> to *lower* autovacuum_max_freeze_age. Since there's little duplicate >> w

Re: [HACKERS] Proposal for changes to recovery.conf API

n > no discussion for the last three weeks doesn't mean this effort is > dead; I would like very much to see it move forward. Has this gone anywhere? Given that we're in "break all the things" mode for PostgreSQL 10, it would be the ideal time to consolidate recovery.conf with pg.conf. -- -- Josh Berkus Red Hat OSAS (any opinions are my own) -- 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] Default setting for autovacuum_freeze_max_age

to *lower* autovacuum_max_freeze_age. Since there's little duplicate work in a freeze scan, a lot of users will find that frequent freezing benefits them a lot ... especially if they can take advantage of index-only scans. -- -- Josh Berkus Red Hat OSAS (any opinions are my own) -- Sent

Re: [HACKERS] Disable autovacuum guc?

On 10/20/2016 06:34 AM, Joshua D. Drake wrote: > On 10/19/2016 07:22 PM, Josh Berkus wrote: >> On 10/19/2016 06:27 PM, Joshua D. Drake wrote: >>> Hello, >>> >>> After all these years, we are still regularly running into people who >>> say, "pe

Re: [HACKERS] Disable autovacuum guc?

use-case, it makes far more sense to do batch loads interspersed with ANALYZEs and VACUUMS of loaded/updated tables. -- -- Josh Berkus Red Hat OSAS (any opinions are my own) -- 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] Remove vacuum_defer_cleanup_age

l from the > standby to the master, while vacuum_defer_cleanup_age behaves like > old_snapshot_threshold in that it causes cancel for long-running > queries. See Andres' response on this thread. He's already covered why the setting is still useful, but why we might want to remove it anyway.

Re: [HACKERS] Remove vacuum_defer_cleanup_age

On 10/18/2016 01:37 PM, Andres Freund wrote: > Hi, > > On 2016-10-09 21:51:07 -0700, Josh Berkus wrote: >> Given that hot_standby_feedback is pretty bulletproof now, and a lot of >> the work in reducing replay conflicts, I think the utility of >> vacuum_defer_cleanup_

Re: [HACKERS] Remove vacuum_defer_cleanup_age

On 10/18/2016 01:28 PM, Robert Haas wrote: > On Tue, Oct 18, 2016 at 4:18 PM, Josh Berkus <j...@agliodbs.com> wrote: >> On 10/12/2016 05:00 PM, Robert Haas wrote: >>> On Sun, Oct 9, 2016 at 9:51 PM, Josh Berkus <j...@agliodbs.com> wrote: >>>> Given that

Re: [HACKERS] Remove vacuum_defer_cleanup_age

On 10/12/2016 05:00 PM, Robert Haas wrote: > On Sun, Oct 9, 2016 at 9:51 PM, Josh Berkus <j...@agliodbs.com> wrote: >> Given that hot_standby_feedback is pretty bulletproof now, and a lot of >> the work in reducing replay conflicts, I think the utility of >> vacuum_def

[HACKERS] Remove vacuum_defer_cleanup_age

the option in 10? -- -- Josh Berkus Red Hat OSAS (any opinions are my own) -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

[HACKERS] Congrats on the on-time release!

development and adoption. -- -- Josh Berkus Red Hat OSAS (any opinions are my own) -- 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] Quorum commit for multiple synchronous replication.

ey wanted quorum. So the sensible default would be: "k (n1, n2, n3)" == "any k (n1, n2, n3)" ... however, that will break backwards compatibility. Thoughts? My $0.02 is that we break backwards compat somehow and document the heck out of it. -- -- Josh Berkus Red Hat OSA

Re: [HACKERS] increasing the default WAL segment size

gments). I'm not sure this is a real problem which users will notice (in today's scales, 144MB ain't much), but if it turns out to be, it would be nice to have a way to switch it back *just for them* without recompiling. -- -- Josh Berkus Red Hat OSAS (any opinions are my own) -- Sent via pgsq

Re: [HACKERS] PSA: Systemd will kill PostgreSQL

On 08/15/2016 05:18 PM, Tom Lane wrote: > Josh Berkus <j...@agliodbs.com> writes: >> On 08/15/2016 02:43 PM, Tom Lane wrote: >>> Last I heard, there's an exclusion for "system" accounts, so an >>> installation that's using the Fedora-provided pgsql accou

Re: [HACKERS] PSA: Systemd will kill PostgreSQL

On 08/15/2016 02:43 PM, Tom Lane wrote: > Josh Berkus <j...@agliodbs.com> writes: >> On 07/10/2016 10:56 AM, Joshua D. Drake wrote: >>> tl;dr; Systemd 212 defaults to remove all IPC (including SYSV memory) >>> when a user "fully" logs out. > >&

Re: [HACKERS] PSA: Systemd will kill PostgreSQL

a user "fully" logs out. That looks like it was under discussion in April, though. Do we have confirmation it was never fixed? I'm not seeing systemd killing Postgres under Fedora24. -- -- Josh Berkus Red Hat OSAS (any opinions are my own) -- Sent via pgsql-hackers mailing list (pgs

Re: [HACKERS] Why we lost Uber as a user

id have issues for a couple of years where replication accuracy was poorly tested, and did have several bugs associated with that. It's not surprising that a few major users got hit hard by those bugs and decided to switch. -- -- Josh Berkus Red Hat OSAS (any opinions are my own) -- Sent via pg

Re: [HACKERS] Why we lost Uber as a user

On 07/26/2016 08:45 PM, Robert Haas wrote: > That's why I found Josh's restatement useful - I am assuming without > proof that his restatement is accurate FWIW, my restatement was based on some other sites rather than Uber. Including folks who didn't abandon Postgres. -- -- Josh Berk

Re: [HACKERS] Why we lost Uber as a user

On 07/26/2016 03:07 PM, Tom Lane wrote: > Josh Berkus <j...@agliodbs.com> writes: >> That's a recipe for runaway table bloat; VACUUM can't do much because >> there's always some minutes-old transaction hanging around (and SNAPSHOT >> TOO OLD doesn't really help, we're

Re: [HACKERS] Why we lost Uber as a user

On 07/26/2016 01:53 PM, Josh Berkus wrote: > The write amplification issue, and its correllary in VACUUM, certainly > continues to plague some users, and doesn't have any easy solutions. To explain this in concrete terms, which the blog post does not: 1. Create a small table, but one with

Re: [HACKERS] Why we lost Uber as a user

or replication corruption issues now, in response to this. -- -- Josh Berkus Red Hat OSAS (any opinions are my own) -- 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] 10.0

the depths of the stuff which will break because folks are parsing our version numbers with regexes. In more major software, this will break nagios check_postgres. I'm not happy with it, but I believe that's where we'll end up. -- -- Josh Berkus Red Hat OSAS (any opinions are my own) -- Sent

Re: [HACKERS] 10.0

registered trademark on "PostgreSQL", but "postgres" is public domain. -- -- Josh Berkus Red Hat OSAS (any opinions are my own) -- 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] Rename max_parallel_degree?

Are people OK with this? +1 > > Note that there is a dump/restore hazard if people have set the > parallel_degree reloption on a beta1 install, or used ALTER { USER | > DATABASE } .. SET parallel_degree. Can everybody live with that? > Should I bump catversion when applying this?

Re: [HACKERS] [BUGS] Routine analyze of single column prevents standard autoanalyze from running at all

rs are aware that you *can* analyze individual columns. -- -- Josh Berkus Red Hat OSAS (any opinions are my own) -- 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] Rename max_parallel_degree?

s, replication, > autovacuum, parallel workers, background workers (by tag/label/group), > and so on. Now that's crazy talk. I mean, next thing you'll be saying that we need the ability to monitor this, or even change it at runtime. Where does the madness end? ;-) Seriously, you hav

Re: [HACKERS] Rename max_parallel_degree?

cularly since this would involve scanning some of the global catalogs we've been trying to move activity off of. -- -- Josh Berkus Red Hat OSAS (any opinions are my own) -- 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] Rename max_parallel_degree?

On 06/02/2016 01:08 PM, David G. Johnston wrote: > On Thu, Jun 2, 2016 at 3:52 PM, Josh berkus <j...@agliodbs.com > <mailto:j...@agliodbs.com>>wrote: > > On 06/02/2016 08:53 AM, Tom Lane wrote: > > Josh berkus <j...@agliodbs.com <mailto:j...@agliodbs.

Re: [HACKERS] Rename max_parallel_degree?

On 06/02/2016 08:53 AM, Tom Lane wrote: > Josh berkus <j...@agliodbs.com> writes: >> On 06/02/2016 04:58 AM, Robert Haas wrote: >>> Well, I think we could drop node, if you like. I think parallel >>> wouldn't be good to drop, though, because it sounds like we wa

Re: [HACKERS] Rename max_parallel_degree?

h controls the number of workers for the whole statement? -- -- Josh Berkus Red Hat OSAS (any opinions are my own) -- 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] Rename max_parallel_degree?

ork*, and whether that's consistent across our various resource management settings. -- -- Josh Berkus Red Hat OSAS (any opinions are my own) -- 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] Rename max_parallel_degree?

On 05/31/2016 01:04 PM, Tom Lane wrote: > The name should be closely related to what we use for #3. I could go for > max_total_parallel_workers for #2 and max_parallel_workers for #3. > Or maybe max_parallel_workers_total? How about parallel_worker_pool? -- -- Josh Berkus Red Hat

Re: [HACKERS] Logic behind parallel default? WAS: Rename max_parallel_degree?

On 05/31/2016 11:10 AM, Tom Lane wrote: > Josh berkus <j...@agliodbs.com> writes: >> Is there a thread on how we determined this default of 2? I can't find >> one under likely search terms. > > The 9.6 open-items list cites > > https://w

Re: [HACKERS] Rename max_parallel_degree?

On 05/31/2016 11:29 AM, Tom Lane wrote: > Josh berkus <j...@agliodbs.com> writes: >> One more consistency question: what's the effect of running out of >> max_parallel_workers? > > ITYM max_worker_processes (ie, the cluster-wide pool size)? Yes. Sorry for contribu

Re: [HACKERS] Rename max_parallel_degree?

On 05/31/2016 11:27 AM, Peter Geoghegan wrote: > On Tue, May 31, 2016 at 11:22 AM, Josh berkus <j...@agliodbs.com> wrote: >>> I think we can hope that developers are going to be less confused about >>> that than users. >> >> Makes sense. > > Maybe

Re: [HACKERS] Rename max_parallel_degree?

On 05/31/2016 11:17 AM, Peter Eisentraut wrote: > On 5/31/16 2:02 PM, Josh berkus wrote: >> I get where you're coming from, but I think Haas's query plan output is >> going to show us the confusion we're going to get. So we need to either >> change the parameter, the exp

Re: [HACKERS] Logic behind parallel default? WAS: Rename max_parallel_degree?

is why I want to understand the logic here. -- -- Josh Berkus Red Hat OSAS (any opinions are my own) -- 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] Rename max_parallel_degree?

On 05/31/2016 10:51 AM, Peter Geoghegan wrote: > On Tue, May 31, 2016 at 10:46 AM, Josh berkus <j...@agliodbs.com> wrote: >> In parallel seq scan and join, do the "masters" behave as workers as well? > > It depends. They will if they can. If the parallel seq sca

Re: [HACKERS] Rename max_parallel_degree?

On 05/31/2016 10:38 AM, Peter Geoghegan wrote: > On Tue, May 31, 2016 at 10:23 AM, Josh berkus <j...@agliodbs.com> wrote: >> It's still WAY simpler to understand "max_parallel is the number of >> parallel workers I requested". > > (Sorry Josh, someh

Re: [HACKERS] Rename max_parallel_degree?

On 05/31/2016 10:16 AM, Peter Geoghegan wrote: > On Tue, May 31, 2016 at 10:10 AM, Josh berkus <j...@agliodbs.com> wrote: >> "max_parallel_degree is the amount of parallelism in the query, with the >> understanding that the original parent process counts as 1, whic

Re: [HACKERS] Rename max_parallel_degree?

On 05/31/2016 10:03 AM, Tom Lane wrote: > Josh berkus <j...@agliodbs.com> writes: >> I realize there's a lot of water under the bridge here, but I think >> we're going to get 1000 questions on -general of the type: "I asked for >> 8 parallel workers, why d

Re: [HACKERS] Rename max_parallel_degree?

0..177436.01 rows=10 width=8) (actual > time=383.040..383.237 rows=9 loops=1) > Workers Planned: 9 > Workers Launched: 8 I realize there's a lot of water under the bridge here, but I think we're going to get 1000 questions on -general of the type: "I asked for 8 paral

Re: [HACKERS] Adding an alternate syntax for Phrase Search

uery('Berkus') && phraseto_tsquery('PostgreSQL Version 10.0'); > does it as you wish Aha, you didn't mention this in your presentation. That seems plenty good enough for 9.6. -- -- Josh Berkus Red Hat OSAS (any opinions are my own) -- Sent via pgsql-hackers mailing list (pgsql-hackers

[HACKERS] Adding an alternate syntax for Phrase Search

ersion <-> 10.0 )') I realize we're already in beta, but pgCon was actually the first time I saw the new syntax. I think if we don't do this now, we'll be doing it for 10.0. -- -- Josh Berkus Red Hat OSAS (any opinions are my own) -- Sent via pgsql-hackers mailing list (pgsql-hackers@

Re: [HACKERS] Reviewing freeze map code

c.? If we're only doing this for integrity checking, then maybe it's better if it becomes a function, which could be later extended with additional forensic features? -- -- Josh Berkus Red Hat OSAS (any opinions are my own) -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To

Re: [HACKERS] 10.0

.0? Yes/No?". Which argument will be just as long as this one. So, my vote is now +1 to go to the 2-part numbering scheme. -- -- Josh Berkus Red Hat OSAS (any opinions are my own) -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription:

Re: [HACKERS] 10.0

a long discussion on -advocacy, nobody has any specific plans to do substantial breakage of backwards compatibility. Theoretically we might someday want to change the on-disk format, but nobody has plans to do so in the immediate future. How long should we hold out for that? Until 9.27? And I do

Re: [HACKERS] 10.0

in the near future, it would be sad if we > foreclosed the possibility by a poor choice of versioning scheme. Well, we have done two major releases in a year before, mostly due to one release being late and the succeeding one being on time. -- -- Josh Berkus Red Hat OSAS (any opinions are my own)

Re: [HACKERS] Lets (not) break all the things. Was: [pgsql-advocacy] 9.6 -> 10.0

On 05/13/2016 01:04 PM, Joshua D. Drake wrote: > On 05/13/2016 12:03 PM, Josh berkus wrote: >> On 05/13/2016 11:48 AM, Robert Haas wrote: >>> On Fri, May 13, 2016 at 12:12 PM, Joshua D. Drake >>> <j...@commandprompt.com> wrote: > >> Anyway, all o

Re: [HACKERS] 10.0

urrent practice of debating when > to bump the same digit, then let's agree that 10.0 will follow 9.6 and > after that we'll bump the first digit after X.4, as we did with 7.X > and 8.X. Why X.4? Seems arbitrary. -- -- Josh Berkus Red Hat OSAS (any opinions are my own) -- 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] 10.0

On 05/13/2016 11:49 AM, Tom Lane wrote: > Alvaro Herrera <alvhe...@2ndquadrant.com> writes: >> Josh berkus wrote: >>> Anyway, can we come up with a consensus of some minimum changes it will >>> take to make the next version 10.0? > >> I think the next ver

Re: [HACKERS] Lets (not) break all the things. Was: [pgsql-advocacy] 9.6 -> 10.0

ll of this is a moot point, because nobody has the power to tell the various companies what to do. We're just lucky that everyone is still committed to writing stuff which adds to PostgreSQL. -- -- Josh Berkus Red Hat OSAS (any opinions are my own) -- Sent via pgsql-hackers mailing list (pg

Re: [HACKERS] 10.0

alpha releases, not beta. Can someone > dig up the details? /me digs through the announcement archives ... We changed it to 9.0 for Alpha4. By Beta1, it was already 9.0. -- -- Josh Berkus Red Hat OSAS (any opinions are my own) -- Sent via pgsql-hackers mailing list (pgsql-hackers@post

Re: [HACKERS] 10.0

On 05/13/2016 11:31 AM, Alvaro Herrera wrote: > Josh berkus wrote: > >> Anyway, can we come up with a consensus of some minimum changes it will >> take to make the next version 10.0? > > I think the next version should be 10.0 no matter what changes we put > in. &

  1   2   3   4   5   6   7   8   9   10   >