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 17:57:49 -0400, Michael Paquier > wrot

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 minutes later. That's inten

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 27, 2016 at 7:56 PM, S

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 th

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 & changed status to "Ready for >>

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 earlier in the list. > 2.

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 list_length(root->parse->

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 and testing. I seems

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 of > modifications. Having re

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 tr

[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 id

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] 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 t

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 t

Re: [HACKERS] pg_dump / copy bugs with "big lines" ?

Tomas Vondra wrote: > 4) HandleParallelMessage needs a tweak, as it uses msg->len in a log > message, but with '%d' and not '%ld' (as needed after changing the type > to Size). This could be %zu for the Size type. It's supported by elog(). However, it occurs to me that if we don't clai

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

On Wed, Sep 28, 2016 at 7:03 PM, Heikki Linnakangas wrote: > 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/en

[HACKERS] psql casts aspersions on server reliability

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 before or while processing the request. Basically everythin

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 independent, and I don't think they sh

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 also be waiting >> for the network? > > I certainly didn

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 shouldn't we take advantage of >>> that at call sites where we might be idle but we

[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] 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

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 > before or while processing t

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 version that worked for you? W

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 def

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 from the people > on the different approaches. I'

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 unexpectedly >> This probably means the server

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 for what. > > > Thanks Stephen Frost for listing down all the concern

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 writes: > > Trying to build 9.6RC1, with Python3.4,

