Re: [HACKERS] Password identifiers, protocol aging and SCRAM protocol

On 09/28/2016 12:53 PM, Heikki Linnakangas wrote: On 09/26/2016 09:02 AM, Michael Paquier wrote: * [PATCH 2/8] Move encoding routines to src/common/ I wonder if it is confusing to have two of encode.h/encode.c. Perhaps they should be renamed to make them distinct? Yes it may be a good idea

Re: [HACKERS] Password identifiers, protocol aging and SCRAM protocol

On 09/28/2016 12:53 PM, Heikki Linnakangas wrote: On 09/26/2016 09:02 AM, Michael Paquier wrote: * [PATCH 2/8] Move encoding routines to src/common/ I wonder if it is confusing to have two of encode.h/encode.c. Perhaps they should be renamed to make them distinct? Yes it may be a good idea

Re: [HACKERS] Fix checkpoint skip logic on idle systems by tracking LSN progress

On Wed, Sep 28, 2016 at 6:12 AM, David Steele wrote: > I tried the attached patch set and noticed an interesting behavior. With > archive_timeout=5 whenever I made a change I would get a WAL segment within > a few seconds as expected then another one would follow a few

Re: [HACKERS] Push down more full joins in postgres_fdw

On 2016/09/26 16:30, Etsuro Fujita wrote: On 2016/09/13 14:17, Ashutosh Bapat wrote: It won't remain minimal as the number of paths created increases, increasing the number of times a query is deparsed. We deparse query every time time we cost a path for a relation with use_remote_estimates

[HACKERS] Transaction user id through logical decoding

Hi all, I'm developing a custom plugin to stream Postgres CDC changes to my client application. One of the info the application needs is the user id of the user who executed a certain transaction. I can see we have access to other transaction info (xid, lsn, changed data) but apparently the user

Re: [HACKERS] Password identifiers, protocol aging and SCRAM protocol

On 09/26/2016 09:02 AM, Michael Paquier wrote: * [PATCH 2/8] Move encoding routines to src/common/ > > I wonder if it is confusing to have two of encode.h/encode.c. Perhaps > they should be renamed to make them distinct? Yes it may be a good idea to rename that, like encode_utils.[c|h] for the

Re: [HACKERS] Fix checkpoint skip logic on idle systems by tracking LSN progress

