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
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, %, new
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
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
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
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
Details:
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?
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
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
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
#random_page_cost =
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 scale as
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:
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
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
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 ...
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() would
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
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 does this:
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 an
elein [EMAIL PROTECTED] writes:
From: Tom Lane tgl ( at ) sss ( dot ) pgh ( dot ) pa ( dot ) us
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
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 thinks
21 matches
Mail list logo
