Re: [HACKERS] [patch] Proposal for \rotate in psql

> postgres=# \crosstabview 4 +month label > Maybe using optional int order column instead label is better - then you can do sort on client side so the syntax can be "\crosstabview VCol [+/-]HCol [[+-]HOrderCol] Regards Pavel > >

Re: [HACKERS] [sqlsmith] Failed to generate plan on lateral subqueries

Andreas Seltenreich writes: > Tom Lane writes: >> [2. transitive-lateral-fixes-1.patch] > I was about to write that sqlsmith likes the patch, but after more than > 10^8 ok queries the attached ones were generated. Ah-hah --- the new check I added in join_is_legal understood

[HACKERS] REASSIGN OWNED doesn't know how to deal with USER MAPPINGs

Hi, We just notice $SUBJECT. Attached patch fixes it by ignoring USER MAPPINGs in shdepReassignOwned() just like it happens with default ACLs. DROP OWNED manages it well. -- Jaime Casanova www.2ndQuadrant.com Professional PostgreSQL: Soporte 24x7 y capacitación diff --git

Re: [HACKERS] Inaccurate results from numeric ln(), log(), exp() and pow()

On Sun, Nov 15, 2015 at 4:40 AM, Dean Rasheed wrote: > On 14 November 2015 at 20:05, Tom Lane wrote: >> I committed this with that change and some other >> mostly-cosmetic revisions. > > Thanks. This patch, or something nearby, seems to have changed

Re: [HACKERS] mdnblocks() sabotages error checking in _mdfd_getseg()

On Thu, Dec 10, 2015 at 1:48 PM, Tom Lane wrote: > Robert Haas writes: >> On Thu, Dec 10, 2015 at 1:22 PM, Simon Riggs wrote: >>> We can seq scan the array at relcache build time and invalidate relcache >>> when we extend. WAL

Re: [HACKERS] Inaccurate results from numeric ln(), log(), exp() and pow()

On 10 December 2015 at 18:59, Robert Haas wrote: Why did we make the change? I'm not sure it's bad, but > it seems funny to whack a user-visible behavior around like this > without a clearly-explained reason. > Surely the title of the post explains? -- Simon Riggs

Re: [HACKERS] Patch: ResourceOwner optimization for tables with many partitions

On Thu, Dec 10, 2015 at 2:11 PM, Tom Lane wrote: > Robert Haas writes: >> Well, sorta. To be honest, I think this patch is really ugly. If we >> were going to do this then, yes, I would want to split the patch into >> two parts along those lines. But

Re: [HACKERS] Inaccurate results from numeric ln(), log(), exp() and pow()

Robert Haas writes: > This patch, or something nearby, seems to have changed the number of > significant figures produced by log() and maybe some of the other > functions this patch touched. Yeah, not surprising. > It's certainly not obvious from the commit message that

Re: [HACKERS] Speedup twophase transactions

On 9 December 2015 at 18:44, Stas Kelvich wrote: > In this patch I’ve changed this procedures to following: > * on prepare backend writes data only to xlog and store pointer to the > start of the xlog record > * if commit occurs before checkpoint then backend reads

Re: [HACKERS] Bootstrap DATA is a pita

Hello Hackers, Reviving an old thread on simplifying the bootstrap process. I'm a developer from the GPDB / HAWQ side of the world where we did some work a while back to enable catalog definition via SQL files and we have found it valuable from a dev perspective. The mechanism currently in

Re: [HACKERS] Patch: ResourceOwner optimization for tables with many partitions

Robert Haas writes: > Well, sorta. To be honest, I think this patch is really ugly. If we > were going to do this then, yes, I would want to split the patch into > two parts along those lines. But actually I don't really want to do > it this way at all. It's not that I

Re: [HACKERS] Inaccurate results from numeric ln(), log(), exp() and pow()

On Thu, Dec 10, 2015 at 2:25 PM, Simon Riggs wrote: > On 10 December 2015 at 18:59, Robert Haas wrote: >Why did we make the change? I'm not sure it's bad, but >> >> it seems funny to whack a user-visible behavior around like this >> without a

