Re: [HACKERS] fixes for the Danish locale

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 ... >

Re: [HACKERS] fixes for the Danish locale

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

Re: [HACKERS] Proposal: revert behavior of IS NULL on row types

> "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)

Re: [HACKERS] Proposal: revert behavior of IS NULL on row types

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

Re: [HACKERS] Design for In-Core Logical Replication

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

Re: [HACKERS] Design for In-Core Logical Replication

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

Re: [HACKERS] Re: Unexpected memory usage for repeated inserts within plpgsql function

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

Re: [HACKERS] Proposal: revert behavior of IS NULL on row types

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,

Re: [HACKERS] Proposal: revert behavior of IS NULL on row types

> "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

Re: [HACKERS] Proposal: revert behavior of IS NULL on row types

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 >

Re: [HACKERS] Proposal: revert behavior of IS NULL on row types

> "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>

Re: [HACKERS] Proposal: revert behavior of IS NULL on row types

> "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

Re: [HACKERS] Proposal: revert behavior of IS NULL on row types

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

[HACKERS] Proposal: revert behavior of IS NULL on row types

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

[HACKERS] AdvanceXLInsertBuffer vs. WAL segment compressibility

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

Re: [HACKERS] [PROPOSAL] Temporal query processing with range types

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

Re: [HACKERS] Rethinking TupleTableSlot deforming

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

Re: [HACKERS] Bug with plpgsql handling of NULL argument of compound type

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.

Re: [HACKERS] Bug with plpgsql handling of NULL argument of compound type

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

Re: [HACKERS] fixes for the Danish locale

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

Re: [HACKERS] Bug with plpgsql handling of NULL argument of compound type

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

Re: [HACKERS] Bug with plpgsql handling of NULL argument of compound type

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

Re: [HACKERS] Rethinking TupleTableSlot deforming

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 > >>

Re: [HACKERS] Rethinking TupleTableSlot 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

Re: [HACKERS] Bug with plpgsql handling of NULL argument of compound type

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

Re: [HACKERS] Rethinking TupleTableSlot deforming

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

Re: [HACKERS] Rethinking TupleTableSlot deforming

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

Re: [HACKERS] Rethinking TupleTableSlot deforming

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

Re: [HACKERS] Rethinking TupleTableSlot deforming

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

Re: [HACKERS] Bug with plpgsql handling of NULL argument of compound type

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 >

Re: [HACKERS] Bug with plpgsql handling of NULL argument of compound type

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

Re: [HACKERS] Rethinking TupleTableSlot deforming

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

Re: [HACKERS] Bug with plpgsql handling of NULL argument of compound type

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

Re: [HACKERS] fixes for the Danish locale

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'. >>>

[HACKERS] Bug with plpgsql handling of NULL argument of compound type

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

[HACKERS] Re: Unexpected memory usage for repeated inserts within plpgsql function

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:

Re: [HACKERS] Oddity in handling of cached plans for FDW queries

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

Re: [HACKERS] Design for In-Core Logical Replication

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

Re: [HACKERS] Design for In-Core Logical Replication

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

Re: [HACKERS] Curing plpgsql's memory leaks for statement-lifespan values

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

Re: [HACKERS] Rethinking TupleTableSlot deforming

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

Re: [HACKERS] Rethinking TupleTableSlot deforming

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

[HACKERS] Cache Hash Index meta page.

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

Re: [HACKERS] freeze map open item

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 > > *

[HACKERS] Re: [HACKERS] Design for In-Core Logical Replication

> >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

Re: [HACKERS] Constraint merge and not valid status

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

Re: [HACKERS] freeze map open item

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

Re: [HACKERS] asynchronous and vectorized execution

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

Re: [HACKERS] Constraint merge and not valid status

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: > >>

Re: [HACKERS] Password identifiers, protocol aging and SCRAM protocol

On Fri, Jul 22, 2016 at 9:06 AM, Michael Paquier wrote: > On Fri, Jul 22, 2016 at 9:02 AM, Tom Lane wrote: >> Michael Paquier writes: >>> One thing about my current set of patches is that I have begun adding >>> files

Re: [HACKERS] PoC: Make it possible to disallow WHERE-less UPDATE and DELETE

On Thu, Jul 21, 2016 at 09:52:26AM -0700, David Fetter wrote: > On Thu, Jul 21, 2016 at 12:46:29PM -0400, Robert Haas wrote: > > On Thu, Jul 21, 2016 at 12:39 PM, David Fetter wrote: > > > On Thu, Jul 21, 2016 at 06:20:37PM +0300, Teodor Sigaev wrote: > > >> > Please find

Re: [HACKERS] [BUG] pg_basebackup from disconnected standby fails

Hello, At Thu, 21 Jul 2016 22:32:08 +0900, Michael Paquier wrote in > On Thu, Jul 21, 2016 at 5:19 PM, Kyotaro HORIGUCHI > wrote: > > + * minRecoveryPoint can go