Re: [HACKERS] Optimizer questions

Konstantin Knizhnik writes: > On 03/08/2016 07:01 AM, Tom Lane wrote: >> I've not spent a lot of time on this, but I think maybe what would make >> sense is to consider both the case where function calculations are >> postponed to after ORDER BY and the case where they

Re: [HACKERS] [PROPOSAL] VACUUM Progress Checker.

On 2016/03/09 9:22, Kyotaro HORIGUCHI wrote: >> On Wed, Mar 9, 2016 at 12:24 AM, Robert Haas wrote: >>> This patch has been worked on by so many people and reviewed by so >>> many people that I can't keep track of who should be credited when it >>> gets committed. Could

Re: [HACKERS] Performance improvement for joins where outer side is unique

David Rowley writes: > [1] http://www.postgresql.org/message-id/8907.1440383...@sss.pgh.pa.us Oh, okay, I had looked at the many changes in the regression outputs and jumped to the conclusion that you were printing the info all the time. Looking closer I see it's

Re: [HACKERS] syslog configurable line splitting behavior

On 02/27/2016 04:49 AM, Peter Eisentraut wrote: So I propose the two attached patches that introduce new configuration Boolean parameters syslog_sequence_numbers and syslog_split_lines that can toggle these behaviors. As someone who uses syslog for my servers I find both of these GUCs useful,

Re: [HACKERS] syslog configurable line splitting behavior

On 3/4/16 11:01 AM, Alexander Korotkov wrote: > On Sat, Feb 27, 2016 at 6:49 AM, Peter Eisentraut > wrote: > > Writing log messages to syslog caters to ancient syslog implementations > in two ways: > > - sequence numbers > - line

Re: [HACKERS] GCC 6 warning fixes

On Mon, Feb 29, 2016 at 4:50 PM, Thomas Munro wrote: > On Sat, Feb 20, 2016 at 5:14 PM, Peter Eisentraut wrote: >> Here are three patches to fix new warnings in GCC 6. >> >> 0001 is apparently a typo. > > Right, looks like it. Builds and tests OK

Re: [HACKERS] silent data loss with ext4 / all current versions

On Mon, Mar 7, 2016 at 10:18 PM, Andres Freund wrote: >> Instead of "durable" I think that "persistent" makes more sense. > > I find durable a lot more descriptive. persistent could refer to > retrying the rename or something. Yeah, I like durable, too. -- Robert Haas

Re: [HACKERS] pgcrypto: add s2k-count

Jeff Janes wrote: > pgcrypto supports s2k-mode for key-stretching during symmetric > encryption, and even defaults to s2k-mode=3, which means configurable > iterations. But it doesn't support s2k-count to actually set those > iterations to be anything other than the default. If you are >

Re: [HACKERS] [PROPOSAL] VACUUM Progress Checker.

At Wed, 9 Mar 2016 01:16:26 +0900, Amit Langote wrote in > On Wed, Mar 9, 2016 at 12:24 AM, Robert Haas wrote: > > This patch has been worked on by so many people and reviewed by

Re: [HACKERS] multivariate statistics v11

