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 pgstat_progress_set_command_target(Oid objid); >

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] 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&dt=2016-03-08%2004%3A22%3A00 > 2016-03-08 05:56:05.566 UTC [56de6971.723:5] LOG: statement: select > plperl_sum_array('{}'); > ==1827== In

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 all, or could be needed two > >>

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 for different > > relations can happen in parall

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: pam_ac

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 minor version upgrades should > > never affect the planne

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 Mon, Mar 7, 2016 at 12:41 PM, Masahiko Sawada >> wrote: >> > Attached latest version optimisation patch. >> > I'm still consi

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

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 add some tests to src/te

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 initialize >> transaction_read_only to 0". >> > >

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 > conversion code from pg_up

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: Here is a translation into perl of the sed script, courtesy o

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 additional stuff in PGPROC is tha

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 pull requests due to the limitation >> of GitH

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, thanks. I left out the relkind check from the fina

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 replace_postgre

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, stddev(hist_rat

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 adding > >> more stuff to PGPROC? > > > > One ide

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 get it done > in a week or tw

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 cheapest path, so this > may not be fu

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 committed. -- Robert Ha

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 machines to see a difference.

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 to bigint. > > * Added back the

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 we're > doing more stuff t

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, Andrew Dunstan wrote: Here is a translation into pe

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 server, it is found that >>> the parallel query fails with an error "ERROR: f

[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" appea

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 tarball. Thus, any file

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 > pg_dum

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 floating point syntax to

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 to > break it out. Oh

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 in released versions

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 -general has also produced

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

On 03/08/2016 10:43 AM, Tom Lane wrote: 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

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)? Original authors are Rah

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 use of sed to generate p

Re: [HACKERS] Relation extension scalability

On Tue, Mar 8, 2016 at 8:34 PM, 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 additional 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, thanks. > >> Including it, I've attached remaining

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 mi

Re: [HACKERS] Odd warning from pg_dump

* Tom Lane (t...@sss.pgh.pa.us) wrote: > 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,

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 ca

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 bytea column come up on a regular >> basis, as in [1

Re: [HACKERS] WIP: Upper planner pathification

I wrote: > There might be some other things we could do to provide a fast-path for > particularly trivial cases. I wanted to look into that before the code or tests had drifted far enough to make comparisons dubious. Attached is a simple patch that lets grouping_planner fall out with a minimum am

Re: [HACKERS] Odd warning from pg_dump

Tom Lane wrote: > 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

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

On Mon, Mar 7, 2016 at 12:41 PM, Masahiko Sawada wrote: > Attached latest version optimisation patch. > I'm still consider regarding pg_upgrade regression test code, so I > will submit that patch later. I just spent some time looking at this and I'm a bit worried about the following (existing) co

Re: [HACKERS] extend pgbench expressions with functions

On Tue, Mar 8, 2016 at 11:48 AM, Fabien COELHO wrote: > If this is a blocker I'll do them, but I'm convince it is not what should be > done. Well, I think it's a blocker. Exiting within deeply-nested code instead of propagating the error upward does not strike me as a good practice. -- Robert

Re: [HACKERS] Odd warning from pg_dump

Alvaro Herrera writes: > Tom Lane wrote: >> So maybe we should drop the hunk you've got there (which frankly seems a >> bit of a kluge) and instead hot-wire things so that stuff in pg_catalog >> is excluded even if it would otherwise match the inclusion lists. > Not sure that's reasonable. We ha

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

Robert Haas writes: > The patch makes some attempt to update the comment mechanically, but > that's not nearly enough. That comment is explaining that you *can't* > rely on the visibility map to tell you *for sure* that a page does not > require vacuuming. For current uses, that's OK, because if

Re: [HACKERS] JPUG wants to have a copyright notice on the translated doc

On 03/04/2016 06:01 PM, Tatsuo Ishii wrote: > I imagine kind of an extream case: a bad guy removes "Copyright > 1996-2016 The PostgreSQL Global Development Group" and replaces it > with his/her copyright. The PostgreSQL license does not permit that; you have to retain the original copyright notic

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

On Wed, Mar 9, 2016 at 1:23 AM, Jeff Janes wrote: > On Tue, Mar 8, 2016 at 5:30 AM, Robert Haas wrote: > I left out the relkind check from the final commit because, for one > thing, the check you added isn't actually right: toast relations can > also have a visibility map. And also, I'm sort of

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

On Tue, Mar 8, 2016 at 12:49 PM, Tom Lane wrote: >> However, after some further thought, I think we might actually be OK. >> If a page goes from all-frozen to not-all-frozen while VACUUM is >> running, any new XID added to the page must be newer than the >> oldestXmin value computed by vacuum_set_

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

On Tue, Mar 8, 2016 at 3:36 PM, Joel Jacobson wrote: > Hi Alex, > > Thanks for excellent research. > Joel, Thank you for spending your time to run these :-) I've ran your queries against Trustly's production database and I can > confirm your findings, the results are similar: > > WITH ... > SE

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

On Tue, Mar 8, 2016 at 12:59 PM, Masahiko Sawada wrote: >> How about instead changing things so that we specifically reject >> indexes? And maybe some kind of a check that will reject anything >> that lacks a relfilnode? That seems like it would be more on point. > > I agree, I don't have strong

Re: [HACKERS] Optimizer questions

On 03/08/2016 07:01 AM, Tom Lane wrote: Konstantin Knizhnik writes: Attached please find improved version of the optimizer patch for LIMIT clause. This patch isn't anywhere close to working after 3fc6e2d7f5b652b4. (TBH, the reason I was negative about this upthread is that I had that one in th

Re: [HACKERS] Getting sorted data from foreign server for merge join

On Thu, Jan 7, 2016 at 4:05 AM, Ashutosh Bapat wrote: > In get_useful_ecs_for_relation(), while checking whether to use left or > right argument of a mergejoinable operator, the arguments to bms_is_subset() > are passed in reverse order. bms_is_subset() checks whether the first > argument in subse

Re: [HACKERS] Pushing down sorted joins

On Tue, Feb 23, 2016 at 7:48 AM, Ashutosh Bapat wrote: > Rushabh pointed out that declarations of helper functions > get_useful_ecs_for_relation and get_useful_pathkeys_for_relation() are part > of FDW routines declarations rather than helper function declaration. Since > those functions are relat

Re: [HACKERS] Minor documentation tweak to GetForeignPlan documentation

On Fri, Jan 15, 2016 at 6:20 AM, Etsuro Fujita wrote: > Attached patch makes minor modification to the GetForeignPlan > documentation. This adds the description about outer_plan, the new > parameter added in 9.5. Good catch. Committed and back-patched to 9.5. -- Robert Haas EnterpriseDB: http

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

On 2016-03-08 08:58:22 -0500, Andrew Dunstan wrote: > On 03/07/2016 08:39 PM, Andres Freund wrote: > >Does anybody have a better idea about how to do this? > > Why not just create a make target which does this? It could be run after > 'make' and before 'make check'. I would make it assume valgrind

Re: [HACKERS] Minor comment update in setrefs.c

On Fri, Jan 15, 2016 at 5:36 AM, Etsuro Fujita wrote: > The point in the previous patch was to update the list of expressions to be > adjusted for the case of scanrelid=0 like that for the case of scanrelid>0 > case in set_foreignscan_references. So, I'd like to propose to add > *fdw_recheck_qual

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

On Wed, Jan 20, 2016 at 5:09 PM, Tom Lane wrote: > Alvaro Herrera writes: >> Tom Lane wrote: >>> "Shulgin, Oleksandr" writes: This post summarizes a few weeks of research of ANALYZE statistics distribution on one of our bigger production databases with some real-world data and pro

Re: [HACKERS] Relation extension scalability

On Tue, Mar 8, 2016 at 11:20 AM, Dilip Kumar wrote: > I have come up with this patch.. > > If this approach looks fine then I will prepare final patch (more comments, > indentation, and improve some code) and do some long run testing (current > results are 5 mins run). > > Idea is same what Robert

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

On Wed, Mar 9, 2016 at 1:25 AM, Shulgin, Oleksandr wrote: > Thank you for spending your time to run these :-) n/p, it took like 30 seconds :-) > I don't want to be asking for too much here, but is there a chance you could > try the effects of the proposed patch on an offline copy of your databas

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

