On 04/01/2014 08:58 AM, Amit Langote wrote:
Hi,
Just noticed the following in contrib/sepgsql/relation.c:
1 /* -
2 *
3 * contrib/sepgsql/label.c
4 *
Attached fixes this.
Thanks, fixed.
- Heikki
--
Sent via
On 31 March 2014 01:58, Florian Pflug f...@phlo.org wrote:
Attached are updated patches that include the EXPLAIN changes mentioned
above and updated docs.
These patches need re-basing --- they no longer apply to HEAD.
Regards,
Dean
--
Sent via pgsql-hackers mailing list
Please find attached an updated version v13 for this patch.
I have (I hope) significanlty improved the documentation, including not so
helpful mathematical explanation about the actual meaning of the threshold
value. If a native English speaker could check the documentation, it would
be
On 03/30/2014 11:50 PM, Иван Парфилов wrote:
The implementation of this algorithm would be for data type cube and based
on GiST.
The key concept of BIRCH algorithm is clustering feature. Given a set of N
d-dimensional data points, the clustering feature CF of the set is defined
as the triple CF
On 03/30/2014 11:50 PM, Иван Парфилов wrote:
* Quantifiable results*
Adding support of BIRCH algorithm for data type cube
Aside from the details of *how* that would work, the other question is:
Do we want this in contrib/cube? There are currently no clustering
functions, or any other
Hi MIchael,
I tried to fix the offset problem. PFA the patch. It does solve the problem
of setting wrong offset in ECPGdo() call.
But then there is problem of interpreting the result from server as an
array within array of structure. The problem is there is in
ecpg_get_data(). This function can
On 27 March 2014 17:16, Tom Lane Wrote:
I agree we need to make the docs match the code, but changing behavior
that's been like that for ten or fifteen years isn't the answer.
Sounds good.
Please find the attached patch with only documentation change.
Thanks and Regards,
Kumar Rajeev Rastogi
Hi,
Am Wed, 12 Feb 2014 13:47:41 -0500
schrieb Robert Haas robertmh...@gmail.com:
On Mon, Feb 10, 2014 at 12:14 PM, Jeff Janes jeff.ja...@gmail.com
wrote:
Presumably whatever behavior difference you are seeing is somehow
related to the use of PQconnectdbParams() rather than
Good Afternoon.
Enclosed please find continuation of the discussion of an accidental or
malicious breaking a server consistency.
After reading please comment if there are more objections for changing the
depedency type for trigger to constraint dependency from the
DEPENDENCY_INTERNAL to
Hi all,
As of now, pg_basebackup creates an empty repository for pg_replslot/
in a base backup, forcing the user to recreate slots on other nodes of
the cluster with pg_create_*_replication_slot, or copy pg_replslot
from another node. This is not really user-friendly especially after a
failover
Stephen Frost sfr...@snowman.net writes:
* Michael Paquier (michael.paqu...@gmail.com) wrote:
Except if I am missing something, the second query means that it is
going to replace the existing user test with a new one, with the
settings specified in the 2nd query, all being default values. As
On Tue, Apr 1, 2014 at 9:13 AM, Andrzej Mazurkiewicz
andr...@mazurkiewicz.org wrote:
It seems that if the trigger is internal (tgisinternal = true) it is not
visible to the DROP TRIGGER command. So it cannot be deleted using DROP
TRIGGER command, although the dependency type is
Adrian Vondendriesch adrian.vondendrie...@credativ.de writes:
I patched the function conninfo_array_parse() which is used by
PQconnectStartParams to behave like PQsetdbLogin. The patch also
contains a document patch which clarify unspecified parameters.
I see no documentation update here.
On Fri, Mar 28, 2014 at 4:47 AM, Albe Laurenz laurenz.a...@wien.gv.at wrote:
Peter Geoghegan wrote:
With the addition of LATERAL subqueries, Tom fixed up the mechanism
for keeping track of which relations are visible for column references
while the FROM clause is being scanned. That allowed
Andrzej Mazurkiewicz andr...@mazurkiewicz.org writes:
After reading please comment if there are more objections for changing the
depedency type for trigger to constraint dependency from the
DEPENDENCY_INTERNAL to DEPENDENCY_AUTO.
I'm not sure which part of no you didn't understand, but we're
Hello pgdevs,
I noticed that my pg_stat_statements is cluttered with hundreds of entries
like DEALLOCATE dbdpg_p123456_7, occuring each only once.
It seems to me that it would be more helful if these similar entries where
aggregated together, that is if the query normalization could ignore
On Tue, Apr 1, 2014 at 2:24 PM, Michael Paquier
michael.paqu...@gmail.comwrote:
Hi all,
As of now, pg_basebackup creates an empty repository for pg_replslot/
in a base backup, forcing the user to recreate slots on other nodes of
the cluster with pg_create_*_replication_slot, or copy
On 04/01/2014 10:45 AM, Fabien COELHO wrote:
Hello pgdevs,
I noticed that my pg_stat_statements is cluttered with hundreds of
entries like DEALLOCATE dbdpg_p123456_7, occuring each only once.
It seems to me that it would be more helful if these similar entries
where aggregated together,
On 2014-04-01 16:45:46 +0200, Magnus Hagander wrote:
On Tue, Apr 1, 2014 at 2:24 PM, Michael Paquier
michael.paqu...@gmail.comwrote:
Hi all,
As of now, pg_basebackup creates an empty repository for pg_replslot/
in a base backup, forcing the user to recreate slots on other nodes of
Am 01.04.2014 16:32, schrieb Tom Lane:
Adrian Vondendriesch adrian.vondendrie...@credativ.de writes:
I patched the function conninfo_array_parse() which is used by
PQconnectStartParams to behave like PQsetdbLogin. The patch also
contains a document patch which clarify unspecified parameters.
On Tue, Apr 1, 2014 at 10:45 AM, Magnus Hagander mag...@hagander.net wrote:
On Tue, Apr 1, 2014 at 2:24 PM, Michael Paquier michael.paqu...@gmail.com
wrote:
As of now, pg_basebackup creates an empty repository for pg_replslot/
in a base backup, forcing the user to recreate slots on other
I noticed that my pg_stat_statements is cluttered with hundreds of entries
like DEALLOCATE dbdpg_p123456_7, occuring each only once.
It seems to me that it would be more helful if these similar entries where
aggregated together, that is if the query normalization could ignore the
name of
On Sun, Mar 30, 2014 at 10:04 AM, Bruce Momjian br...@momjian.us wrote:
On Sat, Mar 29, 2014 at 06:33:39PM -0400, Bruce Momjian wrote:
On Sat, Mar 29, 2014 at 06:16:19PM -0400, Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
Are you saying most people like Has OIDs: yes, or the idea
On Mon, Mar 31, 2014 at 1:14 AM, Craig Ringer cr...@2ndquadrant.com wrote:
On 03/31/2014 12:49 PM, Michael Paquier wrote:
On Mon, Mar 31, 2014 at 1:36 PM, Fabrízio de Royes Mello
fabriziome...@gmail.com wrote:
It's a nice idea, but the deadline to students send a proposal was 21th
April.
On Tue, Apr 1, 2014 at 12:39 AM, Jeff Janes jeff.ja...@gmail.com wrote:
On Monday, March 31, 2014, Robert Haas robertmh...@gmail.com wrote:
On Fri, Mar 28, 2014 at 1:06 AM, Kyotaro HORIGUCHI
horiguchi.kyot...@lab.ntt.co.jp wrote:
Mmm. I don't think it is relevant to this problem. The problem
On Tue, Apr 1, 2014 at 11:30:54AM -0400, Robert Haas wrote:
OK, I have now applied the conditional display of Replica Identity
patch (which is how it was originally coded anyway). The attached patch
matches Tom's suggestion of displaying the same OID text, just
conditionally.
Seeing
On Mon, Mar 31, 2014 at 4:21 PM, steve k steven.c.koh...@nasa.gov wrote:
I'd love to see an actual working example where an executing C++ program was
able to in fact determine that copy data containing bad data that was sent
by the C++ program was rejected by the server and subsequently the C++
On Tue, Apr 1, 2014 at 11:42 AM, Bruce Momjian br...@momjian.us wrote:
On Tue, Apr 1, 2014 at 11:30:54AM -0400, Robert Haas wrote:
OK, I have now applied the conditional display of Replica Identity
patch (which is how it was originally coded anyway). The attached patch
matches Tom's
Bruce Momjian br...@momjian.us writes:
On Tue, Apr 1, 2014 at 11:30:54AM -0400, Robert Haas wrote:
Frankly, I think this is all completely wrong-headed. \d+ should
display *everything*. That's what the + means, isn't it? Coming up
with complex rules for which things get shown and which
Robert Haas robertmh...@gmail.com writes:
On Tue, Apr 1, 2014 at 11:42 AM, Bruce Momjian br...@momjian.us wrote:
The bottom line is we already have complex rules to display only what is
_reasonable_. If you want everything, you have to look at the system
tables.
I don't really agree with
Thanks Robert,
I'm already there. Obviously I'm the only one in the room that didn't get
the memo. I've had some time to reflect on what might be done differently,
just not any time to try it. If I get it to work I'll let everyone know.
The code I was working with went away when the Network
On 31.3.2014 21:04, Robert Haas wrote:
On Thu, Mar 27, 2014 at 10:00 PM, Tomas Vondra t...@fuzzy.cz wrote:
The patch also does one more thing - it changes how the arrays (in the
aggregate state) grow. Originally it worked like this
/* initial size */
astate-alen = 64;
/* when
On Fri, Mar 7, 2014 at 12:36 AM, Tom Lane t...@sss.pgh.pa.us wrote:
=?ISO-8859-1?Q?Fabr=EDzio_de_Royes_Mello?= fabriziome...@gmail.com
writes:
Do you think is difficult to implement ALTER TABLE ... SET UNLOGGED
too?
Thinking in a scope of one GSoC, of course.
I think it's basically the
On 2014-04-01 13:37:57 -0300, Fabrízio de Royes Mello wrote:
In the GSoC proposal page [1] I received some suggestions to strech goals:
* ALTER TABLE name SET UNLOGGED. This is essentially the reverse of the
core proposal, which is ALTER TABLE name SET LOGGED. Yes, I think that
should
Hi Ashutosh,
I tried to fix the offset problem. PFA the patch. It does solve the
problem of setting wrong offset in ECPGdo() call.
Thanks, looks correct to me.
But then there is problem of interpreting the result from server as an
array within array of structure. The problem is there is in
In bug #9817 there's a complaint that the planner fails to consider
these expressions equivalent:
foo('a'::text, 'b'::text)
foo(variadic array['a'::text, 'b'::text])
when foo() is declared as taking variadic text[].
Such cases worked okay before 9.3, the reason being that the use of
How much of this problem can be attributed by the fact that repalloc has
to copy the data from the old array into the new one? If it's large,
perhaps we could solve it by replicating the trick we use for
InvalidationChunk. It'd be a bit messy, but the mess would be pretty
well contained, I
Tomas Vondra t...@fuzzy.cz writes:
I've been thinking about it a bit more and maybe the doubling is not
that bad idea, after all.
It is not. There's a reason why that's our standard behavior.
The current array_agg however violates some of the assumptions
mentioned above, because it
(1)
On Tue, Apr 1, 2014 at 12:09 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Tue, Apr 1, 2014 at 11:42 AM, Bruce Momjian br...@momjian.us wrote:
The bottom line is we already have complex rules to display only what is
_reasonable_. If you want everything,
On 03/07/2014 05:36 AM, Tom Lane wrote:
=?ISO-8859-1?Q?Fabr=EDzio_de_Royes_Mello?= fabriziome...@gmail.com writes:
Do you think is difficult to implement ALTER TABLE ... SET UNLOGGED too?
Thinking in a scope of one GSoC, of course.
I think it's basically the same thing. You might hope to
On 2014-04-01 13:36:02 -0400, Robert Haas wrote:
I can't accept that tinkering with that is
reducing clutter in any meaningful way; it's just change for the sake
of change.
+1
Greetings,
Andres Freund
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL
On Tue, Apr 1, 2014 at 8:42 AM, Bruce Momjian br...@momjian.us wrote:
On Tue, Apr 1, 2014 at 11:30:54AM -0400, Robert Haas wrote:
OK, I have now applied the conditional display of Replica Identity
patch (which is how it was originally coded anyway). The attached
patch
matches Tom's
On Tue, Apr 1, 2014 at 10:03 AM, Tom Lane t...@sss.pgh.pa.us wrote:
I'm willing to bend that to the extent of saying that COR leaves in place
subsidiary properties that you might add *with additional statements* ---
for example, foreign keys for a table, or privilege grants for a role.
But the
On Tue, Apr 1, 2014 at 12:14 PM, steve k steven.c.koh...@nasa.gov wrote:
I'm already there. Obviously I'm the only one in the room that didn't get
the memo. I've had some time to reflect on what might be done differently,
just not any time to try it. If I get it to work I'll let everyone
On Tue, Apr 1, 2014 at 2:46 PM, Robert Haas robertmh...@gmail.com wrote:
On Tue, Apr 1, 2014 at 10:03 AM, Tom Lane t...@sss.pgh.pa.us wrote:
I'm willing to bend that to the extent of saying that COR leaves in place
subsidiary properties that you might add *with additional statements* ---
On 3/4/14, 8:50 AM, Andres Freund wrote:
Can't that be solved by just creating the permanent relation in a new
relfilenode? That's equivalent to a rewrite, yes, but we need to do that
for anything but wal_level=minimal anyway.
Maybe I'm missing something, but doesn't this actually involve
On Tue, Apr 1, 2014 at 8:13 AM, Andrzej Mazurkiewicz
andr...@mazurkiewicz.org wrote:
That change is necessary to reduce scope of modifications necessary for an
implementation of the inheritance of foregn key constraints, particularly for
removing of objects.
Nobody here is going to accept that
On 2014-04-01 12:56:04 -0500, Jim Nasby wrote:
On 3/4/14, 8:50 AM, Andres Freund wrote:
Can't that be solved by just creating the permanent relation in a new
relfilenode? That's equivalent to a rewrite, yes, but we need to do that
for anything but wal_level=minimal anyway.
Maybe I'm missing
On Tue, Apr 1, 2014 at 12:52 PM, Tom Lane t...@sss.pgh.pa.us wrote:
In bug #9817 there's a complaint that the planner fails to consider
these expressions equivalent:
foo('a'::text, 'b'::text)
foo(variadic array['a'::text, 'b'::text])
when foo() is declared as taking variadic
On Tue, Apr 1, 2014 at 7:25 AM, Robert Haas robertmh...@gmail.com wrote:
There's a risk of adding not
only CPU cycles but also clutter. If we do things that encourage
people to crank the log verbosity down, I think that's going to be bad
more often than it's good.
While I share your concern
2014-03-27 17:56 GMT+01:00 Pavel Stehule pavel.steh...@gmail.com:
Hello
After week, I can to evaluate a community reflection:
2014-03-19 16:34 GMT+01:00 Pavel Stehule pavel.steh...@gmail.com:
Hello
I wrote a few patches, that we use in our production. These patches are
small, but I
Robert Haas robertmh...@gmail.com writes:
On Tue, Apr 1, 2014 at 12:52 PM, Tom Lane t...@sss.pgh.pa.us wrote:
In bug #9817 there's a complaint that the planner fails to consider
these expressions equivalent:
foo('a'::text, 'b'::text)
foo(variadic array['a'::text, 'b'::text])
when foo() is
On 2014-04-01 12:52:54 -0400, Tom Lane wrote:
We could possibly salvage something by redefining funcvariadic as only
being true if VARIADIC was used *and* the function is VARIADIC ANY,
so that it returns to not being different for semantically-equivalent
cases. This would be a bit messy,
Andres Freund and...@2ndquadrant.com writes:
On 2014-04-01 12:52:54 -0400, Tom Lane wrote:
We could possibly salvage something by redefining funcvariadic as only
being true if VARIADIC was used *and* the function is VARIADIC ANY,
so that it returns to not being different for
On 1.4.2014 19:08, Tom Lane wrote:
Tomas Vondra t...@fuzzy.cz writes:
I've been thinking about it a bit more and maybe the doubling is not
that bad idea, after all.
It is not. There's a reason why that's our standard behavior.
The current array_agg however violates some of the
Tomas Vondra t...@fuzzy.cz writes:
On 1.4.2014 19:08, Tom Lane wrote:
Actually, though, the patch as given outright breaks things for both
the grouped and ungrouped cases, because the aggregate no longer
releases memory when it's done. That's going to result in memory
bloat not savings, in
On 1.4.2014 20:56, Tom Lane wrote:
Tomas Vondra t...@fuzzy.cz writes:
On 1.4.2014 19:08, Tom Lane wrote:
You're conveniently ignoring the callers that set release=true.
Reverse engineering a query that exhibits memory bloat is left
as an exercise for the reader (but in a quick look, I'll bet
On 3/18/14, 12:13 PM, Greg Stark wrote:
Fwiw I'm finding myself repeatedly caught up by the operator
precedence rules when experimenting with jsonb:
stark=***# select segment-'id' as id from flight_segments where
segment-'marketing_airline_code'
segment-'operating_airline_code' ;
ERROR:
On 04/01/2014 03:40 PM, Jim Nasby wrote:
On 3/18/14, 12:13 PM, Greg Stark wrote:
Fwiw I'm finding myself repeatedly caught up by the operator
precedence rules when experimenting with jsonb:
stark=***# select segment-'id' as id from flight_segments where
segment-'marketing_airline_code'
Hackers; as per $subject...
We have an FK defined on a table large enough and 24x7 as to make a
redefining of same constraint a painful solution.
Ran into a case where defining as deferrable initially immediate and
just running one batch job with deferred firing would solve a
concurrency
On Tue, Apr 1, 2014 at 2:23 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Tue, Apr 1, 2014 at 12:52 PM, Tom Lane t...@sss.pgh.pa.us wrote:
In bug #9817 there's a complaint that the planner fails to consider
these expressions equivalent:
foo('a'::text,
On 04/01/2014 01:07 PM, Andrew Dunstan wrote:
What really bugs me about the example is that has a different
precedence from =, which seems more than odd. The example works just
fine if you use = instead of . But I guess it's been that way for a
very long time and there's not much to be done
On 4/1/14, 1:04 PM, Peter Geoghegan wrote:
It strains credulity to think that this
patch alone would have that effect, but there might be quite a few
similar improvements that are possible. So I think it would be good
to consider how far we want to go in this direction and where we think
we
On 4/1/14, 3:07 PM, Andrew Dunstan wrote:
What are cases where things would break if we changed the precedence of - and
-? ISTM that's what we really should do if there's some way to manage the
backwards compatibility...
There is no provision for setting the precedence of any operators. The
On 04/01/2014 05:42 PM, Jim Nasby wrote:
On 4/1/14, 3:07 PM, Andrew Dunstan wrote:
What are cases where things would break if we changed the precedence
of - and -? ISTM that's what we really should do if there's some
way to manage the backwards compatibility...
There is no provision for
On Tue, Apr 1, 2014 at 11:50 AM, Michael Meskes mes...@postgresql.org wrote:
Hi Ashutosh,
I tried to fix the offset problem. PFA the patch. It does solve the
problem of setting wrong offset in ECPGdo() call.
Thanks, looks correct to me.
But then there is problem of interpreting the result
On 04/01/2014 05:24 AM, Michael Paquier wrote:
Hi all,
As of now, pg_basebackup creates an empty repository for pg_replslot/
in a base backup, forcing the user to recreate slots on other nodes of
the cluster with pg_create_*_replication_slot, or copy pg_replslot
from another node. This is
The current typedefs list seems to be lacking any Windows-only typedefs.
Noticed while trying to pgindent postmaster.c.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
On Tue, Apr 1, 2014 at 11:59 PM, Andres Freund and...@2ndquadrant.com wrote:
On 2014-04-01 16:45:46 +0200, Magnus Hagander wrote:
On Tue, Apr 1, 2014 at 2:24 PM, Michael Paquier
michael.paqu...@gmail.comwrote:
As of now, pg_basebackup creates an empty repository for pg_replslot/
in a base
On 04/01/2014 08:53 PM, Tom Lane wrote:
The current typedefs list seems to be lacking any Windows-only typedefs.
Noticed while trying to pgindent postmaster.c.
Hmm. odd. will check.
cheers
andrew
--
Sent via pgsql-hackers mailing list
I wrote:
IOW, it looks to me like intermittent failures in the reverse DNS lookup
could disable matching by hostname, and nothing would be said in the
postmaster log. Why is there no complaint if check_hostname's call to
pg_getnameinfo_all (line 600 in HEAD) fails?
After sleeping on it, I
So, you are saying that we should try to catch such errors and report
during pre-compile time. That's better than silently corrupting the data.
On Tue, Apr 1, 2014 at 10:20 PM, Michael Meskes mes...@postgresql.orgwrote:
Hi Ashutosh,
I tried to fix the offset problem. PFA the patch. It does
On 04/01/2014 09:22 PM, Andrew Dunstan wrote:
On 04/01/2014 08:53 PM, Tom Lane wrote:
The current typedefs list seems to be lacking any Windows-only typedefs.
Noticed while trying to pgindent postmaster.c.
Hmm. odd. will check.
It's apparently causing the buildfarm to crash, which
On Mon, Mar 31, 2014 at 7:08 PM, Yugo Nagata nag...@sraoss.co.jp wrote:
Hi Amit Kapila,
Thank you for your reviewing. I updated the patch to v5.
I have checked the latest version and found few minor improvements that
are required:
1.
! if (!missing_ok)
! ereport(ERROR,
!
74 matches
Mail list logo
