On Mon, Mar 31, 2014 at 7:08 PM, Yugo Nagata 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,
! (errcode(ERRCODE_UNDEFINED_OBJECT),
!
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 is
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 wrote:
> Hi Ashutosh,
>
> > I tried to fix the offset problem. PFA the patch. It does solve the
> > prob
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
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 (pgsql-hackers@postgresql.
On Tue, Apr 1, 2014 at 11:59 PM, Andres Freund wrote:
> On 2014-04-01 16:45:46 +0200, Magnus Hagander wrote:
>> On Tue, Apr 1, 2014 at 2:24 PM, Michael Paquier
>> wrote:
>> > As of now, pg_basebackup creates an empty repository for pg_replslot/
>> > in a base backup, forcing the user to recreate s
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:
http://www.postgresql.org
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
On Tue, Apr 1, 2014 at 11:50 AM, Michael Meskes 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 from server
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 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. T
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 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
On Tue, Apr 1, 2014 at 2:23 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Tue, Apr 1, 2014 at 12:52 PM, Tom Lane 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':
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 probl
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' <>
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 1.4.2014 20:56, Tom Lane wrote:
> Tomas Vondra 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
> ARRAY_
Tomas Vondra 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 any sit
On 1.4.2014 19:08, Tom Lane wrote:
> Tomas Vondra 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
Andres Freund 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 semantically-equivalent
>> cases.
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, s
Robert Haas writes:
> On Tue, Apr 1, 2014 at 12:52 PM, Tom Lane 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 tex
2014-03-27 17:56 GMT+01:00 Pavel Stehule :
> Hello
>
> After week, I can to evaluate a community reflection:
>
>
> 2014-03-19 16:34 GMT+01:00 Pavel Stehule :
>
> Hello
>>
>> I wrote a few patches, that we use in our production. These patches are
>> small, but I hope, so its can be interesting for
On Tue, Apr 1, 2014 at 7:25 AM, Robert Haas 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 here, I think that
On Tue, Apr 1, 2014 at 12:52 PM, Tom Lane 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 text[].
My first r
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
On Tue, Apr 1, 2014 at 8:13 AM, Andrzej Mazurkiewicz
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 goal as a valid reaso
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 writi
On Tue, Apr 1, 2014 at 2:46 PM, Robert Haas wrote:
> On Tue, Apr 1, 2014 at 10:03 AM, Tom Lane 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 ta
On Tue, Apr 1, 2014 at 12:14 PM, steve k 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 know.
> The code I was wo
On Tue, Apr 1, 2014 at 10:03 AM, Tom Lane 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 properties of
On Tue, Apr 1, 2014 at 8:42 AM, Bruce Momjian 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 sugge
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 Developme
On 03/07/2014 05:36 AM, Tom Lane wrote:
=?ISO-8859-1?Q?Fabr=EDzio_de_Royes_Mello?= 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 optimize it;
but you have
On Tue, Apr 1, 2014 at 12:09 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Tue, Apr 1, 2014 at 11:42 AM, Bruce Momjian 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.
>
>>
Tomas Vondra 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) pre-alloca
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 think.
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
VA
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
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
> shoul
On Fri, Mar 7, 2014 at 12:36 AM, Tom Lane wrote:
> =?ISO-8859-1?Q?Fabr=EDzio_de_Royes_Mello?=
> 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 o
On 31.3.2014 21:04, Robert Haas wrote:
> On Thu, Mar 27, 2014 at 10:00 PM, Tomas Vondra 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
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 a
Robert Haas writes:
> On Tue, Apr 1, 2014 at 11:42 AM, Bruce Momjian 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 that. I understand that there's
Bruce Momjian 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 things get
>>
On Tue, Apr 1, 2014 at 11:42 AM, Bruce Momjian 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 suggestion
On Mon, Mar 31, 2014 at 4:21 PM, steve k 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++
> program was able to
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.
>
On Tue, Apr 1, 2014 at 12:39 AM, Jeff Janes wrote:
> On Monday, March 31, 2014, Robert Haas wrote:
>>
>> On Fri, Mar 28, 2014 at 1:06 AM, Kyotaro HORIGUCHI
>> wrote:
>> > Mmm. I don't think it is relevant to this problem. The problem
>> > specific here is 'The database was running until just now
On Mon, Mar 31, 2014 at 1:14 AM, Craig Ringer 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
>> wrote:
>>> It's a nice idea, but the deadline to students send a proposal was 21th
>>> April.
>> 21st of March. All the details are
On Sun, Mar 30, 2014 at 10:04 AM, Bruce Momjian 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 writes:
>> > > Are you saying most people like "Has OIDs: yes", or the idea of just
>> > > displa
On Tue, Apr 1, 2014 at 10:45 AM, Magnus Hagander wrote:
> On Tue, Apr 1, 2014 at 2:24 PM, Michael Paquier
> 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 nodes of
>> the cluster with pg_create_*_
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
Am 01.04.2014 16:32, schrieb Tom Lane:
> Adrian Vondendriesch 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 documentat
On 2014-04-01 16:45:46 +0200, Magnus Hagander wrote:
> On Tue, Apr 1, 2014 at 2:24 PM, 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 wit
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 Tue, Apr 1, 2014 at 2:24 PM, 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 no
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 igno
Andrzej Mazurkiewicz 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 not
doing that.
>
On Fri, Mar 28, 2014 at 4:47 AM, Albe Laurenz 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
>> errorMissingColu
Adrian Vondendriesch 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. I'm also fairly concerned abou
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 DEPENDENC
Stephen Frost 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 the
>> defaul
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 wh
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 DEPEND
Hi,
Am Wed, 12 Feb 2014 13:47:41 -0500
schrieb Robert Haas :
> On Mon, Feb 10, 2014 at 12:14 PM, Jeff Janes
> wrote:
> >> Presumably whatever behavior difference you are seeing is somehow
> >> related to the use of PQconnectdbParams() rather than
> >> PQsetdbLogin(), but the fine manual does not
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 Rastog
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 no
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 stati
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
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 nic
On 31 March 2014 01:58, Florian Pflug 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 (pgsql-hackers@postgresql.org)
73 matches
Mail list logo
