Re: [HACKERS] WIP: About CMake v2

On 26-11-2015 14:06, YUriy Zhuravlev wrote: > On Thursday 26 November 2015 17:42:16 you wrote: >> No point in doing any work if you don't agree with the basic prerequisites. > I meant that support for older versions of CMake I'll do when will implement > other functions. > I think you don't

Re: [HACKERS] New email address

Stefan Kaltenbrunner writes: > that seems entirely doable with our current infrastructure (and even > with minimal-to-no hackery on mj2) - but it still carries the "changes > From:" issue :/ Yeah. What do you think of the other approach of trying to preserve validity of

Re: [HACKERS] New email address

On Wed, Nov 25, 2015 at 6:55 PM, Tom Lane wrote: > > But my point was that while the RFC says what to put there there's > > absolutely no reference anywhere for when the information should cause > > any MUA or MTA to behave differently. > > Agreed. To my mind that's a reason

[HACKERS] Errors in our encoding conversion tables

There's a discussion over at http://www.postgresql.org/message-id/flat/2sa.dhu5.1hk1yrptnfy.1ml...@seznam.cz of an apparent error in our WIN1250 -> LATIN2 conversion. I looked into this and found that indeed, the code will happily translate certain characters for which there seems to be no

Re: [HACKERS] New email address

On Tue, Nov 24, 2015 at 7:50 PM, Tom Lane wrote: > Yeah, but SPF is also used as part of DMARC, which means that merely > forwarding somebody's email out of our listserv is probably going to look > like spam, even if we didn't change anything at all about the message >

Re: [HACKERS] New email address

On 11/26/2015 09:12 PM, Greg Stark wrote: On Wed, Nov 25, 2015 at 6:55 PM, Tom Lane wrote: But my point was that while the RFC says what to put there there's absolutely no reference anywhere for when the information should cause any MUA or MTA to behave differently.

Re: [HACKERS] New email address

Greg Stark wrote: > Hm, I see it as a reason why signing Sender is reasonable. If it were > a functional header then there might be a reason it would have to be > changed. But if it's purely informational and the receiving MUA is > going to display to the user (which is a bad idea imho but Gmail

Re: [HACKERS] New email address

On Thu, Nov 26, 2015 at 11:13 PM, José Luis Tallón wrote: > From DMARC.org's Wiki: > <<< 2 Add an "Original Authentication Results" header to indicate you have > performed the authentication and you are validating it > 3 Take ownership of the email, by removing the

Re: [HACKERS] Errors in our encoding conversion tables

> There's a discussion over at > http://www.postgresql.org/message-id/flat/2sa.dhu5.1hk1yrptnfy.1ml...@seznam.cz > of an apparent error in our WIN1250 -> LATIN2 conversion. I looked into this > and found that indeed, the code will happily translate certain characters > for which there seems to be

Re: [HACKERS] Foreign join pushdown vs EvalPlanQual

On 2015/11/27 0:14, Kouhei Kaigai wrote: >> The documentation says as following so I think the former has. >> >> # I don't understhad what 'can or must' means, though... 'can and >> # must'? >> >> + Also, this callback can or must recheck scan qualifiers and join >> + conditions which are

Re: [HACKERS] WIP: About CMake v2

On 27 November 2015 at 12:39, Tom Lane wrote: > Euler Taveira writes: > > On 26-11-2015 14:06, YUriy Zhuravlev wrote: > >> I meant that support for older versions of CMake I'll do when will > implement > >> other functions. > > > I think you don't

Re: [HACKERS] WIP: About CMake v2

Craig Ringer writes: > One thing to consider: I can't imagine backporting this to all supported > back branches, it'd be a switch for the next release. Right? Agreed. > That means he doesn't have to worry about what RH / Debian policy for their > old versions is. RH isn't

Re: [HACKERS] Foreign join pushdown vs EvalPlanQual

On 2015/11/27 0:14, Kouhei Kaigai wrote: On 2015/11/26 14:04, Kouhei Kaigai wrote: The attached patch adds: Path *fdw_outerpath field to ForeignPath node. FDW driver can set arbitrary but one path-node here. After that, this path-node shall be transformed to plan-node by createplan.c, then

Re: [HACKERS] WIP: About CMake v2

Euler Taveira writes: > On 26-11-2015 14:06, YUriy Zhuravlev wrote: >> I meant that support for older versions of CMake I'll do when will implement >> other functions. > I think you don't understand the point: start with the *right* cmake > version because you could have

Re: [HACKERS] pg_stat_replication log positions vs base backups

On Thu, Nov 26, 2015 at 10:53 PM, Magnus Hagander wrote: > On Thu, Nov 26, 2015 at 1:03 PM, Michael Paquier > wrote: >> >> On Thu, Nov 26, 2015 at 6:45 PM, Magnus Hagander wrote: >> > I'm only talking about the actual value in pg_stat_replication

Re: [HACKERS] WIP: About CMake v2

On Fri, Nov 27, 2015 at 2:50 PM, Craig Ringer wrote: > On 27 November 2015 at 12:39, Tom Lane wrote: >> >> Euler Taveira writes: >> > On 26-11-2015 14:06, YUriy Zhuravlev wrote: >> >> I meant that support for older versions of

