On 7 January 2016 at 01:17, Peter Eisentraut wrote:
> On 12/22/15 4:55 AM, Craig Ringer wrote:
> > I'm a touch frustrated by that, as a large part of the point of
> > submitting the output plugin separately and in advance of the downstream
> > was to get attention for it separately, as its own en
On Tue, Dec 22, 2015 at 12:16 AM, Fabien COELHO wrote:
> So you would just like to remove double double(int) and double sqrt(double)
> from the patch, and basically that is all? int int(double)??
> debug??? (hmmm, useful debugging a non trivial expression).
OK, so I am finally back on this item,
2016-01-07 1:11 GMT+01:00 Tom Lane :
> Dean Rasheed writes:
> > On 6 January 2016 at 20:09, Robert Haas wrote:
> >> On Wed, Jan 6, 2016 at 10:21 AM, Dean Rasheed
> wrote:
> >>> It seems like a useful function to have, but perhaps it should just be
> >>> called trim() rather than numeric_trim(),
On Thu, Jan 7, 2016 at 2:29 PM, Stephen Frost wrote:
> Robert,
>
> * Robert Haas (robertmh...@gmail.com) wrote:
>
>> Apart from the issue of whether this is doomed for some architectural
>> reason, it is not entirely clear to me that there's any consensus that
>> we want this. I don't think that
On 2016/01/06 13:07, Haribabu Kommi wrote:
> On Wed, Jan 6, 2016 at 1:43 PM, Amit Langote
>>
>> Patch 4_database_catalog_tenancy_v5 fails to apply:
>
> May be you missed to apply the 3_shared_catalog_tenancy_v4 path,
> because 4_database_catalog_tenancy_v5 patch depends on it.
Oops, I even missed
On Fri, Dec 25, 2015 at 6:36 AM, Robert Haas wrote:
> On Wed, Dec 23, 2015 at 1:16 AM, Amit Kapila
> wrote:
> >> >
> >> > Here procArrayGroupXid sounds like Xid at group level, how about
> >> > procArrayGroupMemberXid?
> >> > Find the patch with renamed variables for PGProc
> >> > (rename_pgproc
On Wed, Jan 6, 2016 at 8:00 PM, Michael Paquier
wrote:
> On Wed, Jan 6, 2016 at 3:04 PM, Michael Paquier
> wrote:
>> Attached is an updated patch.
>
> Forgot to update rules.out...
Thanks for the update. Patch looks good to me.
I marked it as ready for committer.
Regards,
Hari Babu
Fujitsu Aust
Noah Misch writes:
> On Tue, Jan 05, 2016 at 01:46:51PM -0500, Tom Lane wrote:
>> I do not see a lot of point in the namespacing of encoding conversions
>> either. Does anyone really need or use search-path-dependent lookup of
>> conversions?
> I have not issued CREATE CONVERSION except to exper
On 1/6/16 9:22 PM, Michael Paquier wrote:
On Thu, Jan 7, 2016 at 9:28 AM, Tom Lane wrote:
Jim Nasby writes:
Somewhat related to that, I don't believe there's any reason why commit
fest managers need to be committers; it seems like the job is really
just about reading through email activity to
On 1/6/16 6:18 PM, Greg Stark wrote:
On Wed, Jan 6, 2016 at 11:42 PM, Jim Nasby wrote:
Right. Personally, I feel the TODO has pretty much outlived it's usefulness.
An issue tracker would make maintaining items like this a lot more
reasonable, but it certainly wouldn't be free.
Eh, a bug track
On 2016/01/06 23:50, Tom Lane wrote:
> Amit Langote writes:
>> On 2016/01/06 17:32, Amit Langote wrote:
>>> I stumbled upon a possibly strange behavior which may be related to recent
>>> initdb changes. For a freshly initdb'd cluster, the following looks fishy:
>>> ...
>>> These seem to be leftove
On Tue, Jan 05, 2016 at 01:46:51PM -0500, Tom Lane wrote:
> I do not see a lot of point in the namespacing of encoding conversions
> either. Does anyone really need or use search-path-dependent lookup of
> conversions?
I have not issued CREATE CONVERSION except to experiment, and I have never
wor
Robert,
* Robert Haas (robertmh...@gmail.com) wrote:
> On Tue, Jan 5, 2016 at 11:07 PM, Haribabu Kommi
> wrote:
> > May be you missed to apply the 3_shared_catalog_tenancy_v4 path,
> > because 4_database_catalog_tenancy_v5 patch depends on it.
> >
> > Here I attached all the patches for your conv
On Thu, Jan 7, 2016 at 9:28 AM, Tom Lane wrote:
> Jim Nasby writes:
>> Somewhat related to that, I don't believe there's any reason why commit
>> fest managers need to be committers; it seems like the job is really
>> just about reading through email activity to see where things are at.
>
> They
On Thu, Jan 7, 2016 at 12:20 AM, Alvaro Herrera
wrote:
> Vladimir Borodin wrote:
>
>> There are situations in which vacuuming big btree index causes stuck
>> in WAL replaying on hot standby servers for quite a long time. I’ve
>> described the problem in more details in this thread [0]. Below in
>>
On Wed, Jan 6, 2016 at 6:51 PM, Dean Rasheed wrote:
> On 6 January 2016 at 20:09, Robert Haas wrote:
>> On Wed, Jan 6, 2016 at 10:21 AM, Dean Rasheed
>> wrote:
>>> It seems like a useful function to have, but perhaps it should just be
>>> called trim() rather than numeric_trim(), for consistenc
On 2016/01/07 1:03, Tom Lane wrote:
> Amit Langote writes:
>> On Wed, Jan 6, 2016 at 11:51 PM, Tom Lane wrote:
>>> "non-existant" is flat wrong, so if we're going to fix typos, let's
>>> fix them to actually be English.
>
>> So, non-existent? non-extant? I seems to me like an 's' accidentally
>>
On Wed, Jan 6, 2016 at 3:51 PM, Tom Lane wrote:
> Yeah. The other problem is that stuff that's actually small doesn't tend
> to hang around undone for long, so there's not really a broad array of
> stuff just waiting for someone to have a little time. If we had a more
> actively maintained TODO
Jim Nasby writes:
> Somewhat related to that, I don't believe there's any reason why commit
> fest managers need to be committers; it seems like the job is really
> just about reading through email activity to see where things are at.
They don't need to be. Michael Paquier did a fine job with
On Wed, Jan 6, 2016 at 11:42 PM, Jim Nasby wrote:
> Right. Personally, I feel the TODO has pretty much outlived it's usefulness.
> An issue tracker would make maintaining items like this a lot more
> reasonable, but it certainly wouldn't be free.
Eh, a bug tracker that tracks actual bugs would be
Dean Rasheed writes:
> On 6 January 2016 at 20:09, Robert Haas wrote:
>> On Wed, Jan 6, 2016 at 10:21 AM, Dean Rasheed
>> wrote:
>>> It seems like a useful function to have, but perhaps it should just be
>>> called trim() rather than numeric_trim(), for consistency with the
>>> names of the oth
On 01/06/2016 03:57 PM, Jim Nasby wrote:
On 1/6/16 5:51 PM, Tom Lane wrote:
Having said that, it occurs to me that one way to contribute without
actually writing C code would be to try to drive those unfinished
discussions to consensus, and come up with specs for features that people
agree are w
On 1/6/16 5:51 PM, Tom Lane wrote:
Having said that, it occurs to me that one way to contribute without
actually writing C code would be to try to drive those unfinished
discussions to consensus, and come up with specs for features that people
agree are well-thought-out. Conversely, establishing
On 6 January 2016 at 20:09, Robert Haas wrote:
> On Wed, Jan 6, 2016 at 10:21 AM, Dean Rasheed
> wrote:
>> It seems like a useful function to have, but perhaps it should just be
>> called trim() rather than numeric_trim(), for consistency with the
>> names of the other numeric functions, which d
Robert Haas writes:
> On Wed, Jan 6, 2016 at 10:43 AM, Catalin Iacob wrote:
>> I also think a list of small things suitable for new contributors
>> would help attracting them. Not all would stick and go on to larger
>> items but hopefully at least some would.
> I agree with this. Curating such
On 1/6/16 2:18 PM, Robert Haas wrote:
On Wed, Jan 6, 2016 at 10:43 AM, Catalin Iacob wrote:
I also think a list of small things suitable for new contributors
would help attracting them. Not all would stick and go on to larger
items but hopefully at least some would.
I agree with this. Curati
Peter Krauss writes:
> I need to access an array-item from an array of arrays.
Multi-dimensional arrays in Postgres are not "arrays of arrays".
If you persist in thinking they are, it's mostly going to lead you
astray about what will work or not.
Having said that, you might find that plpgsql's
I need to access an array-item from an array of arrays. Suppose
WITH t AS (SELECT '{{1,2,3},{33,44,55}}'::int[][] as a)SELECT
a[2],-- returns null (!), why not works?
a[2:2], -- returns array-into-array, not a simple arrayFROM t;
There are a simple function or operator to acess i
On Wed, Jan 6, 2016 at 10:43 AM, Catalin Iacob wrote:
> I also think a list of small things suitable for new contributors
> would help attracting them. Not all would stick and go on to larger
> items but hopefully at least some would.
I agree with this. Curating such a list is a fair amount of w
On Tue, Jan 5, 2016 at 11:07 PM, Haribabu Kommi
wrote:
> May be you missed to apply the 3_shared_catalog_tenancy_v4 path,
> because 4_database_catalog_tenancy_v5 patch depends on it.
>
> Here I attached all the patches for your convenience, I am able to
> apply all patches in the order without any
On 2016-01-06 21:01:47 +0100, Tomas Vondra wrote:
> >Although I disagree with some aspects of Andres patch, I'm not a
> >committer and I'm tired of arguing. I'm just planing to do minor changes
> >to Andres version to fix a potential issue if the file is closed which
> >flushing is in progress, but
On Wed, Jan 6, 2016 at 10:21 AM, Dean Rasheed wrote:
> It seems like a useful function to have, but perhaps it should just be
> called trim() rather than numeric_trim(), for consistency with the
> names of the other numeric functions, which don't start with
> "numeric_".
That wouldn't work in thi
On Thu, Dec 31, 2015 at 6:22 AM, Dilip Kumar wrote:
> On Fri, Dec 18, 2015 at 10:51 AM, Dilip Kumar
> wrote:
>
> On Sun, Jul 19 2015 9:37 PM Andres Wrote,
>>
>> > The situation the read() protect us against is that two backends try to
>> > extend to the same block, but after one of them succeede
On Mon, Dec 28, 2015 at 2:15 PM, Alvaro Herrera
wrote:
>> 1. CS API.
>> I agree with you that FDW API seems to be not enough to efficiently support
>> work with CS.
>> At least we need batch insert.
>> But may be it is better to extend FDW API rather than creating special API
>> for CS?
>
> The pa
Hi,
On 12/16/2015 08:27 PM, Fabien COELHO wrote:
Hello Tomas,
I'm planning to do some thorough benchmarking of the patches proposed
in this thread, on various types of hardware (10k SAS drives and
SSDs). But is that actually needed? I see Andres did some testing, as
he posted summary of the r
2016-01-06 19:52 GMT+01:00 Robert Haas :
> On Sun, Jan 3, 2016 at 3:24 PM, Peter Krauss wrote:
> > The usefulness of ->> operator is indisputable, but even with boolean
> or
> > numeric values, with good binary internal representation, it returns
> JSONB
> > value as text data type.
> >
> > The
On Thu, Dec 31, 2015 at 11:09 AM, Edson - Amplosoft Software
wrote:
> [ quote of an existing message in its entirety ]
> --
> Sent from my Android device with K-9 Mail. Please excuse my brevity.
Yes, that was extremely brief.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterpri
On Sun, Jan 3, 2016 at 3:24 PM, Peter Krauss wrote:
> The usefulness of ->> operator is indisputable, but even with boolean or
> numeric values, with good binary internal representation, it returns JSONB
> value as text data type.
>
> The simple (myJSONB->>'myField')::expectedType is not enough
Joe Conway writes:
> Compared to both of these alternatives, I still feel that the specific
> SET ROLE hook is cleanest and best path forward. If there are no other
> comments or concerns, I will commit this in a day or two.
While I don't think there's any great harm in inventing such a hook, I'm
On Wed, Jan 6, 2016 at 5:17 PM, Peter Eisentraut wrote:
> I can't imagine that there is a lot of interest in a replication tool
> where you only get one side of it, no matter how well-designed or
> general it is.
Well I do have another purpose in mind myself so I do appreciate it
being available
On 01/06/2016 02:39 AM, Pavel Stehule wrote:
> I did a review of this patch.
>
> 1. the proposal is clean and there are not any objection against it. I
> checked a implementation, and it does exactly same what was proposed.
>
> 2. This hook has impact only on SET role to XXX statement, what isn't
Hello,
>Please find attached patch addressing following comments
I have tested this patch.
It is showing empty (null) in phase column of pg_stat_vacuum_progress, when
I switched to a unprivileged user.
In the previous patch, it is showing in phase
column.
Thanks and Regards,
Sudhir Lonkar
--
V
Robert Haas writes:
> On Sun, Jan 3, 2016 at 5:22 PM, Jim Nasby wrote:
>> The rule that gets executed if you do `make installcheck` with something
>> using PGXS is
>>
>> pgxs.mk:$(pg_regress_installcheck) $(REGRESS_OPTS) $(REGRESS)
>>
>> where $(pg_regress_installcheck) is set in Makefi
On Sun, Jan 3, 2016 at 5:22 PM, Jim Nasby wrote:
> The rule that gets executed if you do `make installcheck` with something
> using PGXS is
>
> pgxs.mk:$(pg_regress_installcheck) $(REGRESS_OPTS) $(REGRESS)
>
> where $(pg_regress_installcheck) is set in Makefile.global.in to
>
>> pg_regress
On Sun, Jan 3, 2016 at 9:05 PM, Ian Barwick wrote:
> Like the docs say, vacuumdb is a "wrapper around the SQL command VACUUM"
> which I used to use in dim-and-distant pre-autovacuum days came for cronjobs,
> but until messing around with pg_upgrade recently I hadn't really had much
> use for it. A
On Tue, Jan 5, 2016 at 11:55 PM, David Rowley
wrote:
> On 4 January 2016 at 21:49, David Rowley
> wrote:
>>
>> I've not tested the patch yet. I will send another email soon with the
>> results of that.
>
>
> Hi,
>
> As promised I've done some testing on this, and I've found something which
> is n
On Wed, Jan 6, 2016 at 11:13 AM, Stephen Frost wrote:
> I just wanted to start off by saying thank you for taking the time read
> and comment with your thoughts on this concept. I was a bit frustrated
> about it feeling rather late, but appreciate the comments which have
> been made as they've ce
On 12/22/15 4:55 AM, Craig Ringer wrote:
> I'm a touch frustrated by that, as a large part of the point of
> submitting the output plugin separately and in advance of the downstream
> was to get attention for it separately, as its own entity. A lot of
> effort has been put into making this usable f
On Mon, Jan 4, 2016 at 8:52 PM, Dilip Kumar wrote:
> One strange behaviour, after increasing number of processor for VM,
> max_parallel_degree=0; is also performing better.
So, you went from 6 vCPUs to 8? In general, adding more CPUs means
that there is less contention for CPU time, but if you a
On Wed, Jan 6, 2016 at 4:50 PM, Magnus Hagander wrote:
> Hi!
>
> I'm about to start some upgrades on the machine running
> commitfest.postgresql.org. The app itself won't change, but the
> underlying OS and webserver will, so there will be some disruptions of
> service and some strange and scary
On 6 January 2016 at 09:03, David Rowley
wrote:
> It seems worthwhile to investigate how we might go about improving this so
> that the evaluation of the target list happens after LIMIT, at least for
> the columns which are not required before LIMIT.
>
Currently, the FunctionScan executes until
Robert, Noah,
I just wanted to start off by saying thank you for taking the time read
and comment with your thoughts on this concept. I was a bit frustrated
about it feeling rather late, but appreciate the comments which have
been made as they've certainly been constructive.
* Robert Haas (rober
Amit Langote writes:
> On Wed, Jan 6, 2016 at 11:51 PM, Tom Lane wrote:
>> "non-existant" is flat wrong, so if we're going to fix typos, let's
>> fix them to actually be English.
> So, non-existent? non-extant? I seems to me like an 's' accidentally
> sneaked in when the author of the comment tr
On Wed, Jan 6, 2016 at 11:51 PM, Tom Lane wrote:
> Amit Langote writes:
>> Attached fixes a typo: s/non-exstant/non-existant.
>> Alternatively, it could be spelled as 'existent' but the patch doesn't.
>
> "non-existant" is flat wrong, so if we're going to fix typos, let's
> fix them to actually b
Hi!
I'm about to start some upgrades on the machine running
commitfest.postgresql.org. The app itself won't change, but the underlying
OS and webserver will, so there will be some disruptions of service and
some strange and scary error messages for a while.
Hopefully it will take less than an hou
On Wed, Jan 6, 2016 at 3:11 AM, Jim Nasby wrote:
> Which doesn't help anyone, because neither of those provide a list of "hey,
> here's stuff you could do to contribute". The closest we come to that is the
> TODO, which isn't well known and has almost no items for newbies (and the
> newbie items t
Hi
2016-01-06 16:21 GMT+01:00 Dean Rasheed :
> On 27 December 2015 at 07:11, Pavel Stehule
> wrote:
> >> 2015-11-19 3:58 GMT+01:00 Marko Tiikkaja :
> >>> Here's a patch for the second function suggested in
> >>> 5643125e.1030...@joh.to.
> >>>
> > So I am sending a review of this patch.
> >
>
> I
On 27 December 2015 at 07:11, Pavel Stehule wrote:
>> 2015-11-19 3:58 GMT+01:00 Marko Tiikkaja :
>>> Here's a patch for the second function suggested in
>>> 5643125e.1030...@joh.to.
>>>
> So I am sending a review of this patch.
>
I took a quick look at this too.
It seems like a useful function t
Vladimir Borodin wrote:
> There are situations in which vacuuming big btree index causes stuck
> in WAL replaying on hot standby servers for quite a long time. I’ve
> described the problem in more details in this thread [0]. Below in
> that thread Kevin Grittner proposed a good way for improving b
Amit Langote writes:
> Attached fixes a typo: s/non-exstant/non-existant.
> Alternatively, it could be spelled as 'existent' but the patch doesn't.
"non-existant" is flat wrong, so if we're going to fix typos, let's
fix them to actually be English.
regards, tom lane
--
Amit Langote writes:
> On 2016/01/06 17:32, Amit Langote wrote:
>> I stumbled upon a possibly strange behavior which may be related to recent
>> initdb changes. For a freshly initdb'd cluster, the following looks fishy:
>> ...
>> These seem to be leftovers of activities of initdb.c's setup_descrip
On Wed, Jan 6, 2016 at 5:06 AM, Jim Nasby wrote:
> On 1/5/16 9:16 PM, Tom Lane wrote:
>
>> Jim Nasby writes:
>>
>>> FWIW, I suspect very few people know about the verbosity setting (I
>>> didn't until a few months ago...) Maybe psql should hint about it the
>>> first time an error is reported in
On 25 December 2015 at 10:00, Etsuro Fujita wrote:
> On 2015/12/24 4:34, Robert Haas wrote:
>>
>> On Wed, Dec 23, 2015 at 5:50 AM, Rushabh Lathia
>> wrote:
>>>
>>> +1.
>>>
>>> I like idea of separate FDW API for the DML Pushdown. Was thinking can't
>>> we
>>> can re-use the IterateForeignScan(Fo
On 01/06/2016 12:03 PM, David Rowley wrote:
Konstantin, are you thinking of looking into this more, with plans to implement
code to improve this?
I am not familiar with PostgreSQL optimizer, but I now looking inside its code
and trying to find a way to fix this problem.
But if there is someb
Hi
I did a review of this patch.
1. the proposal is clean and there are not any objection against it. I
checked a implementation, and it does exactly same what was proposed.
2. This hook has impact only on SET role to XXX statement, what isn't used
in our critical path, so there are not any perf
On Tue, Jan 5, 2016 at 11:35 AM, Shulgin, Oleksandr <
oleksandr.shul...@zalando.de> wrote:
> On Tue, Jan 5, 2016 at 10:39 AM, Shulgin, Oleksandr <
> oleksandr.shul...@zalando.de> wrote:
>
>>
>> I didn't look in the code yet, but if someone knows off top of the head
>> the reason to this behavior,
I started looking at updated patch and its definitely iked the new
approach.
Patch passing the mandatory checks:
1) Patch applied cleanly using patch -p1 command
2) Source got compiled cleanly
3) make check, running cleanly
Explain output for the remote table and inheritance relations looks bet
On 2016/01/06 17:32, Amit Langote wrote:
> Hi,
>
> I stumbled upon a possibly strange behavior which may be related to recent
> initdb changes. For a freshly initdb'd cluster, the following looks fishy:
>
> postgres=# SELECT relname, relnamespace::regnamespace FROM pg_class
> WHERE relnamespace !
Ultimately I would also like to see a general hook available which would
>> fire for all changes to GUC settings, but I think this one is still very
>> useful as it is highly targeted.
>>
>> Comments?
>>
>
> I read discussion in this thread and I am thinking so creating hook is the
> most simple an
Hi,
I have an updated patch which uses Matches() rather than TailMatches().
Andreas
diff --git a/src/bin/psql/tab-complete.c b/src/bin/psql/tab-complete.c
index b5117d4..158b913 100644
--- a/src/bin/psql/tab-complete.c
+++ b/src/bin/psql/tab-complete.c
@@ -1934,12 +1934,19 @@ psql_completion(con
On 01/04/2016 07:26 AM, Michael Paquier wrote:
You may want to use Matches() instead of TailMatches() for performance reasons.
Here is an updated version which uses Matches().
Andreas
diff --git a/src/bin/psql/tab-complete.c b/src/bin/psql/tab-complete.c
index 4d2bee1..34dabc5 100644
--- a/src
Hi,
Attached fixes a typo: s/non-exstant/non-existant.
Alternatively, it could be spelled as 'existent' but the patch doesn't.
Nor does it drop the 's' and spell it 'non-extant' which may have been the
original intent.
Thanks,
Amit
diff --git a/src/backend/catalog/namespace.c b/src/backend/cata
On 6 January 2016 at 13:13, Alexander Korotkov
wrote:
> On Wed, Jan 6, 2016 at 12:08 AM, Tom Lane wrote:
>
>> konstantin knizhnik writes:
>> > 1. The cost compared in grouping_planner doesn't take in account price
>> of get_authorized_users - it is not changed when I am altering function
>> cos
On Wed, Jan 6, 2016 at 3:04 PM, Michael Paquier
wrote:
> Attached is an updated patch.
Forgot to update rules.out...
--
Michael
From 4bc33d1497c302b8669b1f1d9d43f2f806029693 Mon Sep 17 00:00:00 2001
From: Michael Paquier
Date: Fri, 18 Dec 2015 22:44:21 +0900
Subject: [PATCH] Add system view and
On 01/06/2016 01:13 AM, Michael Paquier wrote:
On Wed, Jan 6, 2016 at 2:03 AM, Tom Lane wrote:
I've pushed the second patch now. I made a few adjustments --- notably,
I didn't like the way you'd implemented '*' wildcards, because they
wouldn't have behaved very sanely in combination with '|'.
Hi,
I stumbled upon a possibly strange behavior which may be related to recent
initdb changes. For a freshly initdb'd cluster, the following looks fishy:
postgres=# SELECT relname, relnamespace::regnamespace FROM pg_class
WHERE relnamespace != 'pg_catalog'::regnamespace
AND relnamespace != 'pg_to
76 matches
Mail list logo