Re: [HACKERS] Aggregate transition state merging vs. hypothetical set functions

On 10/13/2017 02:41 AM, Tom Lane wrote: David Rowley writes: On 13 October 2017 at 12:08, Tom Lane wrote: Therefore, I think we need to bite the bullet and provide an aggregate property (CREATE AGGREGATE argument / pg_aggregate column) that

Re: [HACKERS] Aggregate transition state merging vs. hypothetical set functions

On 10/13/2017 02:08 AM, Tom Lane wrote: I started to look into fixing orderedsetaggs.c so that we could revert 52328727b, and soon found a rather nasty problem. Although the plain OSAs seem amenable to supporting multiple finalfn calls on the same transition state, the "hypothetical set"

Re: [HACKERS] Binary search in fmgr_isbuiltin() is a bottleneck.

On 10/04/2017 10:33 AM, Andres Freund wrote: On 2017-10-02 15:01:36 -0700, Andres Freund wrote: On 2017-10-02 17:57:51 -0400, Tom Lane wrote: Andres Freund writes: Done that way. It's a bit annoying, because we've to take care to initialize the "unused" part of the array

Re: [HACKERS] pgbench - minor fix for meta command only scripts

On 09/29/2017 08:43 PM, Fabien COELHO wrote: reality. So I don't know if this needs backpatching or not. But it should be fixed for v10, as there it becomes a demonstrably live issue. Yes. Patch looks good to me, so committed to master and v10. Thanks! - Heikki -- Sent via pgsql-hackers

Re: [HACKERS] SCRAM in the PG 10 release notes

On 09/18/2017 11:13 AM, Noah Misch wrote: On Thu, Sep 14, 2017 at 09:57:36AM +0300, Heikki Linnakangas wrote: On 09/12/2017 04:09 AM, Noah Misch wrote: On Wed, May 10, 2017 at 10:50:51PM -0400, Bruce Momjian wrote: On Mon, May 1, 2017 at 08:12:51AM -0400, Robert Haas wrote: On Tue, Apr 25

Re: [HACKERS] SCRAM in the PG 10 release notes

On 09/12/2017 04:09 AM, Noah Misch wrote: On Wed, May 10, 2017 at 10:50:51PM -0400, Bruce Momjian wrote: On Mon, May 1, 2017 at 08:12:51AM -0400, Robert Haas wrote: On Tue, Apr 25, 2017 at 10:16 PM, Bruce Momjian wrote: Well, we could add "MD5 users are encouraged to

Re: [HACKERS] SCRAM salt length

On 08/17/2017 05:23 PM, Peter Eisentraut wrote: On 8/17/17 09:21, Heikki Linnakangas wrote: The RFC doesn't say anything about salt length, but the one example in it uses a 16 byte string as the salt. That's more or less equal to the current default of 12 raw bytes, after base64-encoding

Re: [HACKERS] SCRAM salt length

On 08/17/2017 04:04 PM, Robert Haas wrote: On Wed, Aug 16, 2017 at 10:42 PM, Michael Paquier wrote: In the initial discussions there was as well a mention about using 16 bytes. https://www.postgresql.org/message-id/507550bd.2030...@vmware.com As we are using

Re: [HACKERS] Atomics for heap_parallelscan_nextpage()

On 08/17/2017 12:20 AM, Tom Lane wrote: Andres Freund <and...@anarazel.de> writes: On 2017-08-16 16:20:28 +0300, Heikki Linnakangas wrote: + pg_atomic_write_u64(>phs_nallocated, 0); It's not ok to initialize an atomic with pg_atomic_write_u64 - works well enough for "

Re: [HACKERS] Atomics for heap_parallelscan_nextpage()

On 08/16/2017 09:00 PM, Tom Lane wrote: Robert Haas writes: On Wed, Aug 16, 2017 at 1:44 PM, Tom Lane wrote: I was feeling a bit uncomfortable with the BUFFERALIGN_DOWN() for a different reason: if the caller has specified the exact amount of space

Re: [HACKERS] Atomics for heap_parallelscan_nextpage()

On 08/16/2017 08:10 PM, Andres Freund wrote: Afaict shm_create/shm_toc_allocate don't actually guarantee that the end of the toc's memory is suitably aligned. But I didn't yet have any coffee, so ... Robert, I'm not quite sure what the intended behaviour of shm_toc is wrt alignment. I see

Re: [HACKERS] Atomics for heap_parallelscan_nextpage()

On 08/16/2017 04:20 PM, Heikki Linnakangas wrote: On 05/06/2017 04:57 PM, David Rowley wrote: Andres mentioned in [2] that it might be worth exploring using atomics to do the same job. So I went ahead and did that, and came up with the attached, which is a slight variation on what he mentioned