Re: [HACKERS] Inaccurate results from numeric ln(), log(), exp() and pow()

Robert Haas writes: > On Thu, Dec 10, 2015 at 2:47 PM, Tom Lane wrote: >> That's on me as author of the commit message, I guess. The rscale >> in most of these functions is exactly the number of fraction digits >> that will be emitted, and we changed

Re: [HACKERS] Error with index on unlogged table

Hi, On 2015-12-10 18:36:32 +0100, Andres Freund wrote: > On 2015-12-10 12:19:12 -0500, Robert Haas wrote: > > > The real problem there imo isn't that the copy_relation_data() doesn't > > > deal with 0 block tables, but that ATExecSetTableSpace() doesn't have a > > > unlogged table specific

Re: [HACKERS] Inaccurate results from numeric ln(), log(), exp() and pow()

On Thu, Dec 10, 2015 at 2:47 PM, Tom Lane wrote: > Robert Haas writes: >> This patch, or something nearby, seems to have changed the number of >> significant figures produced by log() and maybe some of the other >> functions this patch touched. > >

Re: [HACKERS] mdnblocks() sabotages error checking in _mdfd_getseg()

On Thu, Dec 10, 2015 at 11:36 AM, Andres Freund wrote: >> In fact, having no way to get the relation length other than scanning >> 1000 files doesn't seem like an especially good choice even if we used >> a better data structure. Putting a header page in the heap would make

Re: [HACKERS] Error with index on unlogged table

On 2015-12-10 18:36:32 +0100, Andres Freund wrote: > On 2015-12-10 12:19:12 -0500, Robert Haas wrote: > > On Thu, Dec 10, 2015 at 11:32 AM, Andres Freund wrote: > > > I've, pushed the fix for the promotion related issue. I'm afraid that > > > the ALTER TABLE SET TABLESPACE

Re: [HACKERS] REASSIGN OWNED doesn't know how to deal with USER MAPPINGs

On 10 December 2015 at 13:04, Jaime Casanova wrote: > Hi, > > We just notice $SUBJECT. Attached patch fixes it by ignoring USER > MAPPINGs in shdepReassignOwned() just like it happens with default > ACLs. > BTW, shouldn't we at least give a warning on those cases

Re: [HACKERS] mdnblocks() sabotages error checking in _mdfd_getseg()

On 10 December 2015 at 16:47, Robert Haas wrote: > On Thu, Dec 10, 2015 at 11:36 AM, Andres Freund > wrote: > >> In fact, having no way to get the relation length other than scanning > >> 1000 files doesn't seem like an especially good choice even if

[HACKERS] Is postgresql on Windows compatible with flex 2.6.0?

Collegues, Recently (about a month ago) flex 2.6.0 have been released. But when we tried to compile PostgreSQL 9.5 beta 1 from git with it on Windows, we've encountered that src/tools/msvc/pgflex.pl explicitely checks that minor version of flex is equal to 5. unless ($verparts[0] == 2 &&

Re: [HACKERS] Rework the way multixact truncations work

+1 On Thu, Dec 10, 2015 at 9:58 AM, Peter Geoghegan wrote: > On Thu, Dec 10, 2015 at 12:34 AM, Andres Freund > wrote: > >> > Ripping it out and replacing it monolithically will not > >> > change that; it will only make the detailed history harder to > >> >

Re: [HACKERS] Rework the way multixact truncations work

On 2015-12-09 20:23:06 -0500, Noah Misch wrote: > By the way, it occurs to me that I should also make pg_upgrade blacklist the > range of catversions that might have data loss. No sense in putting ourselves > in the position of asking whether data files of a 9.9.3 cluster spent time in > a

Re: [HACKERS] [sqlsmith] Failed to generate plan on lateral subqueries

Tom Lane writes: > [2. transitive-lateral-fixes-1.patch] I was about to write that sqlsmith likes the patch, but after more than 10^8 ok queries the attached ones were generated. regards, Andreas post-patch-errors.sql Description: application/sql -- Sent via pgsql-hackers mailing list

Re: [HACKERS] Rework the way multixact truncations work

