t to replace hstore, but we can't get just get rid of hstore because
> it has too many users
Yes, please! This was the original approach that we talked about and
everyone agreed to, and what Andrew has been trying to implement.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts
individual scans are consistent, not that
> separate scans are. Each individual scan takes a new snapshot if there's been
> ddl.
>
> Andres
>
I thought that we were sharing the same snapshot, for parallel dump?
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
really the point of contention at all.
>
Actually, I didn't know any such thing. Just a couple days ago, you
were arguing fairly strongly for moving jsonb to the hstore extension.
You weren't clear that you'd given up on that line of argument.
--
Josh Berkus
PostgreSQL Exper
my view the most important thing right now is that before anything
> is committed, at the very least there needs to be a strategy around
> getting hstore-style GIN indexing in jsonb.
I think it's a good idea to have a strategy.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
ease correct me if I'm
> mistaken.
I would agree with you.
Andrew was onsite with a client over the weekend, which is why you
haven't heard from him on this thread.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via pgsql-hackers mailing list (pgsql-hack
ever, surely these hstore operator classes have
> independent value, or represent incremental progress?
Primary value is that in theory the hstore2 opclasses are available
*now*, as opposed to a year from now.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via pgsql-hacke
uld use this exploit to create a wormed version of PostgresQL on the
target build system. Is that possible?
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
ould
> be similar to the previous few commit fests. So decent job so far.
So, other than Hstore2/JSONB and Logical Changesets, what are the
big/difficult patches left?
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.
On 02/28/2014 11:19 AM, Greg Stark wrote:
> On Fri, Feb 28, 2014 at 7:12 PM, Josh Berkus wrote:
>> * As cited, many sysadmins block the install of the -contrib package.
>
> Of course the more you put things in core the more you make this logic
> sound reasonable.
Touche'!
-hackers soundly rejected that proposal,
so we're currently stuck in the proverbial polluted estuary.
My cause, as everyone knows, is adoption. Given that, I'm pretty
strongly in favor of proposal (A); I think a jsonb type which "just
works" will drive twice the adoption tha
ll the kingdoms wanting her attention.
That's one of the more colorful metaphors ever posted on this list. I
don't think we've had language like that since Hitoshi stopped being
active. ;-)
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via pgsql-hacke
elopers, and hstore2 without JSON support simply is not. At trade
shows and developer conferences, I get more questions about PostgreSQL's
JSON support than I do for any new feature since streaming replication.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via pgsql-
e had this discussion already in November-December, which
resulted in the current patch. Now you and Robert want to change the
rules on Andrew, which means Andrew is ready to quit, and we go another
year without JSON indexing.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via
On 02/26/2014 11:39 AM, Merlin Moncure wrote:
> On Wed, Feb 26, 2014 at 12:05 PM, Josh Berkus wrote:
>> On 02/26/2014 09:57 AM, Merlin Moncure wrote:
>>> What is not going to be so clear for users (particularly without good
>>> supporting documentation) is how things b
to suggest two changes to postgresql:
And thank you for writing that driver!
I have no opinion about your request for VALUES() stuff, though. It
looks fairly complex as far as grammar and libpq is concerned.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via pgsql-hacke
rs to existing functions without breaking old application
code. So, -1 from me.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 02/26/2014 09:57 AM, Merlin Moncure wrote:
> On Wed, Feb 26, 2014 at 11:41 AM, Josh Berkus wrote:
>> On 02/26/2014 07:02 AM, Merlin Moncure wrote:
>>> On Tue, Feb 25, 2014 at 3:57 PM, Hannu Krosing
>>> wrote:
>>>> It is not in any specs, but neverthe
On 02/25/2014 08:07 PM, Craig Ringer wrote:
> On 02/26/2014 06:21 AM, Merlin Moncure wrote:
>> On Tue, Feb 25, 2014 at 4:03 PM, Josh Berkus wrote:
>>> On 02/25/2014 12:12 PM, Robert Haas wrote:
>>>> I don't agree that jsonb should be preferred in all but a ha
entation.
Actually, that's not true; neither Mongo/BSON nor CouchDB preserve field
ordering. So users who are familiar with JSONish data *storage* should
be aware that field ordering is not preserved.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via pgsql-hackers maili
g_dump was that 9.2's release notes say "pg_dump" and
9.3's say "pg_dumpall", causing users to think there's been some kind of
change.
Of course, this means I need to fix the upgrade page, and I need to
write backported versions of that fix for at least 9.1 and
able of contents though?
I owe an update of
http://www.postgresql.org/docs/9.3/static/upgrading.html; I think I can
easily include a discussion of the various options there.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgre
On 02/25/2014 03:41 PM, Tom Lane wrote:
> Josh Berkus writes:
>> Can we change this text in the template release notes?
>
>> A dump/restore using
>> pg_dumpall<http://www.postgresql.org/docs/9.3/static/app-pg-dumpall.html>,
>> or use of
>> pg_upgrade
te data from any previous release.
Again, here we're recommending pg_dumpall with its many limitations, and
not mentioning pg_dump/pg_restore at all. This has caused several
people to ask me if pg_dump is not supported for upgrading anymore. Fix?
--
Josh Berkus
PostgreSQL Experts Inc.
htt
proposal to present a comparison which fairly
> illustrates the situations in which each will outperform the other.
Awaiting doc patch from Merlin, then. It will need to be clear enough
that an ordinary user can distinguish which type they want.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts
Why would I want to use json
instead of either jsonb or TEXT", the answer becomes quite narrow.
Possibly I should expand the little chart and add a column for TEXT?
It's a viable option for storing JSON data, especially if you store a
lot of broken JSON or fragments.
--
Josh Berkus
Postg
On 02/25/2014 10:50 AM, Robert Haas wrote:
> On Tue, Feb 25, 2014 at 1:45 PM, Josh Berkus wrote:
>> On 02/25/2014 10:31 AM, Robert Haas wrote:
>>> And I definitely don't
>>> agree that our documentation should push people towards stuffing
>>> everything in
On 02/25/2014 10:31 AM, Robert Haas wrote:
> And I definitely don't
> agree that our documentation should push people towards stuffing
> everything in a JSON blob instead of using real column definitions.
Where did you get this out of my doc patch?
--
Josh Berkus
PostgreS
he other, hence "Use jsonb unless you need X".
Merlin is pushing the type of multivariable comparison where *I*
wouldn't be able to make sense of which one I should pick, let alone
some web developer who's just trying to get a site built. That sort of
thing *really* doesn't help
en they want jsonb in 9.5 and have
to rewrite all their tables.
Mind you, we'll need to fix the slow deserialization, though.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
ections of
Functions, and if they're complex it's because of the sheer number of
JSON-related functions.
Anyway, this version of datatypes introduces a comparison table, which I
think should make things a bit clearer for users.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
Teodor, Oleg:
Some bitrot on the nested-hstore patch on current HEAD, possibly due to
the recent update release?
josh@radegast:~/git/pg94$ patch -p1 -i nested-hstore-10.patch
patching file contrib/hstore/.gitignore
patching file contrib/hstore/Makefile
patching file contrib/hstore/crc32.c
take.
I'm not sure how broad the actual use case for this is -- most folks
with sophisticated password needs use AD or LDAP -- but if someone wants
to write the code, I'd be for accepting it.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via pgsql-hackers mai
seful if you have many as you only need to remember the
> single password.
Sounds interesting, but probably better as an external utility than as
part of PostgreSQL. Call it pgWallet.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via pgsql-hackers mailing list (pgsql-ha
tixact is, anywhere, so that we
can link it?
Minor:
ECPG or ecpg? Pick one or the other.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailp
idea in general.
In 10 years of tuning PostgreSQL professionally, I still don't have a
mathematical model for the interaction of the various *_cost parameters
with the speeds of CPU, RAM and IO. If someone else has one, please
post it so that we can make some intelligent decisions on defaults
On 02/14/2014 01:11 PM, Andres Freund wrote:
> Hi,
>
> On 2014-02-14 13:08:34 -0500, Josh Berkus wrote:
>> Do the 9.3.3 replication fixes mean that users should reclone their
>> replicas, like 9.3.2 did? Or not?
>
> Which replication replication fixes a
All,
Do the 9.3.3 replication fixes mean that users should reclone their
replicas, like 9.3.2 did? Or not?
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http
orporate more of
> the hstore feature set than it did.
That was the original goal. However, Oleg and Teodor's late delivery of
Hstore2 limited what Andrew could do for JSONB before CF4 started.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via pgsql-hackers mai
Frankly, if it were entirely up to me HSTORE2 would be part of core and
its only interface would be JSONB. But it's not. So this is a compromise.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
ust that it's still nearly
> as ugly as when I pointed out several of the dangers some weeks back.
Oleg, Teodor, any comments on the above?
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
one.
> Maybe we'll see a pattern.
FWIW, we've periodically seen reports from our clients of replica
databases being slightly larger than the master. Nothing reproducable
or as severe as Greg's issue, or we'd have reported it. But this could
be a more widespread issue, just tha
uld start looking at
the code now.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
is true
Hmmm. What about just making any impossibly complex objects type JSON?
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
revise it.
I was working on doing a two-column table comparison chart; I still
think that's the best way to go.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
likely to me that stddev will pay its
> way, but I'm much less certain about the others.
What I really want is percentiles, but I'm pretty sure we already shot
that down. ;-)
I could use min/max -- think of performance test runs. However, I agree
that they're less valuable
feedback? Or can we fix
> these problems by inventing a new user aspect called MONITOR (similar
> to REPLICATION)? We can grant application_name and replication details
> to that.
Yeah, except I don't see doing the MONITOR thing for 9.4. We'd need a
spec for it first.
--
Josh
no reason to block the patch for
> that reason
If we're talking here about min, max and stddev, then +1. The stats
we've seen so far seem to indicate that any affect on query response
time is within the margin of error for pgbench.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexp
On 01/28/2014 12:10 PM, Tom Lane wrote:
> Josh Berkus writes:
>> For example, I would really like to GRANT an unpriv user access to the
>> WAL columns in pg_stat_replication so that I can monitor replication
>> delay without granting superuser permissions.
>
> Just ou
, I would really like to GRANT an unpriv user access to the
WAL columns in pg_stat_replication so that I can monitor replication
delay without granting superuser permissions.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql
On 01/28/2014 10:56 AM, Alvaro Herrera wrote:
> Josh Berkus escribió:
>
>> Or is this just about whitespace and line breaks?
>
> If the docs are going to be rehauled, please ignore my whitespace
> comments.
I'm sure you'll find plenty to criticize in my
aving reviewed the docs before Andrew sent them in, I felt they
already *were* "minimum acceptable". Certainly they're as complete as
the original JSON docs were.
Or is this just about whitespace and line breaks?
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
S
e the end of the application period (Feb 15). We
can't have a repeat of last year.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
t; Because I first need to know its type. Sometimes it's an array, or an
> object, or a boolean, and for those I won't call the _text version
> afterwards but just use the original.
It would make more sense to extract them as JSON, check the type, and
convert.
--
Josh Berkus
Post
datatype page really needs
expansion and clarification.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
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 constantly degrading then reattaching the sync
standby, resulting in horrible performance.
If we did offer "degrade once" though, we'd need some easy way to
determine that the master was in a state of permanent degrade, and a
command to make it resync.
Discuss?
--
Josh Ber
That'll give us a whole
dev cycle to argue about it.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
have not been 100% consistent. Community
> design can be a bit messy that way.
FWIW, I prefer the parameter to having differently named functions.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make chang
it back on afterwards" --- and that was the end of it.
Anything which depends on a timing-based feedback loop is going to be
hopeless. Saying "autovac shouldn't run if load is high" sounds like a
simple statement, until you actually try to implement it.
--
Josh Berkus
PostgreSQL E
On 01/23/2014 02:55 PM, Josh Berkus wrote:
> On 01/23/2014 02:17 PM, Magnus Hagander wrote:
>> FWIW, I have a patch around somewhere that I never cleaned up properly for
>> submissions that simply added a counter to pg_stat_user_tables indicating
>> how many times vacuu
info (it was for my case) to cover this case, I can try to dig it out
> again and clean it up...
It would be 100% more information than we currently have. How much more
difficult would it be to count completed autovacuums as well? It's
really the ratio of the two which matters ...
-
serve as they say.
>
> Thoughts?
If we let autovacuum block user activity, a lot more people would turn
it off.
Now, if you were to argue that we should have some way to monitor the
tables which autovac can never touch because of conflicts, I would agree
with you.
--
Josh Berkus
PostgreSQL Expe
ly Heroku has some more specific exploit case to be concerned
about here; if so, might I suggest taking it up with the -security list?
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
complexity pg_stat_get_activity() has.
That would work for me, personally. I don't know how it would work for
anyone else.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription
ely as an
unprivileged user, but that one fact requires the handyrep database user
to be a superuser.
It would be really nice to be able to GRANT/REVOKE on some of these
special system views ...
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via pgsql-hackers mailing list (
All,
pg_isready works against older versions of PostgreSQL. Does anyone know
if there's a limit to that? v3 protocol change? Something else?
Backwards compatibility ought to be in its docs, but to fix that I need
to know what version it's compatible *to*.
--
Josh Berkus
PostgreS
Mel,
So we have a few interested parties. What do we need to do to set up
the Collab session?
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org
n a new function would add. But if we create
> PQsetClientEncodingIfDifferent() (or whatever) we can remove those
> extra lines in 9.4 ;-)
Hey, since we're about to do 9.3.3: was this patch ever committed?
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent vi
why I was just advocating changing the *defaults*, not mandating
anything. Actual directory locations and usage should be configurable
by distros, packagers and users.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
or other
> packages.
FWIW, this is what I was proposing. We have an "include_dir
postgresql.conf.d" currently in the stock postgresql.conf, but it's
disabled (commented out) by default. I'd just like it enabled by
default, and to pass a suggestion to the packagers that they
nf.d reference to that file. I'm talking about the vast
majority of our users who never edit pg.conf by hand.
> Independent of the above, I don't agree with that. postgresql.auto.conf
> is a special thing and should have its own special place. For once
> thing, when putting configurati
anagement tools becomes much
harder.
Yes, I'm also arguing that postgresql.auto.conf should go into conf.d.
I said I'd bring that up again after ALTER SYSTEM SET was committed, and
here it is.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via pgsql-hackers mailin
om
FWIW, I'm talking with Amazon later this week and checking how they're
handling their tenant-loadable extensions. I'd like to come up with one
solution here which covers all cloud providers.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via pgsql
On 01/13/2014 05:48 PM, Andres Freund wrote:
> On 2014-01-13 10:56:00 -0800, Josh Berkus wrote:
>> Well, it was the lack of sysctl options which takes the 2Q change from
>> "annoyance" to "potential disaster". We can't ever get away from the
>> possi
On 01/13/2014 05:30 PM, Dave Chinner wrote:
> On Mon, Jan 13, 2014 at 03:24:38PM -0800, Josh Berkus wrote:
> No matter what default NUMA allocation policy we set, there will be
> an application for which that behaviour is wrong. As such, we've had
> tools for setting applicat
ose who do hit it,
replication is impossible and there's no workaround.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 01/13/2014 05:10 PM, Jim Nasby wrote:
> On 1/13/14, 7:06 PM, Josh Berkus wrote:
>> Regularly? No. But I've seen it, especially as part of a "does this
>> query return any rows?" test. That's not the best way to test that, but
>> that doesn't st
On 01/13/2014 04:20 PM, Jim Nasby wrote:
> On 1/13/14, 5:57 PM, Josh Berkus wrote:
>> I *really* don't want to go through all my old code to find places where
>> I used SELECT ... INTO just to pop off the first row, and ignored the
>> rest. I doubt anyone else does, eit
7;t want to go through all my old code to find places where
I used SELECT ... INTO just to pop off the first row, and ignored the
rest. I doubt anyone else does, either.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
ble. I understand the goal was to make memory usage local
to the processors stuff was running on, but that includes an implicit
assumption that no individual process will ever want more than one
memory bank worth of cache.
So disabling all of the NUMA optimizations is the way to go for any
wor
Everyone,
I am looking for one or more hackers to go to Collab with me to discuss
this. If you think that might be you, please let me know and I'll look
for funding for your travel.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via pgsql-hackers mailing list (
On 01/13/2014 10:51 AM, Kevin Grittner wrote:
>> How about "don't add major IO behavior changes with no
>> backwards-compatibility switches"? ;-)
>
> I notice, Josh, that you didn't mention the problems many people
> have run into with Transparent Hug
more".
How about "don't add major IO behavior changes with no
backwards-compatibility switches"? ;-)
Seriously, one thing I'd like to get out of Collab would be a reasonable
regimen for testing database performance on Linux kernels.
--
Josh Berkus
PostgreSQL Experts Inc.
On 01/12/2014 12:35 PM, Stephen Frost wrote:
> * Josh Berkus (j...@agliodbs.com) wrote:
>> You don't want to handle all of those issues the same way as far as sync
>> rep is concerned. For example, if the standby is restaring, you
>> probably want to wait instea
we need a more sophisticated approach to
wal_sender_timeout to go with all this.
===
On 01/11/2014 08:33 PM, Bruce Momjian wrote:
> On Sat, Jan 11, 2014 at 07:18:02PM -0800, Josh Berkus wrote:
>> In other words, if we're going to have auto-degrade, the most
>>
ut of the file and leave it in the main
docs and pg_settings where it belongs.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
to have a really,
really hard time determining when to degrade.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 01/10/2014 01:34 PM, David Rowley wrote:
> On Sat, Jan 11, 2014 at 8:28 AM, Josh Berkus wrote:
>
>> All,
>>
>> To make this easier for everyone to participate in, I've created a wiki
>> page:
>>
>> https://wiki.postgresql.org/wiki/9.4CF4Triage
&g
e (or function) to report on
degraded mode. If we have those things, then it becomes completely
possible to have an external monitoring framework, which is capable of
answering questions like "is the replica down or just slow?", control
degrade.
Oh, wait! We DO have such a command. It
on). Scalable
clustered filesystems added N(M) quorum commit in order to support more
than 2 nodes. Either of these courses are reasonable for us to pursue.
What's a bad idea is adding an auto-degrade option without any tools to
manage and monitor it, which is what this patch does by my
All,
To make this easier for everyone to participate in, I've created a wiki
page:
https://wiki.postgresql.org/wiki/9.4CF4Triage
Please add the patches you know well to the appropriate list, thanks!
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via pgsql-ha
o zero-fill and switch segments, yes. We should
NEVER be in a position of archiving two different versions of the same
segment.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
nd say that if the Hstore2 patch doesn't support JSONB
for 9.4, we should postpone it to 9.5. We really don't want to get into
a situation where we need an Hstore3 because we accepted an Hstore2
which needs to be rev'd for JSON.
Especially since there's no good reason for the JS
at being a CP-oriented
> system.
I'm not categorically opposed to having any form of auto-degrade at all;
what I'm opposed to is a patch which adds auto-degrade **without adding
any additional monitoring or management infrastructure at all**.
--
Josh Berkus
PostgreSQL Experts In
ant MM replication anyway.
"Sync N times" is really just a guarantee against data loss as long as
you lose N-1 servers or fewer. And it becomes an even
lower-availability solution if you don't have at least N+1 replicas.
For that reason, I'd like to see some realistic actual use
their tradeoffs (including the
different sync modes and per-transaction sync). Anything short of that
is just going to muddy the waters further.
Mind you, someone needs to take a machete to the HA section of the docs
anyway.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sen
de makes even less
sense.
I really think that demand for auto-degrade is coming from users who
don't know what sync rep is for in the first place. The fact that other
vendors are offering auto-degrade as a feature instead of the ginormous
foot-gun it is adds to the confusion, but we
On 01/08/2014 01:49 PM, Tom Lane wrote:
> Josh Berkus writes:
>> If we really want auto-degrading sync rep, then we'd (at a minimum) need
>> a way to determine *from the replica* whether or not it was in degraded
>> mode when the master died. What good do messages to t
On 01/08/2014 02:04 PM, Peter Eisentraut wrote:
> Anyone else?
>
> Or you'll have to deal with me again?
>
>
I vote for Peter.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To
rep groups as well, and would make them
practical (right now, they're pretty useless). However, I seriously
doubt that someone is going to code that up in the next 5 days.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@post
e possible to
triage the new/updated stuff which comes in in the first 48 hours of the
CF. If we wait until the CF begins, we'll spend at least the first week
of the CF triaging.
That's why we set this schedule at the developer meeting.
And besides, we already know what category *yo
801 - 900 of 5051 matches
Mail list logo
