Tom Lane escribió:
> "Steven Flatt" <[EMAIL PROTECTED]> writes:
> > I noticed that the Postgres autovacuum process was vacuuming some tables
> > that had enabled = false in pg_autovacuum.
>
> I think what is happening is that because you set
> pg_autovacuum.freeze_max_age to zero, the thing always
elein <[EMAIL PROTECTED]> writes:
> From: Tom Lane
>> Hmmm ... are you using integer timestamps by any chance?
>> It looks to me like TimestampTzPlusMilliseconds() would overflow
>> for such a large timeout.
> Is this a bug or should there be documentation that tells us the max
> of statement tim
"Steven Flatt" <[EMAIL PROTECTED]> writes:
> I noticed that the Postgres autovacuum process was vacuuming some tables
> that had enabled = false in pg_autovacuum.
I think what is happening is that because you set
pg_autovacuum.freeze_max_age to zero, the thing always thinks that it's
time to force
On Wed, Jan 23, 2008 at 11:22:06AM -0800, elein wrote:
> Running 8.3RC1
>
> I have an sql script where one or more create index statements
> raise a statement timeout message. The statement timeout is
> set to 1d.
>
> The script runs in ~3 hours including the timeout messages.
>
> The script doe
The following bug has been logged online:
Bug reference: 3898
Logged by: Steven Flatt
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.2.4
Operating system: FreeBSD 6.1
Description:Postgres autovacuum not respecting pg_autovacuum.enabled
= false
Details:
I not
elein <[EMAIL PROTECTED]> writes:
> Running 8.3RC1
> I have an sql script where one or more create index statements
> raise a statement timeout message. The statement timeout is
> set to 1d.
Hmmm ... are you using integer timestamps by any chance?
It looks to me like TimestampTzPlusMilliseconds()
Running 8.3RC1
I have an sql script where one or more create index statements
raise a statement timeout message. The statement timeout is
set to 1d.
The script runs in ~3 hours including the timeout messages.
The script does this:
BEGIN;
create table temp.xxx ...
insert into temp.xxx ...
COMMIT
The following bug has been logged online:
Bug reference: 3897
Logged by: David Gradwell
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.3rc2
Operating system: Windows Server 2003
Description:plJava dll still doesn't load
Details:
I've successfully installed p
"Guillaume Smet" <[EMAIL PROTECTED]> writes:
> On Jan 23, 2008 4:22 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
>> What do you find odd about it? Whatever scale you choose to think these
>> values are in, they all have to be on the same scale.
> So they are not defined in relation compared to the seq
On Jan 23, 2008 4:22 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
> What do you find odd about it? Whatever scale you choose to think these
> values are in, they all have to be on the same scale.
So they are not defined in relation compared to the sequential page
fetch cost as they were before? I mean
"Guillaume Smet" <[EMAIL PROTECTED]> writes:
> #seq_page_cost = 1.0# measured on an arbitrary scale
> #random_page_cost = 4 # same scale as above
> #cpu_tuple_cost = 0.01 # same scale as above
> #cpu_index_tuple_cost = 0.005 # same sca
> On Jan 23, 2008 11:50 AM, Guillaume Smet <[EMAIL PROTECTED]> wrote:
> > I just noticed something odd in the Planner constants part of the 8.2
> > and 8.3 postgresql.conf:
> > # - Planner Cost Constants -
> >
> > #seq_page_cost = 1.0# measured on an arbitrary scale
> > #rando
Hi Harald,
On Jan 23, 2008 1:36 PM, Harald Armin Massa <[EMAIL PROTECTED]> wrote:
> that should be regarded more to be a feature then a bug:
That's not my point :). It's just that the comments are misleading or
at least a bit absurd.
--
Guillaume
---(end of broadcast)--
Guillaume,
that should be regarded more to be a feature then a bug:
within 8.1, the seq_page_cost was virtuelle fixed at 1; if you found
that cost to be i.e. 12.123 as you measured "time to read in ms" with
some other tool, you had to rescale all costs so that 12.123 is
transformed to 1.0
Now t
Adam Hardy написа:
[...]
it seems to me from what you just said that PostgreSQL server and JDBC
driver require the schema name to be lower case deliberately, and that
any given name that is not all lower case is converted to lower case by
the server or the driver. Am I correct?
http://www.po
On 23/01/2008, Arjan Bolmer <[EMAIL PROTECTED]> wrote:
>
> The following bug has been logged online:
>
> Bug reference: 3895
> Logged by: Arjan Bolmer
> Email address: [EMAIL PROTECTED]
> PostgreSQL version: 8.2.6
> Operating system: Vista
> Description:Access denied
>
The following bug has been logged online:
Bug reference: 3895
Logged by: Arjan Bolmer
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.2.6
Operating system: Vista
Description:Access denied
Details:
I tried installing Postgres 8.2.6, everything went fine but th
Hi -bugs,
I just noticed something odd in the Planner constants part of the 8.2
and 8.3 postgresql.conf:
# - Planner Cost Constants -
#seq_page_cost = 1.0# measured on an arbitrary scale
#random_page_cost = 4 # same scale as above
#cpu_tuple_cost = 0.01
Kris Jurka on 23/01/08 08:51, wrote:
On Tue, 22 Jan 2008, Adam Hardy wrote:
The following bug has been logged online:
Bug reference: 3894
Description:JDBC DatabaseMetaData.getTables is inconsistently
case-sensitive with schema name
Details:
create schema DEV;
but then DatabaseMet
On Tue, 22 Jan 2008, Adam Hardy wrote:
The following bug has been logged online:
Bug reference: 3894
Description:JDBC DatabaseMetaData.getTables is inconsistently
case-sensitive with schema name
Details:
create schema DEV;
but then DatabaseMetaData.getTables(null, "DEV", "%",
The following bug has been logged online:
Bug reference: 3894
Logged by: Adam Hardy
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.2.5
Operating system: Linux
Description:JDBC DatabaseMetaData.getTables is inconsistently
case-sensitive with schema name
Details
21 matches
Mail list logo
