Hi,
On Thu, Aug 13, 2009 at 2:24 AM, Magnus Hagander wrote:
> Not sure. Potentially pure luck. SIGINT has never *worked*, though, it
> just hasn't crashed.
OK.
> We could implement the same type of check in pg_standby, but it
> requires something like CHECK_FOR_INTERRUPTS. And these interrupts
>
Itagaki Takahiro wrote:
> PostgreSQL version: 8.4.0
> Operating system: all versions
>
> If we set FILLFACTOR to a table, autovacuum parameters in postgresql.conf
> will not affect to the table; default values are always used.
>
> In 8.4.0, we create StdRdOptions if a relation has some fields i
> Ok I looked around at the other fsec assignments in adt/ and did not
> see any that were not treating them as fractional correctly. This
> seems to be the only case. Anywho is the below more what you
> expected? (I decided to do it for the floating point case as well...)
Applied with some cosm
Itagaki Takahiro escreveu:
> In 8.4.0, we create StdRdOptions if a relation has some fields in
> pg_class.reloption. Then, unspecified fields are filled with the
> default values. The values are always hard-coded default values and
> don't reflect current GUC settings.
>
Hey, how I couldn't notice
Alex Hunsaker writes:
> On Tue, Aug 18, 2009 at 12:07, Tom Lane wrote:
>> Throwing overflow errors doesn't seem very nice either, especially not
>> for values that worked just fine before 8.4.
> I just checked both 8.3.7 and 8.2.13 give:
> # select '4817191.623 ms'::interval;
> interval
> ---
On Tue, Aug 18, 2009 at 11:22 AM, Tom Lane wrote:
> "Morus Walter" writes:
>> when trying to use the array_agg aggregate I ran into a `out of memory'
>> issue.
>
> This looks like a known issue, fixed here:
>
> http://archives.postgresql.org/pgsql-committers/2009-07/msg00210.php
>
> It will be in
On Tue, Aug 18, 2009 at 12:07, Tom Lane wrote:
> Throwing overflow errors doesn't seem very nice either, especially not
> for values that worked just fine before 8.4.
I just checked both 8.3.7 and 8.2.13 give:
# select '4817191.623 ms'::interval;
interval
--
-00:35:47.483648
(
Alex Hunsaker writes:
> Ok well we can add overflow checks where we need-em. If you don't
> think the attached patch is horridly ugly- im willing wade through the
> uses of fsec and apply something similar where we need them.
Throwing overflow errors doesn't seem very nice either, especially not
On Tue, Aug 18, 2009 at 10:42, Tom Lane wrote:
> Alex Hunsaker writes:
>> It only happens if you have integer date times on... seems to have
>> gotten introduced by
>> http://archives.postgresql.org/pgsql-committers/2008-03/msg00406.php
>
> Uh, no, fsec_t was int32 before that (look towards the bo
The following bug has been logged online:
Bug reference: 4994
Logged by: Ali Al-Aswad
Email address: alaw...@hotmail.com
PostgreSQL version: postgresql-8.2
Operating system: Win XP Prof SP2
Description:Silent Installation
Details:
Hi,,
I'm using the following batc
Alex Hunsaker writes:
> It only happens if you have integer date times on... seems to have
> gotten introduced by
> http://archives.postgresql.org/pgsql-committers/2008-03/msg00406.php
Uh, no, fsec_t was int32 before that (look towards the bottom of the
diff). I'm fairly dubious that fixing it a
"Morus Walter" writes:
> when trying to use the array_agg aggregate I ran into a `out of memory'
> issue.
This looks like a known issue, fixed here:
http://archives.postgresql.org/pgsql-committers/2009-07/msg00210.php
It will be in 8.4.1.
regards, tom lane
--
Sent via
On Tue, Aug 18, 2009 at 06:00, hubert depesz
lubaczewski wrote:
> Hi,
> tried on latest 8.5, and some 8.3:
> # select '4817191.623 ms'::interval;
> interval
> --
> -00:35:47.483648
> (1 row)
>
> I am pretty sure the answer is wrong. But why?
It only happens if you have integer
The following bug has been logged online:
Bug reference: 4993
Logged by: Morus Walter
Email address: morus.walter...@googlemail.com
PostgreSQL version: 8.4.0
Operating system: linux
Description:memory issue with array_agg
Details:
Hi,
when trying to use the array_a
Hi.
Sorry, I can't understand the problem which you report.
please tell more details?
Although it is a slightly strange version..
Regards,
Hiroshi Saito
- Original Message -
From: "veneti"
The following bug has been logged online:
Bug reference: 4991
Logged by:
"Stratsimir Kolchevski" writes:
> [ BEFORE DELETE triggers can suppress foreign key updates too ]
This is not a bug, it's operating as designed. If we didn't do that
it would foreclose many useful applications of triggers.
regards, tom lane
--
Sent via pgsql-bugs maili
The following bug has been logged online:
Bug reference: 4992
Logged by: Stratsimir Kolchevski
Email address: stratsi...@bastun.net
PostgreSQL version: 8.4.0
Operating system: Linux
Description:"BEFORE DELETE" trigger puts the database in an
inconsistent state
Details
Hi,
tried on latest 8.5, and some 8.3:
# select '4817191.623 ms'::interval;
interval
--
-00:35:47.483648
(1 row)
I am pretty sure the answer is wrong. But why?
depesz
--
Linkedin: http://www.linkedin.com/in/depesz / blog: http://www.depesz.com/
jid/gtalk: dep...@depesz.c
The following bug has been logged online:
Bug reference: 4991
Logged by: veneti
Email address: annita.ven...@qs-unisolution.com
PostgreSQL version: 1.82
Operating system: Windows
Description:problem with ODBC driver 8.4
Details:
When you upgrade to the new odbc driv
PostgreSQL version: 8.4.0
Operating system: all versions
If we set FILLFACTOR to a table, autovacuum parameters in postgresql.conf
will not affect to the table; default values are always used.
In 8.4.0, we create StdRdOptions if a relation has some fields in
pg_class.reloption. Then, unspecifie
20 matches
Mail list logo
