Re: [HACKERS] reducing our reliance on MD5

2015-02-11 Thread José Luis Tallón
On 02/11/2015 03:55 PM, Claudio Freire wrote: On 02/11/2015 03:39 PM, Claudio Freire wrote: [snip] Seems the risk of someone either lifting pg_authid from disk or by hacking the system and being postgres, thereby accessing passwords stored somewhere else, is actually the bigger problem. But

Re: [HACKERS] Manipulating complex types as non-contiguous structures in-memory

2015-02-11 Thread Stephen Frost
* Tom Lane (t...@sss.pgh.pa.us) wrote: I think restricting this feature to varlena types is just fine. Agreed. Thanks, Stephen signature.asc Description: Digital signature

Re: [HACKERS] reducing our reliance on MD5

2015-02-11 Thread Bruce Momjian
On Tue, Feb 10, 2015 at 09:30:37PM -0500, Tom Lane wrote: I think it would be wise to take two steps back and think about what the threat model is here, and what we actually need to improve. Offhand I can remember two distinct things we might wish to have more protection against: * scraping

Re: [HACKERS] [pgsql-advocacy] GSoC 2015 - mentors, students and admins.

2015-02-11 Thread Stephen Frost
Thom, * Thom Brown (t...@linux.com) wrote: Before I do that, I'd like to have an idea of how many people are interested in being either a student or a mentor. I'm happy to participate as a mentor again this year. Thanks! Stephen signature.asc Description: Digital

Re: [HACKERS] reducing our reliance on MD5

2015-02-11 Thread Stephen Frost
All, * Heikki Linnakangas (hlinnakan...@vmware.com) wrote: On 02/11/2015 05:57 AM, Tom Lane wrote: In any case, my larger point was that given the pain that we're going to incur here, and the certainly years-long transition interval involved, it would be foolish to think only about replacing

Re: [HACKERS] reducing our reliance on MD5

2015-02-11 Thread Stephen Frost
* Heikki Linnakangas (hlinnakan...@vmware.com) wrote: Let's do this properly. I can help with that, although I don't know if I'll find the time and enthusiasm to do all of it alone. Agreed- let's do it properly. This is definitely an area of interest for me and if I can ever get out from

Re: [HACKERS] libpq's multi-threaded SSL callback handling is busted

2015-02-11 Thread Jan Urbański
Jan Urbański writes: I did some more digging on bug http://www.postgresql.org/message-id/cahul3dpwyfnugdgo95ohydq4kugdnbkptjq0mnbtubhcmg4...@mail.gmail.com which describes a deadlock when using libpq with SSL in a multi-threaded environment with other threads doing SSL independently.

Re: [HACKERS] reducing our reliance on MD5

2015-02-11 Thread Joshua D. Drake
On 02/11/2015 07:54 AM, José Luis Tallón wrote: On 02/11/2015 04:40 PM, Tom Lane wrote: =?UTF-8?B?Sm9zw6kgTHVpcyBUYWxsw7Nu?= jltal...@adv-solutions.net writes: In any case, just storing the password BLOB(text or base64 encoded) along with a mechanism identifier would go a long way towards

Re: [HACKERS] pgbench -f and vacuum

2015-02-11 Thread Robert Haas
On Wed, Feb 11, 2015 at 2:00 PM, Jeff Janes jeff.ja...@gmail.com wrote: I would rather just learn to add the -n when I use -f and don't have the default tables in place, than have to learn new methods for saying no really, I left -n off on purpose when I have a custom file which does use the

[HACKERS] Standby receiving part of missing WAL segment

2015-02-11 Thread Thom Brown
Hi, Today I witnessed a situation which appears to have gone down like this: - The primary server starting streaming WAL data from segment 00A8 to the standby - The standby server started receiving that data - Before 00A8 is finished, the wal sender process dies on the primary, but the archiver

Re: [HACKERS] ibm system z in the buildfarm