[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 fr

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 command >>> server closed the connection une

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 >> pass, of which

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 >>> >>> Having one block for ea

Re: [HACKERS] assert violation in logical messages serialization

On Tue, Sep 27, 2016 at 10:45 AM, Stas Kelvich wrote: > During processing of logical messages in ReorderBufferSerializeChange() > pointer to ondisk structure isn’t updated after possible reorder buffer > realloc by > ReorderBufferSerializeReserve(). > > Actual reason spotted by Konstantin Knizhni

Re: [HACKERS] Remove superuser() checks from pgstattuple

Michael, * Michael Paquier (michael.paqu...@gmail.com) wrote: > On Tue, Sep 27, 2016 at 4:43 AM, Stephen Frost wrote: > > * Peter Eisentraut (peter.eisentr...@2ndquadrant.com) wrote: > >> This is now being obsoleted by the later idea of allowing base installs > >> from a chain of upgrade scripts.

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

On Tue, Sep 27, 2016 at 5:15 PM, Tomas Vondra wrote: > So, I got the results from 3.10.101 (only the pgbench data), and it looks > like this: > > 3.10.101 1 8 16 32 64128192 > > granular-l

[HACKERS] compiler warning read_objtype_from_string()

I'm getting the following compiler warning (using nondefault optimization options): objectaddress.c: In function 'read_objtype_from_string': objectaddress.c:2309:9: error: 'type' may be used uninitialized in this function [-Werror=maybe-uninitialized] return type; The comment for the function s

Re: [HACKERS] Cache Hash Index meta page.

On Tue, Sep 27, 2016 at 1:53 AM, Jeff Janes wrote: > I think that this needs to be updated again for v8 of concurrent and v5 of wal Adding the rebased patch over [1] + [2] [1] Concurrent Hash index.

Re: [HACKERS] Tuplesort merge pre-reading

On 09/28/2016 06:05 PM, Peter Geoghegan wrote: On Thu, Sep 15, 2016 at 9:51 PM, Heikki Linnakangas wrote: I don't think it makes much difference in practice, because most merge passes use all, or almost all, of the available tapes. BTW, I think the polyphase algorithm prefers to do all the merg

Re: [HACKERS] Tuplesort merge pre-reading

On Wed, Sep 28, 2016 at 5:04 PM, Heikki Linnakangas wrote: >> Not sure that I understand. I agree that each merge pass tends to use >> roughly the same number of tapes, but the distribution of real runs on >> tapes is quite unbalanced in earlier merge passes (due to dummy runs). >> It looks like y

Re: [HACKERS] Tuplesort merge pre-reading

On Wed, Sep 28, 2016 at 5:11 PM, Peter Geoghegan wrote: > This is why I never pursued batch memory for non-final merges. Isn't > that what you're doing here? You're pretty much always setting > "state->batchUsed = true". Wait. I guess you feel you have to, since it wouldn't be okay to use almost

Re: [HACKERS] "Some tests to cover hash_index"

On Tue, Sep 20, 2016 at 2:26 PM, Alvaro Herrera wrote: > Why not use generate_series() queries to insert the appropriate number > of tuples, instead of a handful of INSERT lines each time? Since each > insert is a separate transaction, that would probably be faster. > > Why do you have a plpgsql

Re: [HACKERS] compiler warning read_objtype_from_string()

Peter Eisentraut wrote: > I'm getting the following compiler warning (using nondefault > optimization options): > > objectaddress.c: In function 'read_objtype_from_string': > objectaddress.c:2309:9: error: 'type' may be used uninitialized in this > function [-Werror=maybe-uninitialized] > return

Re: [HACKERS] [COMMITTERS] pgsql: pg_ctl: Detect current standby state from pg_control

On 9/28/16 12:44 AM, Michael Paquier wrote: > On Tue, Sep 27, 2016 at 9:55 AM, Michael Paquier > wrote: >> > Seems overcomplicated to me. How about returning the control file all >> > the time and let the caller pfree the result? You could then use >> > crc_ok in pg_ctl.c's get_control_dbstate() t

Re: [HACKERS] Issue with bgworker, SPI and pgstat_report_stat

On Sat, Sep 3, 2016 at 12:29 AM, Michael Paquier wrote: > On Sat, Sep 3, 2016 at 10:02 AM, Tomas Vondra > wrote: >> In any case, I think adding the pgstat_report_stat() into worker_spi seems >> like a reasonable (and backpatchable) fix. > > Doing just that sounds reasonable seen from here. I am w

Re: [HACKERS] IF (NOT) EXISTS in psql-completion

On Tue, Sep 20, 2016 at 3:50 AM, Michael Paquier wrote: > On Mon, Sep 19, 2016 at 6:11 PM, Pavel Stehule > wrote: >> I am thinking so commit's description should be inside README > > Horiguchi-san, your patch has some whitespace issues, you may want to > get a run with git diff --check. Here are

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

Pavel Stehule writes: > 2016-09-28 16:03 GMT+02:00 Tom Lane : >> I propose to push my current patch (ie, move PL function >> source code to \df+ footers), and we can use it in HEAD for awhile >> and see what we think. We can alway improve or revert it later. > I had some objection to format of s

Re: [HACKERS] hstore: add hstore_length function

On Wed, Jun 8, 2016 at 10:44 AM, Robert Haas wrote: > On Mon, Jun 6, 2016 at 7:57 PM, Korbin Hoffman wrote: >> With regards to your second point- I've been maintaining consistency >> with the rest of the hstore module. Hstore's _size is internally >> stored as a uint, but all uses of HS_COUNT acr

Re: [HACKERS] [PATCH] SortSupport for macaddr type

On Wed, Sep 14, 2016 at 6:14 AM, Julien Rouhaud wrote: > On 26/08/2016 19:44, Brandur wrote: >> Hello, > Hello, > >> I've attached a patch to add SortSupport for Postgres' macaddr which has the >> effect of improving the performance of sorting operations for the type. The >> strategy that I employ

Re: [HACKERS] Binary I/O for isn extension

On Mon, Aug 22, 2016 at 8:14 AM, Fabien COELHO wrote: > Hello Shay, >> Attached is a new version of the patch, adding an upgrade script and the >> rest of it. Note that because, as Fabien noted, there's doesn't seem to be >> a way to add send/receive functions with ALTER TYPE, I did that by >> upd

Re: [HACKERS] Change error code for hstore syntax error

On Sun, Sep 4, 2016 at 7:15 PM, Marko Tiikkaja wrote: > On 2016-05-09 19:42, Sherrylyn Branchaw wrote: >> >> I'm attaching a revised patch; please let me know if there are any other >> issues before I submit to the commitfest. > > I think this is mostly good, but these two should be changed: > >

Re: [HACKERS] pg_basebackup stream xlog to tar

On Mon, Sep 5, 2016 at 4:01 AM, Michael Paquier wrote: > [ review comments ] This thread has been sitting idle for more than 3 weeks, so I'm marking it "Returned with Feedback" in the CommitFest application. Magnus, Michael's latest round of comments seem pretty trivial, so perhaps you want to ju

Re: [HACKERS] Proposal for changes to recovery.conf API

On Tue, Sep 6, 2016 at 10:11 AM, David Steele wrote: > On 9/6/16 8:07 AM, Robert Haas wrote: >> On Wed, Aug 31, 2016 at 9:45 PM, Simon Riggs >> wrote: >>> Related cleanup >>> * Promotion signal file is now called "promote.trigger" rather than >>> just "promote" >>> * Remove user configurable "tri

Re: [HACKERS] pg_basebackup stream xlog to tar

On Sep 28, 2016 19:11, "Robert Haas" wrote: > > On Mon, Sep 5, 2016 at 4:01 AM, Michael Paquier > wrote: > > [ review comments ] > > This thread has been sitting idle for more than 3 weeks, so I'm > marking it "Returned with Feedback" in the CommitFest application. > Magnus, Michael's latest roun

Re: [HACKERS] [PATCH] add option to pg_dumpall to exclude tables from the dump

On Tue, Sep 6, 2016 at 9:37 PM, Gerdan Rezende dos Santos wrote: > After review, I realized that there is a call to the function: > doShellQuoting (pgdumpopts, OPTARG), which no longer seems to exist ... > After understand the code, I saw that the call is appendShellString > (pgdumpopts, OPTARG).

Re: [HACKERS] Truncating/vacuuming relations on full tablespaces

On Thu, Sep 8, 2016 at 2:46 AM, Haribabu Kommi wrote: > Patch needs rebase, it is failing to apply on latest master. > And also there are some pending comment fix from Robert. It's been almost three weeks and this hasn't been updated, so I think it's pretty clear that it should be marked "Returne

Re: [HACKERS] Sample configuration files

On Thu, Sep 8, 2016 at 8:52 AM, Tom Lane wrote: > Vik Fearing writes: >> I noticed that this patch has been marked Waiting on Author with no >> comment. Peter, what more should I be doing right now while waiting for >> Martín's review? > > FWIW, I agree with the upthread misgivings about whether

Re: [HACKERS] Change error code for hstore syntax error

Since no revised patch has been forthcoming and the CommitFest is due to end shortly, I've marked this "Returned with Feedback". Sherrylyn, please feel free to update the patch and resubmit to the next CommitFest. Will do, Robert, and many thanks to Marko for the feedback. I apologize for the del

Re: [HACKERS] Index Onlys Scan for expressions

On Thu, Sep 8, 2016 at 2:58 PM, Vladimir Sitnikov wrote: > Ildar> Could you please try the patch and tell if it works for you? > > I've tested patch6 against recent head. The patch applies with no problems. > > The previous case (filter on top of i-o-s) is fixed. Great work. > > Here are the test

Re: [HACKERS] pgbench more operators & functions

The following review has been posted through the commitfest application: make installcheck-world: tested, passed Implements feature: tested, passed Spec compliant: not tested Documentation:tested, passed The patch looks good to me now. Passing this to committer. The n

Re: [HACKERS] identity columns

On Mon, Sep 12, 2016 at 5:02 PM, Peter Eisentraut wrote: > Thank you for this extensive testing. I will work on getting the bugs > fixed. It looks like the patch has not been updated; since the CommitFest is (hopefully) wrapping up, I am marking this "Returned with Feedback" for now. -- Robert

Re: [HACKERS] PassDownLimitBound for ForeignScan/CustomScan

On Tue, Sep 13, 2016 at 9:07 PM, Kouhei Kaigai wrote: > It is because of just my time pressure around the patch submission days. > I'll try to enhance postgres_fdw as a usage of this run-time optimization. Time has (pretty much) expired for this CommitFest. In any case, this will amount to a who

Re: [HACKERS] Set log_line_prefix and application name in test drivers

On Thu, Sep 15, 2016 at 5:18 PM, Robert Haas wrote: > On Sat, Aug 27, 2016 at 3:59 PM, Tom Lane wrote: >> Christoph Berg writes: >>> I've always been wondering why we don't set a log_line_prefix by >>> default. >> >> I think the odds of getting to something that everyone would agree on >> are ni

Re: [HACKERS] less expensive pg_buffercache on big shmem

On Tue, Sep 20, 2016 at 7:43 PM, Tomas Vondra wrote: > On 09/02/2016 11:01 AM, Robert Haas wrote: >> >> On Fri, Sep 2, 2016 at 8:49 AM, Andres Freund wrote: >>> >>> On 2016-09-02 08:31:42 +0530, Robert Haas wrote: I wonder whether we ought to just switch from the consistent method to >>

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

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 & reviewers can get a reasonable collection of data sets if > needed, instead of scrambling every time. Opinions? In theo

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

On Thu, Sep 22, 2016 at 1:37 PM, Tom Lane wrote: > OK, I'll think about how to do that more efficiently. The smaller > incremental improvement isn't surprising, because in this example the > index would still be 90-something MB if it had no free space at all, > so there's going to be decreasing r

[HACKERS] CommitFest wrap-up

As some of you probably noticed, I just made a sweep through everything that was marked "Waiting on Author" in the CommitFest and hadn't been updated in the last couple of days. Most of those I marked as "Returned with Feedback", but some of them got some other status, one I committed, and a few I

[HACKERS] Batches, error handling and transaction in the protocol

Hi everyone, I'd appreciate some guidance on an issue that's been raised with Npgsql, input from other driver writers would be especially helpful. Npgsql currently supports batching (or pipelining) to avoid roundtrips, and sends a Sync message only at the end of the batch (so Parse1/Bind1/Describe

Re: [HACKERS] Binary I/O for isn extension

Sorry about this, I just haven't had a free moment (and it's definitely not very high priority...) On Wed, Sep 28, 2016 at 5:04 PM, Robert Haas wrote: > On Mon, Aug 22, 2016 at 8:14 AM, Fabien COELHO > wrote: > > Hello Shay, > >> Attached is a new version of the patch, adding an upgrade script

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

Robert Haas writes: > On Thu, Sep 22, 2016 at 1:37 PM, Tom Lane wrote: >> OK, I'll think about how to do that more efficiently. The smaller >> incremental improvement isn't surprising, because in this example the >> index would still be 90-something MB if it had no free space at all, >> so there

Re: [HACKERS] Tuplesort merge pre-reading

On 09/28/2016 07:11 PM, Peter Geoghegan wrote: On Wed, Sep 28, 2016 at 5:04 PM, Heikki Linnakangas wrote: Not sure that I understand. I agree that each merge pass tends to use roughly the same number of tapes, but the distribution of real runs on tapes is quite unbalanced in earlier merge passe

Re: [HACKERS] psql casts aspersions on server reliability

On 28/09/16 17:13, David Steele wrote: > 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 administrato

Re: [HACKERS] should xlog_outdesc modify its argument?

> On Sep 27, 2016, at 11:25 PM, Heikki Linnakangas wrote: > > On 09/28/2016 02:35 AM, Mark Dilger wrote: >> The function >> >> static void xlog_outdesc(StringInfo buf, XLogReaderState *record); >> >> in src/backend/access/transam/xlog.c is called by XLogInsertRecord, >> and after returning a

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

Hi 2016-09-28 18:57 GMT+02:00 Tom Lane : > Pavel Stehule writes: > > 2016-09-28 16:03 GMT+02:00 Tom Lane : > >> I propose to push my current patch (ie, move PL function > >> source code to \df+ footers), and we can use it in HEAD for awhile > >> and see what we think. We can alway improve or re

Re: [HACKERS] Set log_line_prefix and application name in test drivers

Re: Robert Haas 2016-09-28 > > Well, practically anything that includes a PID and the timestamp is > > going to be an improvement over the status quo. Just because we can't > > all agree on what would be perfect does not mean that we can't do > > better than what we've got now. +1 for trying. >

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

On Wed, Sep 28, 2016 at 2:11 PM, Tom Lane wrote: > Robert Haas writes: >> On Thu, Sep 22, 2016 at 1:37 PM, Tom Lane wrote: >>> OK, I'll think about how to do that more efficiently. The smaller >>> incremental improvement isn't surprising, because in this example the >>> index would still be 90-

Re: [HACKERS] Binary I/O for isn extension

On Wed, Sep 28, 2016 at 2:05 PM, Shay Rojansky wrote: > Sorry about this, I just haven't had a free moment (and it's definitely not > very high priority...) No issues, just cleaning house. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via

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