Re: [HACKERS] Error with index on unlogged table

On Sat, Nov 21, 2015 at 11:30 PM, Michael Paquier wrote: > On Fri, Nov 20, 2015 at 4:11 PM, Michael Paquier > wrote: >> For master and perhaps 9.5, I would think that a dedicated WAL record >> type enforcing the fsync is the way to go. This

Re: [HACKERS] New email address

On 11/26/2015 09:10 PM, Tom Lane wrote: > Stefan Kaltenbrunner writes: >> that seems entirely doable with our current infrastructure (and even >> with minimal-to-no hackery on mj2) - but it still carries the "changes >> From:" issue :/ > > Yeah. What do you think of the

Re: [HACKERS] Errors in our encoding conversion tables

Tatsuo Ishii writes: > I have started to looking into it. I wonder how do you create the part > of your patch: The code I used is below. > In the above you seem to disable the conversion from 0x96 of win1250 > to ISO-8859-2 by using the Unicode mapping files in >

Re: [HACKERS] Foreign join pushdown vs EvalPlanQual

> -Original Message- > From: Etsuro Fujita [mailto:fujita.ets...@lab.ntt.co.jp] > Sent: Friday, November 27, 2015 2:40 PM > To: Kaigai Kouhei(海外 浩平); Kyotaro HORIGUCHI > Cc: robertmh...@gmail.com; t...@sss.pgh.pa.us; pgsql-hackers@postgresql.org; > shigeru.han...@gmail.com > Subject: Re:

Re: [HACKERS] parallel joins, and better parallel explain

On 26 November 2015 at 03:41, Robert Haas wrote: > Attached find a patch that does (mostly) two things. First, it allows > the optimizer to generate plans where a Nested Loop or Hash Join > appears below a Gather node. This is a big improvement on what we > have today,

Re: [HACKERS] Optimization for updating foreign tables in Postgres FDW

Hi Thom, Thank you for paying attention to this! On 2015/11/25 20:36, Thom Brown wrote: On 13 May 2015 at 04:10, Etsuro Fujita wrote: On 2015/05/13 0:55, Stephen Frost wrote: While the EXPLAIN output changed, the structure hasn't really changed from what was

Re: [HACKERS] pg_stat_replication log positions vs base backups

On Thu, Nov 26, 2015 at 8:17 AM, Michael Paquier wrote: > > > On Wed, Nov 25, 2015 at 11:08 PM, Magnus Hagander > wrote: > >> On Wed, Nov 25, 2015 at 3:03 PM, Michael Paquier < >> michael.paqu...@gmail.com> wrote: >> >>> On Wed, Nov 25, 2015 at

Re: [HACKERS] Redefine default result from PQhost()?

On Wed, Nov 25, 2015 at 11:59 PM, Tom Lane wrote: > Currently, libpq's PQhost() function will return NULL if the connection is > using the default Unix-socket connection address. This seems like a > pretty dubious definition to me. psql works around it in several places >

Re: CustomScan in a larger structure (RE: [HACKERS] CustomScan support on readfuncs.c)

> -Original Message- > From: pgsql-hackers-ow...@postgresql.org > [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Kouhei Kaigai > Sent: Saturday, November 21, 2015 8:05 AM > To: Robert Haas > Cc: Andres Freund; Amit Kapila; pgsql-hackers > Subject: Re: CustomScan in a larger

Re: [HACKERS] WIP: About CMake v2

On Thursday 26 November 2015 01:29:37 Euler Taveira wrote: > I give it a try. Nice WIP. IMHO you should try to support cmake version > that are available in the stable releases. Looking at [1], I think the > best choice is 2.8.11 (because it will cover Red Hat based distros and > also Debian based

Re: [HACKERS] pg_stat_replication log positions vs base backups

On Thu, Nov 26, 2015 at 6:45 PM, Magnus Hagander wrote: > I'm only talking about the actual value in pg_stat_replication here, not > what we are using internally. These are two different things of course - > let's keep them separate for now. In pg_stat_replication, we explicitly > check for

Re: [HACKERS] Some questions about the array.

YUriy Zhuravlev wrote: On Friday 06 November 2015 12:55:44 you wrote: Omitted bounds are common in other languages and would be handy. I don't think they'd cause any issues with multi-dimensional arrays or variable start-pos arrays. And yet, what about my patch? My vote: let us do it,

Re: [HACKERS] Getting sorted data from foreign server for merge join

Hi Ashutosh, I reviewed your latest version of patch and over all the implementation and other details look good to me. Here are few cosmetic issues which I found: 1) Patch not getting applied cleanly - white space warning 2) -List *usable_pathkeys = NIL; +List

Re: [HACKERS] Foreign join pushdown vs EvalPlanQual

On 2015/11/26 14:04, Kouhei Kaigai wrote: On 2015/11/24 2:41, Robert Haas wrote: On Fri, Nov 20, 2015 at 12:11 AM, Kouhei Kaigai wrote: One subplan means FDW driver run an entire join sub-tree with local alternative sub-plan; that is my expectation for the majority case.