2015-02-11 Thread Mark Wong
On 02/11/2015 05:48 AM, David Fetter wrote: On Tue, Feb 10, 2015 at 05:49:18PM -0800, Mark Wong wrote: Hi everyone, I've seen in the archive a call for more architecture coverage so I just wanted to send a quick note that there is now Linux on System Z in the buildfarm now:

Re: [HACKERS] GSoC 2015 - mentors, students and admins.

2015-02-11 Thread Josh Berkus
On 02/11/2015 04:33 AM, Anastasia Lubennikova wrote: I'm interested to participate as student again. Let's *really* hope for no US sanctions, then. -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make

Re: [HACKERS] pgbench -f and vacuum

2015-02-11 Thread Jeff Janes
On Tue, Dec 23, 2014 at 7:42 AM, Alvaro Herrera alvhe...@2ndquadrant.com wrote: Robert Haas wrote: On Mon, Dec 22, 2014 at 6:55 PM, Alvaro Herrera alvhe...@2ndquadrant.com wrote: Here's a completely different idea. How about we add an option that means vacuum this table before running

Re: [HACKERS] [pgsql-advocacy] GSoC 2015 - mentors, students and admins.

2015-02-11 Thread Grzegorz Parka
I'm interested to participate as student. Regards, Grzegorz Parka 2015-02-11 17:55 GMT+01:00 Stephen Frost sfr...@snowman.net: Thom, * Thom Brown (t...@linux.com) wrote: Before I do that, I'd like to have an idea of how many people are interested in being either a student or a mentor.

Re: [HACKERS] parallel mode and parallel contexts

2015-02-11 Thread Robert Haas
On Wed, Feb 11, 2015 at 1:59 PM, Robert Haas robertmh...@gmail.com wrote: I'm not sure what you mean by the severity of the lock. How about marking the locks that the worker inherited from the parallel master and throwing an error if it tries to lock one of those objects in a mode that it

Re: [HACKERS] reducing our reliance on MD5

2015-02-11 Thread Claudio Freire
On Wed, Feb 11, 2015 at 10:31 AM, Magnus Hagander mag...@hagander.net wrote: On Wed, Feb 11, 2015 at 4:57 AM, Tom Lane t...@sss.pgh.pa.us wrote: Robert Haas robertmh...@gmail.com writes: On Tue, Feb 10, 2015 at 9:30 PM, Tom Lane t...@sss.pgh.pa.us wrote: Another thing we need to keep in

Re: [HACKERS] reducing our reliance on MD5

2015-02-11 Thread José Luis Tallón
On 02/11/2015 03:39 PM, Claudio Freire wrote: [snip] Seems the risk of someone either lifting pg_authid from disk or by hacking the system and being postgres, thereby accessing passwords stored somewhere else, is actually the bigger problem. But also one that should be reasonably easy (TM) to

Re: [HACKERS] reducing our reliance on MD5

2015-02-11 Thread Magnus Hagander
On Wed, Feb 11, 2015 at 3:10 PM, José Luis Tallón jltal...@adv-solutions.net wrote: On 02/11/2015 02:31 PM, Magnus Hagander wrote: In any case, my larger point was that given the pain that we're going to incur here, and the certainly years-long transition interval involved, it would be

Re: [HACKERS] reducing our reliance on MD5

2015-02-11 Thread José Luis Tallón
On 02/11/2015 03:14 PM, Magnus Hagander wrote: [snip] The hash value in pg_authid already contains md5 as a prefix. No need for another column. Yes, but for variable length mechanism names (i.e. not just 3 chars) it would become increasingly difficult to differentiate between the algo name

Re: [HACKERS] reducing our reliance on MD5

2015-02-11 Thread Claudio Freire
On Wed, Feb 11, 2015 at 11:48 AM, José Luis Tallón jltal...@adv-solutions.net wrote: On 02/11/2015 03:39 PM, Claudio Freire wrote: [snip] Seems the risk of someone either lifting pg_authid from disk or by hacking the system and being postgres, thereby accessing passwords stored somewhere