On Thu, Dec 10, 2015 at 12:34 AM, Andres Freund wrote: >> > Ripping it out and replacing it monolithically will not >> > change that; it will only make the detailed history harder to >> > reconstruct, and I *will* want to reconstruct it. >> >> What's something that might

Re: [HACKERS] Making tab-complete.c easier to maintain

Hello, At Wed, 9 Dec 2015 10:31:06 -0800, David Fetter wrote in <20151209183106.gc10...@fetter.org> > On Wed, Dec 09, 2015 at 03:49:20PM +, Greg Stark wrote: > > On Wed, Dec 9, 2015 at 2:27 PM, David Fetter wrote: > > > Agreed that the "whole new

Re: [HACKERS] postgres_fdw join pushdown (was Re: Custom/Foreign-Join-APIs)

On Wed, Dec 2, 2015 at 6:45 AM, Ashutosh Bapat wrote: > It's been a long time since last patch on this thread was posted. I have > started > to work on supporting join pushdown for postgres_fdw. Attached please find > three > patches > 1. pg_fdw_core.patch:

Re: [HACKERS] Cluster "stuck" in "not accepting commands to avoid wraparound data loss"

On Thu, Dec 10, 2015 at 4:55 PM, Andres Freund wrote: > Hi, > > I recently started a pgbench benchmark (to evaluate a piece of hardware, > not postgres) with master. Unfortunately, by accident, I started > postgres in a shell, not screen like pgbench. > > Just logged back in

[HACKERS] Cluster "stuck" in "not accepting commands to avoid wraparound data loss"

Hi, I recently started a pgbench benchmark (to evaluate a piece of hardware, not postgres) with master. Unfortunately, by accident, I started postgres in a shell, not screen like pgbench. Just logged back in and saw: client 71 aborted in state 8: ERROR: database is not accepting commands to

Re: [HACKERS] Re: In-core regression tests for replication, cascading, archiving, PITR, etc.

Noah Misch wrote: > On Mon, Dec 07, 2015 at 02:34:39PM +0900, Michael Paquier wrote: > > I don't directly see any limitation with the use of kill on Windows.. > > http://perldoc.perl.org/functions/kill.html > > But indeed using directly pg_ctl kill seems like a better fit for the > > PG

Re: [HACKERS] Cluster "stuck" in "not accepting commands to avoid wraparound data loss"

On 2015-12-10 17:13:12 -0500, Robert Haas wrote: > Is the postmaster in a "stopped" state (T)? No, running normally. New connections are possible without problems. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription:

Re: [HACKERS] mdnblocks() sabotages error checking in _mdfd_getseg()

On Thu, Dec 10, 2015 at 7:09 PM, Robert Haas wrote: >> I really don't like Robert's proposal of a metapage though. We've got too >> darn many forks per relation already. > > Oh, I wasn't thinking of adding a fork, just repurposing block 0 of > the main fork, as we do for

Re: [HACKERS] [sqlsmith] Failed to generate plan on lateral subqueries

I wrote: > Ah-hah --- the new check I added in join_is_legal understood about > chains of LATERAL references, but it forgot that we could also have chains > of outer-join ordering constraints. When we're looking to see if joining > on the basis of a LATERAL reference would break some later outer

Re: [HACKERS] Fwd: [GENERAL] pgxs/config/missing is... missing

Jim Nasby writes: > AFAICT the problem is that missing wasn't included in install or > uninstall in config/Makefile. Attached patch fixes that, and results in > missing being properly installed in lib/pgxs/config. I thought we'd more or less rejected that approach in

[HACKERS] Fwd: [GENERAL] pgxs/config/missing is... missing

Full story below, but in short: I see that there is a config/missing script in source, and that Makefile.global.in references it: > src/Makefile.global.in:missing= $(SHELL) $(top_srcdir)/config/missing AFAICT the problem is that missing wasn't included in install or uninstall

Re: [HACKERS] Error with index on unlogged table

On Fri, Dec 11, 2015 at 1:57 AM, Robert Haas wrote: > On Mon, Nov 30, 2015 at 9:53 PM, Michael Paquier > wrote: >>> I feel quite uncomfortable that it solves the problem from a kind >>> of nature of unlogged object by arbitrary flagging which is