On Tue, Mar 8, 2016 at 12:13 PM, Tomas Vondra wrote: > Hi, > > attached is v11 of the patch - this is mostly a cleanup of v10, removing > redundant code, adding missing comments, removing obsolete FIXME/TODOs > and so on. Overall this shaves ~20kB from the patch (not

Re: [HACKERS] VS 2015 support in src/tools/msvc

On Wed, Mar 9, 2016 at 1:07 AM, Andrew Dunstan wrote: > Michael's patch proposes to replace the use of sed to generate probes.h with > the perl equivalent everywhere. That has the advantage that we keep to one > script to generate probes.h, but it does impose a perl

Re: [HACKERS] Declarative partitioning

Hi, On 2016/03/09 9:17, Corey Huinker wrote: >> >> Sorry for replying so late. > No worries! We have jobs to do aside from this. Thanks! >> Everything seemed to go dandy until I tried FOR VALUES (blah , blah], >> where psql wouldn't send the command string without accepting the closing >>

Re: [HACKERS] [PROPOSAL] VACUUM Progress Checker.

On 2016/03/09 0:24, Robert Haas wrote: > On Tue, Mar 8, 2016 at 3:02 AM, Amit Langote > wrote: >> Updated versions attached. >> >> * changed st_progress_param to int64 and so did the argument of >> pgstat_progress_update_param(). Likewise changed param1..param10 of

Re: [HACKERS] Proposal: RETURNING primary_key()

On 9 March 2016 at 04:12, Robert Haas wrote: > I think we have a general problem with the server lacking > certain capabilities that make it easy to implement a high-quality > JDBC driver. And I think it would be good to work on figuring out how > to fix that. There

Re: [HACKERS] Parallel query fails on standby server

On Wed, Mar 9, 2016 at 12:34 AM, Robert Haas wrote: > On Tue, Mar 8, 2016 at 8:23 AM, Michael Paquier > wrote: >> On Tue, Mar 8, 2016 at 9:51 PM, Craig Ringer wrote: >>> On 8 March 2016 at 20:30, Ashutosh Sharma

Re: [HACKERS] Declarative partitioning

> > > So presently partitions that are unbounded on the lower end aren't > > possible, but that's a creation syntax issue, not an infrastructure > issue. > > Correct? > > In case it wasn't apparent, you can create those: > > FOR VALUES END (upper-bound) [INCLUSIVE] > > which is equivalent to: > >

Re: [HACKERS] WIP: Access method extendability

Hi, I went over the latest version of this, here are my notes. create-am.9: + case DO_ACCESS_METHOD: + snprintf(buf, bufsize, +""); + return; Missing the actual description. +

Re: [HACKERS] [PROPOSAL] VACUUM Progress Checker.

Horiguchi-san, Thanks for the review! On 2016/03/08 18:19, Kyotaro HORIGUCHI wrote: >> Updated versions attached. >> >> * changed st_progress_param to int64 and so did the argument of >> pgstat_progress_update_param(). Likewise changed param1..param10 of >> pg_stat_get_progress_info()'s output

Re: [HACKERS] Crash with old Windows on new CPU

On 2/12/16 11:24 AM, Christian Ullrich wrote: > Otherwise, it may be time to update the manual (15.6 Supported > Platforms) where it says PostgreSQL "can be expected to work on these > operating systems: [...] Windows (Win2000 SP4 and later), [...]". > Perhaps we could add "except Windows before 7

Re: [HACKERS] Recovery test failure for recovery_min_apply_delay on hamster

Michael Paquier wrote: > On Wed, Mar 9, 2016 at 12:14 AM, Alvaro Herrera > wrote: > > Is there anything we can do to short-circuit the wait in the case that > > replication happens promptly? A one-minute wait would be acceptable we > > terminate it early by checking

Re: [HACKERS] Performance improvement for joins where outer side is unique

On 9 March 2016 at 13:19, Tom Lane wrote: > I do think that the verbosity this adds to the EXPLAIN output is not > desirable at all, at least not in text mode. Another line for every > darn join is a pretty high price. For me it seems like a good idea to give some sort of

Re: [HACKERS] syslog configurable line splitting behavior

On 3/8/16 9:12 PM, Andreas Karlsson wrote: > As someone who uses syslog for my servers I find both of these GUCs > useful, especially when used in combination, and I do not think a > compile time option like suggest by Alexander would be suitable > substitute because then I would need a custom

Re: [HACKERS] fun with "Ready for Committer" patches

On 9 March 2016 at 07:18, Tatsuo Ishii wrote: > > Many of "needs review" state patches already have reviewer(s). Do you > mean we want more reviewers in addition to them for such patches? > Yeah. Personally I'm not too confident about what precisely is required to move a

Re: [HACKERS] fun with "Ready for Committer" patches

On 2016-03-09 08:18:09 +0900, Tatsuo Ishii wrote: > > It's hard to miss the fact that there are an absolutely breathtaking > > number of patches in this CommitFest - 80! - that are in the "needs > > review" state. We really, really, really need more review to happen - > > Many of "needs review"

Re: [HACKERS] Is there a way around function search_path killing SQL function inlining?

On 03/08/2016 01:24 AM, Regina Obe wrote: On Fri, Mar 4, 2016 at 9:29 PM, Regina Obe > wrote: I think the answer to this question is NO, but thought I'd ask. A lot of folks in PostGIS land are suffering from restore issues, materialized view issues etc. because we have functions

Re: [HACKERS] Proposal: RETURNING primary_key()

On 9 March 2016 at 05:40, Igal @ Lucee.org wrote: > On 3/8/2016 12:12 PM, Robert Haas wrote: > >> I agree that some research should be done on how this works in other >> systems, but I think we have a general problem with the server lacking >> certain capabilities that make it

Re: [HACKERS] GCC 6 warning fixes

On 3/8/16 4:44 PM, Robert Haas wrote: > On Mon, Feb 29, 2016 at 4:50 PM, Thomas Munro > wrote: >> On Sat, Feb 20, 2016 at 5:14 PM, Peter Eisentraut wrote: >>> Here are three patches to fix new warnings in GCC 6. >>> >>> 0001 is apparently a typo.

Re: [HACKERS] Recovery test failure for recovery_min_apply_delay on hamster

On Wed, Mar 9, 2016 at 12:14 AM, Alvaro Herrera wrote: > Is there anything we can do to short-circuit the wait in the case that > replication happens promptly? A one-minute wait would be acceptable we > terminate it early by checking every second. After sleeping (best

[HACKERS] Managing a long-held TupleDesc reference

When PL/Java is told to map a PostgreSQL composite type to a certain Java class, on its first use of the type mapping it calls lookup_rowtype_tupdesc_noerror and then creates a PL/Java UDT structure that retains a reference to the TupleDesc. This seems to be what is leading to a TupleDesc

Re: [HACKERS] Managing a long-held TupleDesc reference

Chapman Flack writes: > When PL/Java is told to map a PostgreSQL composite type to a certain > Java class, on its first use of the type mapping it calls > lookup_rowtype_tupdesc_noerror and then creates a PL/Java UDT structure > that retains a reference to the TupleDesc.

Re: [HACKERS] syslog configurable line splitting behavior

On 03/09/2016 03:20 AM, Peter Eisentraut wrote: On 3/8/16 9:12 PM, Andreas Karlsson wrote: As someone who uses syslog for my servers I find both of these GUCs useful, especially when used in combination, and I do not think a compile time option like suggest by Alexander would be suitable

Re: [HACKERS] Proposal: "Causal reads" mode for load balancing reads without stale data

On Thu, Mar 3, 2016 at 7:34 PM, Michael Paquier wrote: > WAL replay for 2PC should also > call XLogRequestWalReceiverReply() when needed. Ah yes, I missed this important sentence. I will address that in the next version after some testing. -- Thomas Munro

Re: [HACKERS] Pushing down sorted joins

> This patch needs to be rebased. > > Done. > + /* > +* TODO: we should worry about EPQ path but should > that path have > +* pathkeys? I guess, that's not really important > since it's just > +* going to evaluate the join from

Re: [HACKERS] pam auth - add rhost item

On Tue, Mar 8, 2016 at 10:43 PM, Grzegorz Sampolski wrote: > Hi Hari. > To use pam modules you can use whatever backend authentication method > you want. > > This is example configuration: > > Install this library https://github.com/pam-pgsql/pam-pgsql > Create some example

Re: [HACKERS] [PROPOSAL] VACUUM Progress Checker.

On 2016/03/09 10:11, Amit Langote wrote: > The attached revision addresses above and one of Horiguchi-san's comments > in his email yesterday. I fixed one more issue in 0002 per Horiguchi-san's comment. Sorry about so many versions. Thanks, Amit >From 9473230af72e0a0e3b60a8ddf1922698f7f17145

Re: [HACKERS] Crash with old Windows on new CPU

* Peter Eisentraut wrote: On 2/12/16 11:24 AM, Christian Ullrich wrote: Otherwise, it may be time to update the manual (15.6 Supported Platforms) where it says PostgreSQL "can be expected to work on these operating systems: [...] Windows (Win2000 SP4 and later), [...]". Perhaps we could add

Re: [HACKERS] Novice Presentation and Company Project

On Thu, Mar 03, 2016 at 12:04:56PM +0100, Eduardo Morras wrote: > My company is developing code for Postgresql for another company and want to > communicate, debate and share the results with the community. > > The objetives are upgrade the network backend and frontend of Postgresql: > > a) Add

Re: [HACKERS] Optimizer questions

I wrote: > BTW, there's some additional refactoring I had had in mind to do in > grouping_planner to make its handling of the targetlist a bit more > organized; in particular, I'd like to see it using PathTarget > representation more consistently throughout the post-scan-join steps. See

Re: [HACKERS] VS 2015 support in src/tools/msvc

On Tue, Mar 08, 2016 at 10:32:28PM +0900, Michael Paquier wrote: > Subject: [PATCH 3/4] Fix use of locales for VS 2015 > > lc_codepage is a flag missing from locale.h, causing this code path > introduced in VS 2012 to fail. Perhaps there is a reason for this field > to have been clobbered, but

Re: [HACKERS] WAL log only necessary part of 2PC GID

On Fri, Mar 4, 2016 at 9:16 PM, Jesper Pedersen wrote: > >> >> > I can confirm the marginal speed up in tps due to the new WAL size. > > The TWOPHASE_MAGIC constant should be changed, as the file header has > changed definition, right ? > Thanks for looking at it.

Re: [HACKERS] [PROPOSAL] VACUUM Progress Checker.

> On 2016/03/08 18:19, Kyotaro HORIGUCHI wrote: >> + WHEN 0 THEN 100::numeric(5, 2) >> + ELSE ((S.param3 + 1)::numeric / S.param2 * >> 100)::numeric(5, 2) >> >> This usage of numeric seems overkill to me. > > Hmm, how could this rather be written? OK,

[HACKERS] Re: [HACKERS] Re: [HACKERS] Re: [HACKERS] Windows service is not starting so there’s message in log: FATAL: "could not create shared memory segment “Global/PostgreSQL.851401618”: Permission

On Sun, Oct 18, 2015 at 1:03 AM, Tom Lane wrote: > Amit Kapila writes: >> On Sat, Oct 17, 2015 at 12:07 AM, Robert Haas wrote: >>> Maybe we need to be using PostmasterRandom() rather than random() for >>> the control segment

[HACKERS] [PATCH v6] GSSAPI encryption support

Hello friends, Here's yet another version of GSSAPI encryption support. It's also available for viewing on my github: https://github.com/frozencemetery/postgres/tree/feature/gssencrypt6 Let me hit the highlights of this time around: - Fallback code is back! It's almost unchanged from early

Re: [HACKERS] silent data loss with ext4 / all current versions

On 2016-03-08 23:47:48 +0100, Tomas Vondra wrote: > I've repeated the power-loss testing today. With the patches applied I'm > not longer able to reproduce the issue (despite trying about 10x), while > without them I've hit it on the first try. This is on kernel 4.4.2. Yay, thanks for testing!

Re: [HACKERS] silent data loss with ext4 / all current versions

On 03/08/2016 02:16 PM, Robert Haas wrote: On Mon, Mar 7, 2016 at 10:18 PM, Andres Freund wrote: Instead of "durable" I think that "persistent" makes more sense. I find durable a lot more descriptive. persistent could refer to retrying the rename or something. Yeah, I

Re: [HACKERS] Performance improvement for joins where outer side is unique

On 23 January 2016 at 05:36, Tomas Vondra wrote: > Hi, > > On 12/17/2015 02:17 PM, David Rowley wrote: >> >> On 17 December 2015 at 19:11, Simon Riggs > > wrote: >> >> On 17 December 2015 at 00:17, Tomas

Re: [HACKERS] Add generate_series(date,date) and generate_series(date,date,integer)

On Fri, Mar 4, 2016 at 3:17 PM, Corey Huinker wrote: >> >> I feel rather uneasy about simply removing the 'infinity' checks. Is there >> a way to differentiate those two cases, i.e. when the generate_series is >> called in target list and in the FROM part? If yes, we

[HACKERS] fun with "Ready for Committer" patches

OK, so I made a pass through the "Ready for Committer" patches in the current CF. One I committed, several I replied to the thread with review comments and set back to "Waiting on Author". Here's where we are with the rest: Silent data loss with ext4 / all current versions - It looks to me like

Re: [HACKERS] Idle In Transaction Session Timeout, revived

On 2016-03-08 16:42:37 -0500, Robert Haas wrote: > - I really wonder if the decision to ignore sessions that are idle in > transaction (aborted) should revisited. Consider this: > > rhaas=# begin; > BEGIN > rhaas=# lock table pg_class; > LOCK TABLE > rhaas=# savepoint a; > SAVEPOINT > rhaas=#

Re: [HACKERS] Performance improvement for joins where outer side is unique

David Rowley writes: > I also notice that some regression tests, which I think some of which > Tom updated in the upper planner changes have now changed back again > due to the slightly reduced costs on hash and nested loop joins where > the inner side is unique. ??

Re: [HACKERS] empty array case in plperl_ref_from_pg_array not handled correctly

On 2016-03-08 02:11:03 -0700, Alex Hunsaker wrote: > On Mon, Mar 7, 2016 at 11:32 PM, Andres Freund wrote: > > > Hi, > > > > Per the new valgrind animal we get: > > > > > > http://pgbuildfarm.org/cgi-bin/show_log.pl?nm=skink=2016-03-08%2004%3A22%3A00 > > 2016-03-08

Re: [HACKERS] SP-GiST support for inet datatypes

On Thu, Mar 3, 2016 at 11:45 AM, Emre Hasegeli wrote: > > Emre, I checked original thread and didn't find sample data. Could you > provide them for testing ? > > I found it on the Git history: > > >

Re: [HACKERS] SP-GiST support for inet datatypes

On Tue, Mar 8, 2016 at 11:17 PM, Oleg Bartunov wrote: > > > On Thu, Mar 3, 2016 at 11:45 AM, Emre Hasegeli wrote: > >> > Emre, I checked original thread and didn't find sample data. Could you >> provide them for testing ? >> >> I found it on the Git

Re: [HACKERS] Idle In Transaction Session Timeout, revived

On Sun, Jan 31, 2016 at 8:33 AM, Vik Fearing wrote: > Attached is a rebased and revised version of my > idle_in_transaction_session_timeout patch from last year. > > This version does not suffer the problems the old one did where it would > jump out of SSL code thanks to

Re: [HACKERS] fun with "Ready for Committer" patches

> It's hard to miss the fact that there are an absolutely breathtaking > number of patches in this CommitFest - 80! - that are in the "needs > review" state. We really, really, really need more review to happen - Many of "needs review" state patches already have reviewer(s). Do you mean we want

Re: [HACKERS] Add generate_series(date,date) and generate_series(date,date,integer)

> > > It would be simple enough to remove the infinity test on the "stop" and > > leave it on the "start". Or yank both. Just waiting for others to agree > > which checks should remain. > > Let's yank 'em. This is a minor issue which is distracting us from > the main point of this patch, and I

Re: [HACKERS] fun with "Ready for Committer" patches

On 03/08/2016 02:45 PM, Robert Haas wrote: > OK, so I made a pass through the "Ready for Committer" patches in the > current CF. One I committed, several I replied to the thread with > review comments and set back to "Waiting on Author". Here's where we > are with the rest: > plpgsql -

Re: [HACKERS] PATCH: index-only scans with partial indexes

Kyotaro HORIGUCHI writes: > Hello, This is a (maybe) committer-ready patch of a Tomas > Vondra's project. I think this needs quite a bit of work yet. A few comments: * If we're going to pay the price of identifying implied restriction conditions in

Re: [HACKERS] Add generate_series(date,date) and generate_series(date,date,integer)

On Tue, Mar 8, 2016 at 3:57 PM, Corey Huinker wrote: > >> I'm pretty meh about the whole idea of this function, though, >> actually, and I don't see a single clear +1 vote for this >> functionality upthread. (Apologies if I've missed one.) In the >> absence of a few of

Re: [HACKERS] Declarative partitioning

> > Sorry for replying so late. > No worries! We have jobs to do aside from this. > > Everything seemed to go dandy until I tried FOR VALUES (blah , blah], > where psql wouldn't send the command string without accepting the closing > parenthesis, :(. So maybe I should try to put the whole

Re: [HACKERS] empty array case in plperl_ref_from_pg_array not handled correctly

On Mon, Mar 7, 2016 at 11:32 PM, Andres Freund wrote: > Hi, > > Per the new valgrind animal we get: > > > http://pgbuildfarm.org/cgi-bin/show_log.pl?nm=skink=2016-03-08%2004%3A22%3A00 > 2016-03-08 05:56:05.566 UTC [56de6971.723:5] LOG: statement: select >

Re: [HACKERS] Freeze avoidance of very large table.

On Tue, Mar 8, 2016 at 1:20 PM, Kyotaro HORIGUCHI wrote: > Hello, thank you for updating this tool. > > At Mon, 7 Mar 2016 14:03:08 -0500, Robert Haas wrote > in >> On

Re: [HACKERS] Parallel query fails on standby server

On 8 March 2016 at 20:30, Ashutosh Sharma wrote: > > While testing a parallel scan feature on standby server, it is found that > the parallel query fails with an error "*ERROR: failed to initialize > transaction_read_only to 0*". > > Looks like it might be a good idea to

Re: [HACKERS] More stable query plans via more predictable column statistics

On Mon, Mar 7, 2016 at 6:02 PM, Jeff Janes wrote: > On Mon, Mar 7, 2016 at 3:17 AM, Shulgin, Oleksandr > wrote: > > > > They might get that different plan when they upgrade to the latest major > > version anyway. Is it set somewhere that

[HACKERS] Parallel query fails on standby server

Hi All, While testing a parallel scan feature on standby server, it is found that the parallel query fails with an error "*ERROR: failed to initialize transaction_read_only to 0*". Following are the steps used to reproduce the issue: *Master :-* edb=# create table ert(n int); edb=# insert

Re: [HACKERS] pam auth - add rhost item

Hi Hari. To use pam modules you can use whatever backend authentication method you want. This is example configuration: Install this library https://github.com/pam-pgsql/pam-pgsql Create some example database , schema access and two tables: pam_auth and pam_account with example defintion:

Re: [HACKERS] checkpointer continuous flushing - V18

Now I cannot see how having one context per table space would have a significant negative performance impact. The 'dirty data' etc. limits are global, not per block device. By having several contexts with unflushed dirty data the total amount of dirty data in the kernel increases. Possibly,

Re: [HACKERS] [PROPOSAL] VACUUM Progress Checker.

You're so quick. At Tue, 8 Mar 2016 17:02:24 +0900, Amit Langote wrote in <56de8710.4070...@lab.ntt.co.jp> > On 2016/03/07 23:48, Robert Haas wrote: > >> I don't like to treat the target object id differently from other > >> parameters. It could not be needed at

Re: [HACKERS] Relation extension scalability

On Mon, Mar 7, 2016 at 8:34 PM, Robert Haas wrote: > > On Fri, Mar 4, 2016 at 11:49 PM, Amit Kapila wrote: > > I think one thing which needs more thoughts about this approach is that we > > need to maintain some number of slots so that group extend

Re: [HACKERS] [PROPOSAL] VACUUM Progress Checker.

On 2016/03/07 23:48, Robert Haas wrote: > On Sun, Mar 6, 2016 at 11:02 PM, Kyotaro HORIGUCHI > wrote: >> The 0001-P.. adds the following interface functions. >> >> +extern void pgstat_progress_set_command(BackendCommandType cmdtype); >> +extern void

Re: [HACKERS] Freeze avoidance of very large table.

On Tue, Mar 8, 2016 at 7:26 AM, Masahiko Sawada wrote: > Regarding pg_visibility module, I'd like to share some bugs and > propose to add a relation type condition to each functions. OK, thanks. > Including it, I've attached remaining 2 patches; one is removing page >

Re: [HACKERS] Splitting lengthy sgml files

On Mon, Mar 7, 2016 at 10:09 AM, Tom Lane wrote: > Tatsuo Ishii writes: >> There are very lengthy (over 10k lines, for example) SGML files in >> docs. While working on translating docs using GitHub, I noticed that >> sometimes diffs are not showed in

Re: [HACKERS] Parallel query fails on standby server

On Tue, Mar 8, 2016 at 9:51 PM, Craig Ringer wrote: > On 8 March 2016 at 20:30, Ashutosh Sharma wrote: >> >> >> While testing a parallel scan feature on standby server, it is found that >> the parallel query fails with an error "ERROR: failed to

Re: [HACKERS] Relation extension scalability

On Tue, Mar 8, 2016 at 4:27 AM, Amit Kapila wrote: >> Hmm. Can we drive this off of the heavyweight lock manager's idea of >> how big the relation extension lock wait queue is, instead of adding >> more stuff to PGPROC? > > One idea to make it work without adding

Re: [HACKERS] Allowing to run a buildfarm animal under valgrind

On 03/07/2016 08:39 PM, Andres Freund wrote: Hi, I'm setting up a buildfarm animal that runs under valgrind. Unfortunately there's not really any good solution to force make check et al. to start postgres wrapped in valgrind. For now I've resorted to adding something like sub

Re: [HACKERS] More stable query plans via more predictable column statistics

Hi Alex, Thanks for excellent research. I've ran your queries against Trustly's production database and I can confirm your findings, the results are similar: WITH ... SELECT count(1), min(hist_ratio)::real, avg(hist_ratio)::real, max(hist_ratio)::real,

Re: [HACKERS] VS 2015 support in src/tools/msvc

On Mon, Mar 7, 2016 at 10:40 PM, Michael Paquier wrote: > On Sun, Mar 6, 2016 at 5:55 AM, Andrew Dunstan wrote: >> On 03/05/2016 01:31 PM, Michael Paquier wrote: >>> On Sat, Mar 5, 2016 at 11:34 PM, Andrew Dunstan >>> wrote:

Re: [HACKERS] Freeze avoidance of very large table.

On Tue, Mar 8, 2016 at 8:30 AM, Robert Haas wrote: > On Tue, Mar 8, 2016 at 7:26 AM, Masahiko Sawada wrote: >> Regarding pg_visibility module, I'd like to share some bugs and >> propose to add a relation type condition to each functions. > > OK,

Re: [HACKERS] Optimizer questions

Tom Lane wrote: > Konstantin Knizhnik writes: > > Attached please find improved version of the optimizer patch for LIMIT > > clause. > For now, I've set this commitfest entry to Waiting on Author. There's > still time to consider a rewrite in this 'fest, if you can

Re: [HACKERS] Parallel Aggregate

On Mon, Mar 7, 2016 at 5:15 PM, David Rowley wrote: > My concerns are: > 1. Since there's no cheapest_partial_path in RelOptInfo the code is > currently considering every partial_path for parallel hash aggregate. > With normal aggregation we only ever use the

Re: [HACKERS] VS 2015 support in src/tools/msvc

Andrew Dunstan writes: > Do we already have a hard dependency on perl for all non-Windows builds? > I know it's been discussed but I don't recall. If so, back to what version? I think the policy is we require perl for building from a git pull, but not for building from a

Re: [HACKERS] Odd warning from pg_dump

Stephen Frost writes: > * Tom Lane (t...@sss.pgh.pa.us) wrote: >> pg_dump: WARNING: typtype of data type "any" appears to be invalid > This is fixed in my changes to pg_dump, though I didn't expect you'd be > able to hit them in released versions and so hadn't been planning

Re: [HACKERS] The plan for FDW-based sharding

On Tue, Mar 8, 2016 at 6:40 AM, Craig Ringer wrote: > Either that, or bless experimental features/API as an official concept. > I'd quite like that myself - stuff that's in Pg, but documented as "might > change or go away in the next release, experimental feature". As

Re: [HACKERS] Odd warning from pg_dump

* Tom Lane (t...@sss.pgh.pa.us) wrote: > Stephen Frost writes: > > * Tom Lane (t...@sss.pgh.pa.us) wrote: > >> pg_dump: WARNING: typtype of data type "any" appears to be invalid > > > This is fixed in my changes to pg_dump, though I didn't expect you'd be > > able to hit them

Re: [HACKERS] Way to check whether a particular block is on the shared_buffer?

On Mon, Mar 7, 2016 at 4:32 AM, Kouhei Kaigai wrote: >> Why not FileDescriptor(), FileFlags(), FileMode() as separate >> functions like FilePathName()? >> > Here is no deep reason. The attached patch adds three individual > functions. This seems unobjectionable to me, so

Re: [HACKERS] Recovery test failure for recovery_min_apply_delay on hamster

Michael Paquier wrote: > On Wed, Mar 2, 2016 at 2:04 PM, Michael Paquier > wrote: > > Here are a couple of ways to address this problem: > > 1) Remove the check before applying the delay > > 2) Increase recovery_min_apply_delay to a time that will allow even > > slow

Re: [HACKERS] [PROPOSAL] VACUUM Progress Checker.

On Tue, Mar 8, 2016 at 3:02 AM, Amit Langote wrote: > Updated versions attached. > > * changed st_progress_param to int64 and so did the argument of > pgstat_progress_update_param(). Likewise changed param1..param10 of > pg_stat_get_progress_info()'s output columns

[HACKERS] Odd warning from pg_dump

In connection with a question on -general, I tried this: $ pg_dump -n '*' regression >regression.dump pg_dump: WARNING: typtype of data type "any" appears to be invalid pg_dump: WARNING: typtype of data type "anyarray" appears to be invalid pg_dump: WARNING: typtype of data type "anyelement"

Re: [HACKERS] Odd warning from pg_dump

* Tom Lane (t...@sss.pgh.pa.us) wrote: > In connection with a question on -general, I tried this: > > $ pg_dump -n '*' regression >regression.dump > pg_dump: WARNING: typtype of data type "any" appears to be invalid > pg_dump: WARNING: typtype of data type "anyarray" appears to be invalid >

Re: [HACKERS] extend pgbench expressions with functions

On Mon, Mar 7, 2016 at 4:58 AM, Fabien COELHO wrote: >> - 32-b: add double functions, including double variables >> - 32-c: remove \setrandom support (advice to use \set + random instead) > > Here is a rebased version after Tom's updates, 33-b & 33-c. I also extended > the

Re: [HACKERS] Relation extension scalability

On Tue, Mar 8, 2016 at 7:23 PM, Robert Haas wrote: > > On Tue, Mar 8, 2016 at 4:27 AM, Amit Kapila wrote: > >> Hmm. Can we drive this off of the heavyweight lock manager's idea of > >> how big the relation extension lock wait queue is, instead of

Re: [HACKERS] VS 2015 support in src/tools/msvc

On 03/08/2016 08:32 AM, Michael Paquier wrote: On Mon, Mar 7, 2016 at 10:40 PM, Michael Paquier wrote: On Sun, Mar 6, 2016 at 5:55 AM, Andrew Dunstan wrote: On 03/05/2016 01:31 PM, Michael Paquier wrote: On Sat, Mar 5, 2016 at 11:34 PM,

Re: [HACKERS] Parallel query fails on standby server

On Tue, Mar 8, 2016 at 8:23 AM, Michael Paquier wrote: > On Tue, Mar 8, 2016 at 9:51 PM, Craig Ringer wrote: >> On 8 March 2016 at 20:30, Ashutosh Sharma wrote: >>> >>> While testing a parallel scan feature on standby

Re: [HACKERS] VS 2015 support in src/tools/msvc

Andrew Dunstan writes: > On 03/08/2016 10:43 AM, Tom Lane wrote: >> However, there definitely *is* a hard requirement on perl for Windows >> builds, even from tarballs, and I thought this patch was only about >> the Windows build? > Michael's patch proposes to replace the

Re: [HACKERS] [PROPOSAL] VACUUM Progress Checker.

On Wed, Mar 9, 2016 at 12:24 AM, Robert Haas wrote: > This patch has been worked on by so many people and reviewed by so > many people that I can't keep track of who should be credited when it > gets committed. Could someone provide a list of author(s) and > reviewer(s)?

Re: [HACKERS] Freeze avoidance of very large table.

On Tue, Mar 8, 2016 at 5:30 AM, Robert Haas wrote: > On Tue, Mar 8, 2016 at 7:26 AM, Masahiko Sawada wrote: >> Regarding pg_visibility module, I'd like to share some bugs and >> propose to add a relation type condition to each functions. > > OK,

Re: [HACKERS] extend pgbench expressions with functions

Hello Robert, Having a look at 33-b, this looks pretty good now, but: // comments are not allowed. I'd just remove the two you have. Oops, C89 did not make it everywhere yet! It make no sense to exit(1) and then return 0, so don't do that. [...] This would get rid of the internal-error

Re: [HACKERS] raw output from copy

2016-03-04 18:06 GMT+01:00 Pavel Stehule : > > > 2016-03-04 15:54 GMT+01:00 Daniel Verite : > >> Corey Huinker wrote: >> >> > So, for me, RAW is the right solution, or at least *a* right solution. >> >> Questions on how to extract from a

Re: [HACKERS] Odd warning from pg_dump

Stephen Frost writes: > I think the real question is if "-n '*'" should still exclude > 'pg_catalog'. Fixing the issue with defined pseudo types is wonderful, > but aren't you going to end up with a dump you can't restore, > regardless? Yeah, perhaps so. The thread on

Re: [HACKERS] VS 2015 support in src/tools/msvc

On 03/08/2016 11:17 AM, Tom Lane wrote: On the whole, I'd rather that this patch left the non-Windows side alone. OK, that's why I raised the issue. We'll do it that way. As I noted upthread, the sed script has been very stable so the overhead of having to maintain two scripts is pretty

  1   2   >