Re: [HACKERS] reducing our reliance on MD5

2015-02-11 Thread Claudio Freire
On Wed, Feb 11, 2015 at 12:20 PM, José Luis Tallón jltal...@adv-solutions.net wrote: Both seem a step backwards IMO. Hmmm... as opposed to breaking applications innecesarily when simply enabling SSL/TLS would not make it insecure? or when users don't really need it? No, as opposed to cases

Re: [HACKERS] reducing our reliance on MD5

2015-02-11 Thread José Luis Tallón
On 02/11/2015 04:40 PM, Tom Lane wrote: =?UTF-8?B?Sm9zw6kgTHVpcyBUYWxsw7Nu?= jltal...@adv-solutions.net writes: In any case, just storing the password BLOB(text or base64 encoded) along with a mechanism identifier would go a long way towards making this part pluggable... just like we do with

Re: [HACKERS] reducing our reliance on MD5

2015-02-11 Thread Robert Haas
On Wed, Feb 11, 2015 at 8:02 AM, Heikki Linnakangas hlinnakan...@vmware.com wrote: On 02/11/2015 02:49 PM, Robert Haas wrote: So, this all sounds fairly nice if somebody's willing to do the work, but I can't help noticing that you originally proposed adopting SCRAM in 2012, and it's 2015 now.

Re: [HACKERS] reducing our reliance on MD5

2015-02-11 Thread Tom Lane
=?UTF-8?B?Sm9zw6kgTHVpcyBUYWxsw7Nu?= jltal...@adv-solutions.net writes: In any case, just storing the password BLOB(text or base64 encoded) along with a mechanism identifier would go a long way towards making this part pluggable... just like we do with LDAP/RADIUS/Kerberos/PAM today. That's

Re: [HACKERS] assessing parallel-safety

2015-02-11 Thread Robert Haas
On Wed, Feb 11, 2015 at 9:39 AM, Robert Haas robertmh...@gmail.com wrote: On Sun, Feb 8, 2015 at 12:28 PM, Robert Haas robertmh...@gmail.com wrote: On Sun, Feb 8, 2015 at 11:31 AM, Noah Misch n...@leadboat.com wrote: On Sat, Feb 07, 2015 at 08:18:55PM -0500, Robert Haas wrote: There are a few

Re: [HACKERS] reducing our reliance on MD5

2015-02-11 Thread Claudio Freire
On Wed, Feb 11, 2015 at 6:30 PM, Claudio Freire klaussfre...@gmail.com wrote: On Wed, Feb 11, 2015 at 5:25 PM, Heikki Linnakangas hlinnakan...@vmware.com wrote: On 02/11/2015 06:35 AM, Claudio Freire wrote: Usually because handshakes use a random salt on both sides. Not sure about pg's

Re: [HACKERS] reducing our reliance on MD5

2015-02-11 Thread Heikki Linnakangas
On 02/11/2015 05:34 PM, Claudio Freire wrote: On Wed, Feb 11, 2015 at 12:20 PM, José Luis Tallón jltal...@adv-solutions.net wrote: Moreover, requiring everybody to change all passwords and clients *at once* seems like a very poor decision towards allowing for graceful upgrades and make rolling

Re: [HACKERS] reducing our reliance on MD5

2015-02-11 Thread Claudio Freire
On Wed, Feb 11, 2015 at 5:25 PM, Heikki Linnakangas hlinnakan...@vmware.com wrote: On 02/11/2015 06:35 AM, Claudio Freire wrote: Usually because handshakes use a random salt on both sides. Not sure about pg's though, but in general collision strength is required but not slowness, they're not

Re: [HACKERS] reducing our reliance on MD5

2015-02-11 Thread Heikki Linnakangas
On 02/11/2015 11:30 PM, Claudio Freire wrote: On Wed, Feb 11, 2015 at 5:25 PM, Heikki Linnakangas hlinnakan...@vmware.com wrote: On 02/11/2015 06:35 AM, Claudio Freire wrote: Usually because handshakes use a random salt on both sides. Not sure about pg's though, but in general collision

