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
(offset 15 lines).
Hunk #7 succeeded at 885 (offset 15 lines).
Hunk #8 succeeded at 1416 (offset 15 lines).
Hunk #9 succeeded at 1605 (offset 15 lines).
Hunk #10 succeeded at 1720 (offset 15 lines).
2 out of 10 hunks FAILED -- saving rejects to file
contrib/hstore/hstore_op.c.rej
--
Josh Berkus
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 (
this is what would bring such issues to
> the community's attention before people are bitten in production
> environments?
That, too.
--
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
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
On 01/08/2014 11:07 AM, David Fetter wrote:
> On Wed, Jan 08, 2014 at 10:45:37AM -0800, Josh Berkus wrote:
>> Hackers,
>>
>> Per the Developer Meeting, we are scheduled to do a final triage of 9.4
>> patches the week before CF4 starts, which is *now*. The goal of
F4 in this order:
1. do immediately
2. do after (1) is complete
3. assign 1 senior hacker reviewer to each patch
4. review as time permits after 1-3
5. review as time permits after 1-3
Let the triage begin!
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via pgsql-hacke
arn by doing", and here's a program which would
bring you up on a LOT of PostgreSQL:
1. Write a few of your own C functions, including trigger functions and
an operator.
2. Write your own foreign data wrapper for something.
3. Write your own Type, including input/output functions, st
On 12/20/2013 04:44 PM, Gavin Flower wrote:
> On 21/12/13 13:40, Josh Berkus wrote:
>> On 12/20/2013 03:09 PM, Gavin Flower wrote:
>>> What about leap years?
>> What about them?
>>
> some years have 365 days others have 366, so how any days in an interval
>
On 12/20/2013 03:09 PM, Gavin Flower wrote:
> What about leap years?
What about them?
--
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
(or similar) function?
It would certainly make our Python users happy.
And for that matter would get rid of this kind of stupid thing in stored
procedure code:
time_ahead := ( interval '1 minute' * var_skip );
So, +1 for the feature.
--
Josh Berkus
PostgreSQL Experts Inc.
http:/
ing.
The locking version would have to pretty much lock on a table basis (or
even a whole-database basis) every time an assertion executed, 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/mailpref/pgsql-hackers
ven better if we could prevent users from switching
transaction mode, but that's a MUCH bigger and more complicated patch.
--
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 12/17/2013 01:42 PM, Kevin Grittner wrote:
> Josh Berkus wrote:
>> Going back over this patch, I haven't seen any further discussion of the
>> point Heikki raises above, which seems like a bit of a showstopper.
>>
>> Heikki, did you have specific ideas on
as on how to solve this? Right now my
mind boggles.
--
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 9.4
>
> Any other votes?
I still support this patch (as I did originally), and don't think that
the overlap with pgFincore is of any consequence. pgFincore does more
than pgrewarm ever will, but it's also platform-specific, so it still
makes sense for both to exist.
--
Jos
someone else has published.
Well, the idea originally (POSTGRES) was for the Type, Domain, and
Inheritance system to do just what you propose. Nobody ever worked out
all the practicalities and gotchas to make it really work in production,
though.
--
Josh Berkus
PostgreSQL Experts Inc.
http:
the BEFORE trigger does not (it returns 0).
Some drivers and ORMs, most notably Hibernate, check this rows-returned
count, and error if they don't match the rows sent.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgres
On 12/16/2013 04:22 PM, Tom Lane wrote:
> Josh Berkus writes:
>> I've looked in the archives, but I can't find a reason why INSTEAD OF
>> triggers were never enabled for tables.
>
> What would that mean exactly? And how would you do the actual update
>
Hackers,
I've looked in the archives, but I can't find a reason why INSTEAD OF
triggers were never enabled for tables. I'm interested in them in order
to return a rowcount to JDBC for INSERTs into partitioned tables.
Was there a technical obstacle, or is this just a TUIT issue?
On 12/16/2013 10:53 AM, Josh Berkus wrote:
> Some PostgreSQL shops with lots of servers have large internal libraries
> of functions, views, and similar code that they've written to support
> their applications, which don't comprise a complete database. This
> feature would
stem-based install. I
myself have a couple clients who could benefit from this.
I think the name "Extension Templates" is horrible because it misleads
all of us on this list into thinking the proposed feature is completely
something other than what it is. I don't have a better name offha
would we get about "NUMERIC is
fast, but FLOAT is slow"?
--
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
eature set (if any), and why Frost doesn't like it. I tried
reading through the thread on -hackers, and came away even more confused.
Is there maybe a wiki page for it?
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@pos
801 - 900 of 4826 matches
Mail list logo