don't count the WAL files, though, that eliminates the best way to
detecting when archiving is failing.
--
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
All,
Crossing this over to -hackers because it's stopped being a bug and is
now a TODO item. See below.
For those not on pgsql-bugs, I've quoted the full bug report below my
proposal.
On 10/09/2014 12:36 PM, Josh Berkus wrote:
Summary: pg_restore -n attempts to restore objects to pg_catalog
general system views which expose
the options in a user-friendly format (like columns, JSON or an array).
It's already very hard for users to get information about what
reloptions have been set.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via pgsql-hackers mailing list
9.5 Commitfest ... assuming someone wants to
write docs.
Heck, I might write them after some testing. But that testing won't
happen in time for 9.4 release. I certainly couldn't write the docs now.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via pgsql-hackers mailing
it (the common answer) available in the next PostgreSQL release.
Great!
--
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
the documentation and commit it that way, I'm happy with
that too.
I'm also in favor of removing it. We really don't need more GUCs which
nobody has any clear idea how to change or why.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers
than we'd require for a lot of other patches, and
it's not like the 9.5 release is next month.
--
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
, then what's the point in quibbling about docs?
--
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
, not the locking rules. Having a statement silently
take a full table lock when we were expecting it to be concurrent
(because, for example, the index got rebuilt and someone forgot the
UNIQUE) violates POLA from my perspective.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
On 09/30/2014 02:39 PM, Kevin Grittner wrote:
Josh Berkus j...@agliodbs.com wrote:
On 09/30/2014 07:15 AM, Kevin Grittner wrote:
At the risk of pushing people away from this POV, I'll point out
that this is somewhat similar to what we do for unlogged bulk loads
-- if all the conditions
On 09/30/2014 02:51 PM, Kevin Grittner wrote:
Josh Berkus j...@agliodbs.com wrote:
On 09/30/2014 02:39 PM, Kevin Grittner wrote:
Josh Berkus j...@agliodbs.com wrote:
On 09/30/2014 07:15 AM, Kevin Grittner wrote:
At the risk of pushing people away from this POV, I'll point out
for a duplicate column declartion would be nice, there's a raft
of issues with implementing it that way. Users I know are generally
just looking to avoid getting a transaction-halting error when they run
the same create index statement twice.
--
Josh Berkus
PostgreSQL Experts Inc.
http
On 09/30/2014 03:53 PM, Andres Freund wrote:
On 2014-09-30 18:47:24 -0400, Tom Lane wrote:
Josh Berkus j...@agliodbs.com writes:
On 09/30/2014 02:43 PM, Tom Lane wrote:
=?UTF-8?Q?Fabr=C3=ADzio_de_Royes_Mello?= fabriziome...@gmail.com writes:
What's your thoughts about we implement
On 09/30/2014 04:16 PM, Andres Freund wrote:
On 2014-09-30 16:03:01 -0700, Josh Berkus wrote:
On 09/30/2014 03:53 PM, Andres Freund wrote:
Good point. I think it's fair enough to only allow CINE on named
indexes.
On the other hand, the way we form system-generated names is predicable,
so I
On 09/30/2014 04:58 PM, FabrÃzio de Royes Mello wrote:
On Tue, Sep 30, 2014 at 8:47 PM, Josh Berkus j...@agliodbs.com wrote:
On 09/30/2014 04:16 PM, Andres Freund wrote:
On 2014-09-30 16:03:01 -0700, Josh Berkus wrote:
On 09/30/2014 03:53 PM, Andres Freund wrote:
Good point. I think it's
On 09/29/2014 11:49 AM, Arthur Silva wrote:
What's the call on the stride length? Are we going to keep it hardcoded?
Please, yes. The complications caused by a variable stride length would
be horrible.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via pgsql-hackers
On 09/26/2014 06:20 PM, Josh Berkus wrote:
Overall, I'm satisfied with the performance of the length-and-offset
patch.
Oh, also ... no bugs found.
So, can we get Beta3 out now?
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via pgsql-hackers mailing list (pgsql
to zero.
That would not be a back-portable fix.
There are many 3rd-party tools out there (AWS RDS, for one) which do not
use the units.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
be considered
independently.
I'm good with the error. We'll want to add stuff to both the docs and
pg_settings to *show* the minimum value, and an informative error
message would help, i.e.:
Invalid value for log_rotation_interval. Minimum value is 1min
--
Josh Berkus
PostgreSQL Experts Inc
uncompressed (EXTERNAL) was faster on
Q1 than head! This was surprising enough that I retested it.
Overall, I'm satisfied with the performance of the length-and-offset
patch.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers
On 09/25/2014 09:01 AM, Andres Freund wrote:
But independent of which version is chosen, we *REALLY* need to make the
decision soon. This issue has held up the next beta (like jsonb has
blocked previous beta) for *weeks*.
Yes, please!
--
Josh Berkus
PostgreSQL Experts Inc.
http
.
2. However, people are convinced that there's a better patch possible.
3. But nobody is working on this better patch except in their spare time.
Given this, I once again vote for releasing based on Tom's lengths-only
patch, which is done, tested, and ready to go.
--
Josh Berkus
PostgreSQL
On 09/25/2014 10:20 AM, Andres Freund wrote:
On 2014-09-25 10:18:24 -0700, Josh Berkus wrote:
On 09/25/2014 10:14 AM, Bruce Momjian wrote:
On Thu, Sep 25, 2014 at 06:01:08PM +0200, Andres Freund wrote:
But independent of which version is chosen, we *REALLY* need to make the
decision soon
On 09/25/2014 10:26 AM, Andres Freund wrote:
On 2014-09-25 10:25:24 -0700, Josh Berkus wrote:
If Heikki says it's ready, I'll test. So far he's said that it wasn't
done yet.
http://www.postgresql.org/message-id/541c242e.3030...@vmware.com
Yeah, and that didn't include some of Tom's bug
expect, but we should do it anyway.
OK. I'll spend some time trying to get Socorro with JSONB working so
that I'll have a second test case.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes
.
--
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
the patch until he got reviewer OK.
Fortunately, since we use Git and not CVS, reverting patches isn't the
trauma it once was.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription
a patch ready for testing?
--
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
there's both msvc and mingw support for windows builds - borlands
only platform - I see little point in continuing to support it.
+1
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
be reverted),
not whether it should have been in the CF 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://www.postgresql.org/mailpref/pgsql-hackers
. Your ideas can help ...
--
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
as I can tell and seems
more readable.)
That works for 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
.
--
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 09/18/2014 01:10 PM, Hannu Krosing wrote:
One possible syntax would be extending WITH to somehow enable on-spot
functions in addition to on-spot views
WITH FUNCTION myfunc(...) RETURNS TABLE(...) LANGUAGE plpgsql AS $$
...
$$
SELECT f.*
FROM myfunc(x,y,z);
Oh! Awesome!
--
Josh
this syntax for a few years now, so I certainly vote
for it.
Just to clarify: I want the WITH syntax for different purposes.
However, I *also* want DO $$ ... $$ USING ( ). Those are two separate,
different features with different use-cases.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
need a better way to display the grand total
grouping set.
Or maybe:
Grouping Set: (onek.four, onek.ten, onek.hundred)
Grouping Set: (onek.four, onek.ten)
Grouping Set: (onek.four)
Grouping Set: ()
The latter won't work with JSON and YAML output.
--
Josh Berkus
PostgreSQL
On 09/16/2014 06:31 AM, Robert Haas wrote:
On Mon, Sep 15, 2014 at 7:44 PM, Peter Geoghegan p...@heroku.com wrote:
On Mon, Sep 15, 2014 at 4:05 PM, Josh Berkus j...@agliodbs.com wrote:
Actually, having the keys all at the same level *is* relevant for the
issue we're discussing. If those 270
On 09/16/2014 09:54 AM, Robert Haas wrote:
On Tue, Sep 16, 2014 at 12:47 PM, Josh Berkus j...@agliodbs.com wrote:
On 09/16/2014 06:31 AM, Robert Haas wrote:
On Mon, Sep 15, 2014 at 7:44 PM, Peter Geoghegan p...@heroku.com wrote:
On Mon, Sep 15, 2014 at 4:05 PM, Josh Berkus j...@agliodbs.com
.
Not sure exactly where this note should go, mind you.
--
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
particular use case is not it.
Do you feel that way *as a code maintainer*? That is, if you ended up
maintaining the JSONB code, would you still feel that it's worth the
extra complexity? Because that will be the main cost here.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via
On 09/12/2014 01:33 PM, Tom Lane wrote:
Josh Berkus j...@agliodbs.com writes:
However, this better become a FAQ item, because it's not necessarily the
behavior that folks used to JSON but not Postgres will expect.
No, it's a bug, not a documentation deficiency.
Hmmm? Are you proposing
the original offsets
version?
If not, I think the corner case is so obscure as to be not worth
optimizing for. I can't imagine that more than a tiny minority of our
users are going to have thousands of keys per datum.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via
think that
having more than 200 top-level keys in one JSONB value is going to be a
use case for more than 0.1% of our users. I personally do not.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes
On 09/15/2014 12:15 PM, Claudio Freire wrote:
So while you're right that it's perhaps above what would be a common
use case, the range somewhere between 200 and 100K for the tipping
point seems overly imprecise to me.
Well, then, you know how to solve that.
--
Josh Berkus
PostgreSQL Experts
On 09/15/2014 12:25 PM, Claudio Freire wrote:
On Mon, Sep 15, 2014 at 4:17 PM, Josh Berkus j...@agliodbs.com wrote:
On 09/15/2014 12:15 PM, Claudio Freire wrote:
So while you're right that it's perhaps above what would be a common
use case, the range somewhere between 200 and 100K
On 09/15/2014 02:16 PM, Robert Haas wrote:
On Mon, Sep 15, 2014 at 3:09 PM, Josh Berkus j...@agliodbs.com wrote:
On 09/15/2014 10:23 AM, Claudio Freire wrote:
Now, large small keys could be 200 or 2000, or even 20k. I'd guess
several should be tested to find the shape of the curve.
Well, we
the Mozilla Socorro test
environment working, I can also test with Mozilla crash data. That has
some deep nesting and very large values.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
On 09/12/2014 10:00 AM, Robert Haas wrote:
On Fri, Sep 12, 2014 at 1:00 PM, Robert Haas robertmh...@gmail.com wrote:
On Thu, Sep 11, 2014 at 9:01 PM, Josh Berkus j...@agliodbs.com wrote:
So, I finally got time to test Tom's latest patch on this.
TLDR: we want to go with Tom's latest patch
) JB_ROOT_COUNT(tmpl) ||
JB_ROOT_IS_OBJECT(val) != JB_ROOT_IS_OBJECT(tmpl))
PG_RETURN_BOOL(false);
It's likely that JB_ROOT_COUNT(val) JB_ROOT_COUNT(tmpl) should be
checked only for objects, not arrays.
Yeah, agreed.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via pgsql
and past behavior.
However, this better become a FAQ item, because it's not necessarily the
behavior that folks used to JSON but not Postgres will expect.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes
to EXTERNAL, and the
the same performance as the unpatched version.
--
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
want any package concept to be usable with external PLs as
well as PL/pgSQL, which necessitates other Oracle-incompatible changes.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
porcine
makeover.
--
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 09/02/2014 03:19 PM, Josh Berkus wrote:
Well, if I were designing a new procedural SQL extension language, I
wouldn't base it on the bastard child of ADA and SQL89. I would come up
Ada, that is. One is a programming language, the other is the bane of
architects.
--
Josh Berkus
PostgreSQL
On 08/28/2014 09:09 AM, Alvaro Herrera wrote:
Josh Berkus wrote:
On 04/16/2014 01:30 PM, Alvaro Herrera wrote:
Josh Berkus wrote:
You can see the current multixact value in pg_controldata output. Keep
timestamped values of that somewhere (a table?) so that you can measure
consumption rate
to convert the CSV to
JSON, with the existing fields? Waste of time, I can do that with a
5-line script in at least 3 different languages.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
responsibility for the mess which is
our data type naming. What we call timestamptz should just be
timestamp, and whether or not it converts to local timezone on
retrieval should be a GUC setting. And the type we call timestamp
shouldn't exist. Hindsight is 20/20.
--
Josh Berkus
PostgreSQL Experts Inc
called for feedback on by blog, and have gotten some:
http://www.databasesoup.com/2014/08/the-great-jsonb-tradeoff.html
--
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
On 08/26/2014 11:40 AM, Tom Lane wrote:
Josh Berkus j...@agliodbs.com writes:
Anyway, I called for feedback on by blog, and have gotten some:
http://www.databasesoup.com/2014/08/the-great-jsonb-tradeoff.html
I was hoping you'd get some useful data from that, but so far it seems
like
soon.
--
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
+.
Making the bgwriter more aggressive adds a significant risk of writing
the same pages multiple times between checkpoints, so it's not a simple fix.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes
move them back to the database's default tablespace
before using this command.
Aside from being a stupid limitation (I need to copy the tables back to
the old tablespace so that I can recopy them to the new one?), the above
seems to be in direct contradiction to the docs.
--
Josh Berkus
and don't want us to make this
decision based entirely on 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
in findJsonbValueFromContainer and
JsonbIteratorNext
OK, will test.
This means we need a beta3, no?
--
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
On 08/20/2014 08:29 AM, Tom Lane wrote:
Josh Berkus j...@agliodbs.com writes:
On 08/15/2014 04:19 PM, Tom Lane wrote:
Personally I'd prefer to go to the all-lengths approach, but a large
part of that comes from a subjective assessment that the hybrid approach
is too messy. Others might well
to or shouldn't. And not
recommending it for the restore_command is also confusing.
I'm afraid that I agree with Peter here. pg_copy looks like a nice
foundation for the eventual pg_copy utility we need, but it's not there yet.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via
the same size as the lengths-only version.
Huh?
--
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 only 60MB. Which shows just how terrific the improvement in
GIN index size/performance is.
--
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
be
disastrously slow or 300% of the size of comparable TEXT. Mind you, I
don't find +80% to be disastrously slow (especially not with a space
savings of 60%), so maybe that's good enough.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via pgsql-hackers mailing list (pgsql
compression would help.
I thought the destruction case was when we have enough top-level keys
that the offsets are more than 1K total, though, yes?
So we need to test that set ...
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via pgsql-hackers mailing list (pgsql
.
BTW, I find this peculiar:
postgres=# select pg_size_pretty(pg_relation_size('jsonic'));
pg_size_pretty
383 MB
(1 row)
postgres=# select pg_size_pretty(pg_relation_size('jsonbish'));
pg_size_pretty
11 MB
(1 row)
Next up: Tom's patch and indexing!
--
Josh
On 08/14/2014 04:02 PM, Tom Lane wrote:
Josh Berkus j...@agliodbs.com writes:
So, here's a destruction test case:
200,000 JSON values (plus 2 key columns)
Average width 4K (+/- 1K)
183 keys per JSON value
Is that 183 keys exactly each time, or is 183 the average?
Each time exactly
end stuff be smaller?
--
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 08/14/2014 04:47 PM, Josh Berkus wrote:
thetype |colsize_distribution
-+
json| {1777,1803,1890,1940,4424}
jsonb | {5902,5926,5978,6002,6208}
Just realized my query was counting the whole row size instead of just
the column size. Here's just
on the master, but they still don't want to connect
to a replica which is hours behind the last node they queried.
There's also use-cases for which automated connection failover without a
managed proxy is a Seriously Bad Idea. For one thing, you're setting up
a strong risk of split-brain.
--
Josh
Execution time: 5214.212 ms
... so, an 80% increase in lookup and extraction time for swapping
offsets for lengths. That's actually all extraction time; I tried
removing the extraction from the query, and without it both queries are
close enough to be statstically insignificant.
--
Josh Berkus
you for doing this!
--
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
be prohibitive. And we'll be in a position where we have
to support the 9.4 JSONB format/compression technique for years so that
users aren't blocked from upgrading.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org
some talk of trying
to do such coercions via SQL casts, but nothing's been done for fear
of compatibility problems.
Yeah, that's a weeks-long project for someone. And would require a lot
of tests ...
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via pgsql-hackers mailing
(not just one block). Perhaps a better one
would be simply range index, which we could abbreviate to RIN or
BRIN.
How about Block Range Dynamic indexes?
Or Range Usage Metadata indexes?
You see what I'm getting at:
BRanDy
RUM
... to keep with our new indexes naming scheme ...
--
Josh Berkus
On 08/07/2014 05:52 PM, Michael Paquier wrote:
On Fri, Aug 8, 2014 at 9:47 AM, Josh Berkus j...@agliodbs.com wrote:
On 08/07/2014 08:38 AM, Oleg Bartunov wrote:
+1 for BRIN !
On Thu, Aug 7, 2014 at 6:16 PM, Simon Riggs si...@2ndquadrant.com wrote:
On 7 August 2014 14:53, Robert Haas robertmh
would benefit from this. Can you?
--
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
haven't come up with a better name ...
--
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
be raised.
Yes.
BTW, while there's unlikely to be a good reason to put search_path in
pg.conf with appends, there are a LOT of reasons to want to be able to
append to it during a session.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via pgsql-hackers mailing list (pgsql
*couldn't*
fix it, not because anybody wanted 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
; there are reasons why a user might not care that
archive_command was failing (shared storage comes to mind). However,
that would be a surprising break with backwards compatability, since
currently users don't check the result value of pg_stop_backup().
Thoughts?
--
Josh Berkus
PostgreSQL Experts Inc
that this change is worth
breaking backwards compatibility.
--
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
. That's pretty extreme corner-case.
Also, it's my perspective that users who change conf by concurrently
editing pg.conf *and* doing ALTER SYSTEM SET are hopeless anyway.
There's simply no way we can protect them from themselves.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent
pg_upgrade to upgrade
the cluster. We had to change pg_control format post-beta1.
Thank you for testing that 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
by pg itself, and it could be an LSN range instead of a timestamp
really.
What about requiring checksums to be on instead, and checking the
file-level checksums? Hmmm, wait, do we have file-level checksums? Or
just page-level?
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
will be afraid to touch it.
If this means that we need to finally create pg_editcontroldata, then so
be 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
range,
but performance didn't change emails.
--
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
not for
fillfactor.
--
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
their older pg.conf's to 9.4, which will
already have shared_buffers uncommented;
2) Some distros ship their own pg.conf;
3) Doesn't solve the issue of overlapping files in conf.d, which is the
same problem.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via pgsql-hackers mailing
On 07/08/2014 06:10 PM, Mark Kirkwood wrote:
On 09/07/14 05:13, Josh Berkus wrote:
On 07/06/2014 01:27 AM, Christoph Berg wrote:
Another could be that during initdb all the uncommented settings be
written to postgresql.auto.conf file rather than to postgresql.conf.
I think we can do
... NoSQL-ish. Maybe update
the values, maybe 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://www.postgresql.org/mailpref/pgsql-hackers
requirements like can't be
changed except at server start.
+1
This would also make conf.d much more useful; I wouldn't have to worry
as much about overlapping config settings.
Sounds like a 9.5 feature, though.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via pgsql-hackers
of management (or, thirdly, using conf.d); if
they mix methods, we can't prevent confusion at restart time and we
shouldn't try.
--
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
Abjit, all:
If we're adding log_line_prefix support for cluster_name (something I
think is a good idea), we need to also add it to CSVLOG. So, where do
we put it in CSVLog?
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers
On 06/25/2014 10:14 AM, Andres Freund wrote:
Hi,
[sorry for the second copy Robert]
Attached is a new version of the atomic operations patch. Lots has
changed since the last post:
Is this at a state where we can performance-test it yet?
--
Josh Berkus
PostgreSQL Experts Inc.
http
501 - 600 of 4746 matches
Mail list logo