Re: [HACKERS] reducing our reliance on MD5

2015-02-11 Thread Heikki Linnakangas
On 02/11/2015 06:35 AM, Claudio Freire wrote: Usually because handshakes use a random salt on both sides. Not sure about pg's though, but in general collision strength is required but not slowness, they're not bruteforceable. To be precise: collision resistance is usually not important for

Re: [HACKERS] reducing our reliance on MD5

2015-02-11 Thread Heikki Linnakangas
On 02/11/2015 03:52 PM, Robert Haas wrote: On Wed, Feb 11, 2015 at 8:02 AM, Heikki Linnakangas hlinnakan...@vmware.com wrote: On 02/11/2015 02:49 PM, Robert Haas wrote: So, this all sounds fairly nice if somebody's willing to do the work, but I can't help noticing that you originally proposed

Re: [HACKERS] Parallel Seq Scan

2015-02-11 Thread Robert Haas
On Tue, Feb 10, 2015 at 3:56 PM, Andres Freund and...@2ndquadrant.com wrote: On 2015-02-10 09:23:02 -0500, Robert Haas wrote: On Tue, Feb 10, 2015 at 9:08 AM, Andres Freund and...@2ndquadrant.com wrote: And good chunk sizes et al depend on higher layers, selectivity estimates and such. And

Re: [HACKERS] Proposal : REINDEX xxx VERBOSE

2015-02-11 Thread Jim Nasby
On 2/5/15 12:01 PM, Tom Lane wrote: Robert Haas robertmh...@gmail.com writes: We've got a mix of styles for extensible options right now: That we do. So COPY puts the options at the very end, but EXPLAIN and VACUUM put them right after the command name. I prefer the latter style and would

Re: [HACKERS] Corner case for add_path_precheck

2015-02-11 Thread Tom Lane
Antonin Houska a...@cybertec.at writes: Tom Lane t...@sss.pgh.pa.us wrote: Antonin Houska a...@cybertec.at writes: The special case is that the path passed to add_path_precheck() has costs *equal to* those of the old_path. If pathkeys, outer rells and costs are the same, as summarized in the

Re: [HACKERS] Index-only scans for GiST.

2015-02-11 Thread Thom Brown
On 11 February 2015 at 22:50, Anastasia Lubennikova lubennikov...@gmail.com wrote: Finally there is a new version of patch (in attachments). It provides multicolumn index-only scan for GiST indexes. - Memory leak is fixed. - little code cleanup - example of performance test in attachmens

Re: [HACKERS] SSL renegotiation and other related woes

2015-02-11 Thread Andres Freund
On 2015-02-11 14:54:03 +0200, Heikki Linnakangas wrote: Thoughts? Can you reproduce any errors with this? I'm on battery right now, so I can't really test much. Did you test having an actual standby instead of pg_receivexlog? I saw some slightly different errors there. Does this patch alone

Re: [HACKERS] SSL renegotiation and other related woes

2015-02-11 Thread Andres Freund
Hi, On 2015-02-05 23:03:02 +0200, Heikki Linnakangas wrote: On 01/26/2015 12:14 PM, Andres Freund wrote: Hi, When working on getting rid of ImmediateInterruptOK I wanted to verify that ssl still works correctly. Turned out it didn't. But neither did it in master. Turns out there's two

Re: [HACKERS] reducing our reliance on MD5

2015-02-11 Thread Tom Lane
Heikki Linnakangas hlinnakan...@vmware.com writes: On 02/11/2015 03:52 PM, Robert Haas wrote: So are you thinking to integrate with the Cyrus SASL library, or do you have another thought? I think we need to implement the primary MD5 replacement ourselves, so that it's always available

Re: [HACKERS] Corner case for add_path_precheck

