Hi KaiGai-san,
I'd like to work on this issue with you!
On 2015/06/25 10:48, Kouhei Kaigai wrote:
I'd like to suggest a solution that re-construct remote tuple according
to the fdw_scan_tlist on ExecScanFetch, if given scanrelid == 0.
It enables to run local qualifier associated with the Foreig
On Thu, Jun 25, 2015 at 12:15 PM, Michael Paquier
wrote:
> On Wed, Jun 24, 2015 at 11:30 PM, Fujii Masao wrote:
>> On Fri, May 15, 2015 at 9:18 PM, Michael Paquier
>> wrote:
>>> On Fri, May 15, 2015 at 8:55 PM, Beena Emerson
>>> wrote:
There was a discussion on support for N synchronous s
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 work
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 4b960b29446c01ca2f1a44f
On Wed, Jun 24, 2015 at 10:03:50AM -0400, Robert Haas wrote:
> On Tue, Jun 23, 2015 at 10:15 PM, Noah Misch 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
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
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:
>
> http://www.postgresql.org/docs/devel/st
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 r
On Wed, Jun 24, 2015 at 11:30 PM, Fujii Masao wrote:
> On Fri, May 15, 2015 at 9:18 PM, Michael Paquier
> wrote:
>> On Fri, May 15, 2015 at 8:55 PM, Beena Emerson
>> wrote:
>>> There was a discussion on support for N synchronous standby servers started
>>> by Michael. Refer
>>> http://archives.
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
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.df7c
On Wed, Jun 24, 2015 at 9:50 AM, Fabien COELHO 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 +- 9
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 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 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 sc
Robert Haas writes:
> On Wed, Jun 24, 2015 at 3:49 PM, Andres Freund 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 obvious to get there from "SSL
On Sun, Jun 14, 2015 at 2:08 PM, Peter Geoghegan 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.
>
> Also, it's sim
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 str
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 om
On Wed, Jun 24, 2015 at 3:49 PM, Andres Freund 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 branches
On Wed, Jun 24, 2015 at 3:41 PM, 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 us
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
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 Wed, Jun 24, 2015 at 2:03 PM, Jeff Janes wrote:
> On Sat, Jun 20, 2015 at 7:20 AM, Robert Haas wrote:
>>
>> On Sat, Jun 20, 2015 at 10:12 AM, Joel Jacobson wrote:
>> > Is there any chance the project would accept a patch which adds the
>> > pg_stat_*_columns-feature without first optimizing t
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 k
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 u
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 v
On Wed, Jun 24, 2015 at 12:06 PM, Simon Riggs 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 doesn't end up
incentivized
On June 24, 2015 9:07:35 PM GMT+02:00, Peter Eisentraut wrote:
>On 6/24/15 12:26 PM, Tom Lane wrote:
>> Andres Freund 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?
>>
>>> I
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, because
On 6/24/15 12:26 PM, Tom Lane wrote:
> Andres Freund 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
>>
On 24 June 2015 at 19:18, 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
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 Support
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
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
http://www.postgresql.org/m
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
On Wed, Jun 24, 2015 at 11:02 AM, Peter Geoghegan 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.
--
Peter Geoghega
On Sat, Jun 20, 2015 at 7:20 AM, Robert Haas wrote:
> On Sat, Jun 20, 2015 at 10:12 AM, Joel Jacobson 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 it. It's such a pain point alrea
On Wed, Jun 24, 2015 at 7:05 AM, Fujii Masao 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 idea?
> Or we should ju
On Mon, Jun 15, 2015 at 7:47 PM, Jim Nasby 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 mainly when readi
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 2015-06-24 12:57:03 -0400, Robert Haas wrote:
> On Wed, Jun 24, 2015 at 11:11 AM, Tom Lane wrote:
> > Andres Freund 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 thi
On Wed, Jun 24, 2015 at 7:38 AM, Robert Haas 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 did discuss whethe
Dear hackers,
The text below has also been published at:
https://trustly.com/en/postgresql-bug-bounty/
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 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 wrote:
> >
> > The following review has been posted through the commitfest application:
> > make installcheck-world: tested, failed
> > Implements feature
On Wed, Jun 24, 2015 at 8:42 AM, Andres Freund 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.
#warning isn't totall
On 24 June 2015 at 16:30, Simon Riggs 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 by making CIDs mor
On Wed, Jun 24, 2015 at 11:11 AM, Tom Lane wrote:
> Andres Freund 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 agre
On Wed, Jun 24, 2015 at 11:37 AM, Peter Eisentraut 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 over a month
On Wed, Jun 24, 2015 at 11:30 AM, Simon Riggs 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 done, and I think prett
On Jun 24, 2015 5:13 PM, "Tom Lane" wrote:
>
> Andres Freund 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.
>
Yes.
Just on my phone right
Andres Freund 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. More in the ol
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
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
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 co
On 24 June 2015 at 14:57, Robert Haas wrote:
> On Fri, Jun 5, 2015 at 10:46 AM, Robert Haas
> 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
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
Andres Freund 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 the
trouble. And
Tom Lane wrote:
> Alvaro Herrera writes:
> >> On Tue, Jun 23, 2015 at 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. Spe
On 2015-06-24 10:38:38 -0400, Robert Haas wrote:
> On Wed, Jun 24, 2015 at 10:29 AM, Andres Freund 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
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
On Wed, Jun 24, 2015 at 10:29 AM, Andres Freund 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 with an err
On Fri, May 15, 2015 at 9:18 PM, Michael Paquier
wrote:
> On Fri, May 15, 2015 at 8:55 PM, Beena Emerson
> wrote:
>> There was a discussion on support for N synchronous standby servers started
>> by Michael. Refer
>> http://archives.postgresql.org/message-id/cab7npqr9c84ig0zuvhmqamq53vqsd4rc82vy
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 inevita
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"
DETAI
On Tue, Jun 23, 2015 at 10:15 PM, Noah Misch 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, but let's
> che
On Fri, Jun 5, 2015 at 10:46 AM, Robert Haas 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 extended that definiti
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
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 whi
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 TA
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 P
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 wh
On 2015-06-23 21:08:36 -0400, Robert Haas wrote:
> On Tue, Jun 23, 2015 at 5:48 PM, Kevin Grittner wrote:
> > Andres Freund wrote:
> >>>
> >>>
> >>>Improve concurrent locking and buffer scan performance (Andres
> >>>Freund, Kevin Grittner)
> >>>
> >>>
> >
On Wed, Jun 24, 2015 at 1:45 AM, Craig Ringer wrote:
> WARNING: hash indexes are not crash-safe, not replicated, and their
> use is discouraged
+1
--
Peter Geoghegan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgr
On 18 October 2014 at 02:36, Bruce Momjian wrote:
> On Fri, Oct 17, 2014 at 12:56:52PM -0400, Tom Lane wrote:
>> David G Johnston writes:
>> > The question is whether we explain the implications of not being WAL-logged
>> > in an error message or simply state the fact and let the documentation
>>
On 2015-06-23 16:32:54 -0400, Robert Haas wrote:
> On Tue, Jun 23, 2015 at 3:47 PM, Andres Freund 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 it. The obv
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 b/src/backend/comma
77 matches
Mail list logo
