Hi
2015-07-30 12:44 GMT+02:00 Heikki Linnakangas :
> 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 more, "mo
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 wrote:
>
>> Peter Geoghegan writes:
>> > On Wed, Aug 12, 2015 at 10:30 AM, Alvaro Herrera
>> > wrote:
>> >> The name count_nulls() suggest an aggregate function to
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
2015-08-13 9:21 GMT+02:00 Marko Tiikkaja :
> 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 (pgsql-hackers@post
On Thu, Aug 13, 2015 at 12:55 PM, Pavel Stehule
wrote:
>
>
> 2015-08-13 9:21 GMT+02:00 Marko Tiikkaja :
>
>> 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()?
>
>
+1
On Thu, Aug 13, 2015 at 9:25 AM, Pavel Stehule
wrote:
>
>
> 2015-08-13 9:21 GMT+02:00 Marko Tiikkaja :
>
>> 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()?
>
Yes.
2015-08-13 9:47 GMT+02:00 Shulgin, Oleksandr :
> On Thu, Aug 13, 2015 at 9:25 AM, Pavel Stehule
> wrote:
>
>>
>>
>> 2015-08-13 9:21 GMT+02:00 Marko Tiikkaja :
>>
>>> On 8/13/15 9:18 AM, Shulgin, Oleksandr wrote:
>>>
nnulls()
>>>
>>> I think I'd prefer num_nulls() over that.
>>>
>>
>> ca
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 * FRO
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 o
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 (th
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 t
On Thu, Aug 13, 2015 at 2:49 AM, Kouhei Kaigai 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 width=132)
>
> Proba
> On Thu, Aug 13, 2015 at 2:49 AM, Kouhei Kaigai 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 width=13
> 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 bo
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 (it
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 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 ea
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 GinTernaryValue.
> On Fri, Aug 7, 2015 at 2:15 PM, Kouhei Kaigai wrote:
> >
> > > On Sat, Aug 1, 2015 at 6:39 PM, Kouhei Kaigai
> > > wrote:
> > > >
> >
> > > > > > If we pull Funnel here, I think the plan shall be as follows:
> > > > > > Funnel
> > > > > >--> SeqScan on rel1
> > > > > >--> PartialSeqS
* Robert Haas (robertmh...@gmail.com) wrote:
> On Wed, Aug 12, 2015 at 9:36 PM, Stephen Frost 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 wouldn't like u
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 tests
On 8/12/15 9:32 PM, Robert Haas wrote:
On Wed, Aug 12, 2015 at 9:24 PM, Stephen Frost 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 in the
works for th
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 na
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 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 have t
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 wrote:
Certainly don't mind at all, entirely open source under the MIT
license.
Why not the PG license? It would
* 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 tha
Stephen Frost 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 is
>> to rem
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost 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
Stephen Frost writes:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>> Stephen Frost 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 a lot of different permut
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost 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 out
> > of s
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
On Mon, Jun 29, 2015 at 10:11 PM, Michael Paquier
wrote:
> On Wed, Mar 18, 2015 at 1:59 PM, Michael Paquier
> 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 adding
>> this patch to the next CF.
>
> I have
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 patc
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 t
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 in
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 :
> Hi
>
> 2015-07-30 12:44 GMT+02:00 Heikki Linnakangas :
>
>> On 0
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 chec
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 th
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
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 don
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, R
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
> i
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 wrote:
> Gideon
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 model
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 speculativel
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 Herrerahttp:/
On Fri, Aug 14, 2015 at 1:18 AM, Andrew Dunstan 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/ t
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 u
On Fri, Aug 14, 2015 at 12:54 AM, Michael Paquier
wrote:
> On Mon, Jun 29, 2015 at 10:11 PM, Michael Paquier
> wrote:
>> On Wed, Mar 18, 2015 at 1:59 PM, Michael Paquier
>> wrote:
>>> Feedback is of course welcome, but note that I am not seriously
>>> expecting any until we get into 9.6 developm
On 8/13/15 1:31 AM, Peter Geoghegan wrote:
On Wed, Aug 12, 2015 at 11:23 PM, Magnus Hagander 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.
51 matches
Mail list logo