Re: [HACKERS] Atomics for heap_parallelscan_nextpage()

On 05/06/2017 04:57 PM, David Rowley wrote: Andres mentioned in [2] that it might be worth exploring using atomics to do the same job. So I went ahead and did that, and came up with the attached, which is a slight variation on what he mentioned in the thread. To keep things a bit more simple,

Re: [HACKERS] Refactoring identifier checks to consistently use strcmp

On 04/04/2017 10:13 AM, Daniel Gustafsson wrote: On 04 Apr 2017, at 05:52, Alvaro Herrera wrote: Daniel Gustafsson wrote: Testing DefElem options is done with both strcmp() and pg_strcasecmp() a bit mixed. Since the option defnames are all lowercased, either via

[HACKERS] Use PG_DETOAST_DATUM_SLICE in bitlength() (was Re: PG_GETARG_GISTENTRY?)

On 04/25/2017 04:10 AM, Noah Misch wrote: On Mon, Apr 24, 2017 at 09:25:25AM -0700, Mark Dilger wrote: Noah, if you left this case out intentionally, sorry for the noise. I did not immediately see any reason not to follow your lead for this function. This is not following my lead, but that

Re: [HACKERS] [PATCH] Remove unused argument in btree_xlog_split

On 04/06/2017 03:21 PM, Aleksander Alekseev wrote: Hi Robert, Hmm. I don't see anything wrong with that, particularly, but it seems we also don't need the distinction between XLOG_BTREE_SPLIT_L and XLOG_BTREE_SPLIT_L_ROOT or likewise between XLOG_BTREE_SPLIT_R and XLOG_BTREE_SPLIT_R_ROOT --

Re: [HACKERS] Support for Secure Transport SSL library on macOS as OpenSSL alternative

On 08/03/2017 01:02 PM, Daniel Gustafsson wrote: In https://postgr.es/m/69db7657-3f9d-4d30-8a4b-e06034251...@yesql.se I presented a WIP patch for adding support for the Apple Secure Transport SSL library on macOS as, an alternative to OpenSSL. That patch got put on the backburner for a bit, but

Re: [HACKERS] PostgreSQL - Weak DH group

On 07/31/2017 02:27 PM, Heikki Linnakangas wrote: Rebased patch attached, with proposed release notes included. Barring new objections or arguments, I'll commit this (only) to v10 later today. Ok, committed for v10. Thanks Nicolas and Damien, and everyone else involved! - Heikki -- Sent

Re: [HACKERS] PostgreSQL not setting OpenSSL session id context?

