Yes it is possible for both to be on the same pc. Please send mail to
the general or novice list if you need more help.
On Mon, 2004-05-03 at 11:05, olivia jurado wrote:
> Hi.
>
> I'm from Panama.
>
> I don't speak english very well but I'm learning
> english.
>
> I Need help.
>
> I installe
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 p
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 sna
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
Title: Message
Hi
All,
I posted this
subject on General discussion-list but got no takers. I'll restate my
query and be as brief as I possible.
"What are the
issues/dangers involved in putting an external process-execution call in
instance of main postgres-backend thread of execution?"
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 hi
Scott Marlowe wrote:
> While Apache is and has been wildly popular for bulk hosing and domain
> parking, for serious commercial use, Netscape's enterprise server, now Sun
> One, has long been a leader in commercial web sites.
Netscrape/SunONE may have been a leader in some sub-market, but this m
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
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.
Chr
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, mother
[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 req
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.
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)---
T
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, cou
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.
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 se
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-le
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.
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 da
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 queri
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 intolerable
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 comm
> 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 l
-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 incom
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
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
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
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 s
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 i
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 trans
[ 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 manipu
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 w
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 persistent
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 possi
> ...
> 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 datab
> 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
> 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 o
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 shou
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 fo
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.
--
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 wo
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 con
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 ch
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
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". T
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 Oracl
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 quite
> * 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
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 obser
"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 c
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 you
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 v
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 Langu
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 ...
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 liste
> 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
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
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 t
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.
> . al
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 ba
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
s
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 postmast
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
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 independent
>> > (no
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
---+--
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 p
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
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.
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 02:
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
pg_listener
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.
> update pg_conversion set conow
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 surv
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
> 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
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 '{1,2,3}'::bigint
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 there) and that we c
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 (n
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
>sti
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.
79 matches
Mail list logo