Re: [HACKERS] pg_stat_replication log positions vs base backups

On Thu, Nov 26, 2015 at 1:03 PM, Michael Paquier wrote: > On Thu, Nov 26, 2015 at 6:45 PM, Magnus Hagander wrote: > > I'm only talking about the actual value in pg_stat_replication here, not > > what we are using internally. These are two different things of course - >

Re: [HACKERS] WIP: About CMake v2

On 26-11-2015 07:33, YUriy Zhuravlev wrote: > On Thursday 26 November 2015 01:29:37 Euler Taveira wrote: >> I give it a try. Nice WIP. IMHO you should try to support cmake version >> that are available in the stable releases. Looking at [1], I think the >> best choice is 2.8.11 (because it will

Re: [HACKERS] Foreign join pushdown vs EvalPlanQual

> On 2015/11/26 14:04, Kouhei Kaigai wrote: > >> On 2015/11/24 2:41, Robert Haas wrote: > >>> On Fri, Nov 20, 2015 at 12:11 AM, Kouhei Kaigai > >>> wrote: > One subplan means FDW driver run an entire join sub-tree with local > alternative sub-plan; that is my

Re: [HACKERS] Foreign join pushdown vs EvalPlanQual

> At Thu, 26 Nov 2015 05:04:32 +, Kouhei Kaigai wrote > in <9a28c8860f777e439aa12e8aea7694f801176...@bpxm15gp.gisp.nec.co.jp> > > > On 2015/11/24 2:41, Robert Haas wrote: > > > > On Fri, Nov 20, 2015 at 12:11 AM, Kouhei Kaigai > > > > wrote: > > >

Re: [HACKERS] Redefine default result from PQhost()?

Magnus Hagander writes: > On Wed, Nov 25, 2015 at 11:59 PM, Tom Lane wrote: >> I think we should [ return DEFAULT_PGSOCKET_DIR not NULL ] > I agree with this change in genera. But I wonder if there's a risk here > that we break some applications isnt'

Re: [HACKERS] WIP: About CMake v2

Euler Taveira writes: > On 26-11-2015 07:33, YUriy Zhuravlev wrote: >> Maybe you are right. But by the time I finish my work I think 3.0 will >> become >> a standard. CMake is developing rapidly and soon will have version 3.4.1 >> And one more thing: a normal documentation

Re: [HACKERS] What .gitignore files do in the tarball?

On Wed, Nov 25, 2015 at 11:49 PM, Tom Lane wrote: > Euler Taveira writes: >> +1 to remove all of those files. > > Meh. We've always shipped that stuff; before git, we shipped .cvsignore > files, and there were no complaints about it, going back twenty

Re: [HACKERS] WIP: About CMake v2

On Thursday 26 November 2015 11:10:36 you wrote: > Adding a new build > dependency is bad enough; adding one that isn't easily available is a > show-stopper. If someone decided to compile from source Postgres rather than install from RPM then it will not be a problem as to build CMake. On the

Re: [HACKERS] WIP: About CMake v2

On 2015-11-26 19:22:23 +0300, YUriy Zhuravlev wrote: > On Thursday 26 November 2015 11:10:36 you wrote: > > Adding a new build > > dependency is bad enough; adding one that isn't easily available is a > > show-stopper. > > If someone decided to compile from source Postgres rather than install

Re: [HACKERS] WIP: About CMake v2

Andres Freund writes: > On 2015-11-26 19:22:23 +0300, YUriy Zhuravlev wrote: >> On Thursday 26 November 2015 11:10:36 you wrote: >>> Adding a new build dependency is bad enough; adding one that isn't >>> easily available is a show-stopper. >> If someone decided to compile

Re: [HACKERS] WIP: About CMake v2

On Thursday 26 November 2015 17:42:16 you wrote: > No point in doing any work if you don't agree with the basic prerequisites. I meant that support for older versions of CMake I'll do when will implement other functions. -- YUriy Zhuravlev Postgres Professional: http://www.postgrespro.com The

Re: [HACKERS] WIP: About CMake v2

Tom Lane wrote: > Not working with the cmake version shipped in current distributions would > almost certainly cause us to reject this patch. Adding a new build > dependency is bad enough; adding one that isn't easily available is a > show-stopper. You'd better think in terms of what's provided

Re: [HACKERS] New email address

On 11/24/2015 11:03 PM, José Luis Tallón wrote: > On 11/24/2015 07:55 PM, Tom Lane wrote: >> [snip] >> The clearly critical thing, though, is that when forwarding a message >> from >> a person at a DMARC-using domain, we would have to replace the From: line >> with something @postgresql.org. This

Re: [HACKERS] Speed up Clog Access by increasing CLOG buffers

On Tue, Nov 17, 2015 at 6:30 PM, Simon Riggs wrote: > On 17 November 2015 at 11:48, Amit Kapila wrote: > >> >> I think in that case what we can do is if the total number of >> sub transactions is lesser than equal to 64 (we can find that by >>