Oh, sorry. This HP-UX 11.x. But you can get the same using shl_load (HP-UX
10.x) and pass the flag DYNAMIC_PATH provided the executable is linked with
+s. So it's still no showstopper.
If you do find that it is impossible on some older OS (HP-UX 11 arrived 4
years ago), then why not just disable
I believe any non empty password works.
cheers
andrew
Oliver Elphick wrote:
Following instructions on
http://developer.postgresql.org/docs/postgres/cvs.html does not
currently work:
$ cvs -d :pserver:[EMAIL PROTECTED]:/projects/cvsroot login
Logging in to
:pserver:[EMAIL
Gavin,
#1: I really think that we should have a way to set a default tablespace
for any database in a cluster. This property would be vitally important
for anyone wishing to use tablespaces to impose quotas. First, the
superuser would:
ALTER DATABASE db1 ALTER DEFAULT_TABLESPACE
Hi,
in linux you can change LD_LIBRARY_PATH in a running process, but it does not
help. The library-loader initializes himself at process-startup and changing
LD_LIBRARY_PATH do not change the actual path, the process is using for
dlopen.
Tommi Mäkitalo
Am Dienstag, 8. Juni 2004 19:14
When grilled further on (29 Feb 2004 08:46:36 -0800),
[EMAIL PROTECTED] (Hammer) confessed:
Quick one:
Anyone know how to use Putty to open a connection up under SSH which
will allow pgAdmin III to connect to a postgresql database ie. Only
access to server postgresql is on is via ssh.
Per a brief conversation with Tom, I've created a patch for adding support for
'week' within the date_trunc function.
Within the patch I added a couple of test cases and associated target output,
and changed the documentation to add 'week' appropriately.
Comments? Should I of bypassed this
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
(warning: rehashing of issues ahead)
Sometimes when I talk to technical people about using PostgreSQL,
I get a strong reaction along the lines of it's ugly, complex, and
hard to set up. While we have gotten better than we used to be,
some of
Tommi Maekitalo [EMAIL PROTECTED] wrote:
Hi,
in linux you can change LD_LIBRARY_PATH in a running process, but it does
not
help. The library-loader initializes himself at process-startup and
changing
LD_LIBRARY_PATH do not change the actual path, the process is using for
dlopen.
That's bad.
Thomas Hallgren wrote:
Isn't the fact that dynamic_library_path can
be changed at any time by a user a serious security flaw?
It's not a user. Only the superuser can change it.
cheers
andrew
---(end of broadcast)---
TIP 2: you can get off all
Why is this wrong ?:
DROP SCHEMA test CASCADE ;
CREATE SCHEMA test;
CREATE TABLE test.parent (
id serial PRIMARY KEY,
opis text
);
CREATE TABLE test.child_data (
id serial PRIMARY KEY,
id_parent int ,
podaci text,
FOREIGN KEY (id_parent)
[EMAIL PROTECTED] wrote:
The best phrasing would be the accumulating overhead of deletes and
updates.
Yes.
Are you using 7.3?
I am asking because in 7.3 high update / delete tables could suffer
(index and toast) bloat that was untamable via (lazy) VACUUM and FSM.
I believe this is
And only the super user can use directory components in a module name?
regards,
Thomas Hallgren
Andrew Dunstan [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
Thomas Hallgren wrote:
Isn't the fact that dynamic_library_path can
be changed at any time by a user a serious security
Tom Lane wrote:
Christopher Kings-Lynne [EMAIL PROTECTED] writes:
Yep, Tom fixed it good.
Was this another of those darn regurgitated-from-February messages?
I'm about ready to go out and acquire missile targeting coordinates
for pcbuddy.com ...
No, it was me cleaning out my old email.
I am wondering why thread_test.c is checking for mktemp()? That function
is nowhere used in the libpq.
Also, I would suggest that we allow to build the libpq with thread
specific compiler options, even if it is not entirely thread safe. It
would require that a really multithreaded application
We discussed this and thought that it would end up duplicating stuff
already in the docs, and removing the comments means that you have no
way to know which are being set to non-default values. Both seem to be
a loss.
Are people saying the Apache config files are easier to use? I actually
find
Jan Wieck wrote:
I am wondering why thread_test.c is checking for mktemp()? That function
is nowhere used in the libpq.
Uh, it isn't checking for mktemp, it is using it, and it is using it
because someone didn't like hard-coded paths I was using in the past.
Is there something wrong with
I have a LOT of opinions about postgresql.conf, and frankly, I think more
comments are not where the problems lie.
If you *really* want to make configuring postgresql easier,
postgresql.conf HAS to live outside the data directory and specify where
everything is. postgresql.conf should do exactly
Thomas Hallgren [EMAIL PROTECTED] writes:
And only the super user can use directory components in a module name?
Only superusers can create C functions in the first place, so quibbling
about what paths they can use doesn't seem that useful ...
regards, tom lane
Dear Gurus,
I tried to shuffle through the archives but was lost in the technical
details. Please feel free to tell me a search keyword suitable for my case
if there's any.
QUESTION1: is this error _always_ harmless (other than transaction
rollback)?
QUESTION2: is this reported exactly like
I agree. I wasn't aware of that restriction.
regards,
Thomas Hallgren
- Original Message -
From: Tom Lane [EMAIL PROTECTED]
To: Thomas Hallgren [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Wednesday, June 09, 2004 15:56
Subject: Re: [HACKERS] Question regarding dynamic_library_path
[EMAIL PROTECTED] wrote:
I have a LOT of opinions about postgresql.conf, and frankly, I think more
comments are not where the problems lie.
If you *really* want to make configuring postgresql easier,
postgresql.conf HAS to live outside the data directory and specify where
everything is.
Bruce Momjian [EMAIL PROTECTED] writes:
One idea that has been floated around is to pull the docs automatically
from SGML and put them in postgresql.conf.
In theory, postgresql.conf.sample could be a generated file: pull the
docs from SGML and the default values from the GUC tables. However
Darko Prenosil [EMAIL PROTECTED] writes:
CREATE RULE child_ins AS ON INSERT TO test.child
DO INSTEAD SELECT test.testfi(NEW);
INSERT INTO test.child(id,id_data,opis,podaci) VALUES (1,1,'Opis','podaci');
(-403)ERROR: cannot handle whole-row reference
It works in CVS tip ;-). No
[EMAIL PROTECTED] writes:
This is *NOT* a perfect or elegant solution. There is, however, an
important problem. How do you maintain a value that is visable to the
database, but does not incure the cost of a huge number of updates or a
full table scan? I'm talking about systems that need to
On Wed, Jun 09, 2004 at 07:53:19PM +0530, Shridhar Daithankar wrote:
Well, the statement 'postgresql.conf outside data directory' isn't going to
win I think.
One day there won't be any data directory because the data will be
on raw partitions. Then you will _have_ to have the configuration
=?iso-8859-2?B?U1rbQ1MgR+Fib3I=?= [EMAIL PROTECTED] writes:
ERROR: simple_heap_update: tuple concurrently updatedog.
LOG: statement: INSERT INTO pakolas_cikktetel
(cikk, minoseg, helyrol, mennyi, pakolas, sorszam, helyre) VALUES
(102165, 1, 1488, '25', 68615, 1, 1338)
Hmm.
On 6/9/2004 9:36 AM, Bruce Momjian wrote:
Also, I would suggest that we allow to build the libpq with thread
specific compiler options, even if it is not entirely thread safe. It
would require that a really multithreaded application has to have
mutexes around certain operations, but being
Jan Wieck wrote:
On 6/9/2004 9:36 AM, Bruce Momjian wrote:
Jan Wieck wrote:
I am wondering why thread_test.c is checking for mktemp()? That function
is nowhere used in the libpq.
Uh, it isn't checking for mktemp, it is using it, and it is using it
because someone didn't like
Grega Bremec [EMAIL PROTECTED] writes:
Collate order for those databases, however, needs to be different.
If you need multiple LC_COLLATE settings then you have to run multiple
postmasters. There is no other solution today, nor likely to be one in
the near future.
Also, running several
Hello, List,
I recently stumbled across a problem that I can't really get across.
We have a database cluster (PG 7.4.2) that was initialized as follows:
$ pg_controldata /data/dir
pg_control version number:72
Catalog version number: 200310211
Database
On Wed, Jun 09, 2004 at 12:33:03PM +0200, Grega Bremec wrote:
Collate order for those databases, however, needs to be different. Obviously,
[...]
Is it possible to do either of these things that could solve this problem
adequately:
- somehow manage to make one postmaster run on top
Greg Sabino Mullane wrote:
(warning: rehashing of issues ahead)
[snipped: suggestion to have much more documentation in sample postgresql.conf]
Wasn't RedHat working on a configuration utility for Postgres? That
seems to me like a much more productive way to go.
cheers
andrew
On 6/9/2004 9:36 AM, Bruce Momjian wrote:
Jan Wieck wrote:
I am wondering why thread_test.c is checking for mktemp()? That function
is nowhere used in the libpq.
Uh, it isn't checking for mktemp, it is using it, and it is using it
because someone didn't like hard-coded paths I was using in the
I love PG, I've been using it since version 6x, and it has gotten
fantastic over the years, and in many cases, I would choose it over
Oracle, but for systems that need frequent updates, I have a lot of
concerns.
...that's the price you pay for concurrency man...
I think that's a cop-out.
I love PG, I've been using it since version 6x, and it has gotten
fantastic over the years, and in many cases, I would choose it over
Oracle, but for systems that need frequent updates, I have a lot of
concerns.
...that's the price you pay for concurrency man...
Chris
I got:
gcc -O2 -fno-strict-aliasing -g -Wall -Wmissing-prototypes -Wmissing-declarations
-I/home/alvherre/CVS/pgsql/source/13commitOpt/src/interfaces/libpq
-I../../../src/include -I/home/alvherre/CVS/pgsql/source/13commitOpt/src/include
-D_GNU_SOURCE -DFRONTEND -c -o pg_dumpall.o
On 6/9/2004 11:45 AM, Bruce Momjian wrote:
Jan Wieck wrote:
The problem is that if your thread-safety tests fail, there is no way to
build libpq with -pthread and -DREENTRANT or whatever is required on
that platform. On Solaris this results in errno being defined as
extern int errno;
as
Tom Lane [EMAIL PROTECTED] writes:
What I would like to do about this is define INSERT to a subscripted
column name as working the same way that an assignment to a element or
slice of a zero-dimension array presently does --- that is, you get an
actual array back and not a NULL. It would
On 6/9/2004 11:16 AM, Bruce Momjian wrote:
Jan Wieck wrote:
On 6/9/2004 9:36 AM, Bruce Momjian wrote:
Jan Wieck wrote:
I am wondering why thread_test.c is checking for mktemp()? That function
is nowhere used in the libpq.
Uh, it isn't checking for mktemp, it is using it, and it is using it
Honza Pazdziora wrote:
On Wed, Jun 09, 2004 at 07:53:19PM +0530, Shridhar Daithankar wrote:
Well, the statement 'postgresql.conf outside data directory' isn't going to
win I think.
One day there won't be any data directory because the data will be
on raw partitions. Then you will _have_ to have
Dennis Bjorklund [EMAIL PROTECTED] writes:
On Thu, 26 Feb 2004, Gavin Sherry wrote:
Comments? Questions? Suggestions?
Is that plan that in the future one can split a single table into
different table spaces? Like storing all rows with year 1999 in one
tablespace and the rest in
=?iso-8859-2?B?U1rbQ1MgR+Fib3I=?= [EMAIL PROTECTED] writes:
Q1. So is this everything that can be said -- NOTIFY calls
simple_heap_update that is concurrently updated by a different transaction?
If that's what it is, then there's still a question: why? The notify
code has enough locking that
On Wed, Jun 09, 2004 at 10:49:20PM +0800, Christopher Kings-Lynne wrote:
I love PG, I've been using it since version 6x, and it has gotten
fantastic over the years, and in many cases, I would choose it over
Oracle, but for systems that need frequent updates, I have a lot of
concerns.
Added time.h to pg_dumpall.c. Thanks.
---
Alvaro Herrera wrote:
I got:
gcc -O2 -fno-strict-aliasing -g -Wall -Wmissing-prototypes -Wmissing-declarations
Jan Wieck wrote:
On 6/9/2004 11:45 AM, Bruce Momjian wrote:
Jan Wieck wrote:
The problem is that if your thread-safety tests fail, there is no way to
build libpq with -pthread and -DREENTRANT or whatever is required on
that platform. On Solaris this results in errno being defined as
Well, looks like you are missing getpwuid_r():
Your system uses getpwuid() which is not thread-safe. **
and we don't have any workaround for this.
---
Jan Wieck wrote:
On 6/9/2004 11:16 AM, Bruce Momjian wrote:
On 6/8/2004 11:46 AM, [EMAIL PROTECTED] wrote:
This strikes me as a complete nonstarter.
Tom, I have to chuckle here. You HATE every suggestion I ever make. I
can't think of one thing I've suggested over the years that was ever met
with enthusiasm. Never change. :-)
I happen to agree with Tom on
On Wed, Jun 09, 2004 at 10:49:20PM +0800, Christopher Kings-Lynne wrote:
I love PG, I've been using it since version 6x, and it has gotten
fantastic over the years, and in many cases, I would choose it over
Oracle, but for systems that need frequent updates, I have a lot of
concerns.
On 6/9/2004 1:04 PM, Bruce Momjian wrote:
What we really need is a way to do the uid-username mapping in a
thread-safe way. Could we check the environment for $USER or $LOGNAME?
Could we require them to be set for thread builds on OS's without
getpwuid_r and in cases where the username is not
Jan Wieck wrote:
On 6/9/2004 1:04 PM, Bruce Momjian wrote:
What we really need is a way to do the uid-username mapping in a
thread-safe way. Could we check the environment for $USER or $LOGNAME?
Could we require them to be set for thread builds on OS's without
getpwuid_r and in cases
On Wed, Jun 09, 2004 at 13:41:27 -0400,
[EMAIL PROTECTED] wrote:
Sigh, because vacuums take away from performance. Imagine a table that has
to be updated on the order of a few thousand times a minute. Think about
the drop in performance during the vacuum.
On a one row table, vacuum is
Also he said that the problem was solved with enough lazy VACUUM
scheduling. I don't understand why he doesn't want to use that
solution.
Because even lazy VACUUM is horrendous to performance but as I said in
a further post this has been pretty much fixed by (Jan I believe) in 7.5.
Sincerely,
On 6/9/2004 1:44 PM, Bruce Momjian wrote:
Jan Wieck wrote:
On 6/9/2004 1:04 PM, Bruce Momjian wrote:
What we really need is a way to do the uid-username mapping in a
thread-safe way. Could we check the environment for $USER or $LOGNAME?
Could we require them to be set for thread builds on OS's
Sigh, because vacuums take away from performance.
This is a known issue that has been pretty much resolved for 7.5. Vacuum
in 7.5 does not take even close to as much IO resources.
Imagine a table that has
to be updated on the order of a few thousand times a minute. Think about
the drop in
On Wed, 2004-06-09 at 11:41, [EMAIL PROTECTED] wrote:
On Wed, Jun 09, 2004 at 10:49:20PM +0800, Christopher Kings-Lynne wrote:
I love PG, I've been using it since version 6x, and it has gotten
fantastic over the years, and in many cases, I would choose it over
Oracle, but for systems that
Jan Wieck wrote:
On 6/9/2004 1:44 PM, Bruce Momjian wrote:
Jan Wieck wrote:
On 6/9/2004 1:04 PM, Bruce Momjian wrote:
What we really need is a way to do the uid-username mapping in a
thread-safe way. Could we check the environment for $USER or $LOGNAME?
Could we require them to
On Wed, Jun 09, 2004 at 01:41:27PM -0400, [EMAIL PROTECTED] wrote:
On Wed, Jun 09, 2004 at 10:49:20PM +0800, Christopher Kings-Lynne wrote:
Also he said that the problem was solved with enough lazy VACUUM
scheduling. I don't understand why he doesn't want to use that
solution.
Sigh,
Greg Stark [EMAIL PROTECTED] writes:
What I'm curious about is where the original behaviour came from. Is
it just because insert with subscripts was never implemented? Or was
there a rationale for ignoring the subscripts?
It's been awhile, but I think that ignore the subscripts may have been
On 6/8/2004 11:46 AM, [EMAIL PROTECTED] wrote:
This strikes me as a complete nonstarter.
Tom, I have to chuckle here. You HATE every suggestion I ever make. I
can't think of one thing I've suggested over the years that was ever met
with enthusiasm. Never change. :-)
I happen to agree
On Sun, May 30, 2004 at 04:07:27AM -0700, Stephan Szabo wrote:
On Sat, 29 May 2004, Alvaro Herrera wrote:
Ah, this seems to work. I'll implement it and I'll let you know how it
goes.
Ugh... There's one further wrinkle I hadn't thought about, imagine the
following:
Ok Stephan, thank you
I've appended a quote from Ch 41 on the SPI; I'd like
to make sure I understand the implications of this. If
I've allocated resources inside my procedure (file
handles or what-not), how would I clean those up in
the case of a transaction abort? Could I Notify my
application that the transaction
On Fri, May 28, 2004 at 04:05:40PM -0400, Bruce Momjian wrote:
Bruce,
One interesting idea would be for COMMIT to affect the outer
transaction, and END not affect the outer transaction. Of course that
kills the logic that COMMIT and END are the same, but it is an
interesting idea, and
Dear Tom,
Thanks for your reply.
Thinking about it, yes; there are triggers that (may) do updates on this
table, and there is a master table pakolas (pakolas_cikktetel is a
detail of it) that I touch, and yes, it has a NOTIFY in AFTER trigger. (that
is one of the causes I touch that table ;) )
In the last exciting episode, [EMAIL PROTECTED] wrote:
[EMAIL PROTECTED] writes:
Anyway, I'm not quite getting the idea of caching sequence values. I
understand the performance benefits, but it seems problematic across
multiple backends, almost ensuring holes in the sequence of numbers.
The
On Tue, Jun 08, 2004 at 07:16:45PM -0400, [EMAIL PROTECTED] wrote:
[EMAIL PROTECTED] wrote:
I've been down several roads about how to handle data that has to change
on a very frequent and rapid manner.
Think about summary tables, WEB session tables, etc. As great as MVCC is
for the
On Wed, Jun 09, 2004 at 13:41:27 -0400,
[EMAIL PROTECTED] wrote:
Sigh, because vacuums take away from performance. Imagine a table that
has
to be updated on the order of a few thousand times a minute. Think about
the drop in performance during the vacuum.
On a one row table, vacuum is
Alvaro Herrera wrote:
One interesting idea would be for COMMIT to affect the outer
transaction, and END not affect the outer transaction. Of course that
kills the logic that COMMIT and END are the same, but it is an
interesting idea, and doesn't affect backward compatibility because
Is there a TODO here?
---
Tom Lane wrote:
Jeffrey W. Baker [EMAIL PROTECTED] writes:
... Introducing a new query execution step sounds
like a better/easier idea than was I was going to do, which was to
rework some of
On Wed, 9 Jun 2004, Alvaro Herrera wrote:
On Sun, May 30, 2004 at 04:07:27AM -0700, Stephan Szabo wrote:
On Sat, 29 May 2004, Alvaro Herrera wrote:
Ah, this seems to work. I'll implement it and I'll let you know how it
goes.
Ugh... There's one further wrinkle I hadn't thought
A new BETA tarball for the Slony-I replication system is now available
for download form the project homepage:
http://gborg.postgresql.org/project/slony1/projdisplay.php
Regards, the Slony-I project team
---(end of broadcast)---
TIP 7: don't
On Fri, Feb 27, 2004 at 10:48:57AM -0800, Josh Berkus wrote:
RT: I've been using RT for OSCON, and am not wowed by it.Of course, I
can say the same of BZ and GForge-Tracker. From my perspective, it's
neither better nor worse than the other solutions, although the interaction
with
In a recent discussion on IRC, some anomalies concerning CHECK
constraints were brought to light, in that in some cases they do not
guarantee that the data within the table satisfies them. For example
(against 7.4.1),
test=# create table foo (
test(# foo_stamp timestamptz not null,
test(#
Added to TODO:
* Order heap pointers on hash index pages by hash value and ctid
---
Zeugswetter Andreas SB SD wrote:
We could safely sort on the hash value, but I'm not sure how effective
that would be,
Bruce Momjian [EMAIL PROTECTED] writes:
Added to TODO:
* Order heap pointers on hash index pages by hash value and ctid
[blink] This seems to miss out on the actual point of the thread (hash
bucket size shouldn't be a disk page) in favor of an entirely
unsupported sub-suggestion.
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Added to TODO:
* Order heap pointers on hash index pages by hash value and ctid
[blink] This seems to miss out on the actual point of the thread (hash
bucket size shouldn't be a disk page) in favor of an entirely
unsupported
Looks good to me. The only issue I saw was that the default file name
mentioned in postgresql.conf doesn't match the actual default.
Is this ready to be added to the patch queue?
---
Andreas Pflug wrote:
Magnus Hagander
Are people OK with requiring PGUSER, $USER, $LOGNAME, or the username to
be supplied by the connection string in libpq on platforms that want
threads and don't have getpwuid_r() (Solaris, FreeBSD, etc.)?
If so, I can easily create a patch and apply it.
Bruce Momjian [EMAIL PROTECTED] writes:
Looks good to me. The only issue I saw was that the default file name
mentioned in postgresql.conf doesn't match the actual default.
I'm really not happy with the concept that the postmaster overrides
its stderr direction.
78 matches
Mail list logo
