On 2015-06-23 21:08:36 -0400, Robert Haas wrote:
On Tue, Jun 23, 2015 at 5:48 PM, Kevin Grittner kgri...@ymail.com wrote:
Andres Freund and...@anarazel.de wrote:
listitem
para
Improve concurrent locking and buffer scan performance (Andres
Freund, Kevin Grittner)
On 2015-06-23 16:32:54 -0400, Robert Haas wrote:
On Tue, Jun 23, 2015 at 3:47 PM, Andres Freund and...@anarazel.de wrote:
On 2015-06-22 21:05:52 -0400, Robert Haas wrote:
Interesting idea. We could consider the set of stats files a database
unto itself and reserve a low-numbered OID for
On Wed, Jun 24, 2015 at 12:27 AM, Robert Haas wrote:
I think you should be testing RelationNeedsWAL(), not the
relpersistence directly. The same point applies for temporary
indexes.
Indeed. Patch updated attached.
--
Michael
diff --git a/src/backend/commands/indexcmds.c
Hello Hackers.
Because change the commutator and negator raised questions I suggest 3 version
of the patch without them. In addition, for us now is much more important
restrict and join (for Selectivity estimation for intarray patch).
What do you think?
Thanks!
--
Uriy Zhuravlev
Postgres
On 2015-05-31 01:09:18 +0200, Andres Freund wrote:
On 2015-05-27 21:23:34 -0400, Robert Haas wrote:
Oh wow, that's bad, and could explain a couple of the problems we're
seing. One possible way to fix is to replace the sequence with if
(!TAS(spin)) S_UNLOCK();. But that'd mean TAS() has
Does it make sense to put the result tuple of remote join on evety
estate-es_epqTupleSet[] slot represented by this ForeignScan if
scanrelid==0?
It allows to recheck qualifier for each LockRow that intends to lock
base foreign table underlying the remote join.
ForeignScan-fdw_relids tells us
Hi, Merlin.
Thank you for your comment, and sorry for late response.
*) how do you estimate %done and ETA when dumping?
I mentioned in the mail I replied to Andres, I think %done and ETA can be
estimated from number of tuples in pg_class.reltuples.
Pg_dump, you maybe know, writes in file
On Wed, Jun 24, 2015 at 3:49 PM, Andres Freund and...@anarazel.de wrote:
On 2015-06-24 15:41:22 -0400, Peter Eisentraut wrote:
On 6/24/15 3:13 PM, Andres Freund wrote:
Meh. The relevant branches already exist, as you can disable it today.
We could also just change the default in the back
On Wed, Jun 24, 2015 at 3:41 PM, Peter Eisentraut pete...@gmx.net wrote:
On 6/24/15 3:13 PM, Andres Freund wrote:
Meh. The relevant branches already exist, as you can disable it today.
We could also just change the default in the back branches.
One more argument for leaving everything alone.
On Sun, Jun 14, 2015 at 2:08 PM, Peter Geoghegan p...@heroku.com wrote:
Really? The pre-check thing wasn't too complex for Magnus to have a
couple of bullet points on it *specifically* in his high level NYC
talk on Postgres 9.5 features [1]. I don't think it's hard to
understand at all.
On 06/23/2015 04:44 PM, Tom Lane wrote:
Chasing a problem identified by my Salesforce colleagues led me to the
conclusion that my commit f3b5565dd (Use a safer method for determining
whether relcache init file is stale) is rather borked. It causes
pg_trigger_tgrelid_tgname_index to be omitted
I worry that 8.14.3. jsonb Containment and Existence is not
sufficiently clear in explaining that jsonb containment is nested.
I've seen anecdata suggesting that this is unclear to users. We do
say:
The general principle is that the contained object must match the
containing object as to
Noah Misch wrote:
On Sun, Jun 14, 2015 at 12:37:00PM +0200, Magnus Hagander wrote:
Would we in that case want to enforce linearity *and* recent-ness, or just
linearity? as in, do we care about the commit time even if it doesn't
change the order?
If a recency check is essentially free,
On Fri, Jun 5, 2015 at 10:46 AM, Robert Haas robertmh...@gmail.com wrote:
It would be a great deal nicer if we didn't have to keep ANY of the
transactional data for a tuple around once it's all-visible. Heikki
defined ephemeral as only needed when xmin or xmax is in-progress,
but if we
On Wed, Jun 24, 2015 at 10:29 AM, Andres Freund and...@anarazel.de wrote:
On 2015-06-24 23:05:45 +0900, Fujii Masao wrote:
INSERT ON CONFLICT DO UPDATE doesn't seem to work on the current partitioning
mechanism. For example, in the following SQL commands, the last UPSERT
command
would fail
On Tue, Jun 23, 2015 at 10:15 PM, Noah Misch n...@leadboat.com wrote:
That brings it back to the enforcing - would we want to enforce both those?
May as well. AuthorDate is the main source of trouble. You would need to go
out of your way (e.g. git filter-branch) to push an old CommitDate,
On Fri, May 15, 2015 at 9:18 PM, Michael Paquier
michael.paqu...@gmail.com wrote:
On Fri, May 15, 2015 at 8:55 PM, Beena Emerson memissemer...@gmail.com
wrote:
There was a discussion on support for N synchronous standby servers started
by Michael. Refer
Hi,
On 2015-06-24 23:05:45 +0900, Fujii Masao wrote:
INSERT ON CONFLICT DO UPDATE doesn't seem to work on the current partitioning
mechanism. For example, in the following SQL commands, the last UPSERT command
would fail with an error. The error message is
I think that's pretty much
On 2015-06-23 14:33:21 -0400, Tom Lane wrote:
I do not know at this point whether these behaviors are really the same
bug or not, but I wonder whether it's time to consider back-patching the
renegotiation fixes we did in 9.4.
I, by now, have come to a different conclusion. I think it's time to
Tom Lane wrote:
Alvaro Herrera alvhe...@2ndquadrant.com writes:
On Tue, Jun 23, 2015 at 2:33 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I do not know at this point whether these behaviors are really the same
bug or not, but I wonder whether it's time to consider back-patching the
Hi,
INSERT ON CONFLICT DO UPDATE doesn't seem to work on the current partitioning
mechanism. For example, in the following SQL commands, the last UPSERT command
would fail with an error. The error message is
ERROR: duplicate key value violates unique constraint hoge_20150601_pkey
On 2015-06-24 10:38:38 -0400, Robert Haas wrote:
On Wed, Jun 24, 2015 at 10:29 AM, Andres Freund and...@anarazel.de wrote:
On 2015-06-24 23:05:45 +0900, Fujii Masao wrote:
INSERT ON CONFLICT DO UPDATE doesn't seem to work on the current
partitioning
mechanism. For example, in the
Robert Haas robertmh...@gmail.com writes:
On Wed, Jun 24, 2015 at 3:49 PM, Andres Freund and...@anarazel.de wrote:
On 2015-06-24 15:41:22 -0400, Peter Eisentraut wrote:
One more argument for leaving everything alone. If users don't like it,
they can turn it off themselves.
Because it's so
On Wed, Jun 24, 2015 at 3:43 PM, Michael Paquier wrote:
I just realized another problem: We recently learned the hard way that some
people have files in the data directory that are not writeable by the
'postgres' user
(http://www.postgresql.org/message-id/20150523172627.ga24...@msg.df7cb.de).
Fujita-san,
Does it make sense to put the result tuple of remote join on evety
estate-es_epqTupleSet[] slot represented by this ForeignScan if
scanrelid==0?
Sorry, I misunderstood behavior of the es_epqTupleSet[].
I'd like to suggest a solution that re-construct remote tuple according
to the
On 06/24/2015 07:54 PM, Jeff Janes wrote:
Were the stories (or the experience which lead to the stories) on 9.3 or
later? Do they have a good way to reproduce it for testing purposes?
The per-db split can only improve things if there actually are multiple
databases, and if the objects are
On Wed, Jun 24, 2015 at 9:50 AM, Fabien COELHO coe...@cri.ensmp.fr wrote:
flsh | full speed tps | percent of late tx, 4 clients
/srt | 1 client | 4 clients | 100 | 200 | 400 |
N/N | 173 +- 289* | 198 +- 531* | 27.61 | 43.92 | 61.16 |
N/Y | 458 +- 327* | 743
On 6/23/15 8:11 PM, Craig Ringer wrote:
I've certainly had similar issues to you w.r.t. to debug messages from
user-level code, and wanted to be able to enable one particular log
line, all log output from a particular function, or all log output
from a particular extension / all functions in a
Peter,
On 2015-06-25 AM 02:35, Peter Geoghegan wrote:
Inheritance with triggers is a leaky abstraction, so this kind of
thing is always awkward. Still, UPSERT has full support for
*inheritance* -- that just doesn't help in this case.
Could you clarify as to what UPSERT's support for
On 6/12/15 9:31 AM, Robert Haas wrote:
Could we update our git hook to refuse a push of a new commit whose
timestamp is more than, say, 24 hours in the past? Our commit history
has some timestamps in it now that are over a month off, and it's
really easy to do, because when you rebase a
On 2015-06-24 11:11:16 -0400, Tom Lane wrote:
On balance I think I agree that SSL renegotiation has not been worth the
trouble. And we definitely aren't testing it adequately, so if we wanted
to keep it then there's even *more* work that somebody ought to expend.
Right. Our code was nearly
On 2015-06-24 11:57:53 -0400, Peter Eisentraut wrote:
On 6/23/15 2:33 PM, Tom Lane wrote:
I do not know at this point whether these behaviors are really the same
bug or not, but I wonder whether it's time to consider back-patching the
renegotiation fixes we did in 9.4.
If Red Hat fixes
On 6/23/15 2:33 PM, Tom Lane wrote:
I do not know at this point whether these behaviors are really the same
bug or not, but I wonder whether it's time to consider back-patching the
renegotiation fixes we did in 9.4.
If Red Hat fixes their bug, then PostgreSQL doesn't have any actual
problem
Andres Freund and...@anarazel.de writes:
I, by now, have come to a different conclusion. I think it's time to
entirely drop the renegotiation support.
Well, that's a radical proposal, but I think we should take it seriously.
On balance I think I agree that SSL renegotiation has not been worth
On 24 June 2015 at 14:57, Robert Haas robertmh...@gmail.com wrote:
On Fri, Jun 5, 2015 at 10:46 AM, Robert Haas robertmh...@gmail.com
wrote:
It would be a great deal nicer if we didn't have to keep ANY of the
transactional data for a tuple around once it's all-visible. Heikki
defined
On Wed, Jun 24, 2015 at 11:30 PM, Fujii Masao masao.fu...@gmail.com wrote:
On Fri, May 15, 2015 at 9:18 PM, Michael Paquier
michael.paqu...@gmail.com wrote:
On Fri, May 15, 2015 at 8:55 PM, Beena Emerson memissemer...@gmail.com
wrote:
There was a discussion on support for N synchronous
Hello Amit,
[...]
Ok, I misunderstood your question. I thought you meant a dip between 1
client and 4 clients. I meant that when flush is turned on tps goes down by
8% (743 to 681 tps) on this particular run.
This 8% might matter if the dip is bigger with more clients and
more aggressive
Hi,
On 2015-06-11 PM 01:15, Bruce Momjian wrote:
I have committed the first draft of the 9.5 release notes. You can view
the output here:
http://momjian.us/pgsql_docs/release-9-5.html
and it will eventually appear here:
On Thu, Jun 25, 2015 at 12:57 PM, Fujii Masao wrote:
On Thu, Jun 25, 2015 at 12:15 PM, Michael Paquier wrote:
and that's actually equivalent to that in
the grammar: 1(AAA,BBB,CCC).
I don't think that they are the same. In the case of 1(AAA,BBB,CCC), while
two servers AAA and BBB are running,
Hi all,
After looking at the issues with the TAP test suite that hamster faced
a couple of days ago, which is what has been discussed on this thread:
http://www.postgresql.org/message-id/13002.1434307...@sss.pgh.pa.us
I have developed a patch to improve log capture of the TAP tests by
being able
On Tue, May 26, 2015 at 3:39 PM, Michael Paquier wrote:
Here is v6, a rebased version on HEAD (79f2b5d). There were some
conflicts with the indentation and some other patches related to
pg_rewind and initdb's tests.
Attached is v7, rebased on 0b157a0.
--
Michael
From
Andres Freund and...@anarazel.de writes:
On 2015-06-24 11:57:53 -0400, Peter Eisentraut wrote:
If Red Hat fixes their bug, then PostgreSQL doesn't have any actual
problem anymore, does it?
It does, there are numerous bugs around renegotiation that exist with
upstream openssl and postgres.
On Jun 24, 2015 5:13 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Andres Freund and...@anarazel.de writes:
I, by now, have come to a different conclusion. I think it's time to
entirely drop the renegotiation support.
Well, that's a radical proposal, but I think we should take it seriously.
On Wed, Jun 24, 2015 at 11:30 AM, Simon Riggs si...@2ndquadrant.com wrote:
Though TED sounds nice, the way to avoid another round of on-disk bugs is by
using a new kind of testing, not simply by moving the bits around.
I agree that we can do much better at testing than we traditionally
have
On Wed, Jun 24, 2015 at 10:03:50AM -0400, Robert Haas wrote:
On Tue, Jun 23, 2015 at 10:15 PM, Noah Misch n...@leadboat.com wrote:
That brings it back to the enforcing - would we want to enforce both those?
May as well. AuthorDate is the main source of trouble. You would need to
go
On Wed, Jun 24, 2015 at 7:05 AM, Fujii Masao masao.fu...@gmail.com wrote:
How should we treat this problem for 9.5? If we want to fix this problem
completely, probably we would need to make constraint_exclusion work with
even UPSERT. Which sounds difficult to do at least for 9.5. Any other
On Wed, Jun 24, 2015 at 11:02 AM, Peter Geoghegan p...@heroku.com wrote:
I think that the real way to fix this is, as you say, to make it so
that it isn't necessary in general to write trigger functions like
this to make inheritance work.
Excuse me -- I mean to make *partitioning* work.
--
Fabrízio de Royes Mello wrote:
Another rebased version.
There are a number of unrelated whitespace changes in this patch; also
please update the comment on top of check_for_column_name_collision.
--
Álvaro Herrerahttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7
On Sat, Jun 20, 2015 at 7:20 AM, Robert Haas robertmh...@gmail.com wrote:
On Sat, Jun 20, 2015 at 10:12 AM, Joel Jacobson j...@trustly.com wrote:
Is there any chance the project would accept a patch which adds the
pg_stat_*_columns-feature without first optimizing the collector?
I doubt
On 06/24/2015 10:15 AM, Joel Jacobson wrote:
You are most welcome to contact me at j...@trustly.com or by replying
to this thread, if you have any suggestions on how to improve this
bug bounty program, or if you have any other feedback in general.
Members of the PostgreSQL Security Team need
Hello,
I'm interested in adding GiST support for the UUID column type from
the uuid-ossp extension. This has been requested and attempted before:
http://dba.stackexchange.com/questions/83604/optimizing-postgres-row-overlap-constraints-involving-uuids-and-gist
On 2015-06-24 11:18:03 -0700, Josh Berkus wrote:
On 06/24/2015 10:15 AM, Joel Jacobson wrote:
You are most welcome to contact me at j...@trustly.com or by replying
to this thread, if you have any suggestions on how to improve this
bug bounty program, or if you have any other feedback in
On Wed, Jun 24, 2015 at 8:42 AM, Andres Freund and...@anarazel.de wrote:
I'm wondering wether we should add a #warning to atomic.c if either the
fallback memory or compiler barrier is used? Might be annoying to people
using -Werror, but I doubt that's possible anyway on such old systems.
On Wed, Jun 24, 2015 at 7:38 AM, Robert Haas robertmh...@gmail.com wrote:
Is the root of the problem that the trigger is called for an INSERT ..
ON CONFLICT statement but it turns that into a plain INSERT?
Is there any way of writing a partitioning trigger that doesn't have
that defect?
We
On 2015-06-24 19:35:51 +0200, Andres Freund wrote:
Our code currently uses crude hacks (c.f. comment around
SSL_clear_num_renegotiations(), and the loop around SSL_do_handshake()
in the back branches) to manage renegotiations. There's pending patches
to substantially increase the amount of
On Mon, Jun 15, 2015 at 7:47 PM, Jim Nasby jim.na...@bluetreble.com wrote:
On 6/8/15 3:26 PM, Joel Jacobson wrote:
So I've heard from Magnus Hagander today IRL at our Stockholm PostgreSQL
User Group meeting where we discussed this idea. He told me the overhead
in the statistics collector is
On Wed, Jun 24, 2015 at 11:11 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Andres Freund and...@anarazel.de writes:
I, by now, have come to a different conclusion. I think it's time to
entirely drop the renegotiation support.
Well, that's a radical proposal, but I think we should take it seriously.
On Thu, Apr 23, 2015 at 12:05 PM, Fabrízio de Royes Mello
fabriziome...@gmail.com wrote:
On Wed, Apr 22, 2015 at 3:48 PM, Payal Singh pa...@omniti.com wrote:
The following review has been posted through the commitfest application:
make installcheck-world: tested, failed
Implements
On 2015-06-24 12:57:03 -0400, Robert Haas wrote:
On Wed, Jun 24, 2015 at 11:11 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Andres Freund and...@anarazel.de writes:
I, by now, have come to a different conclusion. I think it's time to
entirely drop the renegotiation support.
Well, that's a
On Wed, Jun 24, 2015 at 11:37 AM, Peter Eisentraut pete...@gmx.net wrote:
On 6/12/15 9:31 AM, Robert Haas wrote:
Could we update our git hook to refuse a push of a new commit whose
timestamp is more than, say, 24 hours in the past? Our commit history
has some timestamps in it now that are
On 24 June 2015 at 16:30, Simon Riggs si...@2ndquadrant.com wrote:
Though TED sounds nice, the way to avoid another round of on-disk bugs is
by using a new kind of testing, not simply by moving the bits around.
It might be argued that we are increasing the diagnostic/forensic
capabilities
On 6/24/15 3:13 PM, Andres Freund wrote:
Meh. The relevant branches already exist, as you can disable it today.
We could also just change the default in the back branches.
One more argument for leaving everything alone. If users don't like it,
they can turn it off themselves.
--
Sent via
On 2015-06-24 15:41:22 -0400, Peter Eisentraut wrote:
On 6/24/15 3:13 PM, Andres Freund wrote:
Meh. The relevant branches already exist, as you can disable it today.
We could also just change the default in the back branches.
One more argument for leaving everything alone. If users
On 6/24/15 12:55 PM, Robert Haas wrote:
FWIW, I have been doing that, and I have not considered it a problem.
If the patch was submitted three months ago, reviewed, and then
committed unchanged, the date is what it is. Also, when I cherry-pick a
commit from master to a back branch, I keep the
On 24 June 2015 at 19:18, Josh Berkus j...@agliodbs.com wrote:
On 06/24/2015 10:15 AM, Joel Jacobson wrote:
You are most welcome to contact me at j...@trustly.com or by replying
to this thread, if you have any suggestions on how to improve this
bug bounty program, or if you have any other
On 6/24/15 12:26 PM, Tom Lane wrote:
Andres Freund and...@anarazel.de writes:
On 2015-06-24 11:57:53 -0400, Peter Eisentraut wrote:
If Red Hat fixes their bug, then PostgreSQL doesn't have any actual
problem anymore, does it?
It does, there are numerous bugs around renegotiation that exist
The transforms patch seems to have forgotten to add
TransformRelationId to object_classes[], much like the RLS patch
forgot to add PolicyRelationId in the same place.
Fixing this is easy, but ISTM that we need to insert some sort of a
guard to prevent people from continuing to forget this,
On June 24, 2015 9:07:35 PM GMT+02:00, Peter Eisentraut pete...@gmx.net wrote:
On 6/24/15 12:26 PM, Tom Lane wrote:
Andres Freund and...@anarazel.de writes:
On 2015-06-24 11:57:53 -0400, Peter Eisentraut wrote:
If Red Hat fixes their bug, then PostgreSQL doesn't have any actual
problem
On Wed, Jun 24, 2015 at 12:06 PM, Simon Riggs si...@2ndquadrant.com wrote:
Thanks Joel, good idea.
Any scheme that offers incentives for doing the unglamorous work of
writing a corruption test suite for PostgreSQL is good news, IMV. That
seems to be the idea here. I just hope that someone
On Wed, Jun 24, 2015 at 2:03 PM, Jeff Janes jeff.ja...@gmail.com wrote:
On Sat, Jun 20, 2015 at 7:20 AM, Robert Haas robertmh...@gmail.com wrote:
On Sat, Jun 20, 2015 at 10:12 AM, Joel Jacobson j...@trustly.com wrote:
Is there any chance the project would accept a patch which adds the
Is there a way to implement triConsistent for only some of the strategy
numbers?
It looks like I would have to internally re-implement something like
shimTriConsistentFn for each strategy number for which I don't want to
implement the ternary system in full. Am I missing a trick?
Thanks,
Jeff
On 06/21/2015 01:37 PM, Fabien COELHO wrote:
The worst case with pgbench is that we break two people's test scripts,
they read the release notes, and fix them.
Sure, I agree that breaking pgbench custom scripts compatibility is no
big deal, and having pgbench consistent with psql is
72 matches
Mail list logo
