On Thu, Jul 21, 2016 at 03:53:45PM -0400, Andrew Dunstan wrote:
>
>
> On 07/21/2016 02:26 PM, Greg Stark wrote:
> >On Thu, Jul 21, 2016 at 5:44 PM, Tom Lane wrote:
> >>Confirmed here. Will deal with it, but I wonder why we have no buildfarm
> >>members covering this ...
> >We're not going to ha
On 07/22/2016 03:59 AM, Jeff Janes wrote:
On Thu, Jul 21, 2016 at 2:11 PM, Tom Lane wrote:
I see that the core tests fall over in Turkish still :-(
Turkish has never passed (at least back to 9.0). It looks like it is
in the stemming functions. I don't understand why, I would think
everythin
> "Andrew" == Andrew Gierth writes:
>>> Whole-row vars when constructed never contain the null value.
David> ...but what does this mean in end-user terms?
Andrew> It means for example that this query:
Andrew> select y from x left join y on (x.id=y.id) where y is null;
Andrew> woul
On 7/22/16 8:05 PM, David G. Johnston wrote:
I would expect that >95% of cases where someone has written (x IS NOT
NULL) for x being a composite type, it's actually a bug and that NOT (x
IS NULL) was intended.
Yeah, it would need to be targeted there. I agree with the numbers and
On 7/20/16 8:35 PM, Craig Ringer wrote:
I'm not sure how Petr's current design for in-core replication addresses
this, if it does, or whether it's presently focused only on
point-to-point replication like pglogical. As far as I'm concerned so
long as it does direct point-to-point replication with
ISTM pg_dump should alter publication/subscription when doing partial
dumps, similar to how it handles foreign keys.
Subscribed tables should be read-only by default. If you need something
more advanced than that adding an extra option to the subscription (or
wherever else) is going to be the
On Fri, Jul 22, 2016 at 4:06 PM, Guangzhou Zhang <35514...@qq.com> wrote:
> Thank you. Yes when I correctly created the table (so avoiding insertion
> statement error), the memory usage went no higher than ~ 60MB.
>
> Is this a bug from your point of view?
>
On other thread there are discussion g
On Friday, July 22, 2016, Andrew Gierth wrote:
> > "David" == David G Johnston > writes:
>
> >> Prohibiting IS NOT NULL is not on the cards; it's very widely used.
>
> David> Yet changing how it behaves, invisibly, is?
>
> Did you mean prohibiting it only for composite-type args? It's obv
> "David" == David G Johnston writes:
>> Prohibiting IS NOT NULL is not on the cards; it's very widely used.
David> Yet changing how it behaves, invisibly, is?
Did you mean prohibiting it only for composite-type args? It's obviously
widely used for non-composite args.
I would expect tha
On Fri, Jul 22, 2016 at 8:04 PM, Andrew Gierth
wrote:
> > "David" == David G Johnston writes:
>
> >> 2. x IS NOT NULL if and only if NOT (x IS NULL)
>
> David> I would rather prohibit "IS NOT NULL" altogether. If one needs
> David> to test "NOT (x IS NULL)" they can write it that way.
> "David" == David G Johnston writes:
>> 1. x IS NULL is true if and only if x has the null value (isnull set).
David> I don't have a problem conforming to "ROW(NULL, NULL) IS NULL"
David> being true...if you somehow get a hold of something in that
David> form, which your others point
> "David" == David G Johnston writes:
>> 2. x IS NOT NULL if and only if NOT (x IS NULL)
David> I would rather prohibit "IS NOT NULL" altogether. If one needs
David> to test "NOT (x IS NULL)" they can write it that way.
Prohibiting IS NOT NULL is not on the cards; it's very widely us
On Fri, Jul 22, 2016 at 7:01 PM, Andrew Gierth
wrote:
> In light of the fact that it is an endless cause of bugs both in pg and
> potentially to applications, I propose that we cease attempting to
> conform to the spec's definition of IS NULL in favour of the following
> rules:
>
> 1. x IS NULL
In light of the fact that it is an endless cause of bugs both in pg and
potentially to applications, I propose that we cease attempting to
conform to the spec's definition of IS NULL in favour of the following
rules:
1. x IS NULL is true if and only if x has the null value (isnull set).
2. x IS
Teaser: change made in 9.4 to simplify WAL segment compression
made it easier to compress a low-activity-period WAL segment
from 16 MB to about 27 kB ... but much harder to do better than
that, as I was previously doing (about two orders of magnitude
better).
At $work, we have a usually-low-activi
On Fri, Jul 22, 2016 at 01:15:17PM +0200, Anton Dignös wrote:
> Hi hackers,
>
> we are a group of researches that work on temporal databases. Our
> main focus is the processing of data with time intervals, such as
> the range types in PostgreSQL.
Thanks for your hard work so far!
[Explanation a
Andres Freund writes:
> On 2016-07-22 15:00:32 -0400, Tom Lane wrote:
>> Well, it's a question of whether an extra projection at the scan level is
>> worth the savings in column access during the sort or group stage.
> Well, the projection is what I was thinking of.
One point here is that unless
Alvaro Herrera writes:
> On this topic, see also
> https://www.postgresql.org/message-id/20160708024746.1410.57...@wrigleys.postgresql.org
I'd forgotten about that thread :-( ... but on looking at it, it's very
relevant indeed. See my followup there.
regards, tom lane
Tom Lane wrote:
> Merlin Moncure writes:
> > Not sure we are guided there. Currently we follow the spec
> > specifically with the IS NULL operator but not in other cases.
>
> Yeah. ExecEvalNullTest() has been taught about this, but most other
> places that check null-ness just check overall dat
Jeff Janes writes:
> The attached patch fixes regression tests for Welsh (cy_GB), needed in
> 9.5 and 9.6.
Pushed, thanks.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresq
On Fri, Jul 22, 2016 at 3:04 PM, Merlin Moncure wrote:
> On Fri, Jul 22, 2016 at 1:39 PM, David G. Johnston
> wrote:
> > On Fri, Jul 22, 2016 at 2:13 PM, Tom Lane wrote:
> >>
> >> There is a rather squishy question as to whether NULL::composite_type
> >> should be semantically equivalent to ROW
Merlin Moncure writes:
> Not sure we are guided there. Currently we follow the spec
> specifically with the IS NULL operator but not in other cases.
Yeah. ExecEvalNullTest() has been taught about this, but most other
places that check null-ness just check overall datum null-ness without
any con
On 2016-07-22 15:00:32 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2016-07-22 10:09:18 -0400, Tom Lane wrote:
> >> I'm really suspicious of this line of argument as well. It's possible
> >> that if you only consider all-fixed-width, never-null columns, it might
> >> look like deforming
On 7/22/16 1:58 PM, Andres Freund wrote:
On 2016-07-22 13:51:31 -0500, Jim Nasby wrote:
Another option would be to remember the
tuple offsets (NOT attcacheoff) that have
been computed as well as whether a
varlena attribute has actually been
deformed. That eliminates the need to
pre-declare what
On Fri, Jul 22, 2016 at 1:39 PM, David G. Johnston
wrote:
> On Fri, Jul 22, 2016 at 2:13 PM, Tom Lane wrote:
>>
>> There is a rather squishy question as to whether NULL::composite_type
>> should be semantically equivalent to ROW(NULL,NULL,...)::composite_type.
>> If it is, then the SELECT should
Andres Freund writes:
> On 2016-07-22 10:09:18 -0400, Tom Lane wrote:
>> I'm really suspicious of this line of argument as well. It's possible
>> that if you only consider all-fixed-width, never-null columns, it might
>> look like deforming the columns before the one you need is a waste of
>> eff
On 2016-07-22 13:51:31 -0500, Jim Nasby wrote:
> Another option would be to remember the
> tuple offsets (NOT attcacheoff) that have
> been computed as well as whether a
> varlena attribute has actually been
> deformed. That eliminates the need to
> pre-declare what attributes you're
> allowed to r
On 7/22/16 1:35 PM, Andres Freund wrote:
Sure, it's intentional. But not working that well. The problem is that
very often we actually don't ever access the preceding
columns. Sometimes that knowledge would let us skip directly to the
interesting column(s) (fixed width, no nulls columns precedin
On 2016-07-22 10:09:18 -0400, Tom Lane wrote:
> Greg Stark writes:
> > On Fri, Jul 22, 2016 at 2:56 AM, Andres Freund wrote:
> >> But I think the bigger issue than the above is actually that we're just
> >> performing a lot of useless work in a number of common scenarios. We're
> >> always deform
On Fri, Jul 22, 2016 at 2:13 PM, Tom Lane wrote:
> There is a rather squishy question as to whether NULL::composite_type
> should be semantically equivalent to ROW(NULL,NULL,...)::composite_type.
> If it is, then the SELECT should have failed before even getting into the
> plpgsql function, becau
On 7/22/16 1:13 PM, Tom Lane wrote:
There is a rather squishy question as to whether NULL::composite_type
should be semantically equivalent to ROW(NULL,NULL,...)::composite_type.
If it is, then the SELECT should have failed before even getting into the
plpgsql function, because ROW(NULL,NULL) is
On 2016-07-22 14:33:32 +0100, Greg Stark wrote:
> On Fri, Jul 22, 2016 at 2:56 AM, Andres Freund wrote:
> >
> > But I think the bigger issue than the above is actually that we're just
> > performing a lot of useless work in a number of common scenarios. We're
> > always deforming all columns up to
Jim Nasby writes:
> CREATE DOMAIN text_not_null AS text NOT NULL;
> CREATE TYPE c AS( t text_not_null, i int );
> CREATE TABLE test_table( id serial, c c );
> CREATE OR REPLACE FUNCTION test_func(i test_table) RETURNS oid LANGUAGE
> plpgsql AS $$
> BEGIN
> RETURN pg_typeof(i);
> END$$;
> SELECT t
On Thu, Jul 21, 2016 at 11:49 AM, Jeff Janes wrote:
> On Thu, Jul 21, 2016 at 9:44 AM, Tom Lane wrote:
>> Jeff Janes writes:
>>> In Danish, the sequence 'aa' is sometimes treated as a single letter
>>> which collates after 'z'.
>>> Some regression tests got into 9.5, and are still in 9.6beta3, w
CREATE DOMAIN text_not_null AS text NOT NULL;
CREATE TYPE c AS( t text_not_null, i int );
CREATE TABLE test_table( id serial, c c );
CREATE OR REPLACE FUNCTION test_func(i test_table) RETURNS oid LANGUAGE
plpgsql AS $$
BEGIN
RETURN pg_typeof(i);
END$$;
SELECT test_func(NULL);
ERROR: domain text
Thank you. Yes when I correctly created the table (so avoiding insertion
statement error), the memory usage went no higher than ~ 60MB.
Is this a bug from your point of view?
--
View this message in context:
http://postgresql.nabble.com/Unexpected-memory-usage-for-repeated-inserts-within-plpgs
Etsuro Fujita writes:
> On 2016/07/21 16:30, Etsuro Fujita wrote:
>> One thing I'd like to discuss is GetUserMappingById/GetUserMappingId.
>> Though those functions aren't used in any places, I didn't take them
>> out, because I thought somebody else would need them someday. But
>> considering th
On 22 July 2016 at 22:55, Simon Riggs wrote:
>
> Filtering data at both the sender and receiver has been requested, so
> I guess it makes sense to have a WHERE clause on both the Publication
> and the Subscription, but I will think more on that.
>
Yeah, output plugin level filtering predicates
On 22 July 2016 at 09:54, Dmitriy Sarafannikov wrote:
>
>>
>>CREATE PUBLICATION mypub;
>>ALTER PUBLICATION mypub ADD TABLE users, departments;
>
>>CREATE SUBSCRIPTION mysub WITH CONNECTION dbname=foo host=bar
>>user=repuser PUBLICATION mypub;
>
>>The above will start the replication process w
Craig Ringer writes:
> On 22 July 2016 at 13:24, Craig Ringer wrote:
>> I suggest that in cassert builds, or maybe just CACHE_CLOBBER_ALWAYS, the
>> context is reset after each call even when not cleaning up after an error.
>> That'll help catch mistakes and leaks.
> That is, after each statemen
Greg Stark writes:
> On Fri, Jul 22, 2016 at 2:56 AM, Andres Freund wrote:
>> But I think the bigger issue than the above is actually that we're just
>> performing a lot of useless work in a number of common scenarios. We're
>> always deforming all columns up to the one needed. Very often that's
On Fri, Jul 22, 2016 at 2:56 AM, Andres Freund wrote:
>
> But I think the bigger issue than the above is actually that we're just
> performing a lot of useless work in a number of common scenarios. We're
> always deforming all columns up to the one needed. Very often that's a
> lot of useless work
I have created a patch to cache the meta page of Hash index in
backend-private memory. This is to save reading the meta page buffer every
time when we want to find the bucket page. In “_hash_first” call, we try to
read meta page buffer twice just to make sure bucket is not split after we
found buck
On 2016-07-22 13:57:15 +0530, Amit Kapila wrote:
> On Thu, Jul 21, 2016 at 9:46 PM, Robert Haas wrote:
> > The open items list says this:
> >
> > heap_update sets xmax and infomask without logging the changes or
> > clearing PD_ALL_VISIBLE or visibility map bits
> > * volunteer owner wanted
> > *
>
>CREATE PUBLICATION mypub;
>ALTER PUBLICATION mypub ADD TABLE users, departments;
>CREATE SUBSCRIPTION mysub WITH CONNECTION dbname=foo host=bar
>user=repuser PUBLICATION mypub;
> The above will start the replication process which synchronizes the
> initial table contents of users and
>
Hello,
On 2016/07/22 17:06, Kyotaro HORIGUCHI wrote:
> At Fri, 22 Jul 2016 14:10:48 +0900, Amit Langote wrote:
>> On 2016/07/22 0:38, Robert Haas wrote:
>>> On Wed, Jul 13, 2016 at 5:22 AM, Amit Langote wrote:
Consider a scenario where one adds a *valid* constraint on a inheritance
pare
On Thu, Jul 21, 2016 at 9:46 PM, Robert Haas wrote:
> The open items list says this:
>
> heap_update sets xmax and infomask without logging the changes or
> clearing PD_ALL_VISIBLE or visibility map bits
> * volunteer owner wanted
> * This has been buggy essentially forever but the freeze map chan
The previous patch set doesn't accept --enable-cassert. The
attached additional one fixes it. It theoretically won't give
degradation but I'll measure the performance change.
At Thu, 21 Jul 2016 18:50:07 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI
wrote in
<20160721.185007.268388411.horiguch
Hello,
At Fri, 22 Jul 2016 14:10:48 +0900, Amit Langote
wrote in
> On 2016/07/22 0:38, Robert Haas wrote:
> > On Wed, Jul 13, 2016 at 5:22 AM, Amit Langote
> > wrote:
> >> Consider a scenario where one adds a *valid* constraint on a inheritance
> >> parent which is then merged with a child ta
49 matches
Mail list logo
