Re: [HACKERS] Alpha2/Beta1

On 2015/07/22 12:40, Noah Misch wrote: I vote for alpha2. Comparing the "Open Issues" and "resolved after 9.5alpha1" sections of https://wiki.postgresql.org/wiki/PostgreSQL_9.5_Open_Items, we've not transitioned to a qualitatively different level of API stability. +1 for alpha2. I'd like to p

Re: [HACKERS] Typo in comment in setrefs.c

On 2015/07/21 1:38, Alvaro Herrera wrote: Etsuro Fujita wrote: I ran into a typo in a comment in setrefs.c. Patch attached. Fixed by Heikki in 7845db2aa. Thank you for letting me know about that, Alvaro! And thanks Heikki for picking this up! Best regards, Etsuro Fujita -- Sent via pg

Re: [HACKERS] WAL logging problem in 9.4.3?

On 2015-07-21 21:37:41 +0200, Martijn van Oosterhout wrote: > On Tue, Jul 21, 2015 at 02:24:47PM -0400, Todd A. Cook wrote: > > Hi, > > > > This thread seemed to trail off without a resolution. Was anything done? > > Not that I can tell. Heikki and I had some in-person conversation about it at

[HACKERS] fdw_scan_tlist for foreign table scans breaks EPQ testing, doesn't it?

Hi, The latest foreign-join pushdown patch allows fdw_scan_tlist to be set to a targetlist even for simple foreign table scans. However, since I think we assume that the test tuple of a foreign table for an EPQ testing, whether it may be copied from the whole-row var or returned by the RefetchFor

Re: [HACKERS] Solaris testers wanted for strxfrm() behavior

On 22/07 02.29, Noah Misch wrote: > > I ran this program on Solaris 9 U5 (September 2006) on Sparc and got: > > I appreciate your testing. A few sources give December 2003 as the month for > Solaris 9 Update 5; would you verify the vintage you used? Sorry I was mis-parsing the /etc/release. 9/05

Re: [HACKERS] Solaris testers wanted for strxfrm() behavior

On Tue, Jul 21, 2015 at 04:45:21PM +0200, Bjorn Munch wrote: > On 27/06 12.51, Noah Misch wrote: > > > > PostgreSQL 9.5 adds a strxfrm() call in bttext_abbrev_convert(), which does > > not account for the Solaris bug. I wish to determine whether that bug is > > still relevant today. If you have

Re: [HACKERS] Minor code improvements to create_foreignscan_plan/ExecInitForeignScan

On 2015/07/10 21:59, David Rowley wrote: On 10 July 2015 at 21:40, Etsuro Fujita mailto:fujita.ets...@lab.ntt.co.jp>> wrote: To save cycles, I modified create_foreignscan_plan so that it detects whether any system columns are requested if scanning a base relation. Also, I revised oth

Re: [HACKERS] Alpha2/Beta1

On 21 July 2015 at 22:01, Josh Berkus wrote: > My question for Hackers is: should this be Alpha2 or Beta 1? > Alpha2 -- Simon Riggshttp://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Re: [HACKERS] RFC: replace pg_stat_activity.waiting with something more descriptive