2015-02-11 Thread Antonin Houska
Tom Lane t...@sss.pgh.pa.us wrote: Antonin Houska a...@cybertec.at writes: The special case is that the path passed to add_path_precheck() has costs *equal to* those of the old_path. If pathkeys, outer rells and costs are the same, as summarized in the comment above, I expect

Re: [HACKERS] libpq's multi-threaded SSL callback handling is busted

2015-02-11 Thread Andres Freund
On 2015-02-09 18:17:14 +0100, Jan Urbański wrote: We added unsetting the locking callback in 4e816286533dd34c10b368487d4079595a3e1418 due to this bug report: http://www.postgresql.org/message-id/48620925.6070...@pws.com.au Indeed, commenting out the CRYPTO_set_locking_callback(NULL) call in

Re: [HACKERS] relid of non user created tables

2015-02-11 Thread Jim Nasby
On 2/7/15 5:55 AM, Tom Lane wrote: Deepak S in.live...@live.in writes: I wish to know if it is safe to assume that non user created tables always have a relid of less than 10,000 (I chose this value after trial and error). Depends what you consider user created. System catalogs with

[HACKERS] Index-only scans for GiST.

2015-02-11 Thread Anastasia Lubennikova
Finally there is a new version of patch (in attachments). It provides multicolumn index-only scan for GiST indexes. - Memory leak is fixed. - little code cleanup - example of performance test in attachmens - function OIDs have debugging values (*) just to avoid merge conflicts while testing

[HACKERS] Re: [HACKERS] Streaming replication and WAL archive interactions

2015-02-11 Thread Миша Тюрин
  This should be a very common setup in the field, so how are  people doing it in practice? One of possible workaround with archive and streaming was to use pg_receivexlog from standby to copy/save WALs to archive. but with pg_receivexlog was also issue with fsync. [ master ] -- streaming 

Re: [HACKERS] Typo in logicaldecoding.sgml

2015-02-11 Thread Andres Freund
On 2015-02-10 20:34:33 -0500, Robert Haas wrote: On Tue, Feb 10, 2015 at 6:57 PM, Andres Freund and...@2ndquadrant.com wrote: I think one of them could be a fix. Any advice? I slightly prefer the second form... I think it uses is definitely more standard English usage in this context.

Re: [HACKERS] reducing our reliance on MD5

2015-02-11 Thread Tom Lane
Stephen Frost sfr...@snowman.net writes: * Tom Lane (t...@sss.pgh.pa.us) wrote: We've already got a sufficiency of external authentication mechanisms. If people wanted to use non-built-in authentication, we'd not be having this discussion. Just to be clear- lots of people *do* use the

Re: [HACKERS] reducing our reliance on MD5

2015-02-11 Thread Stephen Frost
* Tom Lane (t...@sss.pgh.pa.us) wrote: Stephen Frost sfr...@snowman.net writes: * Tom Lane (t...@sss.pgh.pa.us) wrote: We've already got a sufficiency of external authentication mechanisms. If people wanted to use non-built-in authentication, we'd not be having this discussion. Just

Re: [HACKERS] pg_upgrade bug in handling postgres/template1 databases

2015-02-11 Thread Bruce Momjian
On Tue, Feb 10, 2015 at 12:52:33PM -0500, Bruce Momjian wrote: The attached patch fixes the problem, and I have reproduced the bug and verified the patch fixes it. It would have been nice if I had figured this out two weeks ago, before we released minor version upgrades. This bug has existed

Re: [HACKERS] reducing our reliance on MD5

2015-02-11 Thread Stephen Frost
* Tom Lane (t...@sss.pgh.pa.us) wrote: Heikki Linnakangas hlinnakan...@vmware.com writes: We could also support using a library like that for additional authentication mechanisms, though, for those who really need them. We've already got a sufficiency of external authentication

Re: [HACKERS] Better error message on pg_upgrade checksum mismatches

