I'd like to report a potential bug (or just my misunderstanding), but
I couldn't find any mention in the TODO or on the mailing list.
I'm using PostgreSQL 9.0 beta 3 on Gentoo x64 (sorry, I don't have
beta 4 yet). I attempted to use string_agg to get values into a
comma-separated list as follows.
On 4 August 2010 10:36, Thom Brown wrote:
> I'd like to report a potential bug (or just my misunderstanding), but
> I couldn't find any mention in the TODO or on the mailing list.
>
> I'm using PostgreSQL 9.0 beta 3 on Gentoo x64 (sorry, I don't have
> beta 4 yet). I attempted to use string_agg t
On 4 August 2010 10:44, Thom Brown wrote:
> On 4 August 2010 10:36, Thom Brown wrote:
>> I'd like to report a potential bug (or just my misunderstanding), but
>> I couldn't find any mention in the TODO or on the mailing list.
>>
>> I'm using PostgreSQL 9.0 beta 3 on Gentoo x64 (sorry, I don't hav
On Wed, Aug 4, 2010 at 6:03 AM, Thom Brown wrote:
> Actually, this rings a bell. I think this may have been raised
> before, something to do with the delimiter being accepted as one of
> the order by values. If this isn't really a bug, could someone
> mention it in the docs somewhere?
Oh, yeah.
Hi,
In my customer's system using v8.2.5, even though no process exited abnormally,
the fast shutdown wrongly caused the automatic restart of a database. The server
log is as follows:
Jul 18 16:21:51 postgres[26624]: [1-1] LOG: received fast shutdown request
Jul 18 16:21:51 postgres[26624]: [2
On 4 August 2010 14:04, Robert Haas wrote:
> On Wed, Aug 4, 2010 at 6:03 AM, Thom Brown wrote:
>> Actually, this rings a bell. I think this may have been raised
>> before, something to do with the delimiter being accepted as one of
>> the order by values. If this isn't really a bug, could someo
2010/8/4 Thom Brown :
> On 4 August 2010 14:04, Robert Haas wrote:
>> On Wed, Aug 4, 2010 at 6:03 AM, Thom Brown wrote:
>>> Actually, this rings a bell. I think this may have been raised
>>> before, something to do with the delimiter being accepted as one of
>>> the order by values. If this isn
On 4 August 2010 14:24, Pavel Stehule wrote:
> 2010/8/4 Thom Brown :
>> On 4 August 2010 14:04, Robert Haas wrote:
>>> On Wed, Aug 4, 2010 at 6:03 AM, Thom Brown wrote:
Actually, this rings a bell. I think this may have been raised
before, something to do with the delimiter being acce
2010/8/4 Thom Brown :
> On 4 August 2010 14:24, Pavel Stehule wrote:
>> 2010/8/4 Thom Brown :
>>> On 4 August 2010 14:04, Robert Haas wrote:
On Wed, Aug 4, 2010 at 6:03 AM, Thom Brown wrote:
> Actually, this rings a bell. I think this may have been raised
> before, something to do
The following bug has been logged online:
Bug reference: 5598
Logged by: Shine
Email address: shine.prak...@icasework.com
PostgreSQL version: 8.4
Operating system: Windows XP
Description:Compatibility modes
Details:
Hi,
We are planning to upgrade from Postgresql 8.
Robert Haas writes:
> Oh, yeah. I guess you need this:
> select thing, string_agg(stuff, ',' order by stuff) from agg_test
> group by thing;
> Rather than this:
> select thing, string_agg(stuff order by stuff, ',') from agg_test
> group by thing;
> It's all kinds of not obvious to me what the
Fujii Masao writes:
> 6. ... the bgwriter had already ended even though there was a backend in
>progress. Postmaster regarded this situation as abnormal and caused the
>recovery.
> In 8.3 or later, since postmaster doesn't regard that situation as abnormal
> and just waits for all backend
On Wed, Aug 4, 2010 at 11:29 AM, Tom Lane wrote:
> Robert Haas writes:
>> Oh, yeah. I guess you need this:
>
>> select thing, string_agg(stuff, ',' order by stuff) from agg_test
>> group by thing;
>
>> Rather than this:
>
>> select thing, string_agg(stuff order by stuff, ',') from agg_test
>> gr
On Wed, Aug 4, 2010 at 10:53 AM, Shine wrote:
> We are planning to upgrade from Postgresql 8.2 to 8.4, and we have hit the
> following error when running our application against it.
>
> org.postgresql.util.PSQLException: ERROR: operator does not exist: character
> varying = integer
>
> We have not
Robert Haas writes:
> I suppose this confusion is only possible because string_agg has both
> a one-argument and a two-argument form.
Right, or at least that's what allows the mistake to go through without
reporting any error.
regards, tom lane
--
Sent via pgsql-bugs m
Excerpts from Tom Lane's message of mié ago 04 12:37:23 -0400 2010:
> Fujii Masao writes:
> > 6. ... the bgwriter had already ended even though there was a backend in
> >progress. Postmaster regarded this situation as abnormal and caused the
> >recovery.
>
> > In 8.3 or later, since postm
On Wed, Aug 4, 2010 at 12:44 PM, Tom Lane wrote:
> Robert Haas writes:
>> I suppose this confusion is only possible because string_agg has both
>> a one-argument and a two-argument form.
>
> Right, or at least that's what allows the mistake to go through without
> reporting any error.
No, that'
On Wed, Aug 4, 2010 at 10:42, Robert Haas wrote:
> On Wed, Aug 4, 2010 at 10:53 AM, Shine wrote:
>> We would like to know if there is a workaround built into postgres by
>> setting some kind of COMPATIBILITY variable (similar to SQL SERVER 2005 /
>> 2008)...
>
> Sorry, there is no such mode...
H
Robert Haas writes:
> On Wed, Aug 4, 2010 at 12:44 PM, Tom Lane wrote:
>> Robert Haas writes:
>>> I suppose this confusion is only possible because string_agg has both
>>> a one-argument and a two-argument form.
>>
>> Right, or at least that's what allows the mistake to go through without
>> re
Alex Hunsaker writes:
> On Wed, Aug 4, 2010 at 10:42, Robert Haas wrote:
>> On Wed, Aug 4, 2010 at 10:53 AM, Shine wrote:
>>> We would like to know if there is a workaround built into postgres by
>>> setting some kind of COMPATIBILITY variable (similar to SQL SERVER 2005 /
>>> 2008)...
>>
>> So
On Wed, Aug 4, 2010 at 1:04 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Wed, Aug 4, 2010 at 12:44 PM, Tom Lane wrote:
>>> Robert Haas writes:
I suppose this confusion is only possible because string_agg has both
a one-argument and a two-argument form.
>>>
>>> Right, or at least th
On Wed, Aug 4, 2010 at 11:04, Tom Lane wrote:
> If we were a bit earlier in the 9.0 cycle I would suggest that this
> confusion is a sufficient reason to drop the one-argument form of
> string_agg. It's too late now though.
FWIW I think we can still change it. Isn't this type of issue part
of
Alex Hunsaker wrote:
> On Wed, Aug 4, 2010 at 11:04, Tom Lane wrote:
>> If we were a bit earlier in the 9.0 cycle I would suggest that
>> this confusion is a sufficient reason to drop the one-argument
>> form of string_agg. It's too late now though.
>
> FWIW I think we can still change it. Is
Alex Hunsaker writes:
> On Wed, Aug 4, 2010 at 11:04, Tom Lane wrote:
>> If we were a bit earlier in the 9.0 cycle I would suggest that this
>> confusion is a sufficient reason to drop the one-argument form of
>> string_agg. It's too late now though.
> FWIW I think we can still change it. Isn'
On Wed, Aug 4, 2010 at 13:11, Tom Lane wrote:
> Alex Hunsaker writes:
>> On Wed, Aug 4, 2010 at 11:04, Tom Lane wrote:
>>> If we were a bit earlier in the 9.0 cycle I would suggest that this
>>> confusion is a sufficient reason to drop the one-argument form of
>>> string_agg. It's too late now t
On Wed, Aug 4, 2010 at 3:25 PM, Alex Hunsaker wrote:
> I think forcing an initdb might be more trouble than this wart is worth.
+1. I would not make this change unless we have to force an initdb
anyway. And I really hope we don't, because I'm sort of hoping the
next 9.0 release will be rc1.
--
Alex Hunsaker writes:
> Either way, I don't have strong feelings on this other than if we dont
> fix it now when will we?
Well, we won't. If 9.0 ships with both forms of string_agg, we're stuck
with it IMO. It's not exactly a bug, so I won't cry if that's how
things go; but it is striking that
On 4 August 2010 20:25, Alex Hunsaker wrote:
> On Wed, Aug 4, 2010 at 13:11, Tom Lane wrote:
>> Alex Hunsaker writes:
>>> On Wed, Aug 4, 2010 at 11:04, Tom Lane wrote:
If we were a bit earlier in the 9.0 cycle I would suggest that this
confusion is a sufficient reason to drop the one-
Robert Haas writes:
> On Wed, Aug 4, 2010 at 3:25 PM, Alex Hunsaker wrote:
>> I think forcing an initdb might be more trouble than this wart is worth.
> +1. I would not make this change unless we have to force an initdb
> anyway. And I really hope we don't, because I'm sort of hoping the
> nex
> Well, it'd take an initdb to get rid of it. In the past we've avoided
> forcing initdb post-beta1 unless it was Really Necessary. OTOH, we seem
> to be in the mode of encouraging beta testers to test pg_upgrade, so
> maybe that concern isn't worth much at the moment.
If it's causing bugs, dro
Josh Berkus writes:
> If it's causing bugs, drop it now. If we include it in 9.0, we're stuck
> with it for years.
Well, it's causing bug reports, which is not exactly the same thing as bugs.
But yeah, I'm thinking we should get rid of it.
regards, tom lane
--
Sent via
04.Ağu.2010 tarihinde 22:44 saatinde, Josh Berkus
şunları yazdı:
I'm OK with forcing an initDB for RC1.
I think beta5 will be a better choice than RC 1 here.
--
Devrim GÜNDÜZ
PostgreSQL DBA @ Akinon/Markafoni, Red Hat Certified Engineer
devrim~gunduz.org, devrim~PostgreSQL.org, devrim.gundu
On Wed, Aug 4, 2010 at 13:42, Tom Lane wrote:
> Robert Haas writes:
>> On Wed, Aug 4, 2010 at 3:25 PM, Alex Hunsaker wrote:
>>> I think forcing an initdb might be more trouble than this wart is worth.
>
>> +1. I would not make this change unless we have to force an initdb
>> anyway. And I real
> Great, I was afraid people would want another beta if we forced an
> initdb. So a hearty +1 for fixing it and not doing another beta
> (pending other bugs obviously).
And, btw, there has been a lot of testing of pg_upgrade due to the
initdbs and otherwise. I think 9.0 is going to have a prett
On 4 August 2010 20:58, Josh Berkus wrote:
>
>> Great, I was afraid people would want another beta if we forced an
>> initdb. So a hearty +1 for fixing it and not doing another beta
>> (pending other bugs obviously).
>
> And, btw, there has been a lot of testing of pg_upgrade due to the
> initdbs
On Wed, Aug 04, 2010 at 09:02:43PM +0100, Thom Brown wrote:
> On 4 August 2010 20:58, Josh Berkus wrote:
> >
> >> Great, I was afraid people would want another beta if we forced
> >> an initdb. So a hearty +1 for fixing it and not doing another
> >> beta (pending other bugs obviously).
> >
> > An
On Wed, Aug 4, 2010 at 3:11 PM, Tom Lane wrote:
> Alex Hunsaker writes:
>> On Wed, Aug 4, 2010 at 11:04, Tom Lane wrote:
>>> If we were a bit earlier in the 9.0 cycle I would suggest that this
>>> confusion is a sufficient reason to drop the one-argument form of
>>> string_agg. It's too late now
I wrote:
> Hm? I don't think that an initdb here would have any impact on whether
> we can call the next drop RC1 or not. We're talking about removing a
> single built-in entry in pg_proc --- it's one of the safest changes we
> could possibly make.
Well, I forgot that an aggregate involves more
On 4 August 2010 23:19, Tom Lane wrote:
> I wrote:
>> Hm? I don't think that an initdb here would have any impact on whether
>> we can call the next drop RC1 or not. We're talking about removing a
>> single built-in entry in pg_proc --- it's one of the safest changes we
>> could possibly make.
>
Thom Brown writes:
> I was afraid that the function would be pulled completely, but from
> looking at the patch, you're only removing the function with a
> single-parameter signature, which is quite innocuous.
Yes, of course, sorry if I confused anyone. It's the combination of
having both one- a
On Wed, Aug 04, 2010 at 06:19:49PM -0400, Tom Lane wrote:
> I wrote:
> > Hm? I don't think that an initdb here would have any impact on whether
> > we can call the next drop RC1 or not. We're talking about removing a
> > single built-in entry in pg_proc --- it's one of the safest changes we
> > c
On Wed, Aug 4, 2010 at 16:33, Thom Brown wrote:
> I was afraid that the function would be pulled completely, but from
> looking at the patch, you're only removing the function with a
> single-parameter signature, which is quite innocuous. So I'm "for"
> now.
Ahh, Now I see why you were worried
Alex Hunsaker writes:
> I dunno about anyone else but (a, ',' order by a) just looks weird.
I suppose, but aren't you just focusing on the argument being constant?
In the more general case I don't think there's anything unnatural about
this syntax.
> Or in other words, any thoughts on:
> select
On 04/08/10 16:55, Tom Lane wrote:
You're right, I did. Perhaps the presence of prebuilt docs in the
source tree confuses something --- anybody wanna test?
The files that seem to be causing the confusion are:
/doc/src/sgml/html-stamp
/doc/src/sgm/man-stamp
A src tree 'maintainer-clean'
On Wed, Aug 4, 2010 at 7:07 PM, Tom Lane wrote:
>> Or in other words, any thoughts on:
>> select string_agg(delim, expression);
>
> That looks pretty weird to me anyway, with or without use of ORDER BY.
> Nobody would think to write the delimiter first. Usually you put the
> "most important" argu
On Wed, Aug 4, 2010 at 17:07, Tom Lane wrote:
> Alex Hunsaker writes:
>> I dunno about anyone else but (a, ',' order by a) just looks weird.
>
> I suppose, but aren't you just focusing on the argument being constant?
Yes.
>> Or in other words, any thoughts on:
>> select string_agg(delim, expres
On Wed, Aug 4, 2010 at 6:19 PM, Tom Lane wrote:
> for: tgl, josh, badalex, mmoncure
> against: rhaas, thom
> Anybody else want to vote, or change their vote after seeing the patch?
If we're not regarding this as beta-forcing, I abstain.
--
Robert Haas
EnterpriseDB: http://www.ente
The following bug has been logged online:
Bug reference: 5599
Logged by: Hitesh Bhambhani
Email address: hite...@asg.com
PostgreSQL version: 8.2.9-1
Operating system: Microsoft Windows Server 2003, Enterprise Edition
Description:Vacuum fails due to index corruption is
On Wed, Aug 4, 2010 at 11:19 PM, Tom Lane wrote:
> What we are doing here, IMO, is not just changing string_agg() but
> instituting a project policy that we are not going to offer built-in
> aggregates with the same names and different numbers of arguments ---
> otherwise the problem will come rig
On Wed, Aug 4, 2010 at 10:47 PM, Hitesh Bhambhani wrote:
>
> PostgreSQL version: 8.2.9-1
Firstly, the current release of 8.2 is 8.2.17. There are a long list
of bugs fixed in those intervening releases including one involving
vacuum truncating relations. I don't think it's the same problem but I
Greg Stark writes:
> On Wed, Aug 4, 2010 at 11:19 PM, Tom Lane wrote:
>> What we are doing here, IMO, is not just changing string_agg() but
>> instituting a project policy that we are not going to offer built-in
>> aggregates with the same names and different numbers of arguments ---
>> otherwise
Excerpts from Mark Kirkwood's message of mié ago 04 19:14:07 -0400 2010:
> On 04/08/10 16:55, Tom Lane wrote:
> >
> > You're right, I did. Perhaps the presence of prebuilt docs in the
> > source tree confuses something --- anybody wanna test?
> >
> >
>
> The files that seem to be causing the
Excerpts from Hitesh Bhambhani's message of mié ago 04 17:47:12 -0400 2010:
> Based on some logs in the Webapp I can see that there were some errors in
> truncating relations. Once those errors disappear the index corruption
> errors start. I'm not sure if there is a connection here.
There proba
Alvaro Herrera writes:
> I think the VPATH mechanism in gmake looks for files in srcdir and then
> in builddir, by default. Not sure if that can be overridden easily.
> Maybe those two files should be deleted from the tarball.
That's not going to work: it would mean that make would try to rebui
2010/8/4 Kevin Grittner :
> Alex Hunsaker wrote:
>> On Wed, Aug 4, 2010 at 11:04, Tom Lane wrote:
>>> If we were a bit earlier in the 9.0 cycle I would suggest that
>>> this confusion is a sufficient reason to drop the one-argument
>>> form of string_agg. It's too late now though.
>>
The same p
The following bug has been logged online:
Bug reference: 5601
Logged by: Rene Novotny
Email address: novotn...@egp.cz
PostgreSQL version: 9.0 beta 4
Operating system: Win 7 64 bit
Description:cannot create language plperl;
Details:
ERROR: Could not load library
c:/
56 matches
Mail list logo