Hello, At Tue, 21 Jul 2015 14:28:25 +0300, Ildus Kurbangaliev wrote in <55ae2cd9.4050...@postgrespro.ru> > On 07/21/2015 01:18 PM, Andres Freund wrote: > > On 2015-07-21 13:11:36 +0300, Ildus Kurbangaliev wrote: > >> /* > >>* Top-level transactions are identified by VirtualTransactionIDs

Re: [HACKERS] Use pg_rewind when target timeline was switched

On Mon, Jul 20, 2015 at 9:18 PM, Alexander Korotkov wrote: > attached patch allows pg_rewind to work when target timeline was switched. > Actually, this patch fixes TODO from pg_rewind comments. > > /* >* Trace the history backwards, until we hit the target timeline. >* >* TODO: This

Re: [HACKERS] pgbench stats per script & other stuff

Hello Josh, Maybe -f file.sql:weight (yuk from my point of view, but it can be done easily). Maybe it's past time for pgbench to have a config file? That is an idea. For "simple" usage, for backward compatibility and for people like me who like them, ISTM that options are fine too:-) Al

Re: [HACKERS] creating extension including dependencies

On Tue, Jul 21, 2015 at 11:20 PM, Tom Lane wrote: > Petr Jelinek writes: >> ... My main question is if we are >> ok with SCHEMA having different behavior with CASCADE vs without >> CASCADE. I went originally with "no" and added the DEFAULT flag to >> SCHEMA. If the answer is "yes" then we don't n

Re: [HACKERS] pgbench stats per script & other stuff

Hello Robert, Pgbench *currently* already accept multiple "-f ..." options, and this is a good thing to test realistic loads which may intermix several kind of transactions, say a lot of readonly and some update or insert, and very rare deletes... Hmm, I didn't realize that. The code looks a

Re: [HACKERS] Linux kernel performance regression tests and Postgres

On Wed, Jul 22, 2015 at 1:27 PM, Peter Geoghegan wrote: > Mel Gorman wrote a tool to perform Linux kernel performance testing. > Detecting performance regressions in new kernels appears to be the > major goal. > > I note that there are Postgres specific tests listed here: > > http://www.csn.ul.ie/

Re: [HACKERS] pg_basebackup and replication slots

On Wed, Jul 22, 2015 at 10:15 AM, Peter Eisentraut wrote: > On 7/2/15 3:37 AM, Michael Paquier wrote: >> 2) >> sub psql >> { >> my ($dbname, $sql) = @_; >> - run [ 'psql', '-X', '-q', '-d', $dbname, '-f', '-' ], '<', \$sql or >> die; >> + my ($stdout, $stderr); >> + run

[HACKERS] Linux kernel performance regression tests and Postgres

Mel Gorman wrote a tool to perform Linux kernel performance testing. Detecting performance regressions in new kernels appears to be the major goal. I note that there are Postgres specific tests listed here: http://www.csn.ul.ie/~mel/results/home/marvin/dashboard-openSUSE-13.1-smart.html -- Pete

Re: [HACKERS] Alpha2/Beta1

On Tue, Jul 21, 2015 at 8:40 PM, Noah Misch wrote: > I vote for alpha2. Comparing the "Open Issues" and "resolved after 9.5alpha1" > sections of https://wiki.postgresql.org/wiki/PostgreSQL_9.5_Open_Items, we've > not transitioned to a qualitatively different level of API stability. I agree. I'd

Re: [HACKERS] Alpha2/Beta1

On Wed, Jul 22, 2015 at 12:40 PM, Noah Misch wrote: > On Tue, Jul 21, 2015 at 02:01:57PM -0700, Josh Berkus wrote: >> At the Developer's Meeting, we said we'd be releasing an alpha or beta >> each month until final 9.5 release. As such, we should be releasing a >> 9.5 alpha/beta in the first week

Re: [BUGS] [HACKERS] object_classes array is broken, again

Jaimin Pan wrote: > Hi all, > > How about this patch. I believe it will never missing someone and be > detected while compiling. Hmm, yeah this looks like something that's worth considering going forward. I can't think of any reason not to do this. Perhaps we can write getObjectClass using this

Re: [HACKERS] Alpha2/Beta1

On Tue, Jul 21, 2015 at 02:01:57PM -0700, Josh Berkus wrote: > At the Developer's Meeting, we said we'd be releasing an alpha or beta > each month until final 9.5 release. As such, we should be releasing a > 9.5 alpha/beta in the first week of August. > > My question for Hackers is: should this b

Re: [HACKERS] ALTER TABLE .. ADD PRIMARY KEY .. USING INDEX has dump-restore hazard

On Wed, Jul 22, 2015 at 9:34 AM, Michael Paquier wrote: > On Wed, Jul 22, 2015 at 1:23 AM, Robert Haas wrote: >> Notice that the collation specifier is gone. Oops. > > As it is not possible to specify directly a constraint for a PRIMARY > KEY expression, what about switching dumpConstraint to ha

Re: [HACKERS] "make check" changes have caused buildfarm deterioration.

On Wed, Jul 22, 2015 at 10:04 AM, Peter Eisentraut wrote: > On 7/21/15 10:00 AM, Tom Lane wrote: >> I agree; this change may have seemed like a good idea at the time, but >> it was not. Failures during "make check"'s install step are rare enough >> that you don't really need all that output in yo

Re: [HACKERS] pg_basebackup and replication slots

On 7/2/15 3:37 AM, Michael Paquier wrote: > Regarding patch 3, I have more comments: > 1) I think that documentation should clearly mention that if -R and -S > are used together, a primary_slot_name entry is added in the > recovery.conf generated with the slot name defined. Updated proposal attach

Re: [HACKERS] "make check" changes have caused buildfarm deterioration.

On Tue, Jul 21, 2015 at 10:34 PM, Andrew Dunstan wrote: > OK, looks sane enough. but please do address the other issue. Okidoki. -- Michael -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hacke

Re: [HACKERS] "make check" changes have caused buildfarm deterioration.

On 7/21/15 10:00 AM, Tom Lane wrote: > I agree; this change may have seemed like a good idea at the time, but > it was not. Failures during "make check"'s install step are rare enough > that you don't really need all that output in your face to help with the > rare situation where it fails. And f

Re: [HACKERS] [PATCH] Reload SSL certificates on SIGHUP

On 07/02/2015 06:13 PM, Peter Eisentraut wrote: I think this would be a useful feature, and the implementation looks sound. But I don't like how the reload is organized. Reinitializing the context in the sighup handler, aside from questions about how much work one should do in a signal handler,

Re: [HACKERS] ALTER TABLE .. ADD PRIMARY KEY .. USING INDEX has dump-restore hazard

On Wed, Jul 22, 2015 at 1:23 AM, Robert Haas wrote: > Notice that the collation specifier is gone. Oops. As it is not possible to specify directly a constraint for a PRIMARY KEY expression, what about switching dumpConstraint to have it use first a CREATE INDEX query with the collation and then

[HACKERS] Planner debug views

Here is a proposal introducing some debugging infrastructure into the core. The basic idea is to allow us to query the planner search space. To so do, we can dump related information to csv files and use foreign table to query them. So here I propose two foreign tables: create foreign table pg_p

Re: [HACKERS] pgbench stats per script & other stuff

On 07/21/2015 09:29 AM, Fabien COELHO wrote: > Maybe -f file.sql:weight (yuk from my point of view, but it can be done > easily). Maybe it's past time for pgbench to have a config file? Given that we want to define some per-workload options, the config file would probably need to be YAML or JSON,

Re: [HACKERS] brin index vacuum versus transaction snapshots

On Tue, Jul 21, 2015 at 3:10 PM, Kevin Grittner wrote: > Kevin Grittner wrote: > > > If you run `make installcheck` against a cluster with > > default_transaction_isolation = 'repeatable read' you get one > > failure: > > > + ERROR: brin_summarize_new_values() cannot run in a transaction that >

Re: [HACKERS] brin index vacuum versus transaction snapshots

Kevin Grittner wrote: > If you run `make installcheck` against a cluster with > default_transaction_isolation = 'repeatable read' you get one > failure: > + ERROR: brin_summarize_new_values() cannot run in a transaction that has > already obtained a snapshot > This is using source at commit 9f

Re: [HACKERS] RFC: Allow materialized views to use unlogged data store

On 2015-07-21 14:38:24 -0700, Joshua D. Drake wrote: > What do we think about $subject? In short, the underlying table of an MV > would have the option of being unlogged. There was a rather long thread about the difficulities of doing so correctly back when matviews went in. It's not just a line o

[HACKERS] RFC: Allow materialized views to use unlogged data store

-hackers, What do we think about $subject? In short, the underlying table of an MV would have the option of being unlogged. JD -- Command Prompt, Inc. - http://www.commandprompt.com/ 503-667-4564 PostgreSQL Centered full stack support, consulting and development. Announcing "I'm offended" is

Re: [HACKERS] pgbench stats per script & other stuff

On Tue, Jul 21, 2015 at 12:29 PM, Fabien COELHO wrote: > Pgbench *currently* already accept multiple "-f ..." options, and this is a > good thing to test realistic loads which may intermix several kind of > transactions, say a lot of readonly and some update or insert, and very rare > deletes...

Re: [HACKERS] Alpha2/Beta1

On 22/07/15 09:01, Josh Berkus wrote: [...] My question for Hackers is: should this be Alpha2 or Beta 1? Yes! :-) (The decision, as to which, I'll leave to the REAL Developers.) More seriously, I expect that the alpha probably generated a lot of useful feedback. Was this actually the cas

Re: [HACKERS] [PATCH] postgres_fdw extension support

On Tue, Jul 21, 2015 at 11:29 AM, Paul Ramsey wrote: > On July 21, 2015 at 11:22:12 AM, Tom Lane (t...@sss.pgh.pa.us) wrote: > > No, *not* populated first-time-through, because that won't handle any of > the CREATE, DROP, or UPGRADE cases. It's also doing a lot of work you > might never need. I wa

[HACKERS] Alpha2/Beta1

All: At the Developer's Meeting, we said we'd be releasing an alpha or beta each month until final 9.5 release. As such, we should be releasing a 9.5 alpha/beta in the first week of August. My question for Hackers is: should this be Alpha2 or Beta 1? -- Josh Berkus PostgreSQL Experts Inc. http

Re: [HACKERS] Arguable RLS security bug, EvalPlanQual() paranoia

Robert, As I mentioned up thread, I'm out until the 27th. I have posted a patch which I will push to fix the copy.c issue, and I have already stated that I'll address the statistics issue. Further, Joe has also been working on issues but he was out of pocket last week attending a conference. I'm

Re: [HACKERS] Arguable RLS security bug, EvalPlanQual() paranoia

On Sun, Jul 19, 2015 at 8:56 PM, Peter Geoghegan wrote: > On Mon, Jun 1, 2015 at 12:29 AM, Peter Geoghegan wrote: >> If you're using another well known MVCC database system that has RLS, >> I imagine when this happens the attacker similarly waits on the >> conflicting (privileged) xact to finish

Re: [HACKERS] BRIN index and aborted transaction

On Sat, Jul 18, 2015 at 5:11 AM, Alvaro Herrera wrote: > Yeah, that's a bit of an open problem: we don't have any mechanism to > mark a block range as needing resummarization, yet. I don't have any > great ideas there, TBH. Some options that were discussed but never led > anywhere: > > 1. whenev

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

On Tue, Jun 30, 2015 at 4:32 AM, Simon Riggs wrote: > Yes, I suggest just a single column on pg_stat_activity called pct_complete > > trace_completion_interval = 5s (default) > > Every interval, we report the current % complete for any operation that > supports it. We just show NULL if the current

[HACKERS] Eliminating CREATE INDEX comparator TID tie-breaker overhead

I have one more idea for accelerating sorting-related operations that is both fairly effective and relatively easy to implement. This just about clears my backlog of those, though. There is an open item on the TODO list entitled "Consider whether duplicate keys should be sorted by block/offset" [1

[HACKERS] brin index vacuum versus transaction snapshots

If you run `make installcheck` against a cluster with default_transaction_isolation = 'repeatable read' you get one failure: *** /home/kgrittn/pg/master/src/test/regress/expected/brin.out 2015-07-21 10:21:58.798619111 -0500 --- /home/kgrittn/pg/master/src/test/regress/results/brin.out 2015-07-21

Re: [HACKERS] WAL logging problem in 9.4.3?

On Tue, Jul 21, 2015 at 02:24:47PM -0400, Todd A. Cook wrote: > Hi, > > This thread seemed to trail off without a resolution. Was anything done? Not that I can tell. I was the original poster of this thread. We've worked around the issue by placing a CHECKPOINT command at the end of the migratio

Re: [HACKERS] pgbench stats per script & other stuff

[...] and that a subsequent -w modifies the meaning of the script-specifiying argument already read. That strikes me as a very unintuitive interface. Ok, I understand this "afterward modification" objection. What if the -w would be required *before*, and supply a weight for (the first/maybe

Re: [HACKERS] [PATCH] postgres_fdw extension support

On July 21, 2015 at 11:22:12 AM, Tom Lane (t...@sss.pgh.pa.us) wrote: > So: yes to a local cache of all forwardable functions/ops, populated in full > the first time through (does that speak maybe to using a binary search on a > sorted list instead of a hash, since I only pay the sort price once

Re: [HACKERS] [PATCH] postgres_fdw extension support

On 2015-07-21 14:07:24 -0400, Tom Lane wrote: > Paul Ramsey writes: > > Folks are going to be OK w/ me dropping in new syscache entries so support > > my niche little feature? > > No, mainly because it adds overhead without fixing your problem. Meh. pg_extension updates are exceedingly rare, an

Re: [HACKERS] WAL logging problem in 9.4.3?

Hi, This thread seemed to trail off without a resolution. Was anything done? (See more below.) On 07/09/15 19:06, Tom Lane wrote: Andres Freund writes: On 2015-07-06 11:49:54 -0400, Tom Lane wrote: Rather than reverting cab9a0656c36739f, which would re-introduce a different performance prob

Re: [HACKERS] [PATCH] postgres_fdw extension support

Paul Ramsey writes: > On July 21, 2015 at 11:07:36 AM, Tom Lane (t...@sss.pgh.pa.us) wrote: > I'm inclined to think that it's not really necessary to worry about  > invalidating a per-connection cache of "is this function safe to ship"  > determinations. > So: yes to a local cache of all forwar

Re: [HACKERS] [PATCH] postgres_fdw extension support

On July 21, 2015 at 11:07:36 AM, Tom Lane (t...@sss.pgh.pa.us) wrote: I'm inclined to think that it's not really necessary to worry about  invalidating a per-connection cache of "is this function safe to ship"  determinations. So: yes to a local cache of all forwardable functions/ops, populated in

Re: [HACKERS] First Aggregate Funtion?

On 7/20/15 11:07 AM, Marko Tiikkaja wrote: On 7/20/15 6:02 PM, Corey Huinker wrote: By using only(a.name_of_the_thing) we'd have a bit more clarity that the author expected all of those values to be the same across the aggregate window, and discovering otherwise was reason enough to fail the que

Re: [HACKERS] [PATCH] postgres_fdw extension support

Paul Ramsey writes: > Folks are going to be OK w/ me dropping in new syscache entries so support my > niche little feature? No, mainly because it adds overhead without fixing your problem. It's not correct to suppose that a syscache on pg_extension would reliably report anything; consider ALTER

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

On 7/20/15 4:32 AM, Thakur, Sameer wrote: Hello, Does this actually handle multiple indexes? It doesn't appear so, which I'd think is a significant problem... :/ Please find v2 attached which does this. I think it'd be better to combine both numbers into one report: elog(WARNING,"Current/Ov

Re: [HACKERS] Selectivity estimation for intarray with @@

On 07/21/2015 07:28 PM, Alexander Korotkov wrote: On Tue, Jul 21, 2015 at 6:49 PM, Heikki Linnakangas wrote: In this version of patch it's not checked if variable is actually and int[] not query_int. See following test case. # create table test2 as (select '1'::query_int val from generate_seri

Re: [HACKERS] [PATCH] postgres_fdw extension support

  On July 21, 2015 at 8:26:31 AM, Andres Freund (and...@anarazel.de(mailto:and...@anarazel.de)) wrote: > On 2015-07-21 17:00:51 +0200, Andres Freund wrote: > > On 2015-07-21 07:55:17 -0700, Paul Ramsey wrote: > > > On Tue, Jul 21, 2015 at 7:45 AM, Andres Freund wrote: > > > So, right after reading

Re: [HACKERS] What is HeapScanDescData.rs_initblock good for?

Alvaro Herrera writes: > Tom Lane wrote: >> The BRIN patch added a HeapScanDescData field rs_initblock, but so far as >> I can see it's utterly without use, and it's quite confusing (people might >> mistake it for rs_startblock, for example). Any objection to taking it >> out again? > Ouch, you'

Re: [HACKERS] What is HeapScanDescData.rs_initblock good for?

Tom Lane wrote: > The BRIN patch added a HeapScanDescData field rs_initblock, but so far as > I can see it's utterly without use, and it's quite confusing (people might > mistake it for rs_startblock, for example). Any objection to taking it > out again? Ouch, you're right, my mistake. Feel free

[HACKERS] What is HeapScanDescData.rs_initblock good for?

The BRIN patch added a HeapScanDescData field rs_initblock, but so far as I can see it's utterly without use, and it's quite confusing (people might mistake it for rs_startblock, for example). Any objection to taking it out again? regards, tom lane -- Sent via pgsql-hac

Re: [HACKERS] Fillfactor for GIN indexes

On Tue, Jul 21, 2015 at 7:20 PM, Heikki Linnakangas wrote: > On 07/21/2015 04:14 PM, Alexander Korotkov wrote: > >> On Tue, Jul 21, 2015 at 3:52 PM, Heikki Linnakangas >> wrote: >> >> On 07/21/2015 02:56 PM, Alexander Korotkov wrote: >>> >>> Probably, but currently we are in quite unlogical si

Re: [HACKERS] pgbench stats per script & other stuff

5~5~5~ That is a truly horrifying abuse of command-line arguments. -1 from me, or minus more than one if I've got that many chits to burn. Are you against the -w, or against saying that pgbench execute scripts, whether internal or from files? I'm against the idea that we accept multiple argu

Re: [HACKERS] Selectivity estimation for intarray with @@

On Tue, Jul 21, 2015 at 6:49 PM, Heikki Linnakangas wrote: > On 07/21/2015 03:44 PM, Alexander Korotkov wrote: > >> While Uriy is on vacation, I've revised this patch a bit. >> > > I whacked this around quite a bit, and I think it's in a committable state > now. But if you could run whatever test

[HACKERS] ALTER TABLE .. ADD PRIMARY KEY .. USING INDEX has dump-restore hazard

Consider: rhaas=# create table foo (a text); CREATE TABLE rhaas=# create unique index on foo (a collate "C"); CREATE INDEX rhaas=# alter table foo add primary key using index foo_a_idx; ALTER TABLE rhaas=# \d foo Table "public.foo" Column | Type | Modifiers +--+--- a

Re: [HACKERS] Fillfactor for GIN indexes

On 07/21/2015 04:14 PM, Alexander Korotkov wrote: On Tue, Jul 21, 2015 at 3:52 PM, Heikki Linnakangas wrote: On 07/21/2015 02:56 PM, Alexander Korotkov wrote: Probably, but currently we are in quite unlogical situation. We have default fillfactor = 90 for GiST where it has no use cases at al

Re: [HACKERS] pgbench stats per script & other stuff

On Tue, Jul 21, 2015 at 10:42 AM, Fabien COELHO wrote: >>> sh> ./pgbench -T 3 -B -N -w 2 -S -w 7 --per-script-stats >> >> That is a truly horrifying abuse of command-line arguments. -1 from >> me, or minus more than one if I've got that many chits to burn. > > Are you against the -w, or against

Re: [HACKERS] TABLESAMPLE patch is really in pretty sad shape

Petr Jelinek writes: > Another thing that's not clear to me after playing with this is how do > we want to detect if to do pagemode scan or not. I understand that it's > neat optimization to say pagemode = true in bernoulli when percentage is > high and false when it's low but then this would h

Re: [HACKERS] Selectivity estimation for intarray with @@

On 07/21/2015 03:44 PM, Alexander Korotkov wrote: While Uriy is on vacation, I've revised this patch a bit. I whacked this around quite a bit, and I think it's in a committable state now. But if you could run whatever tests you were using before on this, to make sure it still produces the sam

Re: [HACKERS] Selectivity estimation for intarray with @@

On Tue, Jul 21, 2015 at 5:14 PM, Teodor Sigaev wrote: > Some notices about code: > > 1 Near function transformOperator() there is wrong operator name "@<" > Fixed. > 2 int_query (and intquery) should be replaced to query_int to be > consistent with actual type name. At least where it's used as

Re: [HACKERS] [PATCH] postgres_fdw extension support

On 2015-07-21 17:00:51 +0200, Andres Freund wrote: > On 2015-07-21 07:55:17 -0700, Paul Ramsey wrote: > > On Tue, Jul 21, 2015 at 7:45 AM, Andres Freund wrote: > > So, right after reading the options in postgresGetForeignRelSize, > > expand the extension list into a list of all ops/functions, in a

Re: [HACKERS] TABLESAMPLE patch is really in pretty sad shape

On 2015-07-20 17:23, Tom Lane wrote: Doesn't look like it to me: heap_beginscan_sampling always passes allow_sync = false to heap_beginscan_internal. Oh, right. More to the point, the existing coding of all these methods is such that they would fail to be reproducible if syncscan were enabl

Re: [HACKERS] [PATCH] postgres_fdw extension support

On 2015-07-21 07:55:17 -0700, Paul Ramsey wrote: > On Tue, Jul 21, 2015 at 7:45 AM, Andres Freund wrote: > So, right after reading the options in postgresGetForeignRelSize, > expand the extension list into a list of all ops/functions, in a > sorted list, and let that carry through to the deparsing

Re: [HACKERS] PL/pgSQL, RAISE and error context

On Tue, Jul 21, 2015 at 2:53 AM, Heikki Linnakangas wrote: > On 07/21/2015 10:38 AM, Pavel Stehule wrote: >> >> where we are with this patch? Can I do some for it? > > > I still feel this approach is misguided, and we should be tweaking psql > and/or libpq instead. I don't feel strongly though, an

Re: [HACKERS] [PATCH] postgres_fdw extension support

On Tue, Jul 21, 2015 at 7:45 AM, Andres Freund wrote: >> + >> + /* We need this relation to scan */ >> + depRel = heap_open(DependRelationId, RowExclusiveLock); >> + >> + /* Scan the system dependency table for a all entries this operator */ >> + /* depends on, then iterate throug

Re: [HACKERS] Solaris testers wanted for strxfrm() behavior

On 27/06 12.51, Noah Misch wrote: > > PostgreSQL 9.5 adds a strxfrm() call in bttext_abbrev_convert(), which does > not account for the Solaris bug. I wish to determine whether that bug is > still relevant today. If you have access to Solaris with the is_IS.ISO8859-1 > locale installed (or root

Re: [HACKERS] [PATCH] postgres_fdw extension support

Hi, On 2015-07-21 07:28:22 -0700, Paul Ramsey wrote: > /* > @@ -229,6 +236,9 @@ foreign_expr_walker(Node *node, > Oid collation; > FDWCollateState state; > > + /* Access extension metadata from fpinfo on baserel */ > + PgFdwRelationInfo *fpinfo = (PgFdwRela

Re: [HACKERS] pgbench stats per script & other stuff

Hello Robert, On Fri, Jul 17, 2015 at 9:50 AM, Fabien wrote: sh> ./pgbench -T 3 -B -N -w 2 -S -w 7 --per-script-stats That is a truly horrifying abuse of command-line arguments. -1 from me, or minus more than one if I've got that many chits to burn. Are you against the -w, or against s

Re: [HACKERS] [PATCH] postgres_fdw extension support

Here's a third revision that allows the 'extensions' option on the wrapper as well, so that supported extensions can be declared once in one place. Since the "CREATE FOREIGN DATA WRAPPER" statement is actually called inside the "CREATE EXTENSION" script for postgres_fdw, the way to get this option

Re: [HACKERS] pgbench stats per script & other stuff

On Fri, Jul 17, 2015 at 9:50 AM, Fabien wrote: > sh> ./pgbench -T 3 -B -N -w 2 -S -w 7 --per-script-stats That is a truly horrifying abuse of command-line arguments. -1 from me, or minus more than one if I've got that many chits to burn. I have been thinking that the way to do this is to push

Re: [HACKERS] creating extension including dependencies

Petr Jelinek writes: > ... My main question is if we are > ok with SCHEMA having different behavior with CASCADE vs without > CASCADE. I went originally with "no" and added the DEFAULT flag to > SCHEMA. If the answer is "yes" then we don't need the flag (in that case > CASCADE acts as the flag

Re: [HACKERS] Selectivity estimation for intarray with @@

Some notices about code: 1 Near function transformOperator() there is wrong operator name "@<" 2 int_query (and intquery) should be replaced to query_int to be consistent with actual type name. At least where it's used as separate lexeme. 3 For historical reasons @@ doesn't commutate with itself

Re: [HACKERS] creating extension including dependencies

On 2015-07-21 15:48, Tom Lane wrote: Robert Haas writes: On Mon, Jul 20, 2015 at 10:29 PM, Michael Paquier wrote:> In short I would give up on the DEFAULT SCHEMA business, and add a new flag in the control file to decide if a given extension passes down the schema name of its child when creat

Re: [HACKERS] "make check" changes have caused buildfarm deterioration.

Andrew Dunstan writes: > On 07/21/2015 01:39 AM, Michael Paquier wrote: >> Regarding install.log, the use of stdout/stderr instead of a log file >> has been changed in dbf2ec1a after that: >> http://www.postgresql.org/message-id/553fe7fc.2040...@gmx.net >> Since 9.5 as the location of the temporar

Re: [HACKERS] creating extension including dependencies

Robert Haas writes: > On Mon, Jul 20, 2015 at 10:29 PM, Michael Paquier > wrote:> >> In short I would give up on the DEFAULT SCHEMA business, and >> add a new flag in the control file to decide if a given extension >> passes down the schema name of its child when created in cascade, >> default be

Re: [HACKERS] "make check" changes have caused buildfarm deterioration.

On 07/21/2015 01:39 AM, Michael Paquier wrote: On Tue, Jul 21, 2015 at 6:17 AM, Tom Lane wrote: Andrew Dunstan writes: Somewhere along the way some changes to the way we do "make check" have caused a significant deterioration in the buildfarm's logging. Compare these two from animal crake, wh

Re: [HACKERS] Fillfactor for GIN indexes

On Tue, Jul 21, 2015 at 3:52 PM, Heikki Linnakangas wrote: > On 07/21/2015 02:56 PM, Alexander Korotkov wrote: > >> Probably, but currently we are in quite unlogical situation. We have >> default fillfactor = 90 for GiST where it has no use cases at all and >> effectively is just a waste of space

Re: [HACKERS] creating extension including dependencies

On Mon, Jul 20, 2015 at 10:29 PM, Michael Paquier wrote:> In > short I would give up on the DEFAULT SCHEMA business, and > add a new flag in the control file to decide if a given extension > passes down the schema name of its child when created in cascade, > default being true for the potential is

Re: [HACKERS] Fillfactor for GIN indexes

On 07/21/2015 02:56 PM, Alexander Korotkov wrote: Probably, but currently we are in quite unlogical situation. We have default fillfactor = 90 for GiST where it has no use cases at all and effectively is just a waste of space. Why is it useless for GiST? - Heikki -- Sent via pgsql-hackers ma

Re: [HACKERS] Selectivity estimation for intarray with @@

Hi! While Uriy is on vacation, I've revised this patch a bit. On Tue, Jul 14, 2015 at 8:55 PM, Jeff Janes wrote: > Hi Uriy, > > This patch looks pretty good. > > The first line of intarray--1.1.sql mis-identifies itself as "/* > contrib/intarray/intarray--1.0.sql */" > Fixed. > The real file

Re: [HACKERS] "make check" changes have caused buildfarm deterioration.

On Tue, Jul 21, 2015 at 7:01 PM, Alvaro Herrera wrote: > Michael Paquier wrote: >> On Tue, Jul 21, 2015 at 2:39 PM, Michael Paquier >> wrote: > >> > Regarding initdb.log and postmaster.log, this is definitely a bug. >> > Those have been moved by dcae5fa from log/ to tmp_check/log/, >> > tmp_check

Re: [HACKERS] Fillfactor for GIN indexes

On Tue, Jul 21, 2015 at 2:49 PM, Heikki Linnakangas wrote: > Hmm. That's slightly different from the test case I used, in that the > update is changing the indexed value, which means that the new value goes > to different posting tree than the old one. I'm not sure if that makes any > difference.

Re: [HACKERS] Fillfactor for GIN indexes

On 07/21/2015 02:00 PM, Alexander Korotkov wrote: On Tue, Jul 21, 2015 at 12:40 PM, Heikki Linnakangas wrote: Has anyone done any performance testing of this? The purpose of a fillfactor is to avoid the storm of page splits right after building the index, when there are some random updates to

Re: [BUGS] [HACKERS] object_classes array is broken, again

Tom Lane wrote: > I wrote: > > +1 to this patch, in fact I think we could remove MAX_OCLASS altogether > > which would be very nice for switch purposes. > > Oh, wait, I forgot that the patch itself introduces another reference to > MAX_OCLASS. I wonder though if we should get rid of that as an en

Re: [HACKERS] RFC: replace pg_stat_activity.waiting with something more descriptive

On 07/21/2015 01:18 PM, Andres Freund wrote: On 2015-07-21 13:11:36 +0300, Ildus Kurbangaliev wrote: /* * Top-level transactions are identified by VirtualTransactionIDs comprising diff --git a/src/include/storage/lwlock.h b/src/include/storage/lwlock.h index cff3b99..55b0687 100644 --- a

Re: [HACKERS] Fillfactor for GIN indexes

On Tue, Jul 21, 2015 at 12:40 PM, Heikki Linnakangas wrote: > Has anyone done any performance testing of this? > > The purpose of a fillfactor is to avoid the storm of page splits right > after building the index, when there are some random updates to the table. > It causes the index to bloat, as

Re: [HACKERS] "make check" changes have caused buildfarm deterioration.

Andres Freund wrote: > On 2015-07-21 14:39:42 +0900, Michael Paquier wrote: > > Regarding initdb.log and postmaster.log, this is definitely a bug. > > Those have been moved by dcae5fa from log/ to tmp_check/log/, > > tmp_check/ getting removed at the end of pg_regress if there are no > > failures c

Re: [HACKERS] RFC: replace pg_stat_activity.waiting with something more descriptive

On 2015-07-21 13:11:36 +0300, Ildus Kurbangaliev wrote: > > /* > * Top-level transactions are identified by VirtualTransactionIDs comprising > diff --git a/src/include/storage/lwlock.h b/src/include/storage/lwlock.h > index cff3b99..55b0687 100644 > --- a/src/include/storage/lwlock.h > +++ b/s

Re: [HACKERS] RFC: replace pg_stat_activity.waiting with something more descriptive

Hello. I did some refactoring to previous patch. Improvements: 1) Wait is determined by class and event without affecting to atomic usage of it. They are still stored in one variable. This improvement gives an opportunity to make more detailed views later (waits can be grouped by class). 2) On

Re: [HACKERS] "make check" changes have caused buildfarm deterioration.

On 2015-07-21 14:39:42 +0900, Michael Paquier wrote: > Regarding initdb.log and postmaster.log, this is definitely a bug. > Those have been moved by dcae5fa from log/ to tmp_check/log/, > tmp_check/ getting removed at the end of pg_regress if there are no > failures counted. FWIW, I think that's b

Re: [HACKERS] "make check" changes have caused buildfarm deterioration.

Michael Paquier wrote: > On Tue, Jul 21, 2015 at 2:39 PM, Michael Paquier > wrote: > > Regarding initdb.log and postmaster.log, this is definitely a bug. > > Those have been moved by dcae5fa from log/ to tmp_check/log/, > > tmp_check/ getting removed at the end of pg_regress if there are no > > f

Re: [HACKERS] [COMMITTERS] pgsql: Improve BRIN documentation somewhat

> Emre Hasegeli told me on IM he's going to submit a patch to add > something similar for the inclusion opclass framework. It is attached. Thank you for pushing forward to improve the documentation. 0001-Improve-BRIN-documentation-for-Inclusion-opclass.patch Description: Binary data -- Sent v

Re: [HACKERS] Fillfactor for GIN indexes

Has anyone done any performance testing of this? The purpose of a fillfactor is to avoid the storm of page splits right after building the index, when there are some random updates to the table. It causes the index to bloat, as every full page is split to two half-full pages, and also adds lat

  1   2   >