2015-02-11 Thread Bruce Momjian
On Tue, Feb 10, 2015 at 10:55:07AM -0500, Greg Sabino Mullane wrote: Just a little thing that's been bugging me. If one side of the pg_upgrade has checksums and the other does not, give a less cryptic error message. Thanks. Slightly adjusted patch attached and applied to head. -- Bruce

Re: [HACKERS] ExplainModifyTarget doesn't work as expected

2015-02-11 Thread Etsuro Fujita
On 2015/02/10 14:49, Etsuro Fujita wrote: On 2015/02/07 1:09, Tom Lane wrote: IIRC, this code was written at a time when we didn't have NO INHERIT check constraints and so it was impossible for the parent table to get optimized away while leaving children. So the comment in

Re: [HACKERS] [REVIEW] Re: Compression of full-page-writes

2015-02-11 Thread Michael Paquier
On Wed, Feb 11, 2015 at 11:03 PM, Syed, Rahila rahila.s...@nttdata.com wrote: IMO, we should add details about how this new field is used in the comments on top of XLogRecordBlockImageHeader, meaning that when a page hole is present we use the compression info structure and when there is no

Re: [HACKERS] The return value of allocate_recordbuf()

2015-02-11 Thread Michael Paquier
On Wed, Feb 11, 2015 at 2:13 AM, Robert Haas robertmh...@gmail.com wrote: On Mon, Feb 9, 2015 at 7:02 AM, Michael Paquier michael.paqu...@gmail.com wrote: On Mon, Feb 9, 2015 at 7:58 PM, Fujii Masao masao.fu...@gmail.com wrote: MemoryContextAllocExtended() was added, so isn't it time to

Re: [HACKERS] reducing our reliance on MD5

2015-02-11 Thread Heikki Linnakangas
On 02/11/2015 05:57 AM, Tom Lane wrote: In any case, my larger point was that given the pain that we're going to incur here, and the certainly years-long transition interval involved, it would be foolish to think only about replacing the MD5 algorithm and not about reconsidering the context we

Re: [HACKERS] GSoC 2015 - mentors, students and admins.

2015-02-11 Thread Вадим Грибанов
Hi Thom! I'm interested to participate as student. On 9 Feb 2015 23:54, Thom Brown t...@linux.com wrote: Hi all, Google Summer of Code 2015 is approaching. I'm intending on registering PostgreSQL again this year. Before I do that, I'd like to have an idea of how many people are

Re: [HACKERS] reducing our reliance on MD5

2015-02-11 Thread Heikki Linnakangas
On 02/11/2015 04:38 AM, Tom Lane wrote: Peter Eisentraut pete...@gmx.net writes: On 2/10/15 8:28 PM, Robert Haas wrote: I don't actually care which algorithm we use, and I dowannahafta care. What I do want to do is provide a framework so that, when somebody discovers that X is better than Y

Re: [HACKERS] What exactly is our CRC algorithm?

2015-02-11 Thread Abhijit Menon-Sen
At 2015-02-10 14:30:51 +0200, hlinnakan...@vmware.com wrote: I propose that we add a new header file in src/port, let's call it crc_instructions.h […] the point of the crc_instructions.h header is to hide the differences between compilers and architectures. Moving the assembly code/compiler

Re: [HACKERS] What exactly is our CRC algorithm?

2015-02-11 Thread Heikki Linnakangas
On 02/11/2015 11:28 AM, Abhijit Menon-Sen wrote: 1. I don't mind moving platform-specific tests for CRC32C instructions to configure, but if we only define PG_HAVE_CRC32C_INSTRUCTIONS, we would anyway have to reproduce all that platform-specific stuff in the header file. To do it

Re: [HACKERS] reducing our reliance on MD5

2015-02-11 Thread Robert Haas
On Wed, Feb 11, 2015 at 4:13 AM, Heikki Linnakangas hlinnakan...@vmware.com wrote: For the first cut, I propose: 1. Implement SASL. The server sends a new AuthenticationSASLRequest message, to which the client responds with AuthenticationSASLResponse message. These messages carry the SASL