[HACKERS] Add IS (NOT) DISTINCT to subquery_Op

Is there any reason we couldn't/shouldn't support IS DISTINCT in subquery_Op? (Or really, just add support to ANY()/ALL()/(SELECT ...)?) -- Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX Experts in Analytics, Data Architecture and PostgreSQL Data in Trouble? Get it in Treble!

[HACKERS] array_remove(anyarray, anyarray)

Recently I had need of removing occurrences of a number of values from an array. Obviously I could have nested array_remove() call or wrapped the whole thing in a SELECT unnest(), but that seems rather silly and inefficient. Any one have objections to changing array_replace_internal() to make

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

On 2015/12/10 20:46, Michael Paquier wrote: > On Thu, Dec 10, 2015 at 7:23 PM, Amit Langote > wrote: >> AIUI, the counts published via stats collector are updated asynchronously >> w.r.t. operations they count and mostly as aggregate figures. For example, >>

Re: [HACKERS] Add IS (NOT) DISTINCT to subquery_Op

Jim Nasby writes: > Is there any reason we couldn't/shouldn't support IS DISTINCT in > subquery_Op? (Or really, just add support to ANY()/ALL()/(SELECT ...)?) It's not an operator (in the sense of something with a pg_operator OID), which means this would be quite a bit

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

On 2015/12/10 15:28, Michael Paquier wrote: > On Thu, Dec 10, 2015 at 4:40 AM, Robert Haas wrote: >> It's going to be *really* important that this facility provides a >> lightweight way of updating progress, so I think this whole API is >> badly designed. VACUUM, for

Re: [HACKERS] [sqlsmith] Failed to generate plan on lateral subqueries

Tom Lane writes: > Merlin Moncure writes: >> Aside from the functional issues, could your changes result in >> performance regressions? [...] > It's a little bit harder to gauge the impact on planner speed. The > transitive closure calculation could be expensive in a query

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

On Thu, Dec 10, 2015 at 7:23 PM, Amit Langote wrote: > On 2015/12/10 15:28, Michael Paquier wrote: >> - The progress tracking facility adds a whole level of complexity for >> very little gain, and IMO this should *not* be part of PgBackendStatus >> because in most

Re: [HACKERS] Error with index on unlogged table

On Thu, Dec 10, 2015 at 8:56 PM, Andres Freund wrote: >> So, do we go for something like the patch you attached in >> 20151208125716.gs4...@alap3.anarazel.de for master and 9.5, and for >> ~9.4 we use the one I wrote in >>

Re: [HACKERS] Error with index on unlogged table