Shulgin, Oleksandr wrote: > Alright. I'm attaching the latest version of this patch split in two > parts: the first one is NULLs-related bugfix and the second is the > "improvement" part, which applies on top of the first one. I went over patch 0001 and it seems pretty reasonable. It's missing

Re: [HACKERS] Proposal: RETURNING primary_key()

On Mon, Mar 7, 2016 at 11:18 PM, Tom Lane wrote: > Craig Ringer writes: >> On 8 March 2016 at 08:56, Igal @ Lucee.org wrote: >>> I'm not sure why it was not accepted at the end? > >> The biggest issue, though it might not be clear from that thread, is that >> what exactly it means to "return gen

Re: [HACKERS] Proposal: Generic WAL logical messages

I think here +const char * +logicalmsg_identify(uint8 info) +{ + if (info & ~XLR_INFO_MASK == XLOG_LOGICAL_MESSAGE) + return "MESSAGE"; + + return NULL; +} we should use brackets const char * logicalmsg_identify(uint8 info) { if ((info & ~XLR_INFO_MASK) == XL

Re: [HACKERS] extend pgbench expressions with functions

Hello Robert. Here is a v34 b & c. // comments are not allowed. I'd just remove the two you have. Back to the eighties! It make no sense to exit(1) and then return 0, so don't do that. I might write this code as: This would get rid of the internal-error case here altogether in favor of t

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

> On 08 Mar 2016, at 10:11, 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&dt=2016-03-08%2004%3A22%3A00 > 2016-03-08 >

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

Andres Freund wrote: > I do wonder if adding a PGCTLPOSTGRESWRAPPER or something to pg_ctl > would be ok. That'd just supplant calling the postgres binary, making > all this easier. This seems a reasonably principled way to go about this. Eventually we might plug other things in it ... -- Álva

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

On 2016-03-08 18:24:23 -0300, Alvaro Herrera wrote: > Andres Freund wrote: > > > I do wonder if adding a PGCTLPOSTGRESWRAPPER or something to pg_ctl > > would be ok. That'd just supplant calling the postgres binary, making > > all this easier. > > This seems a reasonably principled way to go abou

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

Robert Haas writes: > On Wed, Jan 20, 2016 at 5:09 PM, Tom Lane wrote: >> Um, I would like to review it, but I doubt I'll find time before the end >> of the month. > Tom, can you pick this up? Yes, now that I've gotten out from under the pathification thing, I have cycles for patch review. I'l

Re: [HACKERS] Parallel Aggregate

On 9 March 2016 at 04:06, Robert Haas wrote: > 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 on

Re: [HACKERS] Proposal: RETURNING primary_key()

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 easy to implement a high-quality JDBC driver. And I think it would be good to wor

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 Andres' patch in commit >

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 with this change (though I > didn't get any warni

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&dt=2016-03-08%2004%3A22%3A00 > > 2016-03-08 05:56:05.566 UTC [56de6971.7

Re: [HACKERS] pgbench small bug fix

On Wed, Jan 27, 2016 at 2:31 PM, Fabien COELHO wrote: > - when a duration (-T) is specified, ensure that pgbench ends at that >time (i.e. do not wait for a transaction beyond the end of the run). Every other place where doCustom() returns false is implemented as return clientDone(...). I th

Re: [HACKERS] extend pgbench expressions with functions

On Tue, Mar 8, 2016 at 3:52 PM, Fabien COELHO wrote: > [ new patch and assorted color commentary ] This is not acceptable: + /* guess double type (n for "inf", "-inf" and "nan") */ + if (strchr(var, '.') != NULL || strchr(var, 'n') != N

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 EnterpriseDB: http://www.e

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: > > > https://github.com/job/irrexplorer/blob/9e8b5330d7ef0022abbe1af18291257e044eb24b/data/irrexplorer_

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 could do the check >> only in

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 history: >> >> >> https://github.com/job/irrex

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

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

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

Hi, On Mon, 2016-03-07 at 21:55 -0800, Andres Freund wrote: > On 2016-03-08 12:26:34 +0900, Michael Paquier wrote: > > On Tue, Mar 8, 2016 at 12:18 PM, Andres Freund wrote: > > > On 2016-03-08 12:01:18 +0900, Michael Paquier wrote: > > >> I have spent a couple of hours looking at that in details,

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! An

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 - possibilit

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 don

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=# sel

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 check_partial_indexes(), we should at least re

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 those, I recommend we rej

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

Robert Haas wrote: > Let's yank 'em. This is a minor issue which is distracting us from > the main point of this patch, and I don't think it's worth getting > distracted. +1 > I'm pretty meh about the whole idea of this function, though, > actually, and I don't see a single clear +1 vote for th

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

Robert Haas writes: > Unique Joins - This patch has had a lot of review and discussion. It > would be best if Tom Lane looked at it. Yeah, I'll pick it up soon. I've basically been kicking as much as I could down the road for the last couple of months, trying to get the pathification changes do

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 m

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 like durable, too. T

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 Vondra >> mailto:tomas.von...@2ndquadrant.com>> >> w

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 > interest

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 thing

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. ?? I don't see anything in this p

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 so > > many people that I can't keep track of who should be credited when it > > gets committed. Could someone prov

  1   2   >