en around 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
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
s 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
On 06/09/2017 07:54 PM, Greg Stark wrote:
> On 7 June 2017 at 01:01, Josh Berkus 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 bookdata_fts on
_to_tsvector_byid | 3734 3802 | s
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
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 if they t
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
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
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.
>
>>
svector | json_to_tsvector | 114 | s
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
ot any of the other strings.
This is because the # in <#> is an exact match.
Seems like we could really use a way 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
eciated 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
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
Cont
w 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!
--
Sent via pgsql-hackers mailing list (pgsql
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 pgsql-hacker
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
impacted
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
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, I'll
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:
http://www.postgres
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 6th with a number of patches as att
riting the trigger 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
ve 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
3 months since 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@postgresq
UBE, 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-hackers mailing list (pgsql
). 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
>> 3ca7eddbb7c4803729d385a0c9535d8a972e
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
code is intera
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 j
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
>>&g
xactly likely to conflict with 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
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 shut
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 $$
+cr
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 = PG_GETA
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)
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 c
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'
# Whe
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 will
project (assuming that I 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-
eing 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 Berkus
Red Hat
e, 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
to
complain it's too long and want to truncate it. Writing the 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 vi
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 so
n
>> the 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
On 12/08/2016 04:16 PM, Tom Lane wrote:
> Josh Berkus 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 idea. But it would take resources to
would take 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.
ew 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 OSAS
(any op
rays.
Huh? 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@postg
On 10/21/2016 10:29 AM, Robert Haas wrote:
> On Fri, Oct 21, 2016 at 1:17 PM, Josh Berkus 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
>> work in a freeze
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
ven stronger reason
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
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, "perfor
load 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
t; 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.
--
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_
On 10/18/2016 01:28 PM, Robert Haas wrote:
> On Tue, Oct 18, 2016 at 4:18 PM, Josh Berkus wrote:
>> On 10/12/2016 05:00 PM, Robert Haas wrote:
>>> On Sun, Oct 9, 2016 at 9:51 PM, Josh Berkus wrote:
>>>> Given that hot_standby_feedback is pretty bulletproof now,
On 10/12/2016 05:00 PM, Robert Haas wrote:
> On Sun, Oct 9, 2016 at 9:51 PM, 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_age is at an en
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
both 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
or when they 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
R
significant (+144MB for the base 3 WAL segments). 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
R
On 08/15/2016 05:18 PM, Tom Lane wrote:
> Josh Berkus 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 account isn't
On 08/15/2016 02:43 PM, Tom Lane wrote:
> Josh Berkus 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.
>
>> That looks like it was
"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
did 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)
--
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.
-
On 07/26/2016 03:07 PM, Tom Lane wrote:
> Josh Berkus 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
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
to see someone blog about our testing for 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
#x27;re anywhere near plumbing 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
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
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?
IMHO, we just
er; I doubt most
users 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
t; 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 have a point h
before we get it right. Particularly 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
On 06/02/2016 01:08 PM, David G. Johnston wrote:
> On Thu, Jun 2, 2016 at 3:52 PM, Josh berkus <mailto:j...@agliodbs.com>>wrote:
>
> On 06/02/2016 08:53 AM, Tom Lane wrote:
> > Josh berkus mailto:j...@agliodbs.com>> writes:
> >> On
On 06/02/2016 08:53 AM, Tom Lane wrote:
> Josh berkus 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 want a
>>> g
rameter
which 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
out how the parameters *work*, 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
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
On 05/31/2016 11:10 AM, Tom Lane wrote:
> Josh berkus 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://www.postgresql.org/message-id/flat/20160
On 05/31/2016 11:29 AM, Tom Lane wrote:
> Josh berkus 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 contributing to the confusion.
On 05/31/2016 11:27 AM, Peter Geoghegan wrote:
> On Tue, May 31, 2016 at 11:22 AM, Josh berkus wrote:
>>> I think we can hope that developers are going to be less confused about
>>> that than users.
>>
>> Makes sense.
>
> Maybe EXPLAIN doesn't hav
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 par
his, which 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
On 05/31/2016 10:51 AM, Peter Geoghegan wrote:
> On Tue, May 31, 2016 at 10:46 AM, Josh berkus 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 scan leader
> isn'
On 05/31/2016 10:38 AM, Peter Geoghegan wrote:
> On Tue, May 31, 2016 at 10:23 AM, Josh berkus wrote:
>> It's still WAY simpler to understand "max_parallel is the number of
>> parallel workers I requested".
>
> (Sorry Josh, somehow hit reply, not reply-
On 05/31/2016 10:16 AM, Peter Geoghegan wrote:
> On Tue, May 31, 2016 at 10:10 AM, Josh berkus wrote:
>> "max_parallel_degree is the amount of parallelism in the query, with the
>> understanding that the original parent process counts as 1, which means
>> that if
On 05/31/2016 10:03 AM, Tom Lane wrote:
> Josh berkus 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 did I only get 7?".
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 pa
select to_tsquery('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
( PostgreSQL <-> version <-> 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 v
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 make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
kage to rate a .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 you
ing it for marketing reasons.
Per 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 o
;d try to do it 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 opini
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
>>> wrote:
>
>> Anyway, all of this is a moot point, because nobody
ck with the current 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
On 05/13/2016 11:49 AM, Tom Lane wrote:
> Alvaro Herrera 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 version should be 10.0 no matter wh
all 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 (
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@postgre
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 - 100 of 5051 matches
Mail list logo
