Hi all:
Versions:
PostgreSQL 8.0.1
SunOS relayprod02 5.9 Generic_118558-19 sun4u sparc SUNW,Sun-Fire-V440
- Solaris 9 on Sparc processor.
We are running java app over PostgreSQL. Everything works fine but we
detected high semaphore usage during a heavy query process.
This is result of
Hello List,
I try to post this e-mail on this list, as nobody answers me on
pgsql-general :-(
I work with an IA-64 server with Red Hat Enterprise Linux 4 AS update 2
on which the Intel compiler icc 9.1.045 is available and I build
PostgreSQL 8.2 with this compiler.
To do that I generated RPM
Some more thought about that yielded what might or might not be a good
idea: why not just collapse all the members of a class group into one
opclass? In other words, not make a distinction between groups and
individual opclasses? So for example, int2_ops int4_ops and int8_ops
would all
Short version: is it optimal for vacuum to always populate
reltuples
with live rows + dead rows?
If we didn't do that, it would tend to encourage the use of
seqscans on
tables with lots of dead rows, which is probably a bad thing.
So then why does vacuum do that? ISTM that it makes
CREATE OPERATOR CLASS name USING index_method AS
{ [ DEFAULT ] FOR TYPE data_type [ STORAGE storage_type ] [
ALIAS name ]
| OPERATOR strategy_number operator_name [ (op_type,
op_type) ] [ RECHECK ]
| FUNCTION support_number funcname (argument_type [, ...])
} [, ... ]
plus a
Hi,
pg_restore faied by the following operations on Windows XP.
$ createdb test
$ pgbench -i -s 1000 test
$ pg_dump -Fc test out
$ createdb restore
$ pg_restore -d restore out
pg_restore: [custom archiver] error during file seek: Invalid argument
Win32 does not implement fseeko()
Hi everyone,
Do you know in which part of the file analyze.c, PostgreSQL decides to use or
not an index? I´m making a test and I can´t trace the moment that he makes the
choice.
Thks,
Felipe
On Wed, 2006-12-13 at 19:43 -0500, Tom Lane wrote:
Euler Taveira de Oliveira [EMAIL PROTECTED] writes:
Simon Riggs wrote:
Should this be reworked as an src/bin program? Or is the contrib module
the best form for this in 8.3?
Please submit it to -patches. IMHO it should stay in src/bin
On Wed, 2006-12-13 at 17:02 -0500, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
OK, I would propose to extend the guc-file.l to include sufficient code
to allow the parsing of the conf files to be identical between the
postgresql.conf and the recovery.conf (it isn't the same yet).
Simon Riggs wrote:
It would probably be far easier for long-term maintenance if you
just built an independent lexer, instead of trying to make
guc-file.l serve multiple masters.
Will do.
I'm actually not so sure that this is a good idea. The lexical
structure should be exactly the same,
On Thu, Dec 14, 2006 at 10:06:45AM -0300, Felipe Rondon Rocha wrote:
Hi everyone,
Do you know in which part of the file analyze.c, PostgreSQL decides
to use or not an index? I´m making a test and I can´t trace the
moment that he makes the choice.
It doesn't explicitly make the choice
On Wed, Dec 13, 2006 at 07:28:20PM -0500, Tom Lane wrote:
Some more thought about that yielded what might or might not be a good
idea: why not just collapse all the members of a class group into one
opclass? In other words, not make a distinction between groups and
individual opclasses? So
On Thu, 2006-12-14 at 13:52 +0100, Peter Eisentraut wrote:
Simon Riggs wrote:
It would probably be far easier for long-term maintenance if you
just built an independent lexer, instead of trying to make
guc-file.l serve multiple masters.
Will do.
I'm actually not so sure that this
Simon Riggs [EMAIL PROTECTED] writes:
On Thu, 2006-12-14 at 13:52 +0100, Peter Eisentraut wrote:
I'm actually not so sure that this is a good idea. The lexical
structure should be exactly the same, and some things like include
files might become useful as well, so why should all this be
Thanks for the reply at last nights cocoahead meeting in NYC I
asked and found a solution for libpq.a.
1. config and make on a ppc
2. config and make on intel
copy and rename the libpq.a from each system to a common directory
and run 'lipo' on them:
lipo libpqppc.a libpqintel.a
Zeugswetter Andreas ADI SD [EMAIL PROTECTED] writes:
I think it would be easier to understand if we do not merge the
opclasses for different types into one statement.
Agreed, huge CREATE OPERATOR CLASS commands would be no fun, which
is one reason for my recommendation to improve ALTER
Pedro Baldanta [EMAIL PROTECTED] writes:
PostgreSQL 8.0.1
SunOS relayprod02 5.9 Generic_118558-19 sun4u sparc SUNW,Sun-Fire-V440
- Solaris 9 on Sparc processor.
We are running java app over PostgreSQL. Everything works fine but we
detected high semaphore usage during a heavy query process.
Hi. Asaba-san.
From: Yoshiyuki Asaba
Win32 does not implement fseeko() and ftello(). So I think it limit to
handle a 2GB file. Is this a specification?
Yes, Magnus-san suggested the problem. It is present TODO. The entire
adjustment was still difficult though I had tried it.
Permissions on a trigger function seem not to be checked,
and I can execute a function for which I have no privileges.
I consider this a security leak - or am I missing something?
Here is a complete example:
As superuser, create a trigger function that selects from pg_authid
with SECURITY
Martijn van Oosterhout kleptog@svana.org writes:
I think it may be useful to maintain the distinction between groups and
classes for users, because at that level the whole concept is easier to
understand. Dropping and recreating operator classes is easier to
handle than playing strange tricks
Shane Ambler wrote:
# make distclean
# CFLAGS=-isysroot /Developer/SDKs/MacOSX10.4u.sdk -arch ppc -arch
i386 LDFLAGS=-Wl,-syslibroot,/Developer/SDKs/MacOSX10.4u.sdk -arch ppc
-arch i386 ./configure --with-openssl --prefix=/usr/local
# make all
After reading the Apple tech doc on this
Tom Lane [EMAIL PROTECTED] writes:
I'm not sure. The problem that I'm seeing is that currently, cross-type
comparisons go into the opclass associated with their left-hand argument
type. Therefore, if say you want to add tinyint to an opclass group,
you not only need to add an opclass for
Albe Laurenz [EMAIL PROTECTED] writes:
Permissions on a trigger function seem not to be checked,
and I can execute a function for which I have no privileges.
Only if it's a trigger function, but I agree this is not very good.
The question in my mind is what privilege to check and when.
I
Gregory Stark [EMAIL PROTECTED] writes:
Hm, would we still need all the cross-data-type btree operators?
Yes, I think so; remember all the pain we had when we didn't have
indexable cross-type operators and spent years looking for a non-broken
way of introducing casts to solve the problem. Those
Dear Tom,
Thanks for you advice.
Here's the diff for configure.in that works for me.
Best regards
---
*** configure.in.orig jeu déc 14 18:35:27 2006
--- configure.injeu déc 14 18:35:37 2006
***
*** 1122,1137
if test $with_ldap = yes ; then
_LIBS=$LIBS
if
Tom Lane wrote:
The question in my mind is what privilege to check and when.
By extrapolation of the SQL standard, I'd say we'd need to check the
EXECUTE privilege of the function at run time.
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
---(end of
Peter Eisentraut [EMAIL PROTECTED] writes:
Tom Lane wrote:
The question in my mind is what privilege to check and when.
By extrapolation of the SQL standard, I'd say we'd need to check the
EXECUTE privilege of the function at run time.
Certainly EXECUTE privilege is what to check, but whose
The opr_sanity test checks the following:
-- Considering only built-in procs (prolang = 12), look for multiple uses
-- of the same internal function (ie, matching prosrc fields). It's OK to
-- have several entries with different pronames for the same internal function,
-- but conflicts in the
Tom Lane wrote:
Peter Eisentraut [EMAIL PROTECTED] writes:
Tom Lane wrote:
The question in my mind is what privilege to check and when.
By extrapolation of the SQL standard, I'd say we'd need to check
the EXECUTE privilege of the function at run time.
Certainly EXECUTE privilege is
Peter Eisentraut [EMAIL PROTECTED] writes:
The opr_sanity test checks the following:
-- Considering only built-in procs (prolang = 12), look for multiple uses
-- of the same internal function (ie, matching prosrc fields). It's OK to
-- have several entries with different pronames for the same
Folks,
The Center for Internet Security (http://www.cisecurity.org/) will be
preparing a set of recommendations for securing PostgreSQL which will then
be distributed to the US Government, as well as being available to our
community. For the initial draft, I need some volunteer hackers who
Dave Page wrote:
Shane Ambler wrote:
# make distclean
# CFLAGS=-isysroot /Developer/SDKs/MacOSX10.4u.sdk -arch ppc -arch
i386 LDFLAGS=-Wl,-syslibroot,/Developer/SDKs/MacOSX10.4u.sdk -arch
ppc
-arch i386 ./configure --with-openssl --prefix=/usr/local
# make all
After reading the Apple tech
Peter,
PostgreSQL only allows a trigger action of call this function, so in
the SQL standard context that would mean we'd need to check the EXECUTE
privilege of the owner of the trigger. The trick is figuring out who
the owner is. If it's the owner of the table, then TRIGGER privilege
is
Josh Berkus josh@agliodbs.com writes:
... we'd need to check the EXECUTE
privilege of the owner of the trigger. The trick is figuring out who
the owner is. If it's the owner of the table, then TRIGGER privilege
is effectively total control over the owner of the table.
If that's the case,
ohp@pyrenet.fr writes:
Here's the diff for configure.in that works for me.
Applied, thanks.
regards, tom lane
---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
Martijn van Oosterhout kleptog@svana.org writes:
I think it may be useful to maintain the distinction between groups and
classes for users, because at that level the whole concept is easier to
understand. Dropping and recreating operator classes is easier to
handle than playing strange tricks
Hi.
I was doing the field test of Slony-I 1.2.2 release now.
However, I encounter the problem of timestamp.:-(
Was anyone recognizing this problem?
Ver 8.1.5
saito=# select 'Fri Dec 15 14:26:05.502000 2006 JST'::timestamp;
timestamp
-
2006-12-15 14:26:05.502
Ver
37 matches
Mail list logo
