On Sat, Oct 17, 2015 at 12:06 PM, Noah Misch wrote:
>
> On Sat, Oct 17, 2015 at 11:00:57AM +0530, Amit Kapila wrote:
> > On Sat, Oct 17, 2015 at 6:15 AM, Noah Misch wrote:
> > > On Thu, Oct 15, 2015 at 04:30:01PM +0530, Amit Kapila wrote:
> > > > On Mon, Oct 12, 2015 at 9:16 PM, Robert Haas
wrot
On Sat, Oct 17, 2015 at 11:00:57AM +0530, Amit Kapila wrote:
> On Sat, Oct 17, 2015 at 6:15 AM, Noah Misch wrote:
> > On Thu, Oct 15, 2015 at 04:30:01PM +0530, Amit Kapila wrote:
> > > On Mon, Oct 12, 2015 at 9:16 PM, Robert Haas
> > > wrote:
> > > > plpgsql_param_fetch() assumes that it can det
On Sat, Oct 17, 2015 at 11:45 AM, Amit Kapila
wrote:
>
> Agreed and on looking at code, I think in below code, if we pass
> parallelOK as true for the cases where Portal is non-null, such a
> problem could happen.
>
>
> static int
>
> exec_run_select(PLpgSQL_execstate *estate,
>
> PLpgSQL_expr *ex
On Sat, Oct 17, 2015 at 2:41 AM, Robert Haas wrote:
>
> On Fri, Oct 16, 2015 at 2:29 AM, Amit Kapila
wrote:
> >> Yeah, but I think the scenario is legitimate. When a query gets run
> >> from within PL/pgsql, parallelism is an option, at least as we have
> >> the code today. So if a Gather were
On Sat, Oct 17, 2015 at 6:15 AM, Noah Misch wrote:
>
> On Thu, Oct 15, 2015 at 04:30:01PM +0530, Amit Kapila wrote:
> > On Mon, Oct 12, 2015 at 9:16 PM, Robert Haas
wrote:
> > > plpgsql_param_fetch() assumes that it can detect whether it's being
> > > called from copyParamList() by checking wheth
On Fri, Oct 16, 2015 at 3:34 PM, Rajeev rastogi
wrote:
>
>
> Yes it will be really helpful to know the earlier reason for "not making
> backend exit on postmaster death".
> Please let me know if there is any thread, which I can refer to find the
> same.
>
> IMHO there could be below major issues,
On Fri, Oct 16, 2015 at 9:51 PM, Tom Lane wrote:
> Robert Haas writes:
>> Both you and Etsuro Fujita are proposing to fix this problem by
>> somehow making it the FDW's problem to reconstruct the tuple
>> previously produced by the join from whole-row images of the baserels.
>> But that's not loo
* Craig Ringer (cr...@2ndquadrant.com) wrote:
> On 16 October 2015 at 21:34, Stephen Frost wrote:
> >> It's a different auth request, but the handling in be-auth.c is
> >> co-mingled to handle the cases:
> >
> > be-auth.c? You mean src/backend/libpq/auth.c?
>
> Ahem. Yes.
No worries. :)
> Also
I wrote:
> This seems like a very Rube-Goldbergian way of setting up a local
> namespace for the user-defined code. I think perhaps what we should do
> is:
> 1. Compile the user-supplied code directly into a code object, without
> wrapping it in a "def". (Hence, PLy_procedure_munge_source goes a
Robert Haas writes:
> Both you and Etsuro Fujita are proposing to fix this problem by
> somehow making it the FDW's problem to reconstruct the tuple
> previously produced by the join from whole-row images of the baserels.
> But that's not looking back far enough: why are we asking for
> whole-row
On Fri, Oct 16, 2015 at 7:48 PM, Kouhei Kaigai wrote:
> My opinion is, simply, ForeignScan/CustomScan with scanrelid==0 takes
> over the responsibility of EPQ recheck of entire join sub-tree that is
> replaced by the ForeignScan/CustomScan node.
> If ForeignScan run a remote join on foreign tables
On Fri, Oct 16, 2015 at 6:12 PM, Kouhei Kaigai wrote:
> I think, it is right approach to pretend EPQ doesn't exist if scanrelid==0,
> because what replaced by these ForeignScan/CustomScan node are local join
> node like NestLoop. They don't have its own EPQ slot, but constructs joined-
> tuple bas
On Thu, Oct 15, 2015 at 04:30:01PM +0530, Amit Kapila wrote:
> On Mon, Oct 12, 2015 at 9:16 PM, Robert Haas wrote:
> > plpgsql_param_fetch() assumes that it can detect whether it's being
> > called from copyParamList() by checking whether params !=
> > estate->paramLI. I don't know why this works
I've occasionally heard complaints that our regex engine only has
lookahead constraints not lookbehind constraints, while Perl's for example
does have those. While I was fooling around with the other issues in that
code, I learned enough to realize that it would not be that hard to
implement such
> Kouhei Kaigai writes:
> >> On Fri, Oct 16, 2015 at 5:00 AM, Etsuro Fujita
> >> wrote:
> >> I don't see how this can be right. You're basically just pretending
> >> EPQ doesn't exist in the remote join case, which isn't going to work
> >> at all. Those bits of code that look at es_epqTuple, es
On Sat, Oct 17, 2015 at 5:15 AM, Nikolay Shaplov
wrote:
> So what's next?
Wait and see a bit.
> We need something else to discuss?
> We need somebody else's opinion to rule this out?
The spec of the patch looks clear to me.
> Or it's ready to commit, and just not marked this way?
No, I don't
On Sat, Oct 17, 2015 at 3:21 AM, Robert Haas wrote:
> OK, committed his, and yours.
>
> I back-patched his spin.h comment fix to 9.5 since that's a factual
> error, but the rest of this seems like optimization so I committed it
> only to master.
That sounds right. Thanks!
--
Michael
--
Sent vi
Kouhei Kaigai writes:
>> On Fri, Oct 16, 2015 at 5:00 AM, Etsuro Fujita
>> wrote:
>> I don't see how this can be right. You're basically just pretending
>> EPQ doesn't exist in the remote join case, which isn't going to work
>> at all. Those bits of code that look at es_epqTuple, es_epqTupleSet
> On Fri, Oct 16, 2015 at 5:00 AM, Etsuro Fujita
> wrote:
> > As for #2, I updated the patch, which uses a local join execution plan for
> > an EvalPlanQual rechech, according to the comment from Robert [1]. Attached
> > is an updated version of the patch. This is a WIP patch, but it would be
> >
On Fri, Oct 16, 2015 at 2:29 AM, Amit Kapila wrote:
>> Yeah, but I think the scenario is legitimate. When a query gets run
>> from within PL/pgsql, parallelism is an option, at least as we have
>> the code today. So if a Gather were present, and the query used a
>> parameter, then you could have
The shm_mq code handles blocking mode and non-blocking mode
asymmetrically in a couple of places, with the unfortunate result that
if you are using non-blocking mode, and your counterparty dies before
attaching the queue, operations on the queue continue to return
SHM_MQ_WOULD_BLOCK instead of, as
I wrote:
> Anyway, the real problem here is the decision to pass procedure arguments
> by assigning them to keys in the global dict. That is just brain-dead,
> both because it means that recursive calls can't possibly work and because
> it creates the bizarre scoping behavior mentioned in
> http:/
So what's next?
We need something else to discuss?
We need somebody else's opinion to rule this out?
Or it's ready to commit, and just not marked this way?
I am going to make report based on this patch in Vienna. It would be
nice to have it committed until then :)
On 02.10.2015 07:10, Michael Paq
On Fri, Oct 16, 2015 at 2:52 PM, Peter Eisentraut wrote:
> The release notes say that checkpoint_segments has been replaced by
> max_wal_size and min_wal_size, but there is no indication on how to
> convert between the old and new settings. I think a lot of people will
> have checkpoint_segments
2015-10-16 8:12 GMT+02:00 Craig Ringer :
> On 16 October 2015 at 02:47, Pavel Stehule
> wrote:
>
> > postgres=# do $$
> > x = plpy.SPIError('Nazdarek');
> > x.spidata = (100, "Some detail", "some hint", None, None);
> > raise x;
> > $$ language plpythonu;
>
> Shouldn't that look more like
>
> ra
On 2015-10-16 16:32:25 -0300, Fabrízio de Royes Mello wrote:
> On Fri, Oct 16, 2015 at 4:12 PM, Robert Haas wrote:
> > I think this would be a useful feature. What would one do about
> > prepared transactions?
> >
>
> Isn't "rollback all prepared" before an option?
Not necessarily - what if sha
2015-10-16 21:12 GMT+02:00 Robert Haas :
> On Fri, Oct 16, 2015 at 6:22 AM, Pavel Stehule
> wrote:
> > in GoodData we have this feature implemented - little bit different
> named -
> > DROP DATABASE FORCE
> >
> > It is useful in complex environment with mix of pooled and not pooled
> > connection
On Fri, Oct 16, 2015 at 4:12 PM, Robert Haas wrote:
>
> On Fri, Oct 16, 2015 at 6:22 AM, Pavel Stehule
wrote:
> > in GoodData we have this feature implemented - little bit different
named -
> > DROP DATABASE FORCE
> >
> > It is useful in complex environment with mix of pooled and not pooled
> > c
Robert Haas wrote:
> On Thu, Oct 15, 2015 at 12:22 PM, Alvaro Herrera
> wrote:
> > Robert Haas wrote:
> >> - Oversize item computation needs more testing (c.f. ereport(ERROR)
> >> calls in brin_getinsertbuffer). This is pretty vague, and there's no
> >> thread linked. If there's a stability issu
On Thu, Oct 15, 2015 at 12:22 PM, Alvaro Herrera
wrote:
> Robert Haas wrote:
>> - Oversize item computation needs more testing (c.f. ereport(ERROR)
>> calls in brin_getinsertbuffer). This is pretty vague, and there's no
>> thread linked. If there's a stability issue here, presumably it falls
>>
On Thu, Oct 15, 2015 at 1:48 PM, Peter Geoghegan wrote:
> On Wed, Oct 14, 2015 at 3:14 AM, Andres Freund wrote:
>>> What would happen if we didn't do anything at all?
>>
>> Nothing, really. It's essentially some code beautification. A worthwhile
>> goal, but certainly not a release blocker.
>
> W
On Fri, Oct 16, 2015 at 6:22 AM, Pavel Stehule wrote:
> in GoodData we have this feature implemented - little bit different named -
> DROP DATABASE FORCE
>
> It is useful in complex environment with mix of pooled and not pooled
> connections - and in our environment - about 2K databases per server
On Fri, Oct 16, 2015 at 5:00 AM, Etsuro Fujita
wrote:
> As for #2, I updated the patch, which uses a local join execution plan for
> an EvalPlanQual rechech, according to the comment from Robert [1]. Attached
> is an updated version of the patch. This is a WIP patch, but it would be
> appreciated
The release notes say that checkpoint_segments has been replaced by
max_wal_size and min_wal_size, but there is no indication on how to
convert between the old and new settings. I think a lot of people will
have checkpoint_segments delicately tuned, so we should at least give
them a hint on how to
On Thu, Oct 15, 2015 at 11:32 PM, Amit Kapila wrote:
> Another some what related point is currently we are using random()
> function to ensure a unique name for dsm and it seems to me that
> it is always going to generate same number on first invocation (at least
> thats what happening on windows)
On Thu, Oct 15, 2015 at 10:36 PM, Michael Paquier
wrote:
> On Fri, Oct 16, 2015 at 9:07 AM, Thomas Munro
> wrote:
>> On Wed, Oct 7, 2015 at 8:52 AM, Robert Haas wrote:
>>> On Thu, Oct 1, 2015 at 11:01 PM, Michael Paquier
>>> wrote:
> Right, see attached.
It seems to me that we cou
On 10/16/2015 11:13 AM, Robert Haas wrote:
Andrew,
The FileTextArrayFDW-build failure on crake, and the RedisFDW-build
failure on sittella, are expected results of my commit
5043193b78919a1bd144563aadc2f7f726549913. If those FDWs do not push
quals down, they just need to be updated to pass an
On Thu, Oct 15, 2015 at 6:28 AM, Ashutosh Bapat
wrote:
> Attached is the patch which takes care of above comments.
I spent some time on this patch today. But it's still not right.
I've attached a new version which fixes a serious problem with your
last version - having postgresGetForeignPaths d
Update the patch_brin_optimze_mem according to your comment.
At 2015-10-16 10:13:35, "Alvaro Herrera" wrote:
>zhangjinyu wrote:
>
>> However I wonder if it would be simpler to have the dtup structure have
>> the pointers, so that you can pass it as NULL in the first call and then
On 2015-10-16 10:30:20 -0700, Joe Conway wrote:
> On 10/16/2015 09:28 AM, Andres Freund wrote:
> > Alternatively you can just have a elevate_user() function that does the
> > logging and escalating? That seems like the same amount of code and it'd
> > work with released versions of postgres?
> >
>
Joe Conway writes:
> In many environments there is a policy requiring users to login using
> unprivileged accounts, and then escalate their privileges if and when
> they require it. In PostgreSQL this could be done by granting the
> superuser role to an unprivileged user with noinherit, and then
On 10/16/2015 09:28 AM, Andres Freund wrote:
> Alternatively you can just have a elevate_user() function that does the
> logging and escalating? That seems like the same amount of code and it'd
> work with released versions of postgres?
>
> Sure, that has some disadvantages over your approach, but
>
> > > If not, the only solution I can see is for PostgreSQL to not protest
> if it
> > > sees the
> > > parameter in the startup packet.
> > >
> >
> > Yeah, that's the ideal solution here as far as I'm concerned.
>
> Well, it seems that's where we're ending up then. Could you prepare a
> patch?
>
On 2015-10-16 09:20:26 -0700, Joe Conway wrote:
> One of the problems with this is we would ideally like to know whenever
> joe escalates himself to postgres. Right now that is not really possible
> without doing untenable things such as logging every statement.
Alternatively you can just have a e
In many environments there is a policy requiring users to login using
unprivileged accounts, and then escalate their privileges if and when
they require it. In PostgreSQL this could be done by granting the
superuser role to an unprivileged user with noinherit, and then making
the superuser role nol
On Sun, Jun 7, 2015 at 11:01 PM, Peter Geoghegan wrote:
> On Sun, Jun 7, 2015 at 8:10 AM, Andreas Karlsson
> wrote:
> > Are you planning to work on this patch for 9.6?
>
> FWIW I hope so. It's a nice patch.
>
I'm trying to to whisk dust. Rebased version of patch is attached. This
patch isn't pa
On Mon, Oct 12, 2015 at 1:04 PM, Robert Haas wrote:
> Attached are 14 patches. Patches #1-#4 are
> essential for testing purposes but are not proposed for commit,
> although some of the code they contain may eventually become part of
> other patches which are proposed for commit. Patches #5-#12
Ok.
Thak you all!
:)
On Fri, Oct 16, 2015 at 5:20 PM, Robert Haas wrote:
> On Fri, Oct 16, 2015 at 10:50 AM, Euler Taveira
> wrote:
> >> I feel like we've got somebody new showing up to our community with an
> >> idea that is not obviously stupid. If we want such people to stick
> >> around, w
On Fri, Oct 16, 2015 at 12:02:03PM -0300, Alvaro Herrera wrote:
> Bruce Momjian wrote:
>
> > Are you suggesting I remove those links? It is kind of odd to have
> > links to patches for features we don't want, or just keep it?
>
> No, quite the contrary -- I think the links allow some other perso
On Fri, Oct 16, 2015 at 10:50 AM, Euler Taveira wrote:
>> I feel like we've got somebody new showing up to our community with an
>> idea that is not obviously stupid. If we want such people to stick
>> around, we should try to give their ideas a fair shake.
>>
> I share the same feeling. I wasn't
On Fri, Oct 16, 2015 at 12:00:11PM -0300, Alvaro Herrera wrote:
> Bruce Momjian wrote:
> > I have spend the past few days updating our TODO list, removing
> > completed and now-unnecessary items:
> >
> > https://wiki.postgresql.org/wiki/Todo
>
> Thanks. We have "TodoDone" pages for items tha
Andrew,
The FileTextArrayFDW-build failure on crake, and the RedisFDW-build
failure on sittella, are expected results of my commit
5043193b78919a1bd144563aadc2f7f726549913. If those FDWs do not push
quals down, they just need to be updated to pass an additional NIL
argument to make_foreignscan().
On Thu, Oct 15, 2015 at 9:13 PM, Jim Nasby wrote:
> OTOH, now that the catalog is MVCC capable, do we even still need to lock
> the objects for a schema-only dump?
Yes. The MVCC snapshots used for catalog reads are stable only for
the duration of one particular catalog read. We're not using the
On Thu, Oct 15, 2015 at 8:28 PM, Jim Nasby wrote:
> It's just how the authors of pg_repack decided to handle it. It seems pretty
> reasonable, since you probably don't want an errant DDL statement to cause
> the rollback of hours or days of pg_repack work.
>
> Ultimately, I don't think you'll find
Bruce Momjian wrote:
> Are you suggesting I remove those links? It is kind of odd to have
> links to patches for features we don't want, or just keep it?
No, quite the contrary -- I think the links allow some other person
research the issue including the history of patches and discussion, and
de
Bruce Momjian wrote:
> I have spend the past few days updating our TODO list, removing
> completed and now-unnecessary items:
>
> https://wiki.postgresql.org/wiki/Todo
Thanks. We have "TodoDone" pages for items that were done in specific
releases, but only for 8.4, 9.0 and 9.1. I guess it
On 16 October 2015 at 21:34, Stephen Frost wrote:
> * Craig Ringer (cr...@2ndquadrant.com) wrote:
>> On 16 October 2015 at 01:07, Robbie Harwood wrote:
>> > Looking at
>> > http://www.postgresql.org/docs/9.4/static/protocol-message-formats.html
>> > suggests that SSPI follows a separate codepath
On 16-10-2015 10:37, Robert Haas wrote:
- Did he implement this correctly?
>
- Would it break anything?
>
I did not review the patch.
- Are there lots of other knobs we should expose too instead of just one?
>
We are providing PAM_USER and PAM_CONV. The complete list of options are
[1]. Ma
On Fri, Oct 16, 2015 at 11:43:10AM -0300, Alvaro Herrera wrote:
> Bruce Momjian wrote:
>
> > Probably the most controvertial change was to move on-disk bitmap
> > indexes to the "not wanted" section, though I kept the links in case we
> > change our minds. I just can't see how they would be a win
Bruce Momjian wrote:
> Probably the most controvertial change was to move on-disk bitmap
> indexes to the "not wanted" section, though I kept the links in case we
> change our minds. I just can't see how they would be a win with GIN and
> in-memory bitmaps.
Yeah, I recall we discussed bitmap ind
On Fri, Oct 9, 2015 at 10:52 PM, Bruce Momjian wrote:
>
> Any news on this item from 2013, worked on again 2014?
>
> ---
>
> On Wed, Aug 6, 2014 at 12:55:59PM -0400, Bruce Momjian wrote:
>> On Fri, Nov 29, 2013 at 02:04:10AM
We will follow your instructions and get back to you.
Thank you Tom. Much appreciated!
-glenn
On Fri, Oct 16, 2015 at 7:16 AM, Tom Lane wrote:
> Glenn Zhu writes:
> > Is this categorized as a bug specific to GIN indexes or a PostgreSQL bug
> in
> > general?
>
> My gut says it's GIN-specific,
Glenn Zhu writes:
> Is this categorized as a bug specific to GIN indexes or a PostgreSQL bug in
> general?
My gut says it's GIN-specific, but that's really only an educated guess;
we have too little info.
What I would recommend is that you get the data onto a non-production
machine where you can
We can't test a non-concurrent index build in production - but your word is
just as good.
We only see this on some of production databases. We did not see it in QA
testing. But we will try to get a test case in QA.
Is this categorized as a bug specific to GIN indexes or a PostgreSQL bug in
gene
Glenn Zhu writes:
> Currently, after hitting the error, the indexes were still created but
> marked with status of "invalid"
That's just what CREATE INDEX CONCURRENTLY would do with any error.
(It might be worth checking whether a non-CONCURRENTLY build hits the
same error, though I'm betting it
On Fri, Oct 16, 2015 at 5:31 PM, Robert Haas wrote:
>
> On Fri, Oct 16, 2015 at 7:42 AM, Amit Kapila
wrote:
> > I think due to above changes it will report sync location on each page
> > scan, don't we want to report it once at end of scan?
>
> I think reporting for each page is correct. Isn't t
Robert Haas wrote:
> I think some more interesting questions are:
> - Did he implement this correctly?
> - Would it break anything?
> - Are there lots of other knobs we should expose too instead of just one?
> - What would it take to turn this into a committable patch?
> - Would the cost of exposi
Currently, after hitting the error, the indexes were still created but
marked with status of "invalid"
Looks like we shall see inserts to fail with the index on the column,
regardless of the index status ("valid" or "invalid"), if we start to
receive the "bad" values? Maybe I shall drop all these
Glenn Zhu writes:
> We are currently running 9.4.4. 9.4.5 notes have two references to gin
> index but does not seem to address the issue.
> We are however able to create same index on some other databases. So it
> maybe data related or size of table related?
I'd guess that it's triggered by a
>
> As far as I remember, that was introduced because of renegotiation bugs
> with Mono:
> http://lists.pgfoundry.org/pipermail/npgsql-devel/2010-February/001074.html
> http://fxjr.blogspot.co.at/2010/03/ssl-renegotiation-patch.html
>
> Of course, with renegotiation disabled, nobody knows whether t
On 2015-10-16 16:41:16 +0300, Shay Rojansky wrote:
> > If not, the only solution I can see is for PostgreSQL to not protest if it
> > sees the
> > parameter in the startup packet.
> >
>
> Yeah, that's the ideal solution here as far as I'm concerned.
Well, it seems that's where we're ending up the
On Fri, Oct 16, 2015 at 8:47 AM, Euler Taveira wrote:
> On 15-10-2015 05:41, kolo hhmow wrote:
>>
>> I have already explained this in my previous post. Did you read this?
>
>>
> Yes, I do.
>
>> So why postgresql give users an abbility to use a pam modules, when in
>> other side there is advice to
* Robert Haas (robertmh...@gmail.com) wrote:
> We've got a few open items remaining at
> https://wiki.postgresql.org/wiki/PostgreSQL_9.5_Open_Items - we should
> try to get rid of them. Of the 8 items there, 3 are documentation
> issues. It looks to me like one of those is for Stephen to deal wit
Hi Tom,
Thanks for the reply.
We are currently running 9.4.4. 9.4.5 notes have two references to gin
index but does not seem to address the issue.
We are however able to create same index on some other databases. So it
maybe data related or size of table related? So far, the failed cases
repo
* Craig Ringer (cr...@2ndquadrant.com) wrote:
> On 16 October 2015 at 01:07, Robbie Harwood wrote:
> > Looking at
> > http://www.postgresql.org/docs/9.4/static/protocol-message-formats.html
> > suggests that SSPI follows a separate codepath from the GSS code;
> > certainly it's a different auth re
Glenn Zhu writes:
> We are getting an error on the following statement:
> CREATE INDEX CONCURRENTLY customer_jsonb_fields_idx ON customer USING gin
> (jsonb_fields jsonb_path_ops);
> ERROR: invalid memory alloc request size 2013265920
> Anyone know what is causing it?
Sounds like a bug from he
On Fri, Oct 16, 2015 at 2:47 PM, Euler Taveira wrote:
> On 15-10-2015 05:41, kolo hhmow wrote:
>
>> I have already explained this in my previous post. Did you read this?
>>
> >
> Yes, I do.
>
> So why postgresql give users an abbility to use a pam modules, when in
>> other side there is advice to
On Fri, Oct 16, 2015 at 02:50:04PM +0530, Amit Kapila wrote:
> On Fri, Oct 16, 2015 at 8:34 AM, Bruce Momjian wrote:
>
> I have spend the past few days updating our TODO list, removing
> completed and now-unnecessary items:
>
> https://wiki.postgresql.org/wiki/Todo
>
>
>
>
We are getting an error on the following statement:
CREATE INDEX CONCURRENTLY customer_jsonb_fields_idx ON customer USING gin
(jsonb_fields jsonb_path_ops);
ERROR: invalid memory alloc request size 2013265920
Anyone know what is causing it? It does not seem to be data corruption as
when we dep
On 15-10-2015 05:41, kolo hhmow wrote:
I have already explained this in my previous post. Did you read this?
>
Yes, I do.
So why postgresql give users an abbility to use a pam modules, when in
other side there is advice to not use them?
Anyway.
>
Where is such advise? I can't see it in docs [
On Thu, Oct 15, 2015 at 11:38 PM, Haribabu Kommi
wrote:
> Some more tests that failed in similar configuration settings.
> 1. Table that is created under a begin statement is not visible in the worker.
> 2. permission problem in worker side for set role command.
The second problem, too, I have al
On Fri, Oct 16, 2015 at 7:42 AM, Amit Kapila wrote:
> I think due to above changes it will report sync location on each page
> scan, don't we want to report it once at end of scan?
I think reporting for each page is correct. Isn't that what the
non-parallel case does?
--
Robert Haas
Enterprise
On Fri, Oct 16, 2015 at 9:51 AM, Robert Haas wrote:
>
> On Mon, Oct 5, 2015 at 8:20 AM, Amit Kapila
wrote:
> > [ new patch for heapam.c changes ]
>
> I went over this in a fair amount of detail and reworked it somewhat.
> The result is attached as parallel-heapscan-revised.patch. I think
> the w
Hi
2015-10-16 12:13 GMT+02:00 Filip Rembiałkowski <
filip.rembialkow...@gmail.com>:
> DROP DATABASE mydb CONCURRENTLY;
>
> That would perform forced shutdown
>
> 1) reject any new backends to mydb
> 2) terminate old backends
> 3) drop db
>
> 40 upvotes here http://dba.stackexchange.com/a/11895/37
DROP DATABASE mydb CONCURRENTLY;
That would perform forced shutdown
1) reject any new backends to mydb
2) terminate old backends
3) drop db
40 upvotes here http://dba.stackexchange.com/a/11895/3710 inspired me
to propose this improvement.
If you think it's a good idea please include it as a low
On 14 October 2015 14:03, Kyotaro HORIGUCHI:
>Subject: Re: [HACKERS] Dangling Client Backend Process
>
>At Wed, 14 Oct 2015 11:08:37 +0530, Amit Kapila
>wrote in
>
>> On Tue, Oct 13, 2015 at 3:54 PM, Rajeev rastogi
>>
>> wrote:
>> > If we add the event WL_POSTMASTER_DEATH also, client backend pr
I briefly browsed the patch apart from my preference towards the approach.
It has at least two oversight.
*** 48,59 ExecScanFetch(ScanState *node,
+ /*
+* Execute recheck plan and get the next tuple if foreign join.
+*/
+ if (scanre
On Fri, Oct 16, 2015 at 3:10 PM, Jeevan Chalke <
jeevan.cha...@enterprisedb.com> wrote:
>
>
> On Thu, Oct 15, 2015 at 10:44 PM, Robert Haas
> wrote:
>
>> On Thu, Oct 15, 2015 at 3:04 AM, Kyotaro HORIGUCHI
>> wrote:
>> > I confirmed that an epqtuple of foreign parameterized scan is
>> > correctly
> >> On 2015/10/15 11:36, Kouhei Kaigai wrote:
> >>> In case of scanrelid==0, expectation to ForeignScan/CustomScan is to
> >>> behave as if local join exists here. It requires ForeignScan to generate
> >>> joined-tuple as a result of remote join, that may contains multiple junk
> >>> TLEs to carry
On Thu, Oct 15, 2015 at 10:44 PM, Robert Haas wrote:
> On Thu, Oct 15, 2015 at 3:04 AM, Kyotaro HORIGUCHI
> wrote:
> > I confirmed that an epqtuple of foreign parameterized scan is
> > correctly rejected by fdw_recheck_quals with modified outer
> > tuple.
> >
> > I have no objection to this and
Shay Rojansky wrote:
> Just to give some added reasoning...
>
> As Andres suggested, Npgsql sends ssl_renegotiation_limit=0 because we've
> seen renegotiation bugs with
> the standard .NET SSL implementation (which Npgsql uses). Seems like everyone
> has a difficult time
> with renegotiation.
A
On Пт, 2015-10-16 at 09:02 +0530, Amit Kapila wrote:
> On Thu, Oct 15, 2015 at 8:35 PM, Dmitry Vasilyev pro.ru> wrote:
> > I think that function dsm_impl_windows() with EACCES error should
> > not
> > do ereport() with FATAL level. It works, but it is likely to make
> > an
> > infinite loop if th
On Fri, Oct 16, 2015 at 8:34 AM, Bruce Momjian wrote:
> I have spend the past few days updating our TODO list, removing
> completed and now-unnecessary items:
>
> https://wiki.postgresql.org/wiki/Todo
>
>
Thanks. It can help encourage many new entrants to community.
With Regards,
Amit
On 2015/10/14 17:31, Etsuro Fujita wrote:
As KaiGai-san also pointed out before, I think we should address this in
each of the following cases:
1) remote qual (scanrelid>0)
2) remote join (scanrelid==0)
As for #2, I updated the patch, which uses a local join execution plan
for an EvalPlanQual
>> On 2015/10/15 11:36, Kouhei Kaigai wrote:
>>> In case of scanrelid==0, expectation to ForeignScan/CustomScan is to
>>> behave as if local join exists here. It requires ForeignScan to generate
>>> joined-tuple as a result of remote join, that may contains multiple junk
>>> TLEs to carry whole-var
2015-10-16 8:12 GMT+02:00 Craig Ringer :
> On 16 October 2015 at 02:47, Pavel Stehule
> wrote:
>
> > postgres=# do $$
> > x = plpy.SPIError('Nazdarek');
> > x.spidata = (100, "Some detail", "some hint", None, None);
> > raise x;
> > $$ language plpythonu;
>
> Shouldn't that look more like
>
> ra
On Wed, Oct 14, 2015 at 5:58 PM, Beena Emerson wrote:
>
>
> On Wed, Oct 14, 2015 at 10:38 AM, Michael Paquier
> wrote:
>>
>> On Wed, Oct 14, 2015 at 3:02 AM, Masahiko Sawada wrote:
>>
>> > It would be good even if there are some restriction such as the
>> > nesting level, the group setting.
>> >
On Fri, Oct 16, 2015 at 12:16 PM, Kyotaro HORIGUCHI <
horiguchi.kyot...@lab.ntt.co.jp> wrote:
> This is wrong, current code does well for this case. I should
> broke the code during investigating the problem.
>
> > > So, to make the windows version behave as the same,
> > > dsm_impl_windows should
98 matches
Mail list logo