On 2015-12-10 21:10:57 +0900, Michael Paquier wrote: > In short: should I send patches for all those things or are you on it? I'm on it. I don't think the new name you gave the function, and the new comment, are really an improvement. We already have 'SyncOneBuffer' (unusable for our purpose

Re: [HACKERS] Error with index on unlogged table

On Thu, Dec 10, 2015 at 9:13 PM, Andres Freund wrote: > On 2015-12-10 21:10:57 +0900, Michael Paquier wrote: >> In short: should I send patches for all those things or are you on it? > > I'm on it. I don't think the new name you gave the function, and the new > comment, are

Re: [HACKERS] [sqlsmith] Failed to generate plan on lateral subqueries

On Sun, Dec 6, 2015 at 9:52 AM, Andreas Seltenreich wrote: > I've added new grammar rules to sqlsmith and improved some older ones. Could you possibly teach sqlsmith about INSERT ... ON CONFLICT DO UPDATE/IGNORE? I think that that could be very helpful, especially if it could

Re: [HACKERS] Error with index on unlogged table

On Thu, Dec 10, 2015 at 4:57 PM, Andres Freund wrote: > On December 10, 2015 5:02:27 AM GMT+01:00, Michael Paquier > wrote: >>On Wed, Dec 9, 2015 at 9:07 PM, Andres Freund >>wrote: >>> On 2015-12-09 21:03:47 +0900, Michael

Re: [HACKERS] Error with index on unlogged table

> So, do we go for something like the patch you attached in > 20151208125716.gs4...@alap3.anarazel.de for master and 9.5, and for > ~9.4 we use the one I wrote in > cab7npqsxerpzj+bz-mfopzfzp5pabie9jwbucjy6qayertt...@mail.gmail.com? I'm more thinking of using something like my patch for all

Re: [HACKERS] Error with index on unlogged table

On Thu, Dec 10, 2015 at 9:07 PM, Michael Paquier wrote: > On Thu, Dec 10, 2015 at 8:56 PM, Andres Freund wrote: >>> So, do we go for something like the patch you attached in >>> 20151208125716.gs4...@alap3.anarazel.de for master and 9.5, and for >>>

Re: [HACKERS] Is postgresql on Windows compatible with flex 2.6.0?

On Thu, Dec 10, 2015 at 5:45 PM, Victor Wagner wrote: > Recently (about a month ago) flex 2.6.0 have been released. > > But when we tried to compile PostgreSQL 9.5 beta 1 from git with it on > Windows, we've encountered that src/tools/msvc/pgflex.pl explicitely > checks that

Re: [HACKERS] Error with index on unlogged table

On Mon, Nov 30, 2015 at 9:53 PM, Michael Paquier wrote: >> I feel quite uncomfortable that it solves the problem from a kind >> of nature of unlogged object by arbitrary flagging which is not >> fully corresponds to the nature. If we can deduce the necessity >> of fsync

Re: [HACKERS] Error with index on unlogged table

On 2015-12-10 12:19:12 -0500, Robert Haas wrote: > On Thu, Dec 10, 2015 at 11:32 AM, Andres Freund wrote: > > I've, pushed the fix for the promotion related issue. I'm afraid that > > the ALTER TABLE SET TABLESPACE issue is a bit bigger > > than it though. > > I think that I

Re: [HACKERS] mdnblocks() sabotages error checking in _mdfd_getseg()

On Thu, Dec 10, 2015 at 1:22 PM, Simon Riggs wrote: > On 10 December 2015 at 16:47, Robert Haas wrote: >> >> On Thu, Dec 10, 2015 at 11:36 AM, Andres Freund >> wrote: >> >> In fact, having no way to get the relation length other

Re: [HACKERS] Error with index on unlogged table

On Thu, Dec 10, 2015 at 11:32 AM, Andres Freund wrote: > I've, pushed the fix for the promotion related issue. I'm afraid that > the ALTER TABLE SET TABLESPACE issue is a bit bigger > than it though. I think that I would have preferred to fix this by flushing unlogged

Re: [HACKERS] mdnblocks() sabotages error checking in _mdfd_getseg()

On Thu, Dec 10, 2015 at 12:55 PM, Greg Stark wrote: > On Thu, Dec 10, 2015 at 4:47 PM, Robert Haas wrote: >> It's not straightforward, but I don't think that's the reason. What >> we could do is look at the call sites that use >> RelationGetNumberOfBlocks()

Re: [HACKERS] proposal: PL/Pythonu - function ereport

Hi 2015-12-08 7:06 GMT+01:00 Catalin Iacob : > On Thu, Dec 3, 2015 at 6:54 PM, Pavel Stehule > wrote: > > Don't understand - if Fatal has same behave as Error, then why it cannot > be > > inherited from Error? > > > > What can be broken? > >

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

On Tue, Dec 8, 2015 at 6:16 AM, Etsuro Fujita wrote: > Attached is a small patch to adjust a comment in setrefs.c; in > set_foreignscan_references, fdw_recheck_quals also gets adjusted to > reference foreign scan tuple, in case of a foreign join, so I added > "etc.",

Re: [HACKERS] mdnblocks() sabotages error checking in _mdfd_getseg()

On Thu, Dec 10, 2015 at 4:47 PM, Robert Haas wrote: > > It's not straightforward, but I don't think that's the reason. What > we could do is look at the call sites that use > RelationGetNumberOfBlocks() and change some of them to get the > information some other way

Re: [HACKERS] mdnblocks() sabotages error checking in _mdfd_getseg()

Robert Haas writes: > On Thu, Dec 10, 2015 at 1:22 PM, Simon Riggs wrote: >> We can seq scan the array at relcache build time and invalidate relcache >> when we extend. WAL log any extension to a new segment and write the table >> to disk at

Re: [HACKERS] Patch to install config/missing

Alvaro Herrera writes: > Peter Eisentraut wrote: >> On 11/11/15 12:34 PM, Tom Lane wrote: >>> I was thinking more of removing the "missing" script and associated logic >>> entirely, rather than making PGXS a special case. >> Well, about a year ago people were arguing

Re: [HACKERS] [sqlsmith] Failed to generate plan on lateral subqueries

I wrote: > As threatened, here's a patch on top of that that gets rid of > LateralJoinInfo. I'm pretty happy with this, although I have an > itchy feeling that we could dispense with the lateral_vars lists too. I experimented with that and figured out what was bothering me: there is no need for

Re: [HACKERS] Is postgresql on Windows compatible with flex 2.6.0?

On Thu, Dec 10, 2015 at 10:36 PM, Victor Wagner wrote: > Postgres requires relatively recent Perl. Version objects appeared in > Perl 5.10 and most people would have something newer. AFAIK, the minimum requirement for perl is 5.8... -- Michael -- Sent via pgsql-hackers

Re: [HACKERS] Speedup twophase transactions

Michael, Jeff thanks for reviewing and testing. > On 10 Dec 2015, at 02:16, Michael Paquier wrote: > > This has better be InvalidXLogRecPtr if unused. Yes, that’s better. Changed. > On 10 Dec 2015, at 02:16, Michael Paquier wrote: > +

Re: [HACKERS] Is postgresql on Windows compatible with flex 2.6.0?

On Thu, 10 Dec 2015 21:19:46 +0900 Michael Paquier wrote: > On Thu, Dec 10, 2015 at 5:45 PM, Victor Wagner > > Postgres seems to compile fine with flex 2.6.0. > > It seems that 32f15d05 missed to update its equivalent in > src/tools/msvc. Per

Re: [HACKERS] Rework the way multixact truncations work

On Wed, Dec 9, 2015 at 8:23 PM, Noah Misch wrote: > On Wed, Dec 09, 2015 at 11:08:32AM -0500, Robert Haas wrote: >> On Wed, Dec 9, 2015 at 9:43 AM, Noah Misch wrote: >> > I hope those who have not already read commit 4f627f8 will not waste time >> > reading

Re: [HACKERS] [sqlsmith] Failed to generate plan on lateral subqueries

On Thu, Dec 10, 2015 at 4:55 AM, Andreas Seltenreich wrote: > Tom Lane writes: > >> Merlin Moncure writes: >>> Aside from the functional issues, could your changes result in >>> performance regressions? > [...] >> It's a little bit harder to gauge the

Re: [HACKERS] Rework the way multixact truncations work

On 2015-12-10 08:55:54 -0500, Robert Haas wrote: > Maybe. But I think we could use a little more vigorous discussion of > that issue, since Andres doesn't seem to be very convinced by your > analysis, and I don't currently understand what you've fixed because I > can't, as mentioned several

Re: [HACKERS] Tab-comletion for RLS

On Tue, Dec 8, 2015 at 8:32 AM, Masahiko Sawada wrote: > I found some lacks of tab-completion for RLS in 9.5. > > * ALTER POLICY [TAB] > I expected to appear the list of policy name, but nothing is appeared. > > * ALTER POLICY hoge_policy ON [TAB] > I expected to appear the

Re: [HACKERS] postgres_fdw join pushdown (was Re: Custom/Foreign-Join-APIs)

On Tue, Dec 8, 2015 at 6:40 AM, Etsuro Fujita wrote: > IMO I want to see the EvalPlanQual fix in the first version for 9.6. +1. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list

Re: [HACKERS] mdnblocks() sabotages error checking in _mdfd_getseg()

On 2015-12-10 17:55:37 +, Greg Stark wrote: > It seems to me that if you want to fix the linked lists of files > that's orthogonal to whether the file lengths on disk are > authoritative. You can always keep the lengths or at least the number > of files cached and updated in shared memory in a

Re: [HACKERS] Error with index on unlogged table

On Fri, Dec 11, 2015 at 1:32 AM, Andres Freund wrote: > I've, pushed the fix for the promotion related issue. Thanks! It is great to see this issue addressed. -- Michael -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your

Re: [HACKERS] Error with index on unlogged table

On Fri, Dec 11, 2015 at 4:27 AM, Andres Freund wrote: > Hi, > > On 2015-12-10 18:36:32 +0100, Andres Freund wrote: >> On 2015-12-10 12:19:12 -0500, Robert Haas wrote: >> > > The real problem there imo isn't that the copy_relation_data() doesn't >> > > deal with 0 block tables,

Re: [HACKERS] Inaccurate results from numeric ln(), log(), exp() and pow()

On 10 December 2015 at 20:02, Tom Lane wrote: >> It seems to be a loss of 4 digits in every case I've seen. > > I wouldn't have a problem with, say, throwing in an extra DEC_DIGITS worth > of rscale in each of these functions so that the discrepancies tend to > favor more

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

On Thu, Dec 10, 2015 at 9:49 AM, Tom Lane wrote: > Robert Haas writes: >> Oh, please, no. Gosh, this is supposed to be a lightweight facility! >> Just have a chunk of shared memory and write the data in there. If >> you try to feed this through the

Re: [HACKERS] Error with index on unlogged table

Hello, At Thu, 10 Dec 2015 20:27:01 +0100, Andres Freund wrote in <20151210192701.gc11...@alap3.anarazel.de> > > > > A second problem is that the smgrimmedsync() in copy_relation_data() > > > > isn't called for the init fork of unlogged relations, even if it needs > > > >

Re: [HACKERS] Re: In-core regression tests for replication, cascading, archiving, PITR, etc.

On Fri, Dec 11, 2015 at 5:35 AM, Alvaro Herrera wrote: > Noah Misch wrote: >> On Mon, Dec 07, 2015 at 02:34:39PM +0900, Michael Paquier wrote: >> > > Postmaster log file names became less informative. Before the commit: >> > > Should nodes get a name, so we instead see

Re: [HACKERS] postgres_fdw join pushdown (was Re: Custom/Foreign-Join-APIs)

On Thu, Dec 10, 2015 at 11:20 PM, Robert Haas wrote: > On Tue, Dec 8, 2015 at 6:40 AM, Etsuro Fujita > wrote: > > IMO I want to see the EvalPlanQual fix in the first version for 9.6. > > +1. > > I think there is still a lot functionality that

Re: [HACKERS] postgres_fdw join pushdown (was Re: Custom/Foreign-Join-APIs)

On Fri, Dec 11, 2015 at 3:41 AM, Robert Haas wrote: > On Wed, Dec 2, 2015 at 6:45 AM, Ashutosh Bapat > wrote: > > It's been a long time since last patch on this thread was posted. I have > > started > > to work on supporting join pushdown

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

Sorry, I misunderstood the meaning of PgStat_*. At Fri, 11 Dec 2015 09:41:04 +0900, Amit Langote wrote in <566a1ba0.70...@lab.ntt.co.jp> > > As far as I understand it, the basic reason why this patch exists is > > to allow a DBA to have a hint of the progress of a

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

On 2015/12/11 14:41, Kyotaro HORIGUCHI wrote: > Sorry, I misunderstood the meaning of PgStat_*. I should've just said "messages to the stats collector" instead of "PgStat_Msg's". > > At Fri, 11 Dec 2015 09:41:04 +0900, Amit Langote > wrote >>> As far as I

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

On Fri, Dec 11, 2015 at 12:59 AM, Robert Haas wrote: > On Thu, Dec 10, 2015 at 9:49 AM, Tom Lane wrote: >> Robert Haas writes: >>> Oh, please, no. Gosh, this is supposed to be a lightweight facility! >>> Just have a chunk of

Re: [HACKERS] Parallel Aggregate

On Thu, Dec 3, 2015 at 6:06 PM, David Rowley wrote: > On 3 December 2015 at 19:24, Haribabu Kommi > wrote: >> >> On Thu, Dec 3, 2015 at 4:18 PM, David Rowley >> wrote: >> > >> > Hi, >> > >> > I just wanted to

Re: [HACKERS] Is postgresql on Windows compatible with flex 2.6.0?

Andres Freund writes: > Tom, are you applying the patch, or should I? I can do it ... it was my oversight to begin with :-( regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your

Re: [HACKERS] Rework the way multixact truncations work

On Thu, Dec 10, 2015 at 9:04 AM, Andres Freund wrote: > On 2015-12-10 08:55:54 -0500, Robert Haas wrote: >> Maybe. But I think we could use a little more vigorous discussion of >> that issue, since Andres doesn't seem to be very convinced by your >> analysis, and I don't

Re: [HACKERS] Is postgresql on Windows compatible with flex 2.6.0?

On 2015-12-10 09:39:30 -0500, Tom Lane wrote: > Michael Paquier writes: > > On Thu, Dec 10, 2015 at 10:36 PM, Victor Wagner wrote: > >> Postgres requires relatively recent Perl. Version objects appeared in > >> Perl 5.10 and most people would have

Re: [HACKERS] Is postgresql on Windows compatible with flex 2.6.0?

Michael Paquier writes: > On Thu, Dec 10, 2015 at 10:36 PM, Victor Wagner wrote: >> Postgres requires relatively recent Perl. Version objects appeared in >> Perl 5.10 and most people would have something newer. > AFAIK, the minimum requirement for

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

On Thu, Dec 10, 2015 at 6:46 AM, Michael Paquier wrote: > On Thu, Dec 10, 2015 at 7:23 PM, Amit Langote > wrote: >> On 2015/12/10 15:28, Michael Paquier wrote: >>> - The progress tracking facility adds a whole level of complexity for >>>

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

Robert Haas writes: > Oh, please, no. Gosh, this is supposed to be a lightweight facility! > Just have a chunk of shared memory and write the data in there. If > you try to feed this through the stats collector you're going to > increase the overhead by 100x or more, and

Re: [HACKERS] mdnblocks() sabotages error checking in _mdfd_getseg()

On Wed, Dec 9, 2015 at 4:54 PM, Tom Lane wrote: > Robert Haas writes: >> The comment in mdnblocks.c says this: > >> * Because we pass O_CREAT, we will create the >> next segment (with >> * zero length)

Re: [HACKERS] proposal: multiple psql option -c

On Wed, Dec 9, 2015 at 12:15 AM, Pavel Stehule wrote: >> On Wed, Dec 9, 2015 at 2:07 PM, Pavel Stehule >> wrote: >> > should be noted, recorded somewhere so this introduce possible >> > compatibility >> > issue - due default processing .psqlrc.

Re: [HACKERS] Remaining 9.5 open items

On Wed, Dec 9, 2015 at 2:52 AM, Etsuro Fujita wrote: > Thank you for committing the patch! > > Sorry, I overlooked a typo in docs: s/more that one/more than one/ Please > find attached a patch. Committed, thanks. -- Robert Haas EnterpriseDB:

Re: [HACKERS] Error with index on unlogged table

Hi Michael, Robert, On 2015-12-10 21:10:57 +0900, Michael Paquier wrote: > On Thu, Dec 10, 2015 at 9:07 PM, Michael Paquier > wrote: > >>> Note that in both cases the patches are not complete, we need to fix > >>> as well copy_relation_data@tablecmds.c so as the

Re: [HACKERS] Patch: ResourceOwner optimization for tables with many partitions

On Wed, Dec 9, 2015 at 8:30 AM, Aleksander Alekseev wrote: > Hello, Robert > > Thanks for your review. I believe I fixed items 1, 2 and 3 (see > attachment). Also I would like to clarify item 4. > >> 4. It mixes together multiple ideas in a single patch, not only >>

Re: [HACKERS] mdnblocks() sabotages error checking in _mdfd_getseg()

On 2015-12-10 11:10:10 -0500, Robert Haas wrote: > (More broadly, as Kevin was pointing out to me yesterday, md.c looks > like it could do with a face lift. Keeping a linked list of 1GB > segments and chasing down the list to find the length of the file may > have been fine when relations over