On 07/31/2017 02:24 AM, Shay Rojansky wrote: Just to continue the above, I can confirm that adding a simple call to SSL_CTX_set_session_id_context() to be_tls_init() with some arbitrary const value fixes the error for me. Attached is a patch (ideally a test should be done for this, but that's

Re: [HACKERS] PostgreSQL - Weak DH group

On 07/13/2017 11:07 PM, Heikki Linnakangas wrote: On 07/13/2017 10:13 PM, Robert Haas wrote: On Thu, Jul 13, 2017 at 1:30 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: Heikki Linnakangas <hlinn...@iki.fi> writes: I don't think this can be backpatched. It changes the default DH paramete

[HACKERS] Re: [BUGS] BUG #14634: On Windows pg_basebackup should write tar to stdout in binary mode

On 07/14/2017 05:27 AM, Haribabu Kommi wrote: On Fri, Jul 14, 2017 at 2:54 AM, Heikki Linnakangas <hlinn...@iki.fi> wrote: On 05/03/2017 07:32 AM, Haribabu Kommi wrote: [Adding -hackers mailing list] On Fri, Apr 28, 2017 at 6:28 PM, <henry_boehl...@agilent.com> wrote: Execu

Re: [HACKERS] PostgreSQL - Weak DH group

On 07/13/2017 10:13 PM, Robert Haas wrote: On Thu, Jul 13, 2017 at 1:30 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: Heikki Linnakangas <hlinn...@iki.fi> writes: I don't think this can be backpatched. It changes the default DH parameters from 1024 bits to 2048 bits. That's

Re: [HACKERS] Fixup some misusage of appendStringInfo and friends

On 04/27/2017 03:14 AM, David Rowley wrote: On 27 April 2017 at 06:41, Peter Eisentraut wrote: On 4/19/17 08:42, Ashutosh Bapat wrote: I reviewed the patch. It compiles clean, make check-world passes. I do not see any issue with it. Looks reasonable. Let's

Re: [HACKERS] PostgreSQL - Weak DH group

On 07/13/2017 08:04 PM, Alvaro Herrera wrote: Michael Paquier wrote: On Thu, Jul 13, 2017 at 5:32 PM, Heikki Linnakangas <hlinn...@iki.fi> wrote: Objections to committing this now, instead of waiting for v11? But I am -1 for the sneak part. It is not the time to have a new feature

[HACKERS] Re: [BUGS] BUG #14634: On Windows pg_basebackup should write tar to stdout in binary mode

On 05/03/2017 07:32 AM, Haribabu Kommi wrote: [Adding -hackers mailing list] On Fri, Apr 28, 2017 at 6:28 PM, wrote: The following bug has been logged on the website: Bug reference: 14634 Logged by: Henry Boehlert Email address:

Re: [HACKERS] PostgreSQL - Weak DH group

(We dropped the ball back in October, continuing the discussion now) On 10/10/2016 06:24 PM, Heikki Linnakangas wrote: On 10/06/2016 10:26 PM, Christoph Berg wrote: Re: Heikki Linnakangas 2016-10-06 <fd6eb3cc-1585-1469-fd9e-763f8e410...@iki.fi> I propose the attached patch. It gi

Re: [HACKERS] Race condition in GetOldestActiveTransactionId()

On 08/22/2016 01:46 PM, Heikki Linnakangas wrote: While hacking on the CSN patch, I spotted a race condition between GetOldestActiveTransactionId() and GetNewTransactionId(). GetOldestActiveTransactionId() calculates the oldest XID that's still running, by doing: 1. Read nextXid, without a lock

Re: [HACKERS] Typo in backend/storage/ipc/standby.c

On 07/11/2017 10:34 AM, Kyotaro HORIGUCHI wrote: Hello. I noticed that a comment above StandbyAcquireAccessExclusiveLock in backend/storage/ipc/standby.c using wrong names of a variable and a type. The attached patch fixes it. The same mistake is found in older versions back to 9.0.

Re: [HACKERS] Minor style cleanup in tab-complete.c

On 07/12/2017 07:39 AM, Michael Paquier wrote: On Wed, Jul 12, 2017 at 11:19 AM, Thomas Munro wrote: From the triviality department: I noticed some branches in tab-complete.c's gargantuan if statement, mostly brand new, that break from the established brace

[HACKERS] Re: [COMMITTERS] pgsql: Allow multiple hostaddrs to go with multiple hostnames.

On 07/10/2017 01:27 PM, Masahiko Sawada wrote: This commit seems be cause of the documentation compilation error. I think is missing. ... Attached small patch fixes this. Thanks, committed! Strangely, it worked on my system, despite that clear mistake. Looks like the 'osx' tool is more

Re: [HACKERS] List of hostaddrs not supported

On 07/10/2017 01:47 PM, Arthur Zakirov wrote: Hello, 2017-07-10 12:30 GMT+03:00 Heikki Linnakangas <hlinn...@iki.fi>: I just remembered that this was still pending. I made the documentation changes, and committed this patch now. We're uncomfortably close to wrapping the next beta,

Re: [HACKERS] List of hostaddrs not supported

On 06/09/2017 04:26 PM, Robert Haas wrote: On Fri, Jun 9, 2017 at 6:36 AM, Heikki Linnakangas <hlinn...@iki.fi> wrote: Right. I think it's a usability fail as it is; it certainly fooled me. We could make the error messages and documentation more clear. But even better to allow multipl

Re: [HACKERS] AdvanceXLInsertBuffer vs. WAL segment compressibility

On 07/03/2017 06:30 PM, Chapman Flack wrote: On 07/03/2017 09:39 AM, Heikki Linnakangas wrote: Hmm. That's not the problem, though. Imagine that instead of the loop above, you do just: WALInsertLockUpdateInsertingAt(CurrPos); AdvanceXLInsertBuffer(EndPos, false); AdvanceXLInsertBuffer

Re: [HACKERS] AdvanceXLInsertBuffer vs. WAL segment compressibility

On 06/26/2017 04:20 AM, Chapman Flack wrote: I notice CopyXLogRecordToWAL contains this loop (in the case where the record being copied is a switch): while (CurrPos < EndPos) { /* initialize the next page (if not initialized already) */ WALInsertLockUpdateInsertingAt(CurrPos);

Re: [HACKERS] Error-like LOG when connecting with SSL for password authentication

On 05/24/2017 05:29 PM, Michael Paquier wrote: Attached is an updated patch. Thanks, I've pushed the backend read part of this patch. That's enough to fix the original complaint with password authentication. I think the rest was a bit dubious, and I'm hesitant to commit that (or at least to

Re: [HACKERS] gen_random_uuid security not explicit in documentation

On 30 June 2017 06:45:04 EEST, Noah Misch wrote: >This PostgreSQL 10 open item is past due for your status update. >Kindly send >a status update within 24 hours, and include a date for your subsequent >status >update. I'll fix this some time next week. (I'm on vacation

Re: [HACKERS] Comment typo in execMain.c

On 06/21/2017 11:35 AM, Etsuro Fujita wrote: Here is a patch to fix a typo in a comment in ExecWithCheckOptions(): s/as as/as/. Fixed, thanks! - Heikki -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription:

Re: [HACKERS] AdvanceXLInsertBuffer vs. WAL segment compressibility

(I'm cleaning up my inbox, hence the delayed reply) On 08/02/2016 10:51 PM, Robert Haas wrote: On Tue, Aug 2, 2016 at 2:33 PM, Bruce Momjian wrote: On Tue, Jul 26, 2016 at 05:42:43PM -0400, Chapman Flack wrote: Even so, I'd be curious whether it would break anything to have

Re: [HACKERS] GSoC 2017 : Patch for predicate locking in Gist index

On 06/21/2017 10:41 AM, Heikki Linnakangas wrote: On 06/16/2017 01:24 PM, Shubham Barai wrote: @@ -497,6 +499,13 @@ gistplacetopage(Relation rel, Size freespace, GISTSTATE *giststate, for (ptr = dist->next; ptr; ptr = ptr-&g

Re: [HACKERS] GSoC 2017 : Patch for predicate locking in Gist index

On 06/16/2017 01:24 PM, Shubham Barai wrote: @@ -497,6 +499,13 @@ gistplacetopage(Relation rel, Size freespace, GISTSTATE *giststate, for (ptr = dist->next; ptr; ptr = ptr->next) UnlockReleaseBuffer(ptr->buffer); } + +

Re: [HACKERS] [GSOC][weekly report 3] Eliminate O(N^2) scaling from rw-conflict tracking in serializable transactions

On 06/20/2017 06:51 AM, Mengxing Liu wrote: But in my benchmark, the throughput decrease by 15% after the modification. Can you help me do a quick review to find if there is anything wrong? I also attached the flame graph before/after the modification for reference. Hmm. The hash table ought

Re: [HACKERS] Phantom segment upon promotion causing troubles.

On 06/19/2017 10:30 AM, Andres Freund wrote: Greg Burek from Heroku (CCed) reported a weird issue on IM, that was weird enough to be interesting. What he'd observed was that he promoted some PITR standby, and early clones of that node work, but later clones did not, failing to read some

Re: [HACKERS] [GSOC] [Weekly report 2] Eliminate O(N^2) scaling from rw-conflict tracking in serializable transactions

On 06/15/2017 08:51 AM, Mengxing Liu wrote: My design is as follow: For hash table, key is the pointer of SerializableXact; Value is the RWConflictData object. Hashcode is generated based on the SerializableXact pointer. So, given a SerializableXact, we can quickly find if it is conflict with

Re: [HACKERS] List of hostaddrs not supported

On 06/09/2017 05:47 PM, Jeff Janes wrote: Your commit to fix this part, 76b11e8a43eca4612d, is giving me compiler warnings: fe-connect.c: In function 'connectDBStart': fe-connect.c:1625: warning: 'ret' may be used uninitialized in this function gcc version 4.4.7 20120313 (Red Hat 4.4.7-18)

Re: [HACKERS] List of hostaddrs not supported

On 06/08/2017 06:18 PM, Robert Haas wrote: On Thu, Jun 8, 2017 at 10:50 AM, Tom Lane wrote: Robert Haas writes: It doesn't seem like a problem to me if somebody else wants to extend it to hostaddr, though. Whether that change belongs in v10 or v11

Re: [HACKERS] List of hostaddrs not supported

On 06/08/2017 06:39 PM, David G. Johnston wrote: These are already failing so I'd agree that explicit rejection isn't necessary - the question seems restricted to usability. Though I suppose we need to consider whether there is any problem with the current setup if indeed our intended separator

Re: [HACKERS] How to refer to resource files from UDFs written in C

On 06/09/2017 08:56 AM, Supun Nakandala wrote: Hi hackers, I am trying to extend PostgreSQL by adding UDT and UDF for a custom use case and I am using C language extensions to do that. However, I have a requirement of reading a text file from one of the C functions. The compiled *.so files are

Re: [HACKERS] PG10 transition tables, wCTEs and multiple operations on the same table

On 06/08/2017 08:36 PM, Robert Haas wrote: I freely admit I encouraged you to commit this. I did not imagine that would be followed immediately by abdicating all responsibility for it. My mistake, I guess. Robert, chill out. Kevin offered to revert. It's perhaps not the best way forward -

[HACKERS] List of hostaddrs not supported

While testing libpq and GSS the other day, I was surprised by the behavior of the host and hostaddr libpq options, if you specify a list of hostnames. I did this this, and it took me quite a while to figure out what was going on: $ psql "dbname=postgres hostaddr=::1

Re: [HACKERS] Server ignores contents of SASLInitialResponse

On 06/06/2017 06:09 AM, Michael Paquier wrote: On Thu, Jun 1, 2017 at 4:58 AM, Heikki Linnakangas <hlinn...@iki.fi> wrote: To fix, I suppose we can do what you did for SASL in your patch, and move the cleanup of conn->gctx from closePGconn to pgDropConnection. And I presume we n

Re: [HACKERS] Challenges preventing us moving to 64 bit transaction id (XID)?

On 06/06/2017 07:24 AM, Ashutosh Bapat wrote: On Tue, Jun 6, 2017 at 9:48 AM, Craig Ringer wrote: On 6 June 2017 at 12:13, Ashutosh Bapat wrote: What happens when the epoch is so low that the rest of the XID does not fit in 32bits of

Re: [HACKERS] Challenges preventing us moving to 64 bit transaction id (XID)?

On 06/05/2017 11:49 AM, Tianzhou Chen wrote: Hi Pg Hackers, XID wraparound seems to be quite a big concern and we introduce changes like “adding another frozen bit to each page” [http://rhaas.blogspot.com/2016/03/no-more-full-table-vacuums.html

Re: [HACKERS] simplehash.h typo

On 06/05/2017 11:26 AM, Andres Freund wrote: On 2017-06-05 11:10:12 +0300, Heikki Linnakangas wrote: Fixed, thanks. I also fixed and clarified some other comments in the file that seemed wrong or confusing to me. Thanks for looking - I don't see any commit though? Pushed now. Note to self

Re: [HACKERS] Server ignores contents of SASLInitialResponse

On 06/05/2017 09:34 AM, Michael Paquier wrote: On Mon, Jun 5, 2017 at 7:49 AM, Noah Misch wrote: IMMEDIATE ATTENTION REQUIRED. This PostgreSQL 10 open item is long past due for your status update. Please reacquaint yourself with the policy on open item ownership[1] and

Re: [HACKERS] simplehash.h typo

On 05/28/2017 04:50 AM, Jeff Janes wrote: /* round up size to the next power of 2, that's the bucketing works */ That should probably be "that's the **way** bucketing works". Or maybe it is an idiom I don't grok. Fixed, thanks. I also fixed and clarified some other comments in the

Re: [HACKERS] Server ignores contents of SASLInitialResponse

On 05/25/2017 06:36 PM, Michael Paquier wrote: On Thu, May 25, 2017 at 10:52 AM, Michael Paquier wrote: Actually, I don't think that we are completely done here. Using the patch of upthread to enforce a failure on SASLInitialResponse, I see that connecting without

Re: [HACKERS] Server ignores contents of SASLInitialResponse

On 05/24/2017 11:33 PM, Michael Paquier wrote: I have noticed today that the server ignores completely the contents of SASLInitialResponse. ... Attached is a patch to fix the problem. Fixed, thanks! - Heikki -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make

Re: [HACKERS] Tightening isspace() tests where behavior should match SQL parser

On 05/20/2017 01:48 PM, Tom Lane wrote: Attached is a proposed patch. I'm vacillating on whether to back-patch this --- it will fix a reported bug, but it seems at least somewhat conceivable that it will also break cases that were working acceptably before. Thoughts? +1 for back-patching. If

Re: [HACKERS] Error-like LOG when connecting with SSL for password authentication

On 05/22/2017 10:11 PM, Vaishnavi Prabakaran wrote: On Mon, May 22, 2017 at 5:10 PM, Michael Paquier wrote: If the protocol version is SSL 3.0 or TLS 1.0, this result code is returned only if a closure alert has occurred in the protocol, i.e. if the connection has

Re: [HACKERS] Error-like LOG when connecting with SSL for password authentication

On 05/22/2017 03:10 AM, Michael Paquier wrote: Hi all, When attempting to connect using password authentication through SSL, the backend will complain in its log with the following entry before calling sendAuthRequest(), which asks the client for a password: LOG: could not receive data from

Re: [HACKERS] Removal of plaintext password type references

On 05/20/2017 05:41 AM, Tom Lane wrote: Robert Haas writes: I guess it does seem likely that most users of the hook would need to do the same, but it seems confusing to pass the same function both x and f(x), so my vote is to not do that. Right, that was my thinking.

Re: [HACKERS] Preliminary results for proposed new pgindent implementation

On 05/19/2017 06:48 PM, Tom Lane wrote: Heikki Linnakangas <hlinn...@iki.fi> writes: You can get a pretty good typedefs list just by looking for the pattern "} ;". That's going to catch a lot of things that are just variables, though. It might be all right as long as

Re: [HACKERS] Preliminary results for proposed new pgindent implementation

On 05/19/2017 06:05 PM, Stephen Frost wrote: * Tom Lane (t...@sss.pgh.pa.us) wrote: Robert Haas writes: On Thu, May 18, 2017 at 11:00 PM, Tom Lane wrote: The reason PGSSTrackLevel is "unrecognized" is that it's not in typedefs.list, which is a

Re: [HACKERS] PostgreSQL 10beta1 - compilation fails on OpenBSD -current

On 05/19/2017 12:03 PM, Pierre-Emmanuel André wrote: Hi, I tried to build PostgreSQL 10beta1 on OpenBSD -current and i have this error: gmake[3]: Entering directory '/usr/ports/pobj/postgresql-10beta1/postgresql-10beta1/src/backend/libpq' cc -Wall -Wmissing-prototypes -Wpointer-arith

Re: [HACKERS] 10beta1/m68k: static assertion failed: "MAXALIGN too small to fit int32"

On 05/18/2017 12:31 PM, Christoph Berg wrote: Re: Heikki Linnakangas 2017-05-18 <e0bfad8e-ec5d-28ee-ebbc-4670d465b...@iki.fi> I'll commit that, barring objections. If you can verify that it fixes the problem before that, that'd be great, otherwise I guess we'll find out some time

Re: [HACKERS] 10beta1/m68k: static assertion failed: "MAXALIGN too small to fit int32"

On 05/17/2017 10:39 PM, Christoph Berg wrote: Not sure if a lot of people still care about m68k, but it's still one of the unofficial Debian ports (it used to be the first non-x86 port done decades ago): gcc -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement -Wendif-labels

Re: [HACKERS] Typo in json.c

On 05/18/2017 10:17 AM, Daniel Gustafsson wrote: Spotted while reading code, patch attached. Applied, thanks. - Heikki -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Removal of plaintext password type references

On 05/15/2017 07:03 AM, Noah Misch wrote: On Thu, May 11, 2017 at 10:08:30AM +0900, Michael Paquier wrote: On Wed, May 10, 2017 at 10:22 PM, Michael Paquier <michael.paqu...@gmail.com> wrote: On Wed, May 10, 2017 at 10:01 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: Heikki Linnak

[HACKERS] Pulling up more complicated subqueries

Hi, I spent some time staring at TPC-DS benchmark's query 6. It contains a somewhat complicated subquery, and most of the time spent on that query is currently spent on executing the subquery again and again. The essence of the query boils down to this: CREATE TABLE foo (i int4, j int4);

Re: [HACKERS] Receive buffer size for the statistics socket

On 05/14/2017 09:54 PM, Tom Lane wrote: Also, it's clear that a session could easily shove much more than 8KB at a time out to the stats collector, because what we're doing in the stats test does not involve touching any very large number of tables. So I think this is not just a test failure

Re: [HACKERS] Small improvement to compactify_tuples

On 05/14/2017 09:47 PM, Sokolov Yura wrote: Good day, everyone. I've been playing a bit with unlogged tables - just random updates on simple key-value table. I've noticed amount of cpu spent in a compactify_tuples (called by PageRepareFragmentaion). Most of time were spent in qsort of

Re: [HACKERS] eval_const_expresisions and ScalarArrayOpExpr

On 05/11/2017 06:21 PM, Tom Lane wrote: Heikki Linnakangas <hlinn...@iki.fi> writes: Eval_const_expressions() doesn't know about ScalarArrayOpExpr. ... That seems like an oversight. I guess that scenario doesn't happen very often in practice, but there's no reason not to do it when i

[HACKERS] eval_const_expresisions and ScalarArrayOpExpr

Eval_const_expressions() doesn't know about ScalarArrayOpExpr. We simplify the arguments, but if all the arguments are booleans, we don't take the obvious step of replacing the whole expression with a boolean Const. For example: postgres=# explain select * from foo where 1 IN (1,2,3);

Re: [HACKERS] SCRAM in the PG 10 release notes

On 05/11/2017 07:03 AM, Michael Paquier wrote: On Thu, May 11, 2017 at 11:50 AM, Bruce Momjian wrote: I have added this as an open item because we will have to wait to see where we are with driver support as the release gets closer. As Postgres ODBC now has a hard

Re: [HACKERS] Removal of plaintext password type references

On 05/10/2017 08:01 AM, Michael Paquier wrote: On Wed, May 10, 2017 at 10:51 AM, Vaishnavi Prabakaran wrote: Following recent removal of support to store password in plain text, modified the code to 1. Remove "PASSWORD_TYPE_PLAINTEXT" macro 2. Instead of using

Re: [HACKERS] password_encryption, default and 'plain' support

On 05/05/2017 03:42 PM, Michael Paquier wrote: +This option is obsolete but still accepted for backwards +compatibility. Isn't that incorrect English? It seems to me that this be non-plural, as "for backward compatibility". I changed most cases to "backward compatibility",

Re: [HACKERS] password_encryption, default and 'plain' support

On 05/06/2017 01:56 PM, Gavin Flower wrote: On 06/05/17 22:44, Vik Fearing wrote: On 05/05/2017 02:42 PM, Michael Paquier wrote: +This option is obsolete but still accepted for backwards +compatibility. Isn't that incorrect English? No. It seems to me that this be

Re: [HACKERS] Error message on missing SCRAM authentication with older clients

On 05/05/2017 11:26 AM, Magnus Hagander wrote: On Fri, May 5, 2017 at 10:19 AM, Aleksander Alekseev < a.aleks...@postgrespro.ru> wrote: psql: SCRAM authentication requires libpq version 10 or above Sounds good. +1. Ok, committed. Thanks! - Heikki -- Sent via pgsql-hackers mailing

Re: [HACKERS] Some thoughts about SCRAM implementation

On 04/10/2017 09:28 PM, Álvaro Hernández Tortosa wrote: On 10/04/17 13:02, Heikki Linnakangas wrote: On 04/10/2017 12:39 PM, Álvaro Hernández Tortosa wrote: * The nonce length is not specified by the RFC. I see typical implementations use 24 chars for the client and 18 for the server. Current

Re: [HACKERS] Authentication tests, and plain 'password' authentication with a SCRAM verifier

On 03/14/2017 09:25 PM, Heikki Linnakangas wrote: On 03/14/2017 09:02 PM, Jeff Janes wrote: The message returned to the client for the wrong password differs between pg_hba-set scram and pg_hba-set md5/password methods. Is that OK? psql: error received from server in SASL exchange: invalid

Re: [HACKERS] Error message on missing SCRAM authentication with older clients

On 05/03/2017 03:12 PM, Aleksander Alekseev wrote: Hi Heikki, psql: SCRAM authentication not supported by this version of libpq Maybe it would be better to specify a minimum required version? Yeah, that could be helpful. Can you suggest a wording? My first thought was: psql: SCRAM

Re: [HACKERS] password_encryption, default and 'plain' support

kki >From 62d42e07fe09dcb8586620ee66b1567a8f002f27 Mon Sep 17 00:00:00 2001 From: Heikki Linnakangas <heikki.linnakan...@iki.fi> Date: Thu, 4 May 2017 14:31:45 +0300 Subject: [PATCH 1/1] Remove support for password_encryption='off' / 'plain'. Storing passwords in plaintext hasn't been a good idea for a very

Re: [HACKERS] password_encryption, default and 'plain' support

On 05/03/2017 07:14 PM, Tom Lane wrote: Robert Haas <robertmh...@gmail.com> writes: On Wed, May 3, 2017 at 7:31 AM, Heikki Linnakangas <hlinn...@iki.fi> wrote: So, I propose that we remove support for password_encryption='plain' in PostgreSQL 10. If you try to do that, you'll

[HACKERS] Error message on missing SCRAM authentication with older clients

Currently, if you use 9.6 libpq to connect to a v10 server that requires SCRAM authentication, you get an error: psql: authentication method 10 not supported I'd like to apply this small patch to all the stable branches, to give a nicer error message: psql: SCRAM authentication not

[HACKERS] password_encryption, default and 'plain' support

Hi, In various threads on SCRAM, we've skirted around the question of whether we should still allow storing passwords in plaintext. I've avoided discussing that in those other threads, because it's been an orthogonal question, but it's a good question and we should discuss it. So, I propose

[HACKERS] Error message on missing SCRAM authentication with older clients

Currently, if you use 9.6 libpq to connect to a v10 server that requires SCRAM authentication, you get an error: psql: authentication method 10 not supported I'd like to apply this small patch to all the stable branches, to give a nicer error message: psql: SCRAM authentication not

Re: [HACKERS] scram and \password

On 05/02/2017 07:47 PM, Robert Haas wrote: On Tue, May 2, 2017 at 3:42 AM, Heikki Linnakangas <hlinn...@iki.fi> wrote: There's going to be a default, one way or another. The default is going to come from password_encryption, or it's going to be a hard-coded value or logic based on

Re: [HACKERS] SCRAM authentication, take three

On 05/02/2017 09:57 PM, Robert Haas wrote: Does db_user_namespace work with SCRAM? Yes. Haven't tested it, come to think of it, but it should work. - Heikki -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription:

Re: [HACKERS] scram and \password

On 05/01/2017 07:04 PM, Robert Haas wrote: On Thu, Apr 27, 2017 at 3:22 AM, Heikki Linnakangas <hlinn...@iki.fi> wrote: You could argue, that since we need to document how to avoid the query and the blocking, we might as well always require the application to run the "show password

Re: [HACKERS] scram and \password

On 04/28/2017 07:49 AM, Noah Misch wrote: On Fri, Apr 21, 2017 at 11:04:14PM +0300, Heikki Linnakangas wrote: I'll continue reviewing the rest of the patch on Monday, but [...] This PostgreSQL 10 open item is past due for your status update. Kindly send a status update within 24 hours

Re: [HACKERS] scram and \password

On 04/26/2017 07:57 PM, Tom Lane wrote: Robert Haas <robertmh...@gmail.com> writes: On Wed, Apr 26, 2017 at 6:22 AM, Heikki Linnakangas <hlinn...@iki.fi> wrote: * If algorithm is not given explicitly, PQencryptPasswordConn() queries "SHOW password_encryption", and uses th

Re: [HACKERS] scram and \password

On 04/25/2017 06:26 PM, Heikki Linnakangas wrote: Thoughts? Unless someone has better ideas or objections, I'll go implement that. This is what I came up with in the end. Some highlights and differences vs the plan I posted earlier: * If algorithm is not given explicitly

Re: [HACKERS] scram and \password

On 04/22/2017 01:20 AM, Michael Paquier wrote: On Sat, Apr 22, 2017 at 5:04 AM, Heikki Linnakangas <hlinn...@iki.fi> wrote: I'll continue reviewing the rest of the patch on Monday, but one glaring issue is that we cannot add an argument to the existing libpq PQencryptPassword() fu

Re: [HACKERS] OK, so culicidae is *still* broken

On 04/24/2017 09:50 PM, Andres Freund wrote: On 2017-04-24 14:43:11 -0400, Tom Lane wrote: (We have accepted that kind of overhead for DSM segments, but the intention I think is to allow only very trivial data structures in the DSM segments. Losing compiler pointer type checking for data

Re: [HACKERS] scram and \password

On 04/10/2017 08:42 AM, Michael Paquier wrote: As there have been some conflicts because of the commit of SASLprep, here is a rebased set of patches. I've committed a modified version of the first patch, to change the on-disk format to RFC 5803, as mentioned on the other thread

Re: [HACKERS] On-disk format of SCRAM verifiers

On 04/21/2017 05:33 PM, Simon Riggs wrote: On 21 April 2017 at 14:42, Heikki Linnakangas <hlinn...@iki.fi> wrote: SCRAM-SHA-256$:$: Could you explain where you are looking? I don't see that in RFC5803 >From 1. Overview: Yeah, it's not easy to see, I missed it earlier too.

Re: [HACKERS] On-disk format of SCRAM verifiers

On 21 April 2017 16:20:56 EEST, Michael Paquier <michael.paqu...@gmail.com> wrote: >On Fri, Apr 21, 2017 at 10:02 PM, Simon Riggs <si...@2ndquadrant.com> >wrote: >> On 21 April 2017 at 10:20, Heikki Linnakangas <hlinn...@iki.fi> >wrote: >>> But looking

[HACKERS] On-disk format of SCRAM verifiers

The current format for SCRAM verifiers in pg_authid is: scram-sha-256 While reviewing Michael's patch to change that so that StoredKey and ServerKey are stored base64-encoded, rather than hex-encoded as they are currently [1], I looked again at RFC 5803. RFC 5803 specifies the format to

Re: [HACKERS] SASL minor docs typo

On 04/18/2017 08:50 PM, Jaime Casanova wrote: Hi, reading SASL docs found this typo: in protocol.sgml:1356 """ To begin a SASL authentication exchange, the server an AuthenticationSASL message. """ I guess it should say "the server sends an AuthenticationSASL message" Yep, fixed. Thanks!

Re: [HACKERS] scram and \password

On 04/18/2017 08:44 AM, Noah Misch wrote: On Tue, Apr 11, 2017 at 10:07:12PM +0300, Heikki Linnakangas wrote: Thanks! I've been busy on the other thread on future-proofing the protocol with negotiating the SASL mechanism, I'll come back to this once we get that settled. By the end of the week

  1   2   3   4   5   6   7   8   9   10   >