On Thu, Aug 13, 2015 at 1:31 AM, Robert Haas robertmh...@gmail.com wrote:
On Wed, Aug 12, 2015 at 7:20 PM, Tom Lane t...@sss.pgh.pa.us wrote:
FWIW, I've objected in the past to tests that would significantly
increase the runtime of make check, unless I thought they were
especially valuable
2015-08-13 9:47 GMT+02:00 Shulgin, Oleksandr oleksandr.shul...@zalando.de:
On Thu, Aug 13, 2015 at 9:25 AM, Pavel Stehule pavel.steh...@gmail.com
wrote:
2015-08-13 9:21 GMT+02:00 Marko Tiikkaja ma...@joh.to:
On 8/13/15 9:18 AM, Shulgin, Oleksandr wrote:
nnulls()
I think I'd prefer
2015-08-13 9:21 GMT+02:00 Marko Tiikkaja ma...@joh.to:
On 8/13/15 9:18 AM, Shulgin, Oleksandr wrote:
nnulls()
I think I'd prefer num_nulls() over that.
can be
what about similar twin function num_nonulls()?
Pavel
.m
--
Sent via pgsql-hackers mailing list
On Thu, Aug 13, 2015 at 9:25 AM, Pavel Stehule pavel.steh...@gmail.com
wrote:
2015-08-13 9:21 GMT+02:00 Marko Tiikkaja ma...@joh.to:
On 8/13/15 9:18 AM, Shulgin, Oleksandr wrote:
nnulls()
I think I'd prefer num_nulls() over that.
can be
what about similar twin function
.
Regards
Pavel
.m
libpq-context-filter-20150813-01.patch.gz
Description: GNU Zip compressed data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
FWIW, I've objected in the past to tests that would significantly
increase the runtime of make check, unless I thought they were
especially valuable (which enumerating every minor behavior of a
feature patch generally isn't IMO). I still think that that's an
important consideration: every
On Wed, Aug 12, 2015 at 11:23 PM, Magnus Hagander mag...@hagander.net wrote:
The value of a core regression suite that takes less time to run has
to be weighed against the possibility that a better core regression
suite might cause us to find more bugs before committing. That could
easily be
On 8/13/15 9:18 AM, Shulgin, Oleksandr wrote:
nnulls()
I think I'd prefer num_nulls() over that.
.m
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Thu, Aug 13, 2015 at 12:55 PM, Pavel Stehule pavel.steh...@gmail.com
wrote:
2015-08-13 9:21 GMT+02:00 Marko Tiikkaja ma...@joh.to:
On 8/13/15 9:18 AM, Shulgin, Oleksandr wrote:
nnulls()
I think I'd prefer num_nulls() over that.
can be
what about similar twin function
Views created by UNION ALL could be updated with both UPDATE and
DELETE operations. They are just transformed to UPDATE/DELETE
operation on base tables (or views). I think INSERT cannot be accepted
however. For example, suppose we have v1:
CREATE VIEW v1 AS SELECT * FROM t1 UNION ALL SELECT *
On Thu, Aug 13, 2015 at 2:19 AM, David G. Johnston
david.g.johns...@gmail.com wrote:
On Wed, Aug 12, 2015 at 4:11 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Peter Geoghegan p...@heroku.com writes:
On Wed, Aug 12, 2015 at 10:30 AM, Alvaro Herrera
alvhe...@2ndquadrant.com wrote:
The name
Hi
2015-07-30 12:44 GMT+02:00 Heikki Linnakangas hlinn...@iki.fi:
On 07/25/2015 07:08 PM, Pavel Stehule wrote:
I am sending a new patch - without checking wildcard chars.
The documentation says the option is called --strict-names, while the code
has --strict-mode. I like --strict-names
Hi all,
I saw the email about the idea from KaiGai-san[1],
and I worked to implement this idea.
Now, I have implemented a part of this idea,
so I want to propose this feature.
Patch attached just shows my concept of this feature.
It works fine for EXPLAIN, but it returns wrong result for other
On 08/12/2015 03:46 PM, Stephen Frost wrote:
* Andres Freund (and...@anarazel.de) wrote:
On 2015-08-12 08:16:09 -0400, Stephen Frost wrote:
1) gin stores/queries some bools as GinTernaryValue.
Part of this is easy to fix, just adjust GinScanKeyData-entryRes to
be a GinTernaryValue
On 2015-08-13 13:27:33 +0200, Michael Meskes wrote:
Playing around a bit lead to to find that this is caused by a wrong type
declaration in two places. 'isarray' is declared as bool instead of enum
ARRAY_TYPE in two places. This appears to be an oversight, perhaps
caused by the boolean
Hello,
Autovacuum knows what % of a table needs to be cleaned - that is how it is
triggered.
When a vacuum runs we should calculate how many TIDs we will collect and
therefore how many trips to the indexes we need for given memory.
We can use the VM to find out how many blocks we'll need to
On Thu, Aug 13, 2015 at 2:49 AM, Kouhei Kaigai kai...@ak.jp.nec.com wrote:
In fact, cost of HashJoin underlying Sort node is:
- Hash Join (cost=621264.91..752685.48 rows=1 width=132)
On the other hands, NestedLoop on same place is:
- Nested Loop (cost=0.00..752732.26 rows=1
On Thu, Aug 13, 2015 at 2:49 AM, Kouhei Kaigai kai...@ak.jp.nec.com wrote:
In fact, cost of HashJoin underlying Sort node is:
- Hash Join (cost=621264.91..752685.48 rows=1 width=132)
On the other hands, NestedLoop on same place is:
- Nested Loop (cost=0.00..752732.26 rows=1
On 2015-08-13 00:24:29 -0300, Alvaro Herrera wrote:
Andres Freund wrote:
On 2015-08-12 16:08:08 -0300, Alvaro Herrera wrote:
Alvaro Herrera wrote:
Close some holes in BRIN page assignment
buildfarm evidently didn't like this one :-(
clang seems to see a (the?) problem:
Playing around a bit lead to to find that this is caused by a wrong type
declaration in two places. 'isarray' is declared as bool instead of enum
ARRAY_TYPE in two places. This appears to be an oversight, perhaps
caused by the boolean sounding name.
I vaguely remember that it used to be bool
On 2015-08-13 14:28:58 +0300, Heikki Linnakangas wrote:
On 08/12/2015 03:46 PM, Stephen Frost wrote:
* Andres Freund (and...@anarazel.de) wrote:
On 2015-08-12 08:16:09 -0400, Stephen Frost wrote:
1) gin stores/queries some bools as GinTernaryValue.
Part of this is easy to fix, just
On Fri, Aug 7, 2015 at 2:15 PM, Kouhei Kaigai kai...@ak.jp.nec.com wrote:
On Sat, Aug 1, 2015 at 6:39 PM, Kouhei Kaigai kai...@ak.jp.nec.com
wrote:
If we pull Funnel here, I think the plan shall be as follows:
Funnel
-- SeqScan on rel1
--
On 08/13/2015 02:41 PM, Andres Freund wrote:
On 2015-08-13 14:28:58 +0300, Heikki Linnakangas wrote:
On 08/12/2015 03:46 PM, Stephen Frost wrote:
* Andres Freund (and...@anarazel.de) wrote:
On 2015-08-12 08:16:09 -0400, Stephen Frost wrote:
1) gin stores/queries some bools as
* Robert Haas (robertmh...@gmail.com) wrote:
On Wed, Aug 12, 2015 at 9:36 PM, Stephen Frost sfr...@snowman.net wrote:
Yes, the SCRAM implementation could be buggy. But also, OpenSSL has
repeatedly had security bugs that were due to forcing servers to
downgrade to older protocols. I
On 8/12/15 9:24 PM, Stephen Frost wrote:
* Michael Paquier (michael.paqu...@gmail.com) wrote:
On Thu, Aug 13, 2015 at 5:54 AM, Stephen Frost wrote:
The regression tests included in pgBackRest (available here:
https://github.com/pgmasters/backrest) go through a number of different
recovery
On 2015-08-13 09:32:02 -0400, David Steele wrote:
On 8/12/15 9:32 PM, Robert Haas wrote:
On Wed, Aug 12, 2015 at 9:24 PM, Stephen Frost sfr...@snowman.net wrote:
Certainly don't mind at all, entirely open source under the MIT
license.
Why not the PG license? It would be nicer if we didn't
* Tom Lane (t...@sss.pgh.pa.us) wrote:
I'm not entirely sure what to do about this. We could back-patch that
patch into 9.0 and 9.1, but it's conceivable somebody would squawk about
planner behavioral changes. The only other idea that seems practical is
to remove regression test cases that
Stephen Frost sfr...@snowman.net writes:
* Tom Lane (t...@sss.pgh.pa.us) wrote:
I'm not entirely sure what to do about this. We could back-patch that
patch into 9.0 and 9.1, but it's conceivable somebody would squawk about
planner behavioral changes. The only other idea that seems practical
On 8/12/15 9:32 PM, Robert Haas wrote:
On Wed, Aug 12, 2015 at 9:24 PM, Stephen Frost sfr...@snowman.net wrote:
* Michael Paquier (michael.paqu...@gmail.com) wrote:
Interesting. Do you mind if I pick up from it some ideas for the
in-core replication test suite based on TAP stuff? That's still
David Fetter wrote:
That said, a thing in psql that could slice serialized output into
columns would be handy as a broad, general part of reporting in
psql
To avoid any confusion with server-side PIVOT, I suggest that the
currently proposed command in psql should have a different name
On 8/13/15 9:55 AM, Andres Freund wrote:
On 2015-08-13 09:32:02 -0400, David Steele wrote:
On 8/12/15 9:32 PM, Robert Haas wrote:
On Wed, Aug 12, 2015 at 9:24 PM, Stephen Frost sfr...@snowman.net wrote:
Certainly don't mind at all, entirely open source under the MIT
license.
Why not the PG
* Tom Lane (t...@sss.pgh.pa.us) wrote:
Stephen Frost sfr...@snowman.net writes:
* Tom Lane (t...@sss.pgh.pa.us) wrote:
I'm not entirely sure what to do about this. We could back-patch that
patch into 9.0 and 9.1, but it's conceivable somebody would squawk about
planner behavioral
Stephen Frost sfr...@snowman.net writes:
* Tom Lane (t...@sss.pgh.pa.us) wrote:
Stephen Frost sfr...@snowman.net writes:
Have an alternate file for those other cases, rather than remove the
test? The complaint was about one buildfarm member, so hopefully that's
practical and doesn't require
* Tom Lane (t...@sss.pgh.pa.us) wrote:
Stephen Frost sfr...@snowman.net writes:
I agree, that's a bit unfortunate, but it strikes me as pretty unlikely
that we're ever going to change those tests or that a code change would
end up causing yet another different plan before 9.1 is completely
On 08/01/2015 07:13 PM, Andrew Dunstan wrote:
On 08/01/2015 04:44 PM, Noah Misch wrote:
--enable-tap-tests is a reasonable configuration setting, because it's
about whether or not we have a TAP testing framework available, but I
think we should stop calling the bin tests TAP tests and we
Hi
I am sending updated version
news:
* strict-names everywhere
* checking table names in pg_dump simplified - not necessary to create
single query
* pg_restore support
Regards
Pavel
2015-08-13 9:17 GMT+02:00 Pavel Stehule pavel.steh...@gmail.com:
Hi
2015-07-30 12:44 GMT+02:00 Heikki
On 08/12/2015 06:36 PM, Stephen Frost wrote:
I attempted to address that also by stating that, should an attacker
compromise a system with the goal of gaining the cleartext password,
they would attempt the following, in order:
1) attempt to compromise a superuser account, if not already
On 08/13/2015 02:11 PM, Alvaro Herrera wrote:
So I added the brin isolation test back. Because it needs the
pageinspect module, it can only work under make check, not
installcheck. The problem is that this means buildfarm will not run it,
because it only runs installcheck :-(
I realized
So I added the brin isolation test back. Because it needs the
pageinspect module, it can only work under make check, not
installcheck. The problem is that this means buildfarm will not run it,
because it only runs installcheck :-(
I realized that the important modules that run under make check
Andrew Dunstan wrote:
On 08/13/2015 04:26 PM, Alvaro Herrera wrote:
Argh, and this now broke MSVC :-(
An immediate solution would probably be to add it to @contrib_excludes.
Ah, that seems simpler. Pushed that, let's see if it cures the problem.
--
Álvaro Herrera
On Fri, Aug 14, 2015 at 1:18 AM, Andrew Dunstan and...@dunslane.net wrote:
On 08/13/2015 12:03 PM, Michael Paquier wrote:
On Fri, Aug 14, 2015 at 12:17 AM, Andrew Dunstan wrote:
here's what I propose.
This patch does not take into account that there may be other code
paths than src/bin/
Andres Freund wrote:
This is implemented using a new infrastructure called speculative
insertion. It is an optimistic variant of regular insertion that first
does a pre-check for existing tuples and then attempts an insert. If a
violating tuple was inserted concurrently, the speculatively
On 08/13/2015 04:26 PM, Alvaro Herrera wrote:
Alvaro Herrera wrote:
Re-add BRIN isolation test
This time, instead of using a core isolation test, put it on its own
test module; this way it can require the pageinspect module to be
present before running.
The module's Makefile is loosely
On 08/13/2015 02:52 PM, Alvaro Herrera wrote:
You're also going to have to handle the msvc side of things. That won't be
trivial. See discussion elsewhere today about how we've got that wrong
recently.
Oh my. The pg_upgrade code in src/tools/msvc/vcregress.pl looks rather
unhealthy, and I
Kouhei Kaigai wrote:
Hello,
The attached patch fixes up my careless misses when custom_plans field was
added.
Please apply this fix.
This was applied by Noah as part of b8fe12a83622b.
--
Álvaro Herrerahttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support,
That did it! I certainly should have been able to figure that out on my
own. Thanks for the help!
Unfortunately, I'm still looking at rather slow queries across my entire
dataset. I might wind up having to find another solution.
Gideon.
On Wed, Aug 12, 2015 at 6:29 PM Tom Lane
Andrew Dunstan wrote:
The buildfarm server doesn't control anything the clients do except it
provides them with a list of branches we are interested in. Even that is
invisible to the main program, and only used by the wrapper run_branches.pl.
The main program can run entirely offline and I'm
Alvaro Herrera wrote:
Re-add BRIN isolation test
This time, instead of using a core isolation test, put it on its own
test module; this way it can require the pageinspect module to be
present before running.
The module's Makefile is loosely modeled after test_decoding's, so that
it's
This is regarding supporting of multi-tenancy in a single PostgreSQL instance
using the row level security feature. The main idea is to have the
row level security
enabled on system catalog tables, thus the user can get only the rows that are
either system objects or the user objects, where the
On Fri, Aug 14, 2015 at 12:54 AM, Michael Paquier
michael.paqu...@gmail.com wrote:
On Mon, Jun 29, 2015 at 10:11 PM, Michael Paquier
michael.paqu...@gmail.com wrote:
On Wed, Mar 18, 2015 at 1:59 PM, Michael Paquier
michael.paqu...@gmail.com wrote:
Feedback is of course welcome, but note that
On 8/13/15 1:31 AM, Peter Geoghegan wrote:
On Wed, Aug 12, 2015 at 11:23 PM, Magnus Hagander mag...@hagander.net wrote:
The value of a core regression suite that takes less time to run has
to be weighed against the possibility that a better core regression
suite might cause us to find more bugs
Alvaro Herrera wrote:
Tom Lane wrote:
(If I were tasked with fixing it, I'd be tempted to rewrite it to do
all the work in one call and return a tuplestore; the alternative
seems to be to try to keep the index open across multiple calls,
which would be a mess.)
Here's a patch doing
On Fri, Aug 14, 2015 at 12:17 AM, Andrew Dunstan wrote:
here's what I propose.
This patch does not take into account that there may be other code
paths than src/bin/ that may have TAP tests (see my pending patch to
test pg_dump with extensions including dumpable relations for
example). I guess
On 08/13/2015 12:03 PM, Michael Paquier wrote:
On Fri, Aug 14, 2015 at 12:17 AM, Andrew Dunstan wrote:
here's what I propose.
This patch does not take into account that there may be other code
paths than src/bin/ that may have TAP tests (see my pending patch to
test pg_dump with extensions
On Mon, Jun 29, 2015 at 10:11 PM, Michael Paquier
michael.paqu...@gmail.com wrote:
On Wed, Mar 18, 2015 at 1:59 PM, Michael Paquier
michael.paqu...@gmail.com wrote:
Feedback is of course welcome, but note that I am not seriously
expecting any until we get into 9.6 development cycle and I am
55 matches
Mail list logo
