Hi Robert,
Gather node was oversight by readfunc.c, even though it shall not be
serialized actually.
Also, it used incompatible WRITE_xxx_FIELD() macro on outfuncs.c.
The attached patch fixes both of incomsistence.
Thanks,
--
NEC Business Creation Division / PG-Strom Project
KaiGai Kohei
> --
Hello, I caught up this thread, maybe.
> > So, if we wanted to fix this in a way that preserves the spirit of
> > what's there now, it seems to me that we'd want the FDW to return
> > something that's like a whole row reference, but represents the output
> > of the foreign join rather than some un
> Here's a patch.
Thank you!
With this patch, the standby server down disappears in my environment.
Regards,
Takashi Ohnishi
oonish...@nttdata.co.jp
-Original Message-
From: Alvaro Herrera [mailto:alvhe...@2ndquadrant.com]
Sent: Thursday, October 01, 2015 7:48 AM
To: Fujii Mas
So, testing:
1. I tested running an AWS instance (Ubuntu 14.04) into 100% IOWAIT, and
the shutdown didn't kick in even when storage went full "d" state. It's
possible that other kinds of remote storage failures would cause a
shutdown, but don't we want them to?
2. I tested deleting /pgdata/* sev
Matt Newell writes:
> Patch attached works great. I added the dboid to the QueueBackendStatus
> struct but that might not be needed if there is an easy and fast way to get a
> db oid from a backend pid.
Not particularly; I agree with adding it to this data structure. One
reason is it makes th
On Thu, Oct 1, 2015 at 7:57 AM, Paul Ramsey wrote:
> On September 30, 2015 at 3:32:21 PM, Michael Paquier wrote:
>
> OK. Once you can get a new patch done with a reworked
> extractExtensionList, I'll get a new look at it in a timely fashion
> and then let's move it to a committer's hands.
So, I h
> -Original Message-
> From: pgsql-hackers-ow...@postgresql.org
> [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Robert Haas
> Sent: Wednesday, September 30, 2015 6:55 AM
> To: Etsuro Fujita
> Cc: Kaigai Kouhei(海外 浩平); PostgreSQL-development; 花田茂
> Subject: Re: [HACKERS] Foreign j
On 9/30/15 4:31 PM, Josh Berkus wrote:
On 09/30/2015 12:02 AM, Jim Nasby wrote:
I wish people would at least consider this as an option because it
integrates a ton of different features together. It has *the potential*
to eliminate our need to keep maintaining CommitFest and buildfarm and
could
On Thu, Oct 1, 2015 at 7:10 AM, Tom Lane wrote:
> Christopher Browne writes:
>> It may very well be *worse* than that; it seems quite likely to me that if
>> an issue tracker is not being continually curated by substantially ALL of
>> its users, then you don't get any of those things. That *is*
On 09/30/2015 12:55 PM, Tomas Vondra wrote:
Hello!
On 09/30/2015 10:29 AM, Kyotaro HORIGUCHI wrote:
By the way your comment for indexrinfos is as following,
* 'indexrinfos' is a list of RestrictInfo nodes from the query's WHERE
* or JOIN conditions, excluding those implied by the index pre
On Wed, Sep 30, 2015 at 11:23 AM, Amit Kapila wrote:
>> - I don't believe that shm_toc *toc has any business being part of a
>> generic PlanState node. At most, it should be part of an individual
>> type of PlanState, like a GatherState or PartialSeqScanState. But
>> really, I don't see why we n
On 09/30/2015 03:49 PM, Alvaro Herrera wrote:
Josh Berkus wrote:
Well, it's hard for anyone to volunteer when we don't know what the
actual volunteer tasks are. I certainly intend to do *something* to
support the bug tracker system, but I don't know yet what that something is.
I volunteer to
On September 30, 2015 at 3:32:21 PM, Michael Paquier
(michael.paqu...@gmail.com) wrote:
OK. Once you can get a new patch done with a reworked
extractExtensionList, I'll get a new look at it in a timely fashion
and then let's move it to a committer's hands.
Done and thanks!
P
--
http://po
Josh Berkus wrote:
> Well, it's hard for anyone to volunteer when we don't know what the
> actual volunteer tasks are. I certainly intend to do *something* to
> support the bug tracker system, but I don't know yet what that something is.
I volunteer to do something too, as long as I don't have t
oonish...@nttdata.co.jp wrote:
> The below error messages were shown in standby server log:
>
> FATAL: could not access status of transaction 9009
> DETAIL: Could not read from file "pg_commit_ts/" at offset 90112:
> Success.
> CONTEXT: xlog redo Transaction/COMMIT: 2015-09-30 15:52:41.92
On 09/30/2015 03:28 PM, Josh Berkus wrote:
On 09/30/2015 03:27 PM, Tom Lane wrote:
Josh Berkus writes:
On 09/30/2015 03:10 PM, Tom Lane wrote:
I'd be feeling a lot more positive about this whole thread if any people
had stepped up and said "yes, *I* will put in a lot of grunt-work to make
som
On Thu, Oct 1, 2015 at 4:33 AM, Paul Ramsey wrote:
>
>
> On September 30, 2015 at 7:06:58 AM, Tom Lane (t...@sss.pgh.pa.us) wrote:
>
> I wrote:
> > Hm. Wouldn't it be just fine if only the server is able to define a
> > list of extensions then? It seems to me that all the use-cases of this
> > fea
On 09/30/2015 03:27 PM, Tom Lane wrote:
> Josh Berkus writes:
>> On 09/30/2015 03:10 PM, Tom Lane wrote:
>>> I'd be feeling a lot more positive about this whole thread if any people
>>> had stepped up and said "yes, *I* will put in a lot of grunt-work to make
>>> something happen here". The lack
Josh Berkus writes:
> On 09/30/2015 03:10 PM, Tom Lane wrote:
>> I'd be feeling a lot more positive about this whole thread if any people
>> had stepped up and said "yes, *I* will put in a lot of grunt-work to make
>> something happen here". The lack of any volunteers suggests strongly
>> that th
On 09/30/2015 03:10 PM, Tom Lane wrote:
> I'd be feeling a lot more positive about this whole thread if any people
> had stepped up and said "yes, *I* will put in a lot of grunt-work to make
> something happen here". The lack of any volunteers suggests strongly
> that this thread is a waste of tim
Christopher Browne writes:
> It may very well be *worse* than that; it seems quite likely to me that if
> an issue tracker is not being continually curated by substantially ALL of
> its users, then you don't get any of those things. That *is* a lot more
> pessimistic, and considerably likely, as
On Wed, Sep 30, 2015 at 12:43 PM, Josh Berkus wrote:
> On 09/30/2015 07:44 AM, Merlin Moncure wrote:
>> I'm not trolling in any way. I'm just challenging you to back up your
>> blanket assertions with evidence. For example, you're assertion that
>> mailing lists are insufficient is simply stated
On Wed, Sep 30, 2015 at 5:49 PM, Tom Lane wrote:
> "David G. Johnston" writes:
> > On Wed, Sep 30, 2015 at 2:52 PM, Joe Conway wrote:
> >> I was looking at something in gram.y when I noticed that the following
> >> production works:
> >> SET SESSION SESSION CHARACTERISTICS AS TRANSACTION READ O
On 30 September 2015 at 14:31, Joshua D. Drake wrote:
>
> On 09/30/2015 11:23 AM, Christopher Browne wrote:
>
>> It's well and nice to think that an issue tracker resolves all of this,
>> and, if we
>> had tiny numbers of issues, we could doubtless construct a repository
>> indicating so. (Seems
"David G. Johnston" writes:
> On Wed, Sep 30, 2015 at 2:52 PM, Joe Conway wrote:
>> I was looking at something in gram.y when I noticed that the following
>> production works:
>> SET SESSION SESSION CHARACTERISTICS AS TRANSACTION READ ONLY;
>> "SESSION SESSION" seems fairly odd -- is it intention
On 09/30/2015 12:02 AM, Jim Nasby wrote:
> I wish people would at least consider this as an option because it
> integrates a ton of different features together. It has *the potential*
> to eliminate our need to keep maintaining CommitFest and buildfarm and
> could also replace mediawiki.
>
> If pe
>
> > After further thought, I wonder whether instead of having an incoming
> > listener initialize its "pos" to QUEUE_TAIL, we couldn't have it
> > initialize to the maximum "pos" among existing listeners (with a floor of
> > QUEUE_TAIL of course). If any other listener has advanced over a given
On September 30, 2015 at 7:06:58 AM, Tom Lane (t...@sss.pgh.pa.us) wrote:
Paul Ramsey writes:
> Hm. Wouldn't it be just fine if only the server is able to define a
> list of extensions then? It seems to me that all the use-cases of this
> feature require to have a list of extensions defined p
On Wed, Sep 30, 2015 at 2:52 PM, Joe Conway wrote:
> I was looking at something in gram.y when I noticed that the following
> production works:
>
>
> SET SESSION SESSION CHARACTERISTICS AS TRANSACTION READ ONLY;
>
>
> "SESSION SESSION" seems fairly odd -- is it intentional?
>
Scanning the SET a
I was looking at something in gram.y when I noticed that the following
production works:
SET SESSION SESSION CHARACTERISTICS AS TRANSACTION READ ONLY;
"SESSION SESSION" seems fairly odd -- is it intentional?
Joe
--
Crunchy Data - http://crunchydata.com
PostgreSQL Support for Secure Enterpris
On 09/30/2015 11:33 AM, Andrew Dunstan wrote:
Who exactly is "some guy sitting in a den pushing out code"? And if
that's not a patronizing put down I don't know what is. If you're
referring to me you couldn't be more wrong. I have been a development
director managing a couple of substantial tea
On 09/30/2015 02:16 PM, Joshua D. Drake wrote:
On 09/30/2015 10:45 AM, Andrew Dunstan wrote:
Frankly, an insistence on moving to some integrated solution is likely
to result in the adoption of nothing. And your "educating hackers who
don't understand" is more than a little patronizing. What m
On 09/30/2015 11:23 AM, Christopher Browne wrote:
It's well and nice to think that an issue tracker resolves all of this,
and, if we
had tiny numbers of issues, we could doubtless construct a repository
indicating so. (Seems to me that the bit of "fan service" for GitHub's
bug tracker fits into
On 30 September 2015 at 12:26, Joshua D. Drake wrote:
>
> On 09/30/2015 07:44 AM, Merlin Moncure wrote:
>
>> I'm not trolling in any way. I'm just challenging you to back up your
>> blanket assertions with evidence. For example, you're assertion that
>> mailing lists are insufficient is simply s
On 09/30/2015 10:45 AM, Andrew Dunstan wrote:
Frankly, an insistence on moving to some integrated solution is likely
to result in the adoption of nothing. And your "educating hackers who
don't understand" is more than a little patronizing. What makes you
think your experience in software develop
On 09/30/2015 01:31 PM, Joshua D. Drake wrote:
On 09/30/2015 12:02 AM, Jim Nasby wrote:
If people are hell-bent on every tool being separate then fine, but I
get the distinct impression that everyone is discarding GitLab out of
hand based on completely bogus information.
Right, we need to s
On 09/30/2015 07:44 AM, Merlin Moncure wrote:
> I'm not trolling in any way. I'm just challenging you to back up your
> blanket assertions with evidence. For example, you're assertion that
> mailing lists are insufficient is simply stated and expected to be
> taken on faith: *How* is it insuffici
On 09/30/2015 12:02 AM, Jim Nasby wrote:
If people are hell-bent on every tool being separate then fine, but I
get the distinct impression that everyone is discarding GitLab out of
hand based on completely bogus information.
Right, we need to stop thinking that every task is not interrelated.
On 2015-09-30 19:36:22 +0300, Heikki Linnakangas wrote:
> On 09/30/2015 04:31 AM, Chris Winslett wrote:
> >I'm orchestrating Postgres to behave as a leader-follower cluster. I've run
> >into issues when I am scaling down a connection count for a cluster
> >(scaling up is fine -- scaling down result
On 09/30/2015 04:31 AM, Chris Winslett wrote:
I'm orchestrating Postgres to behave as a leader-follower cluster. I've run
into issues when I am scaling down a connection count for a cluster
(scaling up is fine -- scaling down results in fatal errors). I use an
open source tool I've written to or
On 09/30/2015 07:44 AM, Merlin Moncure wrote:
I'm not trolling in any way. I'm just challenging you to back up your
blanket assertions with evidence. For example, you're assertion that
mailing lists are insufficient is simply stated and expected to be
taken on faith: *How* is it insufficient a
On Tue, Sep 29, 2015 at 10:49 PM, Robert Haas wrote:
>
> On Tue, Sep 29, 2015 at 12:39 AM, Amit Kapila
wrote:
> > Attached patch is a rebased patch based on latest commit (d1b7c1ff)
> > for Gather node.
> >
> > - I have to reorganize the defines in execParallel.h and .c. To keep
> > ParallelExecu
On Wed, Sep 30, 2015 at 7:17 AM, Kam Lasater wrote:
> On Tue, Sep 29, 2015 at 6:39 PM, Josh Berkus wrote:
>> On 09/29/2015 03:08 PM, Merlin Moncure wrote:
>>> I've read this email about three times now and it's not clear at all
>>> to me what a issue/bug tracker brings to the table.
>>
>> Here ar
> > * Suppose we focus on only HashJoin in the first version?
> > This patch also add support on NestLoop and MergeJoin, however, NestLoop
> > has no valuable scenario without parallel execution capability, and the
> > most valuable scenario on MergeJoin is reduction of rows prior to Sort.
> > Once
On September 30, 2015 at 12:54:44 AM, Michael Paquier
(michael.paqu...@gmail.com) wrote:
>> +extern bool extractExtensionList(char *extensionString,
>> + List **extensionOids);
>> What's the point of the boolean status in this new routine? The return
>> value of extractExtensionList is never
Jim Nasby writes:
> Ouch. So it sounds like there's value to seeing if pg_control isn't what
> we expect it to be.
> Instead of looking at the inode (portability problem), what if
> pg_control contained a random number that was created at initdb time? On
> startup postmaster would read that va
Paul Ramsey writes:
> Hm. Wouldn't it be just fine if only the server is able to define aÂ
> list of extensions then? It seems to me that all the use-cases of thisÂ
> feature require to have a list of extensions defined per server, andÂ
> not per fdw type. This would remove a level of complexit
On 09/30/2015 01:18 AM, Michael Paquier wrote:
On Wed, Sep 30, 2015 at 7:19 AM, Tom Lane wrote:
I wrote:
Josh Berkus writes:
Give me source with the change, and I'll put it on a cheap, low-bandwith
AWS instance and hammer the heck out of it. That should raise any false
positives we can ex
On Tue, Sep 29, 2015 at 12:08:56PM +1300, Gavin Flower wrote:
> Linux kernel project uses bugzilla (https://bugzilla.kernel.org)
AIUI this is not mandatory for kernel hackers, and more opt-in from a
some/many/a few(?) subsystem maintainers. Some parts use it more, some
less or not at all.
> and
On Tue, Sep 29, 2015 at 6:39 PM, Josh Berkus wrote:
> On 09/29/2015 03:08 PM, Merlin Moncure wrote:
>> I've read this email about three times now and it's not clear at all
>> to me what a issue/bug tracker brings to the table.
>
> Here are the problems I'd like to solve:
>
> 1. "Was this issue fix
Michael Paquier wrote:
> On Wed, Sep 30, 2015 at 4:15 PM, wrote:
>
> > FATAL: could not access status of transaction 9009
> > DETAIL: Could not read from file "pg_commit_ts/" at offset 90112:
> > Success.
> > CONTEXT: xlog redo Transaction/COMMIT: 2015-09-30 15:52:41.924141+09
> > LOG: st
Pavan Deolasee wrote:
> On Wed, Sep 30, 2015 at 2:16 AM, Alvaro Herrera
> wrote:
>
> > That's a very good point. I think Github and other sites are already
> > blocked in countries like India and Cuba.
>
> Github is not blocked in India and was never as far as I know. Well our
> government rece
* Heikki Linnakangas (hlinn...@iki.fi) wrote:
> I agree with Robert's earlier point that this needs to be split into
> multiple patches, which can then be reviewed and discussed
> separately. Pending that, I'm going to mark this as "Waiting on
> author" in the commitfest.
Attached is an initial sp
Hello!
On 09/30/2015 10:29 AM, Kyotaro HORIGUCHI wrote:
By the way your comment for indexrinfos is as following,
* 'indexrinfos' is a list of RestrictInfo nodes from the query's WHERE
* or JOIN conditions, excluding those implied by the index predicate
* (if the index is not partial, the list
On 2015/09/30 6:55, Robert Haas wrote:
On Mon, Sep 28, 2015 at 11:15 PM, Etsuro Fujita
wrote:
I thought the same thing [1]. While I thought it was relatively easy to
make changes to RefetchForeignRow that way for the foreign table case
(scanrelid>0), I was not sure how hard it would be to do s
On 2015/09/29 21:38, Kouhei Kaigai wrote:
Also note that EvalPlanQualFetchRowMarks() will raise an error
if RefetchForeignRow callback returned NULL tuple.
Is it right or expected behavior?
IIUC, I think that that behavior is reasonable.
It looks to me this callback is designed to pull out
No, I do not have a backtrace.
I 'm sorry about using misleading word ‘crash’.
The standby server did not cause process crash.
It exited abnormally.
Regards,
==
Takashi Ohnishi
oonish...@nttdata.co.jp
From: Michael Paquier [mailto:michael.paqu...@gmail.com]
Sent: Wednesday, September 30, 20
Hello, it looks fine.
> >> cost_index() seems to need to be fixed. It would count excluded
> >> clauses in estimate.
> >
> > Hmm, good point. The problem is that extract_nonindex_conditions uses
> > baserel->baserestrictinfo again, i.e. it does not skip the implied
> > clauses. So we may either st
On Mon, Sep 28, 2015 at 10:47 PM, Paul Ramsey wrote:
> On Sat, Sep 26, 2015 at 5:41 AM, Michael Paquier
> wrote:
>> On Sat, Sep 26, 2015 at 4:29 AM, Paul Ramsey wrote:
>>> On Thu, Aug 20, 2015 at 6:01 PM, Michael Paquier wrote:
>>> src/backend/utils/adt/format_type.c
>>> +/*
>>> + * This version
On Wed, Sep 30, 2015 at 4:15 PM, wrote:
> FATAL: could not access status of transaction 9009
> DETAIL: Could not read from file "pg_commit_ts/" at offset 90112:
> Success.
> CONTEXT: xlog redo Transaction/COMMIT: 2015-09-30 15:52:41.924141+09
> LOG: startup process (PID 23199) exited with
Hi,
Today, I found that standby server crashes with latest code of master branch
and REL9_5_STABLE branch.
This happens not always but sometimes after doing pg_start_backup and
pg_stop_backup for master server.
The below error messages were shown in standby server log:
FATAL: could not access
On 9/29/15 12:46 PM, Tom Lane wrote:
Andres Freund writes:
On 2015-09-29 13:40:28 -0400, Tom Lane wrote:
I think you missed my point: gitlab would then believe it's in charge of,
eg, granting write access to that repo. We could perhaps whack it over
the head till it only does what we want and
On 9/29/15 3:36 PM, Oleg Bartunov wrote:
...What we're not fine with is depending on a proprietary
system, no
matter what type of license, as infrastructure...
Exactly. Which is why I was warning about latching onto features
only available in th
63 matches
Mail list logo
