On Thu, Aug 5, 2010 at 5:18 AM, Pavel Stehule wrote:
> The same problem can be with custom aggregates :( so this syntax isn't
> too robust. We can support Oracle's syntax in future releases, where
> syntax divide aggregate call and ORDER BY clause.
>
What syntax is that?
--
greg
--
Sent via p
On 5 August 2010 10:29, Greg Stark wrote:
> On Thu, Aug 5, 2010 at 5:18 AM, Pavel Stehule wrote:
>> The same problem can be with custom aggregates :( so this syntax isn't
>> too robust. We can support Oracle's syntax in future releases, where
>> syntax divide aggregate call and ORDER BY clause.
>
This is Seol.
I have a problem with Postgresql, so let me know how to solve it.
I'm using 8.4 version of Postgresql.
The problem occured when I made a tablespace on "pgAdmin 3".
I assigned the name and the location for a new tablespace. then a new
tablespace was made.
At this time, I realized that
On Thu, Aug 5, 2010 at 12:55 PM, Hitesh Bhambhani
wrote:
> [HiteshB] I have noted your recommendation and will work with our Product
> Management to upgrade to the latest and greatest. Although we can't change
> the version that the customer has installed (8.2.9-1).
>
The latest and greatest is
Alvaro, thanks for your response.
My comments below...
> From: Alvaro Herrera [mailto:alvhe...@commandprompt.com]
> Sent: Wednesday, August 04, 2010 11:30 PM
> There probably is. What kind of relation are the ones unable to truncate?
> Please see in pg_class where relfilenode = '41274' in this
>
Greg, thanks for your answers.
My comments below...
> From: gsst...@gmail.com [mailto:gsst...@gmail.com] On Behalf Of Greg Stark
> Sent: Wednesday, August 04, 2010 9:35 PM
> Firstly, the current release of 8.2 is 8.2.17. There are a long list of bugs
> fixed in those intervening releases includin
Hitesh Bhambhani wrote:
> Could you give an example of what an 'extraordinary circumstance'
> would be?
Normal vacuums will remove old tuples (versions of rows) which can
no longer be seen by any transaction, and make that space available
for re-use within the PostgreSQL files. It will not no
wrote:
> I tried to uninstall Postgresql. But, "data" folder was denied
> to remove.
How? And how was it installed in the first place?
> When I tried to remove "data" folder in 8.4 folder by force, my
> computer shut down and startup automatically.
Tried to remove it how?
> Can I delete
Thom Brown writes:
> On 5 August 2010 10:29, Greg Stark wrote:
>> On Thu, Aug 5, 2010 at 5:18 AM, Pavel Stehule
>> wrote:
>>> The same problem can be with custom aggregates :( so this syntax isn't
>>> too robust. We can support Oracle's syntax in future releases, where
>>> syntax divide aggrega
2010/8/5 Tom Lane :
> Thom Brown writes:
>> On 5 August 2010 10:29, Greg Stark wrote:
>>> On Thu, Aug 5, 2010 at 5:18 AM, Pavel Stehule
>>> wrote:
The same problem can be with custom aggregates :( so this syntax isn't
too robust. We can support Oracle's syntax in future releases, wher
Hitesh Bhambhani writes:
>> From: Alvaro Herrera [mailto:alvhe...@commandprompt.com]
>> Sent: Wednesday, August 04, 2010 11:30 PM
>> There probably is. What kind of relation are the ones unable to truncate?
>> Please see in pg_class where relfilenode = '41274' in this
>> case:
>>
> [HiteshB] the
Pavel Stehule writes:
The same problem can be with custom aggregates :( so this syntax isn't
too robust.
BTW, I'm really not worried about that case. By the time someone is
advanced enough to have written their own multi-argument aggregate
definitions, they'll have absorbed the idea th
On Thu, Aug 5, 2010 at 00:13, Rene Novotny wrote:
>
> The following bug has been logged online:
> PostgreSQL version: 9.0 beta 4
> Operating system: Win 7 64 bit
> Description: cannot create language plperl;
> Details:
>
> ERROR: Could not load library
> c:/Program Files/PostgreSQL/9.0/li
2010/8/5 Tom Lane :
> Pavel Stehule writes:
> The same problem can be with custom aggregates :( so this syntax isn't
> too robust.
>
> BTW, I'm really not worried about that case. By the time someone is
> advanced enough to have written their own multi-argument aggregate
> definitions, th
Pavel Stehule writes:
> but still when we remove one parametric string_agg, then this issue
> will not be documented.
How so? This paragraph will still be there:
When dealing with multiple-argument aggregate functions, note that the
ORDER BY clause goes after all the aggregate argum
Excerpts from Tom Lane's message of jue ago 05 11:06:57 -0400 2010:
> Seems like we need to think harder about recovering from a truncate
> failure. A few random ideas:
Ugh.
> 1. Write the dirty buffers before dropping them. Kind of ugly from a
> performance viewpoint, but simple and safe.
I
Alvaro Herrera writes:
> Excerpts from Tom Lane's message of jue ago 05 11:06:57 -0400 2010:
>> 1. Write the dirty buffers before dropping them. Kind of ugly from a
>> performance viewpoint, but simple and safe.
> I think "simple" is good, considering that this code is gone in 9.0 and
> HEAD. I
The following bug has been logged online:
Bug reference: 5602
Logged by: Chris
Email address: christoph.sprin...@magicinternet.de
PostgreSQL version: 9.0beta3
Operating system: Debian 5.0.3
Description:Recovering from Hot-Standby file backup leads to the
currupted ind
"Chris" writes:
> A Hot-Standby database is being backed up to a new machine like this:
> 0. pause WAL file deletion from Hot-Standby
> 1. backup pg_control
> 2. sync data and tablespace files
> 3. wait for checkout using pg_controldata and waiting for UNDO address
> change
> 4. copy all WAL file
Excerpts from Tom Lane's message of jue ago 05 12:36:24 -0400 2010:
> Alvaro Herrera writes:
> > Excerpts from Tom Lane's message of jue ago 05 11:06:57 -0400 2010:
> >> 1. Write the dirty buffers before dropping them. Kind of ugly from a
> >> performance viewpoint, but simple and safe.
>
> > I
Alvaro Herrera writes:
> Excerpts from Tom Lane's message of jue ago 05 12:36:24 -0400 2010:
>> Gone? Looks like it's still there to me.
> I mean the btree code that does the truncation on vacuum full is
> truncated. There are other uses for truncation, but it doesn't look to
> that they are as
On 5 August 2010 16:31, Pavel Stehule wrote:
> 2010/8/5 Tom Lane :
>> Pavel Stehule writes:
>> The same problem can be with custom aggregates :( so this syntax isn't
>> too robust.
>>
>> BTW, I'm really not worried about that case. By the time someone is
>> advanced enough to have writte
2010/8/5 Tom Lane :
> Pavel Stehule writes:
>> but still when we remove one parametric string_agg, then this issue
>> will not be documented.
>
> How so? This paragraph will still be there:
>
>
> When dealing with multiple-argument aggregate functions, note that the
> ORDER BY clause goe
Excerpts from Tom Lane's message of jue ago 05 13:19:41 -0400 2010:
> In any case, the removal of VACUUM FULL didn't completely disable
> shrinking of btree indexes did it? I don't recall having removed
> that.
I see no call to RelationTruncate in the btvacuumscan code, but then it
was only call
Alvaro Herrera writes:
> Excerpts from Tom Lane's message of jue ago 05 13:19:41 -0400 2010:
>> In any case, the removal of VACUUM FULL didn't completely disable
>> shrinking of btree indexes did it? I don't recall having removed
>> that.
> I see no call to RelationTruncate in the btvacuumscan c
I wrote:
> Well, I forgot that an aggregate involves more than one catalog row ;-).
> So it's a bit bigger patch than that, but still pretty small and safe.
> See attached.
Applied to HEAD and 9.0. The mistaken case will now yield this:
regression=# select string_agg(f1 order by f1, ',') from te
Excerpts from Tom Lane's message of jue ago 05 14:01:15 -0400 2010:
> You're right, I misremembered. That code is just plain gone in 9.0:
> http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/access/nbtree/nbtree.c.diff?r1=1.174;r2=1.175;f=h
>
> Still, we have a live issue with heap trunc
On ons, 2010-08-04 at 18:19 -0400, Tom Lane wrote:
>
> This policy also implies that we are never going to allow default
> arguments for aggregates, or at least never have any built-in ones
> that use such a feature.
>
> By my count the following people had offered an opinion on making
> this cha
Peter Eisentraut writes:
> I vote against this patch. There are plenty of other places that SQL is
> confusing, and this move seems excessive to me, and I find the
> functionality that is proposed for removal quite useful.
Huh? The functionality proposed for removal is only that of omitting an
On Aug 5, 2010, at 11:25 AM, Tom Lane wrote:
> Applied to HEAD and 9.0. The mistaken case will now yield this:
>
> regression=# select string_agg(f1 order by f1, ',') from text_tbl;
> ERROR: function string_agg(text) does not exist
> LINE 1: select string_agg(f1 order by f1, ',') from text_tbl;
On 5 August 2010 19:39, David E. Wheeler wrote:
> On Aug 5, 2010, at 11:25 AM, Tom Lane wrote:
>
>> Applied to HEAD and 9.0. The mistaken case will now yield this:
>>
>> regression=# select string_agg(f1 order by f1, ',') from text_tbl;
>> ERROR: function string_agg(text) does not exist
>> LINE
On Thu, Aug 5, 2010 at 12:25, Tom Lane wrote:
> regression=# select string_agg(f1 order by f1, ',') from text_tbl;
> ERROR: function string_agg(text) does not exist
> LINE 1: select string_agg(f1 order by f1, ',') from text_tbl;
> ^
> HINT: No function matches the given name and ar
"David E. Wheeler" writes:
> On Aug 5, 2010, at 11:25 AM, Tom Lane wrote:
>> Applied to HEAD and 9.0. The mistaken case will now yield this:
>> regression=# select string_agg(f1 order by f1, ',') from text_tbl;
>> ERROR: function string_agg(text) does not exist
> I'm confused: that looks like t
On Aug 5, 2010, at 11:42 AM, Thom Brown wrote:
>>> LINE 1: select string_agg(f1 order by f1, ',') from text_tbl;
>>> ^
>>
>> I'm confused: that looks like the two-argument form to me. Have I missed
>> something?
>>
>>> HINT: No function matches the given name and argument types.
On Aug 5, 2010, at 11:45 AM, Tom Lane wrote:
>> I'm confused: that looks like the two-argument form to me. Have I missed
>> something?
>
> Yeah, the whole point of the thread: that's not a call of a two-argument
> aggregate. It's a call of a one-argument aggregate, using a two-column
> sort key
> This process seems almost entirely unrelated to the documented way of
> doing it; I'm not surprised that you end up with some files not in sync.
> Please see pg_start_backup and friends.
>
> regards, tom lane
>
Hallo Tom,
It was done as documented in
http://www.postgre
> Well, maybe we need to expend some more sweat on the error message then.
> But this patch was still a prerequisite thing, because without it there
> is no error that we can complain about.
Yes, I'd say an addition to the HINT is in order *assuming* at that
stage we can tell if the user passed a
Josh Berkus writes:
>> Well, maybe we need to expend some more sweat on the error message then.
>> But this patch was still a prerequisite thing, because without it there
>> is no error that we can complain about.
> Yes, I'd say an addition to the HINT is in order *assuming* at that
> stage we ca
On Thu, Aug 5, 2010 at 3:16 PM, Tom Lane wrote:
> Josh Berkus writes:
>>> Well, maybe we need to expend some more sweat on the error message then.
>>> But this patch was still a prerequisite thing, because without it there
>>> is no error that we can complain about.
>
>> Yes, I'd say an addition
On Aug 5, 2010, at 12:16 PM, Tom Lane wrote:
> HINT: No aggregate function matches the given name and argument
> types. Perhaps you misplaced ORDER BY; ORDER BY must appear after all
> regular arguments of the aggregate.
+1
David
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org
Robert Haas writes:
> On Thu, Aug 5, 2010 at 3:16 PM, Tom Lane wrote:
>> Next question: exactly how should the variant HINT be phrased?
>> I'm inclined to drop the bit about explicit casts and make it read
>> something like
>>
>> HINT: No aggregate function matches the given name and argument
>>
valgog writes:
>> This process seems almost entirely unrelated to the documented way of
>> doing it; I'm not surprised that you end up with some files not in sync.
>> Please see pg_start_backup and friends.
> It was done as documented in
> http://www.postgresql.org/docs/9.0/static/backup-increme
On 05/08/10 21:28, Alvaro Herrera wrote:
Excerpts from Tom Lane's message of jue ago 05 14:01:15 -0400 2010:
Maybe write-the-buffers-first is a sufficient longterm solution.
Yeah, perhaps it is, though it's a pity that a single platform problem
is going to slow down everyone else.
How about
Heikki Linnakangas writes:
> On 05/08/10 21:28, Alvaro Herrera wrote:
>> Excerpts from Tom Lane's message of jue ago 05 14:01:15 -0400 2010:
>>> Maybe write-the-buffers-first is a sufficient longterm solution.
>>
>> Yeah, perhaps it is, though it's a pity that a single platform problem
>> is goin
On tor, 2010-08-05 at 14:38 -0400, Tom Lane wrote:
> Huh? The functionality proposed for removal is only that of omitting
> an explicit delimiter argument for string_agg(). Since the default
> value (an empty string) doesn't seem to be the right thing all that
> often anyway, I'm not following wh
On tis, 2010-08-03 at 14:36 +, Dmtiriy Igrishin wrote:
> When 'configure' executed in a directory outside the source tree the
> documentation is not installs later nevertheless the "gmake
> install-docs" or
> "gmake install-world" (I tried to build with "gmake world" also) typed
> to
> install
Peter Eisentraut writes:
> I think I can explain this behavior. When building outside the source
> tree, in looks in the build tree and then in the source tree for
> documentation to install. This is done by looking for a 'html'
> directory. When you already have an 'html' directory in the sour
Peter Eisentraut writes:
> On tor, 2010-08-05 at 14:38 -0400, Tom Lane wrote:
>> Huh? The functionality proposed for removal is only that of omitting
>> an explicit delimiter argument for string_agg(). Since the default
>> value (an empty string) doesn't seem to be the right thing all that
>> of
On Thu, 2010-08-05 at 11:28 -0700, valgog wrote:
> > This process seems almost entirely unrelated to the documented way of
> > doing it; I'm not surprised that you end up with some files not in sync.
> > Please see pg_start_backup and friends.
> It was done as documented in
> http://www.postgresq
The following bug has been logged online:
Bug reference: 5603
Logged by: Nacho Mezzadra
Email address: nachomezza...@gmail.com
PostgreSQL version: 8.3.11
Operating system: Red Hat Enterprise 5.3
Description:pg_tblspc and pg_twoface directories get deleted when
startin
On Thu, Aug 5, 2010 at 7:28 PM, Alvaro Herrera
wrote:
>
> The scope is further reduced by the fact that this only seems to happen
> on Windows, and then only when the antivirus is messing around with the
> files.
So I suspect this could be triggered lots of ways. Imagine a ZFS
volume that runs ou
Simon Riggs writes:
> On Thu, 2010-08-05 at 11:28 -0700, valgog wrote:
>> It was done as documented in
>> http://www.postgresql.org/docs/9.0/static/backup-incremental-updated.html
> The procedure used does differ from that documented. However, IMHO the
> procedure *documented* is *not* safe and
On Fri, Aug 6, 2010 at 12:20 PM, Tom Lane wrote:
> Hm, I was looking at that and thinking it seemed unsafe for entirely
> different reasons. But if you didn't write it, who did?
Incrementally Updated Backups technique has been in the document since 8.2.
In the development cycle of 9.0, I and Hei
The following bug has been logged online:
Bug reference: 5604
Logged by: Jon Erdman (aka StuckMojo)
Email address: postgre...@thewickedtribe.net
PostgreSQL version: Tested 9.0, 8.3
Operating system: Ubuntu Lucid 10.04
Description:Setting NOT NULL on inherited column t
On Thu, Aug 5, 2010 at 1:45 AM, Alvaro Herrera
wrote:
> Excerpts from Tom Lane's message of mié ago 04 12:37:23 -0400 2010:
>> My recollection is that that change was associated with some pretty
>> significant revisions to the postmaster state machine. I'm concerned
>> about the risks involved in
55 matches
Mail list logo