Re: [HACKERS] reducing our reliance on MD5

2015-02-11 Thread Álvaro Hernández Tortosa
On 11/02/15 02:30, Tom Lane wrote: [...] I think it would be wise to take two steps back and think about what the threat model is here, and what we actually need to improve. Offhand I can remember two distinct things we might wish to have more protection against: * scraping of passwords off

Re: [HACKERS] GSoC 2015 - mentors, students and admins.

2015-02-11 Thread Anastasia Lubennikova
I'm interested to participate as student again. -- Best regards, Lubennikova Anastasia

Re: [HACKERS] SSL renegotiation and other related woes

2015-02-11 Thread Heikki Linnakangas
On 02/05/2015 11:03 PM, Heikki Linnakangas wrote: On 01/26/2015 12:14 PM, Andres Freund wrote: Can we work-around that easily? I believe we can. The crucial part is that we mustn't let SSL_write() to process any incoming application data. We can achieve that if we always call SSL_read() to drain

Re: [HACKERS] reducing our reliance on MD5

2015-02-11 Thread Heikki Linnakangas
On 02/11/2015 02:49 PM, Robert Haas wrote: So, this all sounds fairly nice if somebody's willing to do the work, but I can't help noticing that you originally proposed adopting SCRAM in 2012, and it's 2015 now. So I wonder if anyone's really going to do all this work, and if not, whether we

Re: [HACKERS] Manipulating complex types as non-contiguous structures in-memory

2015-02-11 Thread Tom Lane
Jim Nasby jim.na...@bluetreble.com writes: On 2/10/15 5:19 PM, Tom Lane wrote: What do you mean by non-variant? Ugh, sorry, brainfart. I meant to say non-varlena. I can't think of any non-varlena types we'd want this for, but maybe someone else can think of a case. If there is a use-case I

Re: [HACKERS] reducing our reliance on MD5

2015-02-11 Thread Magnus Hagander
On Wed, Feb 11, 2015 at 4:57 AM, Tom Lane t...@sss.pgh.pa.us wrote: Robert Haas robertmh...@gmail.com writes: On Tue, Feb 10, 2015 at 9:30 PM, Tom Lane t...@sss.pgh.pa.us wrote: Another thing we need to keep in mind besides client compatibility is dump/reload compatibility. I don't

Re: [HACKERS] GRANT USAGE on FOREIGN SERVER exposes passwords

2015-02-11 Thread Tom Lane
Jim Nasby jim.na...@bluetreble.com writes: On 2/5/15 10:48 AM, Tom Lane wrote: The dblink example is entirely uncompelling, given that as you said somebody with access to a dblink connection could execute ALTER USER on the far end. Actually, you can eliminate that by not granting direct

Re: [HACKERS] 9.6 Feature help requested: Inclusion Constraints

2015-02-11 Thread David Fetter
On Tue, Feb 10, 2015 at 09:47:22PM -0500, Peter Eisentraut wrote: On 2/9/15 3:12 AM, Jeff Davis wrote: On Sat, 2015-02-07 at 16:08 -0800, Jeff Davis wrote: I believe Inclusion Constraints will be important for postgres. I forgot to credit Darren Duncan with the name of this feature:

Re: [HACKERS] ibm system z in the buildfarm

2015-02-11 Thread David Fetter
On Tue, Feb 10, 2015 at 05:49:18PM -0800, Mark Wong wrote: Hi everyone, I've seen in the archive a call for more architecture coverage so I just wanted to send a quick note that there is now Linux on System Z in the buildfarm now:

Re: [HACKERS] assessing parallel-safety

2015-02-11 Thread Noah Misch
On Wed, Feb 11, 2015 at 03:21:12PM -0500, Robert Haas wrote: On Wed, Feb 11, 2015 at 9:39 AM, Robert Haas robertmh...@gmail.com wrote: This does not seem to work out nicely. The problem here is that simplify_function() gets called from eval_const_expressions() which gets called from a