On Tue, Sep 27, 2016 at 7:16 PM, Kyotaro HORIGUCHI wrote: > I apologize in advance that the comments in this message might > one of the ideas discarded in the past thread.. I might not grasp > the discussion completely X( No problem. > At Wed, 18 May 2016

Re: [HACKERS] Showing parallel status in \df+

On Mon, Sep 26, 2016 at 3:06 PM, Stephen Frost wrote: > I feel like we're getting wrapped around the axle as it regards who is > perceived to be voting for what. Thanks Stephen Frost for listing down all the concerns from the people on the different approaches. On Tue, Sep

Re: [HACKERS] Bug in to_timestamp().

On Fri, Sep 16, 2016 at 10:01 PM, Artur Zakirov wrote: > On 25.08.2016 13:26, amul sul wrote: >>> >>> Thanks. I've created the entry in >>> https://commitfest.postgresql.org/10/713/ >>> . You can add yourself as a reviewer. >>> >> >> Done, added myself as reviewer &

Re: [HACKERS] Python3.4 detection on 9.6 configuration

Lou Picciano writes: > Trying to build 9.6RC1, with Python3.4, on OpenIndiana (Illumos). It > seems the detection of shared library status of the .so has changed. Changed from what? I don't recall that we've touched that code in quite some time. What was the last

Re: [HACKERS] psql casts aspersions on server reliability

Robert Haas writes: > psql tends to do things like this: > rhaas=# select * from pg_stat_activity; > FATAL: terminating connection due to administrator command > server closed the connection unexpectedly > This probably means the server terminated abnormally >

Re: [HACKERS] Tracking wait event for latches

On Tue, Sep 27, 2016 at 8:39 PM, Thomas Munro wrote: > Ok, if they really are independent then shouldn't we take advantage of > that at call sites where we might be idle but we might also be waiting > for the network? I certainly didn't intend for them to be

Re: [HACKERS] Tracking wait event for latches

On Wed, Sep 28, 2016 at 8:38 AM, Michael Paquier wrote: > On Wed, Sep 28, 2016 at 9:35 PM, Robert Haas wrote: >> On Tue, Sep 27, 2016 at 8:39 PM, Thomas Munro >> wrote: >>> Ok, if they really are independent then

Re: [HACKERS] Logical Replication WIP

On 9/23/16 9:28 PM, Petr Jelinek wrote: >> Document to what extent other relation types are supported (e.g., >> > materialized views as source, view or foreign table or temp table as >> > target). Suggest an updatable view as target if user wants to have >> > different table names or write into a

[HACKERS] Python3.4 detection on 9.6 configuration

PostgreSQL Friends: Trying to build 9.6RC1, with Python3.4, on OpenIndiana (Illumos). It seems the detection of shared library status of the .so has changed. This appears to be related to a different(?) elucidation of python configuration. A 'hardwired' change to the configure script to trap

Re: [HACKERS] Password identifiers, protocol aging and SCRAM protocol

On 9/28/16 5:25 AM, Heikki Linnakangas wrote: > > Once we get the main SCRAM patch in, we may want to remove the "on" > alias altogether. We don't promise backwards-compatibility of config > files or GUC values, and not many people set password_encryption=on > explicitly anyway, since it's the

Re: [HACKERS] Tracking wait event for latches

On Wed, Sep 28, 2016 at 9:35 PM, Robert Haas wrote: > On Tue, Sep 27, 2016 at 8:39 PM, Thomas Munro > wrote: >> Ok, if they really are independent then shouldn't we take advantage of >> that at call sites where we might be idle but we might

Re: [HACKERS] Quorum commit for multiple synchronous replication.

On Sat, Sep 24, 2016 at 5:37 PM, Masahiko Sawada wrote: > I still vote for changing behaviour of existing syntax 'k (n1, n2)' to > quorum commit. > That is, > 1. 'First k (n1, n2, n3)' means that the master server waits for ACKs > from k standby servers whose name appear

Re: [HACKERS] Push down more full joins in postgres_fdw

On 2016/09/27 13:33, Ashutosh Bapat wrote: I wrote: ISTM that the use of the same RTI for subqueries in multi-levels in a remote SQL makes the SQL a bit difficult to read. How about using the position of the join rel in join_rel_list, (more precisely, the position plus

Re: [HACKERS] Password identifiers, protocol aging and SCRAM protocol

On 09/26/2016 09:02 AM, Michael Paquier wrote: On Mon, Sep 26, 2016 at 2:15 AM, David Steele wrote: * [PATCH 3/8] Switch password_encryption to a enum Does not apply on HEAD (98c2d3332): Interesting, it works for me on da6c4f6. For here on I used 39b691f251 for review

Re: [HACKERS] LLVM Address Sanitizer (ASAN) and valgrind support

On Wed, Sep 28, 2016 at 7:40 AM, Piotr Stefaniak wrote: > Not remembering the context, I was initially confused about what exactly > supposedly needs to be done in order to have ASan support, especially > since I've been using it for a couple of years without any kind

Re: [HACKERS] Floating point comparison inconsistencies of the geometric types

> Emre, are you going to address the above? It would have to be Real > Soon Now. Yes, I am working on it. I found more problems, replaced more algorithms. That took a lot of time. I will post the new version really soon. I wouldn't feel bad, if you wouldn't have enough time to review it in

Re: [HACKERS] Showing parallel status in \df+

Rushabh Lathia writes: > On Mon, Sep 26, 2016 at 3:06 PM, Stephen Frost wrote: >> I feel like we're getting wrapped around the axle as it regards who is >> perceived to be voting for what. > Thanks Stephen Frost for listing down all the concerns

Re: [HACKERS] psql casts aspersions on server reliability

On Wed, Sep 28, 2016 at 9:14 AM, Tom Lane wrote: > Robert Haas writes: >> psql tends to do things like this: >> rhaas=# select * from pg_stat_activity; >> FATAL: terminating connection due to administrator command >> server closed the connection

Re: [HACKERS] Showing parallel status in \df+

2016-09-28 16:03 GMT+02:00 Tom Lane : > Rushabh Lathia writes: > > On Mon, Sep 26, 2016 at 3:06 PM, Stephen Frost > wrote: > >> I feel like we're getting wrapped around the axle as it regards who is > >> perceived to be voting

Re: [HACKERS] Python3.4 detection on 9.6 configuration

- Original Message - > From: "Tom Lane" > To: "Lou Picciano" > Cc: pgsql-hackers@postgresql.org > Sent: Wednesday, September 28, 2016 9:33:06 AM > Subject: Re: [HACKERS] Python3.4 detection on 9.6 configuration > Lou Picciano

[HACKERS] Handling dropped attributes in pglogical_proto

Hi, pglogical_read_tuple from pglogical_proto.c contains the following code: natts = pq_getmsgint(in, 2); if (rel->natts != natts) elog(ERROR, "tuple natts mismatch, %u vs %u", rel->natts, natts); But if table was just altered and some attribute was removed

Re: [HACKERS] Tuplesort merge pre-reading

On Thu, Sep 15, 2016 at 9:51 PM, Heikki Linnakangas wrote: >> I still don't get why you're doing all of this within mergeruns() (the >> beginning of when we start merging -- we merge all quicksorted runs), >> rather than within beginmerge() (the beginning of one particular merge

Re: [HACKERS] psql casts aspersions on server reliability

On 9/28/16 10:22 AM, Robert Haas wrote: > On Wed, Sep 28, 2016 at 9:14 AM, Tom Lane wrote: >> Robert Haas writes: >>> psql tends to do things like this: >>> rhaas=# select * from pg_stat_activity; >>> FATAL: terminating connection due to administrator

Re: [HACKERS] PATCH: Exclude additional directories in pg_basebackup

On 9/28/16 2:45 AM, Michael Paquier wrote: > On Tue, Sep 27, 2016 at 11:27 PM, David Steele wrote: >> On 9/26/16 2:36 AM, Michael Paquier wrote: >> >>> Just a nit: >>> >>> - postmaster.pid >>> + postmaster.pid and postmaster.opts >>> >>>

Re: [HACKERS] Better tracking of free space during SP-GiST index build

On Wed, Sep 28, 2016 at 10:48 AM, Robert Haas wrote: > On Sun, Sep 25, 2016 at 3:28 PM, Tomas Vondra > wrote: > > Sure, that would be useful. > > > > I think it would be useful to make repository of such data sets, so that > > patch authors &

Re: [HACKERS] less expensive pg_buffercache on big shmem

Hello everyone, patch was rebased. Thank you Tomas for your reviewing this patch and for your valuable comments. From the very beginning we had the misunderstanding with the naming of meethods. > It'd be really useful if you could provide actual numbers, explain what > metrics you compare

Re: [HACKERS] Hash Indexes

On Wed, Sep 28, 2016 at 3:04 PM, Robert Haas wrote: > I'll write another email with my thoughts about the rest of the patch. I think that the README changes for this patch need a fairly large amount of additional work. Here are a few things I notice: - The confusion

<    1   2