On Tue, Jul 21, 2015 at 7:45 AM, Andres Freund and...@anarazel.de 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
On 2015-07-21 07:55:17 -0700, Paul Ramsey wrote:
On Tue, Jul 21, 2015 at 7:45 AM, Andres Freund and...@anarazel.de 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
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 and...@anarazel.de wrote:
So, right after reading the options in postgresGetForeignRelSize,
expand the extension list into a list of all
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
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 |
On Tue, Jul 21, 2015 at 6:49 PM, Heikki Linnakangas hlinn...@iki.fi 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
On 07/21/2015 04:14 PM, Alexander Korotkov wrote:
On Tue, Jul 21, 2015 at 3:52 PM, Heikki Linnakangas hlinn...@iki.fi 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
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
On Tue, Jul 21, 2015 at 2:53 AM, Heikki Linnakangas hlinn...@iki.fi 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
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
Petr Jelinek p...@2ndquadrant.com 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
On Tue, Jul 21, 2015 at 10:42 AM, Fabien COELHO coe...@cri.ensmp.fr 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
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
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 =
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
On Wed, Jul 22, 2015 at 1:23 AM, Robert Haas robertmh...@gmail.com 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
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
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 be
On Wed, Jul 22, 2015 at 1:27 PM, Peter Geoghegan p...@heroku.com 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:
On Tue, Jul 21, 2015 at 5:14 PM, Teodor Sigaev teo...@sigaev.ru 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
On Tue, Jul 21, 2015 at 7:20 PM, Heikki Linnakangas hlinn...@iki.fi wrote:
On 07/21/2015 04:14 PM, Alexander Korotkov wrote:
On Tue, Jul 21, 2015 at 3:52 PM, Heikki Linnakangas hlinn...@iki.fi
wrote:
On 07/21/2015 02:56 PM, Alexander Korotkov wrote:
Probably, but currently we are in
Alvaro Herrera alvhe...@2ndquadrant.com 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
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
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 to
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:
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 the
Paul Ramsey pram...@cleverelephant.ca 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
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
On 07/21/2015 07:28 PM, Alexander Korotkov wrote:
On Tue, Jul 21, 2015 at 6:49 PM, Heikki Linnakangas hlinn...@iki.fi 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
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 for
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 attached.
On Tue, Jul 21, 2015 at 11:20 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Petr Jelinek p...@2ndquadrant.com 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
On Mon, Jul 20, 2015 at 9:18 PM, Alexander Korotkov
a.korot...@postgrespro.ru 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.
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:
On Wed, Jul 22, 2015 at 9:34 AM, Michael Paquier
michael.paqu...@gmail.com wrote:
On Wed, Jul 22, 2015 at 1:23 AM, Robert Haas robertmh...@gmail.com wrote:
Notice that the collation specifier is gone. Oops.
As it is not possible to specify directly a constraint for a PRIMARY
KEY expression,
On Wed, Jul 22, 2015 at 12:40 PM, Noah Misch n...@leadboat.com 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
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
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,
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 and...@anarazel.de writes:
On 2015-07-06 11:49:54 -0400, Tom Lane wrote:
Rather than reverting cab9a0656c36739f, which would re-introduce a
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
[...] 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
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 migration
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
Paul Ramsey pram...@cleverelephant.ca 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
On 2015-07-21 14:07:24 -0400, Tom Lane wrote:
Paul Ramsey pram...@cleverelephant.ca 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
On Tue, Jul 21, 2015 at 12:29 PM, Fabien COELHO coe...@cri.ensmp.fr 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
-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
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 of
Kevin Grittner kgri...@ymail.com 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
On Tue, Jun 30, 2015 at 4:32 AM, Simon Riggs si...@2ndquadrant.com 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
On Sat, Jul 18, 2015 at 5:11 AM, Alvaro Herrera
alvhe...@2ndquadrant.com 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
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.
On Tue, Jul 21, 2015 at 11:29 AM, Paul Ramsey pram...@cleverelephant.ca 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
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
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
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
On Sun, Jul 19, 2015 at 8:56 PM, Peter Geoghegan p...@heroku.com wrote:
On Mon, Jun 1, 2015 at 12:29 AM, Peter Geoghegan p...@heroku.com 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
On Wed, Jul 22, 2015 at 10:04 AM, Peter Eisentraut pete...@gmx.net 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
On Tue, Jul 21, 2015 at 8:40 PM, Noah Misch n...@leadboat.com 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
On Tue, Jul 21, 2015 at 3:10 PM, Kevin Grittner kgri...@ymail.com wrote:
Kevin Grittner kgri...@ymail.com 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
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,
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
Noah Misch wrote:
On Mon, Jul 20, 2015 at 07:01:14PM -0400, Adam Brightwell wrote:
I think that makes sense, but what about other DATABASE level info
such as COMMENT? Should that also be ignored by pg_dump as well? I'm
specifically thinking of the discussion from the following thread:
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, and if some other
committer wants to pick this up in its current form,
2015-07-21 9:53 GMT+02:00 Heikki Linnakangas hlinn...@iki.fi:
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, and if
On Mon, Jul 20, 2015 at 9:59 PM, Beena Emerson memissemer...@gmail.com wrote:
Simon Riggs wrote:
The choice between formats is not
solely predicated on whether we have multi-line support.
I still think writing down some actual use cases would help bring the
discussion to a conclusion.
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 bad
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
Michael Paquier wrote:
On Tue, Jul 21, 2015 at 2:39 PM, Michael Paquier
michael.paqu...@gmail.com 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
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 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
+++
2015-07-09 23:16 GMT+02:00 Pavel Stehule pavel.steh...@gmail.com:
2015-07-09 22:57 GMT+02:00 Merlin Moncure mmonc...@gmail.com:
On Thu, Jul 9, 2015 at 3:31 PM, Pavel Stehule pavel.steh...@gmail.com
wrote:
2015-07-09 20:08 GMT+02:00 Merlin Moncure mmonc...@gmail.com:
On Thu, Jul 9,
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 counted.
On Tue, Jul 21, 2015 at 12:40 PM, Heikki Linnakangas hlinn...@iki.fi
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
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 enum
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
---
On Tue, Jul 21, 2015 at 2:49 PM, Heikki Linnakangas hlinn...@iki.fi 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
On 07/21/2015 02:00 PM, Alexander Korotkov wrote:
On Tue, Jul 21, 2015 at 12:40 PM, Heikki Linnakangas hlinn...@iki.fi
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
On Tue, Jul 21, 2015 at 7:01 PM, Alvaro Herrera
alvhe...@2ndquadrant.com wrote:
Michael Paquier wrote:
On Tue, Jul 21, 2015 at 2:39 PM, Michael Paquier
michael.paqu...@gmail.com wrote:
Regarding initdb.log and postmaster.log, this is definitely a bug.
Those have been moved by dcae5fa from
Hi Hackers,
This is the patch adds a new function called pg_hba_lookup to get all
matching entries
from the pg_hba.conf for the providing input data.The rows are
displayed from the other
the hba conf entries are matched.
This is an updated version of previous failure attempt to create a
catalog
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
Hello,
At Mon, 20 Jul 2015 15:45:21 +0530, Jeevan Chalke
jeevan.cha...@enterprisedb.com wrote in
CAM2+6=X9QWgbjJrR-dcLXh-RvvpGy=9enhuoghzrxhcj2kv...@mail.gmail.com
On Sat, Jul 18, 2015 at 12:27 AM, Andrew Gierth and...@tao11.riddles.org.uk
wrote:
Kyotaro == Kyotaro HORIGUCHI
Robert Haas robertmh...@gmail.com writes:
On Mon, Jul 20, 2015 at 10:29 PM, Michael Paquier
michael.paqu...@gmail.com 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
Andrew Dunstan andrew.duns...@pgexperts.com 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
On Mon, Jul 20, 2015 at 07:01:14PM -0400, Adam Brightwell wrote:
Consistency with existing practice would indeed have pg_dump ignore
pg_shseclabel and have pg_dumpall reproduce its entries.
I think that makes sense, but what about other DATABASE level info
such as COMMENT? Should that
On 07/21/2015 01:39 AM, Michael Paquier wrote:
On Tue, Jul 21, 2015 at 6:17 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Andrew Dunstan andrew.duns...@pgexperts.com writes:
Somewhere along the way some changes to the way we do make check have
caused a significant deterioration in the buildfarm's
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
On Mon, Jul 20, 2015 at 10:29 PM, Michael Paquier
michael.paqu...@gmail.com 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
On Tue, Jul 21, 2015 at 3:52 PM, Heikki Linnakangas hlinn...@iki.fi 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
Hi!
While Uriy is on vacation, I've revised this patch a bit.
On Tue, Jul 14, 2015 at 8:55 PM, Jeff Janes jeff.ja...@gmail.com 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.
On 2015-07-21 15:48, Tom Lane wrote:
Robert Haas robertmh...@gmail.com writes:
On Mon, Jul 20, 2015 at 10:29 PM, Michael Paquier
michael.paqu...@gmail.com 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
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,
Petr Jelinek p...@2ndquadrant.com 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
On Fri, Jul 17, 2015 at 9:50 AM, Fabien coe...@cri.ensmp.fr 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
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 is
Hello Robert,
On Fri, Jul 17, 2015 at 9:50 AM, Fabien coe...@cri.ensmp.fr 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
96 matches
Mail list logo