On Wed, Sep 28, 2016 at 12:02 PM, Emre Hasegeli wrote: >> `make check` finds differences per the attached. Please >> investigate why the regression tests are failing and what the >> appropriate response is. > > I fixed the first one and workaround the second with COLLATE "C". I > have how my ch

Re: [HACKERS] Hash Indexes

On Tue, Sep 27, 2016 at 3:06 PM, Jesper Pedersen wrote: > I have been running various tests, and applications with this patch together > with the WAL v5 patch [1]. > > As I havn't seen any failures and doesn't currently have additional feedback > I'm moving this patch to "Ready for Committer" for

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

Heikki, Michael, Magnus, * Michael Paquier (michael.paqu...@gmail.com) wrote: > On Tue, Sep 27, 2016 at 10:42 PM, Heikki Linnakangas wrote: > > The libpq-side is not. Just calling random() won't do. We haven't needed for > > random numbers in libpq before, but now we do. Is the pgcrypto solution

Re: [HACKERS] Hash Indexes

On 2016-09-28 15:04:30 -0400, Robert Haas wrote: > Andres already > stated that he things working on btree-over-hash would be more > beneficial than fixing hash, but at this point it seems like he's the > only one who takes that position. Note that I did *NOT* take that position. I was saying that

Re: [HACKERS] Hash Indexes

