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

Hi Amit, > -Original Message- > From: Amit Langote [mailto:langote_amit...@lab.ntt.co.jp] > Sent: Wednesday, March 09, 2016 4:29 PM > To: Kyotaro HORIGUCHI > Cc: robertmh...@gmail.com; amitlangot...@gmail.com; SPS ポクレ ヴィ > ナヤック(三技術)

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] 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/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,

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

[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

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

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

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

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

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

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

[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

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

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

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

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

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

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

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

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

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

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

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) ==

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

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

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). > >

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

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

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

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

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.

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

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

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

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

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

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

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

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

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

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

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

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,

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

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

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   >