> Robert Haas writes:
> > On Tue, Mar 17, 2015 at 10:11 AM, Kouhei Kaigai
> > wrote:
> >> It might be an idea if foreign-scan path is not wiped out regardless of the
> >> estimated cost, we will be able to construct an entirely remote-join path
> >> even if intermediation path is expensive than
On Tuesday, March 17, 2015, Воронин Дмитрий
wrote:
> > Make sure to show your full command(s) and the full, exact text of any
> errors.
>
> OK, I use PostgreSQL version 9.4.1.
>
> I create cluster 'main' and connect to it. After cluster init we have
> those shemas:
>
> postgres=# SELECT nspname
On Tue, Mar 17, 2015 at 7:54 PM, Robert Haas wrote:
>
> On Tue, Mar 17, 2015 at 1:42 AM, Amit Kapila
wrote:
> > The problem occurs in second loop inside DestroyParallelContext()
> > where it calls WaitForBackgroundWorkerShutdown(). Basically
> > WaitForBackgroundWorkerShutdown() just checks for
Álvaro,
I think, there are few open questions here and thus marking it back to "Waiting
on Author".
Please have your views on the review comments already posted.
Also make changes as Tom suggested about placing pstate at the beginning.
I am more concerned about this:
1.
postgres=# create or re
On 18 March 2015 at 03:01, Jim Nasby wrote:
> On 3/16/15 11:47 AM, Robert Haas wrote:
>>
>> I am sure there are more sophisticated things to be done here, but I
>> guess my feeling is that time is a good way to go here for a first cut
>> - lots of people have suggested it, and there's clearly a us
> Make sure to show your full command(s) and the full, exact text of any
> errors.
OK, I use PostgreSQL version 9.4.1.
I create cluster 'main' and connect to it. After cluster init we have those
shemas:
postgres=# SELECT nspname FROM pg_namespace ;
nspname
p
On Wed, Mar 11, 2015 at 3:04 PM, Michael Paquier wrote:
> On Wed, Mar 11, 2015 at 2:47 PM, Noah Misch wrote:
>> On Sun, Mar 08, 2015 at 08:19:39PM +0900, Michael Paquier wrote:
>>> So I am planning to seriously focus soon on this stuff, basically
>>> using the TAP tests as base infrastructure for
On Mon, Mar 16, 2015 at 6:22 AM, Petr Jelinek wrote:
>> Do you think it is ready for committer?
>>
>
> In my opinion, yes.
If it wasn't for the autoconf parts of this, I'd probably agree with
you. I need to go over that more carefully.
--
Peter Geoghegan
--
Sent via pgsql-hackers mailing li
On Tue, Mar 17, 2015 at 8:01 PM, Bruce Momjian wrote:
> On Tue, Mar 17, 2015 at 04:21:16PM -0700, Peter Geoghegan wrote:
>> I, as a non-committer, have proposed that the rules be bent once or
>> twice in the past, and those suggestions were rejected without
>> exception, even though I imagined tha
On Sat, Mar 14, 2015 at 8:39 AM, Tomas Vondra
wrote:
> Hi there,
>
> with gcc 4.8.3, I'm getting this warning in xloginsert.c:
Thanks for the report! I fixed this problem at the commit cd6c45c.
Regards,
--
Fujii Masao
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To
On 3/16/15 11:47 AM, Robert Haas wrote:
I am sure there are more sophisticated things to be done here, but I
guess my feeling is that time is a good way to go here for a first cut
- lots of people have suggested it, and there's clearly a use case for
it. If the setting turns out to be popular, w
On 3/17/15 8:06 PM, Alvaro Herrera wrote:
My main question regarding this patch is whether the behavior with MD
arrays is useful at all. Suppose I give it this:
alvherre=# select array_offset('{{{1,2},{3,4},{5,6}},{{2,3},{4,5},{6,7}}}', 3);
array_offset
--
3
(1 fila)
On Wed, Mar 18, 2015 at 10:51 AM, Alvaro Herrera
wrote:
> Michael Paquier wrote:
>> On Wed, Mar 18, 2015 at 2:22 AM, Alvaro Herrera wrote:
>
>> > 1. ordered the argument list to vacuum(), hopefully it's more sensible
>> > now.
>>
>> Fine for me.
>
> Actually, why don't we move va_cols to VacuumPar
Michael Paquier wrote:
> On Wed, Mar 18, 2015 at 2:22 AM, Alvaro Herrera wrote:
> > 1. ordered the argument list to vacuum(), hopefully it's more sensible
> > now.
>
> Fine for me.
Actually, why don't we move va_cols to VacuumParams too?
--
Álvaro Herrerahttp://www.2ndQuadrant.
My main question regarding this patch is whether the behavior with MD
arrays is useful at all. Suppose I give it this:
alvherre=# select array_offset('{{{1,2},{3,4},{5,6}},{{2,3},{4,5},{6,7}}}', 3);
array_offset
--
3
(1 fila)
What can I do with the "3" value it returned
On Wed, Mar 18, 2015 at 2:22 AM, Alvaro Herrera wrote:
> Here's an updated patch. I took your latest version and made some extra
> changes:
Thanks for taking the time to look at it!
> 1. ordered the argument list to vacuum(), hopefully it's more sensible
> now.
Fine for me.
> 2. changed struct
On Tue, Mar 17, 2015 at 04:21:16PM -0700, Peter Geoghegan wrote:
> I, as a non-committer, have proposed that the rules be bent once or
> twice in the past, and those suggestions were rejected without
> exception, even though I imagined that there was a compelling
> cost/benefit ratio. I thought tha
On Wed, Mar 18, 2015 at 3:13 AM, Alvaro Herrera
wrote:
> Michael Paquier wrote:
>
>> So I have recoded the patch to use an hash of arrays (makes the code
>> more readable IMO) to be able to track more easily what to install
>> where, and process now does the following for shared libraries:
>> - In
On Mon, Mar 16, 2015 at 8:10 AM, Dean Rasheed wrote:
> (Note there is some bitrot in gram.y that prevents the first patch
> from applying cleanly to HEAD)
That's trivially fixable. I'll have those fixes in the next revision,
once I firm some things up with Heikki.
> I tested using the attached s
On Tue, Mar 17, 2015 at 3:50 PM, Robert Haas wrote:
>> In any case, I reject the notion that the CF process has anything to
>> do with that decision. The point of the CF submission deadline is
>> that we promise to consider every submission made before the deadline.
>> It is not to forbid committ
On Tue, Mar 17, 2015 at 5:28 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Tue, Mar 17, 2015 at 1:28 PM, Tom Lane wrote:
>>> We do have a process in which even committers have to think twice about
>>> whether it's appropriate to push something, but that's feature freeze
>>> during alpha/beta/R
On Tue, Mar 17, 2015 at 12:11 PM, Heikki Linnakangas wrote:
> I'm still not sure the way the speculative locking works is the best
> approach. Instead of clearing xmin on super-deletion, a new flag on the heap
> tuple seems more straightforward. And we could put the speculative insertion
> token i
Robert Haas writes:
> On Tue, Mar 17, 2015 at 1:28 PM, Tom Lane wrote:
>> We do have a process in which even committers have to think twice about
>> whether it's appropriate to push something, but that's feature freeze
>> during alpha/beta/RC testing, and we are still a long way away from that
>>
Hello Peter,
> > 1. As I did some research on this project, I found *date_trunc()
> > supporting intervals *was suggested last year but not selected as a
> > GSoC project. Is it being floated this year too(as mentioned on the GSoC
> > 2015 wiki page of Postgres)? If yes, what are the exact expect
On 3/17/15 10:26 AM, hitesh ramani wrote:
> 1. As I did some research on this project, I found *date_trunc()
> supporting intervals *was suggested last year but not selected as a
> GSoC project. Is it being floated this year too(as mentioned on the GSoC
> 2015 wiki page of Postgres)? If yes, what
On Tue, Mar 17, 2015 at 1:06 PM, Bruce Momjian wrote:
> I think we would need to create a team to learn the Greenplum code and
> move over what is reasonable. My guess is there is no desire in our
> community to totally merge or maintain the Greenplum code --- of course,
> that is just a guess.
On Tue, Mar 17, 2015 at 02:09:34PM +0800, Craig Ringer wrote:
> It's a valid approach, but it's one that means it's unlikely to be practical
> to
> just cherry-pick a few features. There's sure to be a lot of divergence
> between
> the codebases, and no doubt Greenplum will have implemented infra
On 3/17/15 12:51 PM, Tom Lane wrote:
> Peter Eisentraut writes:
>> It looks like ar isn't even the preferred method to build static
>> libraries on OS X anymore. Instead, one should use libtool (not GNU
>> libtool), which has a -no_warning_for_no_symbols option.
>
> I looked into this a little b
Alvaro Herrera writes:
> Agreed; the attached patch does it that way. (I notice that we have the
> pstate as first arg in many places; I put at the end for
> make_oper_cache_key, together with location. Is there some convention
> to have it as first arg?)
Yes, parser-related functions always ha
On Thu, Mar 5, 2015 at 3:44 PM, Peter Geoghegan wrote:
> Bruce Momjian kindly made available a server for stress-testing [1].
> I'm using jjanes_upsert for this task (I stopped doing this for a
> little while, and was in need of a new server).
BTW, this was run for about another week on Bruce's s
Well, when a database is first initdb'd that relation is in fact 0 bytes:
::***# select pg_relation_filenode(oid) from pg_class where relname =
'pg_auth_members';
┌──┐
│ pg_relation_filenode │
├──┤
│12610 │
└──┘
(1 row)
$
On 03/05/2015 03:18 AM, Peter Geoghegan wrote:
Attached patch series forms what I'm calling V3.0 of the INSERT ... ON
CONFLICT IGNORE/UPDATE feature. (Sorry about all the threads. I feel
this development justifies a new thread, though.)
I'm still not sure the way the speculative locking works i
In the interest of moving forward, I have updated this patch because
Ryan has been inactive for over a month now.
Tom Lane wrote:
> Yeah, setup_parser_errposition_callback would work too. I'm not sure
> offhand which I like better. One thing to keep in mind is that the
> callback approach resul
Hello, all.
We can create temp namespaces and temp objects that contains it. So, for
example, temp table will be create at pg_temp_N (N - backendID). But afrer
cluster init we have pg_temp_1 and pg_toast_temp_1 namespaces with OIDs 11333
and 11334. Those namespaces are visible from any cluster
>
> The attached patch fixes the policy module of regression test.
> However, I also think we may stop to rely permission set of pre-defined
> selinux domains. Instead of pre-defined one, sepgsql-regtest.te may be
> ought to define own domain with appropriate permission set independent
> from the b
On Tue, Mar 17, 2015 at 6:31 PM, Stephen Frost wrote:
> * Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
> > I went to change this patch status in the commitfest app, and the app
> > told me I cannot change the status in the current commitfest. Please
> > somebody with commitfest mace superpow
Michael Paquier wrote:
> So I have recoded the patch to use an hash of arrays (makes the code
> more readable IMO) to be able to track more easily what to install
> where, and process now does the following for shared libraries:
> - In lib/, install all .dll and .lib
> - In bin/, install all .dll
On 03/17/2015 10:35 AM, Peter Geoghegan wrote:
> I'm still going to get a back trace here, because it seems reasonable
> to suppose that there is a Postgres bug even still - it may be that
> whatever differences are in the 14.04 kernel are enough to make a
> previously latent bug trip this code up.
On Tue, Mar 17, 2015 at 1:28 PM, Tom Lane wrote:
> Robert Haas writes:
>> What I was complaining about is new feature patches for 9.5 arriving
>> after the start of the last CF. There has to be some date after which
>> a patch is too late to be considered for a given release, or we will
>> never
On Thu, Mar 12, 2015 at 5:56 PM, Andres Freund wrote:
>> > Any chance that the new nodes also use a different kernel version or
>> > such?
>>
>> They may differ, but that doesn't seem likely to be relevant, at least
>> to me.
>
> There've been some issues with seek(END) sometimes returning the wro
On Tue, Mar 17, 2015 at 01:28:21PM -0400, Tom Lane wrote:
> Or in short: yes, the rules are different for committers and non
> committers. That's one of the reasons we are slow to hand out commit
> bits.
I think one reason the rules are different for committers and
non-committers is that committe
* Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
> I went to change this patch status in the commitfest app, and the app
> told me I cannot change the status in the current commitfest. Please
> somebody with commitfest mace superpowers set it as ready for committer.
I'm afraid the issue is a bu
I went to change this patch status in the commitfest app, and the app
told me I cannot change the status in the current commitfest. Please
somebody with commitfest mace superpowers set it as ready for committer.
--
Álvaro Herrerahttp://www.2ndQuadrant.com/
PostgreSQL Development,
* Bruce Momjian (br...@momjian.us) wrote:
> I think the larger issue is that we have to adjust to a new-normal where
> Tom isn't going to be as helpful in this area. Do we need more
> committers? Do we need to adjust the process or dates? These are
> probably the questions we should be addressin
Robert Haas writes:
> What I was complaining about is new feature patches for 9.5 arriving
> after the start of the last CF. There has to be some date after which
> a patch is too late to be considered for a given release, or we will
> never ship a release. We can argue about what that date is,
Robert Haas writes:
> On Tue, Mar 17, 2015 at 10:11 AM, Kouhei Kaigai wrote:
>> It might be an idea if foreign-scan path is not wiped out regardless of the
>> estimated cost, we will be able to construct an entirely remote-join path
>> even if intermediation path is expensive than local join.
>>
Bruce Momjian wrote:
>
> Are there any use-cases for pg_dump to use CURRENT/SESSION_USER in its
> output, so that restores will not be hard-coded to the dump user? I
> didn't see any cases of that, but wanted to ask.
Good question. I don't know, probably not.
If we ever implement something lik
Are there any use-cases for pg_dump to use CURRENT/SESSION_USER in its
output, so that restores will not be hard-coded to the dump user? I
didn't see any cases of that, but wanted to ask.
pg_dump doesn't have to restore into old clusters so there isn't a
problem with backward compatibility.
---
On Tue, Mar 17, 2015 at 12:47 PM, Bruce Momjian wrote:
> Sorry to be coming late to this thread. I don't think the problem is
> that Tom is working on these patches. Rather, I think since Tom's
> employer now cares more about his current work, Tom just isn't as
> available to help with commitfes
On Tue, Mar 17, 2015 at 01:03:03PM -0400, Tom Lane wrote:
> Bruce Momjian writes:
> > I think one valid criticism is that Tom should transition his
> > commitments to this new-normal, especially for the the Grouping Set
> > patch, rather than allowing things to dangle in an unknown state.
>
> We
Bruce Momjian writes:
> I think one valid criticism is that Tom should transition his
> commitments to this new-normal, especially for the the Grouping Set
> patch, rather than allowing things to dangle in an unknown state.
Well, as far as that goes, I had every intention of getting to the
GROUP
On Mon, Mar 9, 2015 at 03:06:24PM -0400, Robert Haas wrote:
> On Mon, Mar 9, 2015 at 2:33 PM, Tom Lane wrote:
> > As far as that goes, it has never been the case that we expected every
> > patch to go through the commitfest review process. (If we did, our
> > response time to bugs would be proba
Peter Eisentraut writes:
> It looks like ar isn't even the preferred method to build static
> libraries on OS X anymore. Instead, one should use libtool (not GNU
> libtool), which has a -no_warning_for_no_symbols option.
I looked into this a little bit, but that option seems to be a somewhat
rec
Hello,
I agree, but I think it is due to the multi process thread emulation: if you
have real threads, you can do a simple fprintf, possibly with some mutex,
and you're done. There is really nothing to do to implement this
feature.
I think that's probably not a good idea, because fprintf() mi
On Tue, Mar 17, 2015 at 11:27 AM, Fabien COELHO wrote:
> The fprintf we are talking about occurs at most once per pgbench
> transaction, possibly much less when aggregation is activated, and this
> transaction involves networks exchanges and possibly disk writes on the
> server.
random() was occu
On Mon, Mar 16, 2015 at 9:51 PM, Peter Eisentraut wrote:
>> 4. Why guc-use-transforms? Is there some possible negative side effect
>> of transformations, so we have to disable it? If somebody don't would to
>> use some transformations, then he should not to install some specific
>> transformation.
Robert Haas writes:
> For some reason, I didn't get Tom's email, only this reply.
>> On 2015/03/17 5:18, Tom Lane wrote:
>>> This would have one significant drawback, which is that planning for
>>> large inheritance trees (many children) would probably get noticeably
>>> slower. (But in the commo
On Tue, Mar 17, 2015 at 8:34 PM, Robert Haas wrote:
> On Tue, Mar 17, 2015 at 10:11 AM, Kouhei Kaigai
> wrote:
> >> A way to work around this is to leave the ForeignPaths (there can
> possibly be
> >> only one foreign path per join relation) in the joinrel without
> removing them.
> >> FDW shoul
For some reason, I didn't get Tom's email, only this reply.
On Tue, Mar 17, 2015 at 3:44 AM, Etsuro Fujita
wrote:
> On 2015/03/17 5:18, Tom Lane wrote:
>> A few days ago I posted a very-much-WIP patch for making the planner
>> dynamically combine statistics for each member of an appendrel:
>> htt
On Tue, Mar 17, 2015 at 10:11 AM, Kouhei Kaigai wrote:
>> A way to work around this is to leave the ForeignPaths (there can possibly be
>> only one foreign path per join relation) in the joinrel without removing
>> them.
>> FDW should work on joining two relations if they have foreign paths in th
Hello,
I introduced myself on the pgsql-students list but just to introduce here too,
my name is Hitesh Ramani, I'm a student of Hyderabad Central University,
Hyderabad, India. Currently I'm pursuing a project in PostgreSQL as my Post
Graduation project hence I've hacked into the Postgres code a
On Tue, Mar 17, 2015 at 1:42 AM, Amit Kapila wrote:
> The problem occurs in second loop inside DestroyParallelContext()
> where it calls WaitForBackgroundWorkerShutdown(). Basically
> WaitForBackgroundWorkerShutdown() just checks for BGWH_STOPPED
> status, refer below code in parallel-mode patch:
On Tue, Mar 10, 2015 at 04:10:01PM -0400, Peter Eisentraut wrote:
> On 3/10/15 1:12 PM, Tom Lane wrote:
> > Robert Haas writes:
> >> On Tue, Mar 10, 2015 at 12:45 PM, David G. Johnston
> >> wrote:
> >>> I would vote for Auto meaning On in the .0 release.
> >
> >> I don't think users will appreci
> On Sat, Mar 14, 2015 at 3:48 AM, Robert Haas wrote:
>
>
> On Fri, Mar 13, 2015 at 2:31 PM, Tom Lane wrote:
> > Robert Haas writes:
> >> Another bit of this that I think we could commit without fretting
> >> about it too much is the code adding set_join_pathlist_hook.
Jackson Isaac writes:
> I was looking at the proposal ideas at
> https://wiki.postgresql.org/wiki/GSoC_2015 and was very much
> interested in the idea 'PL/PgSQL x++; x+= 2; operators'.
Hm. I don't think that idea has been discussed on-list at all (or maybe
it has but I missed it). I'm not too e
On Sun, Mar 15, 2015 at 3:35 PM, Fabien COELHO wrote:
>> Firstly, the fact that pgbench produces one file per thread is awkward.
>
> I agree, but I think it is due to the multi process thread emulation: if you
> have real threads, you can do a simple fprintf, possibly with some mutex,
> and you're
On Tue, Mar 17, 2015 at 2:26 AM, Noah Misch wrote:
> Neither that rule, nor its variant downthread, would hurt operator authors too
> much. To make the planner categorically parallel-safe, though, means limiting
> evaluate_function() to parallel-safe functions. That would dramatically slow
> sel
On Tue, Mar 17, 2015 at 1:33 AM, Amit Khandekar wrote:
> When the postmaster recovers from a backend or worker crash, it resets bg
> worker's crash time (rw->rw_crashed_at) so that the bgworker will
> immediately restart (ResetBackgroundWorkerCrashTimes).
>
> But resetting rw->rw_crashed_at to 0 m
Hi,
I am Jackson Isaac pursuing 3rd Year B.Tech Computer Science and
Engineering at Amrita Vishwa Vidyapeetham, India.
I was looking at the proposal ideas at
https://wiki.postgresql.org/wiki/GSoC_2015 and was very much
interested in the idea 'PL/PgSQL x++; x+= 2; operators'.
I have been using po
On Tue, Mar 17, 2015 at 10:28 AM, Shigeru Hanada
wrote:
> 2015-03-14 7:18 GMT+09:00 Robert Haas :
> > I think the foreign data wrapper join pushdown case, which also aims
> > to substitute a scan for a join, is interesting to think about, even
> > though it's likely to be handled by a new FDW met
On Sat, Mar 14, 2015 at 3:48 AM, Robert Haas wrote:
> On Fri, Mar 13, 2015 at 2:31 PM, Tom Lane wrote:
> > Robert Haas writes:
> >> Another bit of this that I think we could commit without fretting
> >> about it too much is the code adding set_join_pathlist_hook. This is
> >> - I think - analo
On 15/03/2015 20:27, Julien Tachoires wrote:
> On 15/03/2015 04:34, Andreas Karlsson wrote:
>> On 03/15/2015 04:25 AM, Andreas Karlsson wrote:
>>> Nice. You will also want to apply the attached patch which fixes support
>>> for the --no-tablespaces flag.
>>
>> Just realized that --no-tablespaces ne
On 2015/03/17 5:18, Tom Lane wrote:
> A few days ago I posted a very-much-WIP patch for making the planner
> dynamically combine statistics for each member of an appendrel:
> http://www.postgresql.org/message-id/22598.1425686...@sss.pgh.pa.us
>
> That patch was only intended to handle the case of
On 2015/03/14 7:18, Robert Haas wrote:
I think the foreign data wrapper join pushdown case, which also aims
to substitute a scan for a join, is interesting to think about, even
though it's likely to be handled by a new FDW method instead of via
the hook. Where should the FDW method get called fr
74 matches
Mail list logo