On Wed, Sep 28, 2016 at 3:06 PM, Andres Freund wrote: > On 2016-09-28 15:04:30 -0400, Robert Haas wrote: >> Andres already >> stated that he things working on btree-over-hash would be more >> beneficial than fixing hash, but at this point it seems like he's the >> only one who takes that position.

Re: [HACKERS] Add support for restrictive RLS policies

* Alvaro Herrera (alvhe...@2ndquadrant.com) wrote: > Stephen, the typo "awseome" in the tests is a bit distracting. Can you > please fix it? Done. > I think you should use braces here, not parens: Fixed. > I don't think this paragraph is right -- you should call out each of the > values PERMIS

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

Pavel Stehule wrote: > I am sorry, I disagree. Proposed form is hard readable. Is not possible to > simply copy/paste. Why do you care? You can use \sf if you want to copy&paste the function code. > I cannot to imagine any use case for proposed format. My vote (which was not counted by Stephen

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

* Alvaro Herrera (alvhe...@2ndquadrant.com) wrote: > Pavel Stehule wrote: > > I cannot to imagine any use case for proposed format. > > My vote (which was not counted by Stephen) was to remove it from \df+ Oh, sorry about that, not sure how I missed it. :/ > altogether. I stand by that. People

Re: [HACKERS] ICU integration

On Fri, Sep 23, 2016 at 6:27 PM, Thomas Munro wrote: > On Wed, Aug 31, 2016 at 2:46 PM, Peter Eisentraut > wrote: >> Here is a patch I've been working on to allow the use of ICU for sorting >> and other locale things. > > This is very interesting work, and it's great to see some development > in

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

2016-09-28 21:59 GMT+02:00 Alvaro Herrera : > Pavel Stehule wrote: > > > I am sorry, I disagree. Proposed form is hard readable. Is not possible > to > > simply copy/paste. > > Why do you care? You can use \sf if you want to copy&paste the > function code. > I know so I can use \sf. But I don't

Re: [HACKERS] kqueue

On Thu, Sep 15, 2016 at 11:11 PM, Thomas Munro < thomas.mu...@enterprisedb.com> wrote: > On Thu, Sep 15, 2016 at 11:04 AM, Thomas Munro > wrote: > > On Thu, Sep 15, 2016 at 10:48 AM, Keith Fiske wrote: > >> Thomas Munro brought up in #postgresql on freenode needing someone to > test a > >> patch

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

On Wed, Sep 28, 2016 at 2:04 PM, Kevin Grittner wrote: > Will take a look and post again. I am moving this patch to the next CF. You'll be hearing from me sometime after this CF is closed. -- Kevin Grittner EDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql

Re: [HACKERS] Bug in to_timestamp().

Artur Zakirov writes: > - now DCH_cache_getnew() is called after parse_format(). Because now > parse_format() can raise an error and in the next attempt > DCH_cache_search() could return broken cache entry. I started looking at your 0001-to-timestamp-format-checking-v4.patch and this point imme

Re: [HACKERS] Set log_line_prefix and application name in test drivers

Robert Haas writes: > On Thu, Sep 15, 2016 at 5:18 PM, Robert Haas wrote: >> On Sat, Aug 27, 2016 at 3:59 PM, Tom Lane wrote: >>> I think the odds of getting to something that everyone would agree on >>> are nil, so I'm not excited about getting into that particular >>> bikeshed-painting discuss

Re: [HACKERS] kqueue

On Thu, Sep 29, 2016 at 9:09 AM, Keith Fiske wrote: > On Thu, Sep 15, 2016 at 11:11 PM, Thomas Munro > wrote: >> Ok, here's a version tweaked to use EVFILT_PROC for postmaster death >> detection instead of the pipe, as Tom Lane suggested in another >> thread[1]. >> >> [...] > > Ran benchmarks on

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

Pavel Stehule writes: > We are in cycle because prosrc field is used for two independent features - > and then it can be hard to find a agreement. I thought pretty much everyone was on board with the idea of keeping prosrc in \df+ for internal/C-language functions (and then probably renaming the

Re: [HACKERS] compiler warning read_objtype_from_string()

Alvaro Herrera writes: > Peter Eisentraut wrote: >> I'm getting the following compiler warning (using nondefault >> optimization options): >> objectaddress.c: In function 'read_objtype_from_string': >> objectaddress.c:2309:9: error: 'type' may be used uninitialized in this >> function [-Werror=may

Re: [HACKERS] Set log_line_prefix and application name in test drivers

Tom Lane wrote: > Robert Haas writes: > > On Thu, Sep 15, 2016 at 5:18 PM, Robert Haas wrote: > >> On Sat, Aug 27, 2016 at 3:59 PM, Tom Lane wrote: > >>> I think the odds of getting to something that everyone would agree on > >>> are nil, so I'm not excited about getting into that particular > >

Re: [HACKERS] compiler warning read_objtype_from_string()

Tom Lane wrote: > I do not think you should assume that the compiler is smart enough to > deduce that, nor that all compilers even know ereport(ERROR) doesn't > return. Personally I don't see the point of the "type" variable at > all, anyway. I would have written this as > > [code] Makes sense

Re: [HACKERS] Set log_line_prefix and application name in test drivers

On Wed, Sep 28, 2016 at 6:07 PM, Alvaro Herrera wrote: > I thought Peter's suggestion for regression test drivers was a good one > and I see no reason to block that. Why do you (Tom) object so strongly > against having a different one on buildfarm than elsewhere? I'd rather > have buildfarm adop

Re: [HACKERS] PoC: Make it possible to disallow WHERE-less UPDATE and DELETE

On Mon, Sep 26, 2016 at 5:11 PM, Thomas Munro wrote: > On Mon, Sep 26, 2016 at 1:18 PM, Thomas Munro > wrote: >> >> On Mon, Sep 19, 2016 at 4:02 PM, David Fetter wrote: >> > >> > [training_wheels_004.patch] >> >> [review] Ping. -- Thomas Munro http://www.enterprisedb.com -- Sent via pgsql-

Re: [HACKERS] PoC: Make it possible to disallow WHERE-less UPDATE and DELETE

On Thu, Sep 29, 2016 at 11:12:11AM +1300, Thomas Munro wrote: > On Mon, Sep 26, 2016 at 5:11 PM, Thomas Munro > wrote: > > On Mon, Sep 26, 2016 at 1:18 PM, Thomas Munro > > wrote: > >> > >> On Mon, Sep 19, 2016 at 4:02 PM, David Fetter wrote: > >> > > >> > [training_wheels_004.patch] > >> > >> [

Re: [HACKERS] Set log_line_prefix and application name in test drivers

Alvaro Herrera writes: > Tom Lane wrote: >> Perhaps we should first try to get a consensus on the regression test >> use-case. > I thought Peter's suggestion for regression test drivers was a good one > and I see no reason to block that. Why do you (Tom) object so strongly > against having a dif

  1   2   >