Fabien COELHO wrote:
Dear hackers,
It seems to me that the current default setup for a new database which is
given to some user is not consistent (createdb -O calvin foo or
CREATE DATABASE foo WITH OWNER calvin).
Indeed, although the database belongs to the owner, the public schema
still
Claudio Natoli wrote:
Peter Eisentraut wrote:
Claudio Natoli wrote:
I'm yet to see a convincing argument for why we can't adopt the
binary-location/../share approach as submitted late March.
AFAICS, it was rejected on the basis that it was not platform
independent (no arguments
Claudio Natoli wrote:
I'm yet to see a convincing argument for why we can't adopt the
binary-location/../share approach as submitted late March. AFAICS,
it was rejected on the basis that it was not platform independent (no
arguments there) and that we could not rely on the .. approach.
The
Hi all,
I'm putting together a small package of macros and functions
to help deal with binary cursor results from libpq, but I've run into a
bit of a stumbling block with regard to array results,
for example:
ArrayType *arr;
uint64_t *lin;
...
res = PQexecParams(conn, select
The only hard facts that we can use are hardcoded/compiled-in
locations and explicit information passed via command-line
arguments or environment variables. None of this seems to be
useful for Windows installations. As far as I recall, the
Windows installation routines only ask you for
Peter Eisentraut wrote:
Claudio Natoli wrote:
Peter Eisentraut wrote:
Claudio Natoli wrote:
I'm yet to see a convincing argument for why we can't adopt the
binary-location/../share approach as submitted late March.
AFAICS, it was rejected on the basis that it was not platform
Hi guys,
I know this is off topic, but if there are any developers with
sourceforge accounts here, they might be interested in filling out this
query which came throught the phpPgAdmin lists. It seems legit :)
Chris
Original Message
Subject: [ppa-dev] FASD project: Online
At 02:54 PM 3/05/2004, Tom Lane wrote:
Please dig deeper.
I may have found the problem; all the hung processes show 'async_notify
waiting' in ps, and the ANALYZE eventually dies with 'tuple concurrently
updated'.
The routine 'ProcessIncomingNotify' in async.c does indeed try to lock
Further to this, ProcessIncomingNotify seems to hold the lock on the
listener relation until it's current transaction exits. If the ANALYZE was
not the source of the error, but was just another victim, does that mean it
might hold the lock for a very long time if the analyze is lengthy?
At
At 06:21 PM 3/05/2004, Philip Warner wrote:
'tuple concurrently updated'
The database logs show the same error in each case where a long delay has
occurred. And before anyone suggests it, we already have processes in place
to prevent to ANALYZEs running at the same time.
At 06:21 PM 3/05/2004, Philip Warner wrote:
'tuple concurrently updated'
I lied. The database DO NOT logs show the same error in each case where a
long delay has occurred. It happens sometimes; recent process logs do show
the 'async_notify waiting' status, however.
I'll try not to send any more
Dear committers, dear hackers,
Subject: Re: [COMMITTERS] pgsql-server/src backend/utils/adt/acl.c ...
Ergo, my recommendation is to revert this change altogether. Fabien
should figure out the high-level description of what he wants to know
Please find attached as somehow requested a
I put 36+ rows in a table , and now any select , update , analyze
... command fail.
the log shows ERROR: heapgettup: failed ReadBuffer,
but any INSERT sql command success.
the table schema is
row| type | modifiers
Philip Warner [EMAIL PROTECTED] writes:
I may have found the problem; all the hung processes show 'async_notify
waiting' in ps, and the ANALYZE eventually dies with 'tuple concurrently
updated'.
The routine 'ProcessIncomingNotify' in async.c does indeed try to lock
pg_listener (even if
At 07:33 PM 3/05/2004, Philip Warner wrote:
I'll try not to send any more emails until someone responds ;-)
I also noticed this in SIInsertDataEntry sinvaladt.c:
/*
* Try to prevent table overflow. When the table is 70% full send a
* WAKEN_CHILDREN request to the
At 11:04 PM 3/05/2004, Tom Lane wrote:
Hm. What seems likely to have happened is that the sinval message queue
got full.
I agree (our emails crossed).
That would have left all the idle backends trying to get exclusive lock
on pg_listener, and if the ANALYZE subsequently reached pg_listener, its
On Mon, May 03, 2004 at 02:14:18PM +1000, Gavin Sherry wrote:
It is implemented using shared memory. I got stuck when I considered the
situation where we rung out of shared memory. Some emails in the archive
suggested we just fire all listeners but I didn't like that.
Can this be kept in
Andrew Dunstan writes:
How about if we have a configuration flag --enable-relocation which would
require a fixed layout based on an indeterminate root. This would have the
following effects:
. if prefix did not contain 'postgres' or 'pgsql' then
'postgresql' would be appended.
. all *dir
Philip Warner [EMAIL PROTECTED] writes:
At 11:04 PM 3/05/2004, Tom Lane wrote:
How confident are you in those processes? I don't know of any other
mechanism for 'tuple concurrently updated' failures in ANALYZE than
concurrent analyze runs ...
Fairly. In this particular instance the error
Andrew Dunstan wrote:
Claudio Natoli said:
Peter Eisentraut wrote:
Claudio Natoli wrote:
I'm yet to see a convincing argument for why we can't adopt the
binary-location/../share approach as submitted late March. AFAICS,
it was rejected on the basis that it was not platform
I'm not sure how would one send to the other backends.
Maybe write another file on disk, one for each remote
backend? Surely this can be done somehow. I've heard that
on linux-2.6 they are implementing POSIX message queues
(not sure what those are anyway); maybe we can do that on
On Mon, 3 May 2004, Alvaro Herrera wrote:
On Mon, May 03, 2004 at 02:14:18PM +1000, Gavin Sherry wrote:
It is implemented using shared memory. I got stuck when I considered the
situation where we rung out of shared memory. Some emails in the archive
suggested we just fire all listeners
jihuang [EMAIL PROTECTED] writes:
I put 36+ rows in a table , and now any select , update , analyze
... command fail.
the log shows ERROR: heapgettup: failed ReadBuffer,
What Postgres version is this? AFAICS that error has been impossible
for quite some time ...
Vinay Jain wrote:
Hi
thanx and sorry that I asked such a simple question in postgres-hackers
list
but the complexity which i feel on that basis please allow me to
explain my problem further.
As i am working on sorting order , length and substring functions for
Hindi text(Indian
Bruce Momjian [EMAIL PROTECTED] writes:
Not sure how we can do this for Unix except perhaps probe PATH.
Huh? We have always determined the full path of the executable ---
see FindExec().
I guess what you are saying is we should have a configure-time option to
address configured directories via
Peter Eisentraut wrote:
Andrew Dunstan wrote:
Even if we don't do that can we *please* put in something that
detects the error, and tells the user what they will have to do to
fix it? Failing in a situation which we know we can detect and not
telling the user is intolerable, IMNSHO.
Can
Zeugswetter Andreas SB SD [EMAIL PROTECTED] writes:
* Is it really a good idea for database-wide ANALYZE to run as a single
transaction? Holding all those locks is a recipe for deadlocks, even
if they're as inoffensive as AccessShareLocks normally are.
Wasn't one idea behind that change also
I wrote:
2. As the ANALYZE proceeds, it issues sinval messages due to the updates
it's making in pg_statistic. This is normal.
Small correction: actually, backends only send sinval messages at
commit, so the ANALYZE will just be accumulating pending messages in its
private memory. Your
* Is it really a good idea for database-wide ANALYZE to run as a single
transaction? Holding all those locks is a recipe for deadlocks, even
if they're as inoffensive as AccessShareLocks normally are.
Wasn't one idea behind that change also to not make the planner create a plan
from mixed
At 01:30 AM 4/05/2004, Tom Lane wrote:
can only occur if other
transactions running parallel to the ANALYZE perform sufficient catalog
updating activity to fill the sinval message queue. And there must also
be at least one long-term-idle backend, so that the queue doesn't get
drained.
Sounds
sdv mailer wrote:
Instead, there's a big need to
create a new connection on
every query and with PostgreSQL needing to fork on
every incoming connection
can be quite slow.
Really? My general experience has beent that forking/connection setup
times are very good with PgSQL. Do not assume your
On Sat, May 01, 2004 at 10:16:56PM -, Greg Sabino Mullane wrote:
We could imagine that once we add tracking of plan dependencies,
detection of a change that invalidates a prepared statement's plan
would just cause the prepared statement to be marked as needs
recompilation. The next
Paul Ramsey [EMAIL PROTECTED] writes:
... So the operational benefit of adding the complexity of a
pre-fork system is not very high.
In particular, most of the connection startup overhead work cannot be
performed until we've identified which database to connect to (since
it largely consists of
Fabien COELHO wrote:
Dear Thomas,
* create the database with the new owner specified.
-- As a superuser in the newly created database
update pg_am set amowner = {userid}
update pg_class set relowner = {userid}
You don't want to update ownership of tables in system schemas.
AFAICS, any
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Not sure how we can do this for Unix except perhaps probe PATH.
Huh? We have always determined the full path of the executable ---
see FindExec().
Oh, OK. I forgot that.
I guess what you are saying is we should have a
Bruce Momjian [EMAIL PROTECTED] writes:
Tom Lane wrote:
I guess what you are saying is we should have a configure-time option to
address configured directories via relative paths from the executable's
directory, rather than absolute paths? Seems reasonable ...
Yep. In fact, why would we
At 02:05 AM 29/02/2004, Tom Lane wrote:
Your plpgsql.so may be CVS-tip, but your backend isn't... that function
was just added a few days ago.
I just got this error after upgrading to 7.4.2; I assume it may be because
an old library was still present in memory, but wanted to check.
Thomas Swan [EMAIL PROTECTED] writes:
Fabien COELHO wrote:
You don't want to update ownership of tables in system schemas.
AFAICS, any changes they make are localized to their database not the
whole database system.
A database owner who is not a superuser should *not* be able to fool with
Tom Lane wrote:
Thomas Swan [EMAIL PROTECTED] writes:
Fabien COELHO wrote:
You don't want to update ownership of tables in system schemas.
AFAICS, any changes they make are localized to their database not the
whole database system.
A database owner who is not a superuser
A database owner who is not a superuser should *not* be able to fool with
the built-in catalog entries.
Database owner != superuser, and I don't want us blurring the distinction...
Yes sure. I agree, especially if the owner is one of my students;-)
However, I feel that the owner should own
On Sat, May 01, 2004 at 10:16:56PM -, Greg Sabino Mullane wrote:
I am very uneasy about this. Statements should stay invalidated, else
the prepared statement may no longer even do what was originally
intended when it was first created.
I think Greg's concern is overblown, and would result
...
Without this the db owner cannot drop types that may have been copied
from the template.
Hmmm. I'm concerned about security, such as enabling the owner to load new
trusted code. You may be right, but I'm afraid it is delicate to decide
what owner fields should be changed. Owning a
Tom Lane wrote:
We'd also need to give some thought to pg_config output. I think I
would like to be able to see the relative path computed by configure
as well as the effective actual path ... maybe a switch to specify
which way to print it?
What use could printing the relative path possibly
Forking consumes a large amount of CPU when you have
many simultaneous connections and adds up to the
latency. Particularly MySQL users may think
PostgreSQL's connection time is much slower because
these users tend to perform relatively simple queries.
In my case, connection pooling and
Andrew Dunstan wrote:
However, the problem is that the first line will actually appear to
have succeeded, i.e. MSys's ln is lying to us ;-(
Then msys needs to be fixed. There is certainly a bunch of
autoconfiscated software that gets compiled on mingw/msys every day. I
would like to know
[ WRT/ automagically re-parsing prepared statement from source when
dependency
plan changes.]
If done, this would have the wonderful side-effect of being able to use
regular queries
in plpgsql procedures which must currently be done using the EXECUTE
form, such
as those that just need to
Tom Lane [EMAIL PROTECTED] writes:
Before jumping into doing that, though, I'd want to have some
discussions about the implications for the V3 protocol's notion of
prepared statements. The protocol spec does not say anything that
would suggest that prepared statements are lost on
Peter Eisentraut [EMAIL PROTECTED] writes:
Tom Lane wrote:
We'd also need to give some thought to pg_config output. I think I
would like to be able to see the relative path computed by configure
as well as the effective actual path ... maybe a switch to specify
which way to print it?
What
Fabien COELHO [EMAIL PROTECTED] writes:
However, I feel that the owner should own the public schema and maybe
some other stuff to be carefully selected, without bluring that important
distinction?
From a definitional standpoint I don't have a problem with that. From
an implementation
On Mon, May 03, 2004 at 03:18:37PM -0400, Greg Stark wrote:
Tom Lane [EMAIL PROTECTED] writes:
Before jumping into doing that, though, I'd want to have some
discussions about the implications for the V3 protocol's notion of
prepared statements. The protocol spec does not say anything
Tom Lane wrote:
What use could printing the relative path possibly have?
Debugging. If I can't see it, I *know* I'm going to wish I could.
Well, you can just look inside, it's not that big. Supporting extra
options might make the script twice as big and thus make it harder to
just look at
On Tue, May 04, 2004 at 01:22:53AM -, Greg Sabino Mullane wrote:
What about rolling prepares back if they are in a transaction, though?
They still have the ability to affect a transaction, despite being
partially outside of it:
[example ripped]
IMHO this is an oversight, not a design
On Mon, May 03, 2004 at 04:15:10PM -0400, Greg Stark wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
I don't see how this collides with the ideas presented so far. The JDBC
driver wants the same: they want to prepare some statements and be able
to use them later in the session. They
sdv mailer [EMAIL PROTECTED] writes:
Forking consumes a large amount of CPU when you have
many simultaneous connections and adds up to the
latency. Particularly MySQL users may think
PostgreSQL's connection time is much slower because
these users tend to perform relatively simple queries.
Alvaro Herrera [EMAIL PROTECTED] writes:
I don't see how this collides with the ideas presented so far. The JDBC
driver wants the same: they want to prepare some statements and be able
to use them later in the session. They don't want to be paying
attention to which prepares were committed
tested with autoconf 2.59.
Unfortunately, it does not. It does try to copy if a link
fails, unlike what we have now:
ln -s $ac_rel_source $ac_dest 2/dev/null ||
ln $srcdir/$ac_source $ac_dest 2/dev/null ||
cp -p $srcdir/$ac_source $ac_dest ||
We don't have the last line,
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
If we re-parse from source then we will detect any changes that make the
query visibly incorrect. I don't really see that the user can have any
beef if he continues to use a prepared statement whose source text would
have a valid but
Andrew Dunstan wrote:
Peter Eisentraut wrote:
Andrew Dunstan wrote:
Even if we don't do that can we *please* put in something that
detects the error, and tells the user what they will have to do to
fix it? Failing in a situation which we know we can detect and not
telling the user is
Peter Eisentraut wrote:
Andrew Dunstan wrote:
However, the problem is that the first line will actually appear to
have succeeded, i.e. MSys's ln is lying to us ;-(
Then msys needs to be fixed. There is certainly a bunch of
autoconfiscated software that gets compiled on mingw/msys every
Alvaro Herrera [EMAIL PROTECTED] writes:
Right. But note that Tom wants to distinguish between statements
created via PREPARE (which would rollback) from those created via a
Prepare message (which wouldn't).
Actually, no, I'd prefer not to make such a distinction; I'd be happy
with SQL-level
Hi.
I'm from Panama.
I don't speak english very well but I'm learning
english.
I Need help.
I installed postgresql 7.4 in my computer, I'm using
redhat 9.0 .
I installed pgadmin III but I can't to conecct to the
server.
The port 5432 is not open.
I have one computer. If possible to use
Andrew Dunstan wrote:
Marc G. Fournier wrote:
Personally, I think there are alot of large features that ppl have been
hard at getting complete in time for June 1st that we should stick to it,
else we're going to end up with 'yet another release' delayed in hopes
that the outstanding bugs in Win32
Hi!
Tim Conrad wrote:
I was researching an article I wrote about a comparison between
Postgres and MySQL recently (If you want, you can read the article
at http://www.devx.com/dbzone/Article/20743/). I noticed some clear
differences between the mysql.com website and the Postgres website.
Sorry,
I installed postgresql 7.4 in my computer, I'm using
redhat 9.0 .
I installed pgadmin III but I can't to conecct to the
server.
The port 5432 is not open.
You need to set tcpip_socket = true in your postgresql.conf.
Chris
---(end of broadcast)---
Bruce Momjian [EMAIL PROTECTED] writes:
What we really need is for these folks to start finalizing their patches
and get them submitted.
Eggzackle ... my point is that I see the win32 train leaving the station
pretty soon, and I don't see anyone else ready to get on board.
[EMAIL PROTECTED] (Jim C. Nasby) writes:
I would still argue that if any language should be installed by
default it should be plpgsql and not java. As I mentioned, everyone
using a database already knows SQL; not nearly as many know java.
A vital factor is indeed that pl/pgsql does not require
Hallo
1/
I have made one program in Access, now I need some tool who can make exe
file.
What is the easy but good tool for that purpose and where can I get it.
2/
Also I need (Copy protection) tool who can do returning leash between bayer
and me (taking his serial number form his hard disk,
I'm in the middle of reviewing (read whacking around) Rod Taylor's patch
for multiple operations in ALTER TABLE, so I'm afraid that no patch in
the same area is likely to apply cleanly after the dust settles :-(
OK, Bruce - just ignore the patch I sent in. I'll refactor it after Tom
commits.
Bruce wrote:
Does anyone know of an open source project that *has* successfully
displaced
a market of mature, established products WITHOUT a commercial entity
providing marketing, support direction?
Linux. It doesn't have a single company behind it, but several.
Uh, no. Linux HAD a
Alexey Borzov wrote:
I realize this. I also realize that having a nicely defined roadmap
would
give Postgres a hands up in this category.
A hands up in *what* category? In bragging?
In telling your boss, I think we should use Postgresql.
It's likely he's not stupid, and it's reasonable for him
Title: Message
Hi
All,
I posted this
subject on General discussion-list but got no takers. I'll restate my
query and be asbriefas I possible.
"What are the
issues/dangers involvedin putting an external process-execution call in
instance of main postgres-backend thread of execution?"
The
Bruce wrote:
Now, if you are asking about marketing, yea, we don't have much in that
area right now, and we need it. I think your point was that we need a
single controlling company to provide marketing because if there are
many, there is little incentive to market PostgreSQL because all
Hi!
Tim Conrad wrote:
My favourite part of it is:
MySQL uses traditional row-level locking. PostgreSQL uses something
called Multi Version Concurrency Control (MVCC) by default. MVCC is a
little different from row-level locking in that transactions on the
database are performed on a
Centuries ago, Nostradamus foresaw when [EMAIL PROTECTED] (Joshua D. Drake) would
write:
Personally, plpgSQL is only useful to those who are coming from
Oracle. People are more likely to be comfortable with plPython or
plPerl than plpgSQL.
I beg to differ.
In order to use pl/Python or
74 matches
Mail list logo
