Michael Paesold wrote:
Thomas Hallgren wrote:
I'm using a pre-compiled installation of PostgreSQL. All I want to do
is use pgxs to be able to compile PL/Java.
There is other stuff that seems strange to me. Why do you append
'postgresql' to the include directories further down in the file?
Thomas Hallgren wrote:
I'm using a pre-compiled installation of PostgreSQL. All I want to do is
use pgxs to be able to compile PL/Java.
There is other stuff that seems strange to me. Why do you append
'postgresql' to the include directories further down in the file? I had
to remove that in
On Thu, Sep 22, 2005 at 10:05:57PM -0400, Tom Lane wrote:
With respect to the original point, I'm pretty nervous about either
accepting or rejecting a performance-oriented patch on the strength
of a single test case. This report certainly doesn't favor the PCTFREE
patch, but it probably
Sorry, that conclusion was wrong. What happens is:
1. I change the prefix in Makefile.global to say,
C:/Progra~1/PostgreSQL/8.1-beta2 (this is the default for the installer).
2. I compile.
That triggers the append of 'postgresql' on all directories since my
install location *does not*
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Bruce Momjian
Sent: 22 September 2005 23:07
To: Thomas Hallgren
Cc: pgsql-hackers@postgresql.org
Subject: [HACKERS] pgxs and pginstaller
There is other stuff that seems strange to me. Why do
I have concerns about whether we are overallocating memory for use in
external sorts. (All code relating to this is in tuplesort.c)
When we begin a sort we allocate (work_mem | maintenance_work_mem) and
attempt to do the sort in memory. If the sort set is too big to fit in
memory we then write to
Dave Page wrote:
In the case of PostgreSQL itself, it's built in /usr/local/src/postgresql-8.x,
installed to /usr/local/pgsql and then packaged up from there.
Perhaps you should build it in the directory that the installer suggests
as default for the installation? That way, most of the
On Thu, 2005-09-22 at 14:37 -0500, Jim C. Nasby wrote:
On Thu, Sep 22, 2005 at 10:11:50AM +0100, Simon Riggs wrote:
On Wed, 2005-09-21 at 15:39 -0400, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
Is it possible that the Release Notes do not fully explain the
Constraint
-Original Message-
From: Thomas Hallgren [mailto:[EMAIL PROTECTED]
Sent: 23 September 2005 10:49
To: Dave Page
Cc: pgsql-hackers@postgresql.org
Subject: Re: pgxs and pginstaller
Dave Page wrote:
In the case of PostgreSQL itself, it's built in
How To Hack Or Steal Credit Card Information
HOW TO GAIN VALID CREDIT CARD NUMBERS
In August, 1999, Scientific American ( http://www.sciam.com/ ) has published an article entitled How to stealmillions in chump change which was about online credit card theft. The original article can still
Dave Page wrote:
-Original Message-
From: Thomas Hallgren [mailto:[EMAIL PROTECTED]
Sent: 23 September 2005 10:49
To: Dave Page
Cc: pgsql-hackers@postgresql.org
Subject: Re: pgxs and pginstaller
Dave Page wrote:
In the case of PostgreSQL itself, it's built in
-Original Message-
From: Thomas Hallgren [mailto:[EMAIL PROTECTED]
Sent: 23 September 2005 11:17
To: Dave Page
Cc: pgsql-hackers@postgresql.org
Subject: Re: pgxs and pginstaller
It's two things basically. One I think that the installer
team can fix,
the other is IMHO an
Hi, I seem to recall that in Oracle you load into specific partitions
without specifically naming them in insert statements (in other words you
insert into table, the engine redirects data to the corrisponding
partition), I quickly looked at postgresql partitioning and it seems to me
that you need
On Fri, 2005-09-23 at 12:30 +0200, Paolo Magnoli wrote:
It would be good to have an insert behaviour similar to Oracle by default.
OK, thanks.
Also I see that the original table is always scanned, partition exclusion
happens only on the derived tables, is this correct?
Yes, though if you
Hi,
I have a problem with PL/Java that, if it's going to have a good
solution, requires your help.
PL/Java runs a JVM. Since a JVM is multi threaded, PL/Java goes to
fairly extreme measures to ensure that only one thread at a time can
access the backend. So far, this have worked well but
Thomas Hallgren wrote:
Sorry, that conclusion was wrong. What happens is:
1. I change the prefix in Makefile.global to say,
C:/Progra~1/PostgreSQL/8.1-beta2 (this is the default for the installer).
2. I compile.
That triggers the append of 'postgresql' on all directories since my
install
Thomas Hallgren [EMAIL PROTECTED] writes:
There's another issue with the Makefile.global.in that I feel should be
addressed here. The file contains a lot of entries like:
ifeq $(findstring pgsql, $(pkgincludedir))
ifeq $(findstring postgres, $(pkgincludedir))
override pkgincludedir :=
Simon Riggs [EMAIL PROTECTED] writes:
If not, I would propose that when we move from qsort to tapesort mode we
free the larger work_mem setting (if one exists) and allocate only a
lower, though still optimal setting for the tapesort. That way the
memory can be freed for use by other users or
Dave Page dpage@vale-housing.co.uk writes:
My temporary patch for this was to remove all lines staring
with 'ifeq'
or 'endif' between line 66 and 102.
I agree with your earlier comment - this should definitely be fixed in
PostgreSQL, not pgInstaller.
It's not broken, and I've seen no
Thomas Hallgren [EMAIL PROTECTED] writes:
Someone loads a library that contains a method that spawns a new thread.
They already broke the backend when they did that. max_stack_depth is
just the tip of the iceberg.
regards, tom lane
---(end of
Michael Paesold [EMAIL PROTECTED] writes:
Bruce, others, could this comparision be made case-insensitive at least, so
that it at least finds PostgreSQL and does not append postgresql in that
case?
We could certainly add PostgreSQL to the set of checked-for strings,
but...
That would be the
Tom Lane wrote:
Dave Page dpage@vale-housing.co.uk writes:
My temporary patch for this was to remove all lines staring
with 'ifeq'
or 'endif' between line 66 and 102.
I agree with your earlier comment - this should definitely be fixed in
PostgreSQL, not pgInstaller.
Tom Lane wrote:
Thomas Hallgren [EMAIL PROTECTED] writes:
Someone loads a library that contains a method that spawns a new thread.
They already broke the backend when they did that. max_stack_depth is
just the tip of the iceberg.
I knew I'd get a response like that from you :-)
-Original Message-
From: Tom Lane [mailto:[EMAIL PROTECTED]
Sent: 23 September 2005 15:16
To: Dave Page
Cc: Thomas Hallgren; pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] pgxs and pginstaller
Dave Page dpage@vale-housing.co.uk writes:
My temporary patch for this was
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Tom Lane
Sent: 23 September 2005 15:24
To: Michael Paesold
Cc: Thomas Hallgren; pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] What has happened to pgxs?
Michael Paesold [EMAIL PROTECTED]
Dave Page dpage@vale-housing.co.uk writes:
It does? Dave just told us that the standard installer
package is built to install into /usr/local/pgsql.
No, I said it's built into the installer from /usr/local/pgsql (the path
in the msys dev environment). It actually installs into C:\Program
-Original Message-
From: Tom Lane [mailto:[EMAIL PROTECTED]
Sent: 23 September 2005 15:48
To: Dave Page
Cc: Michael Paesold; Thomas Hallgren; pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] What has happened to pgxs?
Dave Page dpage@vale-housing.co.uk writes:
It does?
On Fri, 2005-09-23 at 10:09 -0400, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
If not, I would propose that when we move from qsort to tapesort mode we
free the larger work_mem setting (if one exists) and allocate only a
lower, though still optimal setting for the tapesort. That
Simon Riggs [EMAIL PROTECTED] writes:
Since we know the predicted size of the sort set prior to starting the
sort node, could we not use that information to allocate memory
appropriately? i.e. if sort size is predicted to be more than twice the
size of work_mem, then just move straight to the
Paolo Magnoli wrote:
Hi, I seem to recall that in Oracle you load into specific partitions
without specifically naming them in insert statements (in other words you
insert into table, the engine redirects data to the corrisponding
partition),
This is correct
--
On most platforms it's quite unlikely that any memory would
actually get
released back to the OS before transaction end, because the memory
blocks belonging to the tuplesort context will be intermixed with
blocks
belonging to other contexts. So I think this is pretty pointless.
(If you
System: Windows XP Pro SP2
Running Postgres 8.0.3 for several months with the embedded PgAdmin3
1.2.1 on the same machine with no problems. Postgres is configured to
start automatically as a service. I installed the PgAdmin3 1.2.2 which
requested a Windows reboot. I rebooted without stopping
Tom Lane wrote:
Bruce Momjian pgman@candle.pha.pa.us writes:
Yea, we could do that, but does it make sense to downgrade the
connection message, especially since the connection authorized message
doesn't contain the hostname. We would have to add the host name to the
connection authorized
Tom Lane wrote:
Tony Caduto [EMAIL PROTECTED] writes:
I just noticed that pronargs in pg_proc does not show the full arg
count, seems only to show count of IN args.
shouldn't this show the full arg count including in/out/inout?
There was some discussion of that just a day or so ago; so
Bruce Momjian pgman@candle.pha.pa.us writes:
Tom Lane wrote:
Tony Caduto [EMAIL PROTECTED] writes:
I just noticed that pronargs in pg_proc does not show the full arg
count, seems only to show count of IN args.
shouldn't this show the full arg count including in/out/inout?
There was some
This patch implements the ability for large objects to be larger than 2GB.
I believe the limit to now be about 2TB, based on the fact that the large
object page size is 2048 bytes, and the page number is still 32 bits.
There are a few things about this patch which probably require tweaking or
at
On Fri, Sep 23, 2005 at 06:39:35PM +0200, Pailloncy Jean-Gerard wrote:
On most platforms it's quite unlikely that any memory would actually
get released back to the OS before transaction end, because the
memory blocks belonging to the tuplesort context will be intermixed
with blocks belonging
Seems this item will have to remain for 8.2. I have added this to TODO:
o Display IN, INOUT, and OUT parameters in \df+
It probably requires psql to output newlines in the proper
column, which is already on the TODO list.
Tom Lane wrote:
Michael Fuhr [EMAIL PROTECTED] writes:
Regarding the removal of ALTER INDEX OWNER commands from pg_dump,
indexes are now restored with the wrong ownership if the user doing
the restore is different than the user who owned the original index
pg_dump is not the source of
Yep, testing confirms this is fixed. Thanks for the report.
---
Michael Fuhr wrote:
Regarding the removal of ALTER INDEX OWNER commands from pg_dump,
indexes are now restored with the wrong ownership if the user doing
Hi,
I'm not a member of this list (yet), so please
CC me on responses and
discussion.
The patch below seems to be completion of work already
started, because the boolean remoteTrFlag was already defined, and all
I had to add was its setting and two references.
I hope someone will find it
From: Tom Lane [EMAIL PROTECTED]
Sent: Sep 23, 2005 2:15 PM
Subject: Re: [PERFORM] Releasing memory during External sorting?
Mark Lewis [EMAIL PROTECTED] writes:
operations != passes. If you were clever, you could probably write a
modified bubble-sort algorithm that only made 2 passes. A
From: Simon Riggs [EMAIL PROTECTED]
Sent: Sep 23, 2005 5:37 AM
Subject: [PERFORM] Releasing memory during External sorting?
I have concerns about whether we are overallocating memory for use in
external sorts. (All code relating to this is in tuplesort.c)
A decent external sorting algorithm, say
Yep. Also, bear in mind that the lg(n!)= ~ nlgn - n lower bound on
the number of comparisions:
a= says nothing about the amount of data movement used.
b= only holds for generic comparison based sorting algorithms.
As Knuth says (vol 3, p180), Distribution Counting sorts without
ever comparing
operations != passes. If you were clever, you could probably write a
modified bubble-sort algorithm that only made 2 passes. A pass is a
disk scan, operations are then performed (hopefully in memory) on what
you read from the disk. So there's no theoretical log N lower-bound on
the number of
For the subfiles, load the top element of each subfile into a priority
queue. Extract the min element and write it to disk. If the next value
is the same, then the queue does not need to be adjusted. If the next
value in the subfile changes, then adjust it.
Then, when the lowest element in the
Jonathan Beit-Aharon [EMAIL PROTECTED] writes:
nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp; if (!conn)br
nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;
DBLINK_CONN_NOT_AVAIL;br
+br
+nbsp;nbsp;nbsp;nbsp;nbsp;nbsp; if (rcon)br
I see a lot of ALTER ROLE items not documented:
SYSID
IN ROLE
ROLE/USER
ADMIN
Is anyone working on documenting these? I see these flags as used by
and documented in CREATE ROLE too. Should they be disabled for ALTER
ROLE?
Tom Lane wrote:
Jonathan Beit-Aharon [EMAIL PROTECTED] writes:
nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp; if (!conn)br
nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;
DBLINK_CONN_NOT_AVAIL;br
Could we see this in a less broken format?
Here is the patch in text
Jeremy Drake [EMAIL PROTECTED] writes:
2) The lo_*64, in order to be convenient from the client end, have
functions added to libpq as the existing lo_* functions. The client side
of libpq did not previously know anything about int64 or how to
send/receive them. I added an include of
Added to TODO:
* Simplify dropping roles that have objects in several databases
---
Alvaro Herrera wrote:
On Fri, Aug 12, 2005 at 09:53:59PM -0400, Bruce Momjian wrote:
Can I have a TODO item for this?
On Fri, Sep 23, 2005 at 04:45:02PM -0400, Bruce Momjian wrote:
Tom Lane wrote:
Michael Fuhr [EMAIL PROTECTED] writes:
Regarding the removal of ALTER INDEX OWNER commands from pg_dump,
indexes are now restored with the wrong ownership if the user doing
the restore is different than the
Bruce Momjian pgman@candle.pha.pa.us writes:
I see a lot of ALTER ROLE items not documented:
SYSID
IN ROLE
ROLE/USER
ADMIN
Is anyone working on documenting these?
No, because they're not actually supported. The grammar happens to
accept them because we use the
OK, I have added comments to gram.y to document what is happening.
ALTER ROLE ... ROLE is supported for ALTER GROUP. The others like IN
ROL are supported by CREATE, but when used by ALTER throw an error
printing their internal names, so it is kind of cryptic. Not sure what
we should do to
On Fri, Sep 23, 2005 at 05:40:09PM -0400, Tom Lane wrote:
Jeremy Drake [EMAIL PROTECTED] writes:
The real problem here is that int64 isn't a well-defined portable
datatype, and so it's going to be very hard to export these
functions in a way that won't break on different platforms,
Thomas Hallgren wrote:
PL/Java runs a JVM. Since a JVM is multi threaded, PL/Java goes to
fairly extreme measures to ensure that only one thread at a time can
access the backend. So far, this have worked well but there is one small
problem. [...]
I assume this means you have a single lock
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Lee,
Patricia S.
Sent: 23 September 2005 17:46
To: pgsql-hackers@postgresql.org; [EMAIL PROTECTED]
Subject: [HACKERS] PgAdmin3 1.2.2 Install on Win32 Disrupts Pg Service
System: Windows XP Pro
Jeremy Drake [EMAIL PROTECTED] writes:
On Fri, 23 Sep 2005, Tom Lane wrote:
Unfortunately that's completely unacceptable from a namespace-pollution
point of view.
I don't quite understand.
postgresql-fe.h defines a ton of stuff that has no business being
visible to libpq's client
I sent this from the wrong address last time so it did not go to the list,
I apologize to anyone who may be getting it again...
On Fri, 23 Sep 2005, Tom Lane wrote:
Jeremy Drake [EMAIL PROTECTED] writes:
2) The lo_*64, in order to be convenient from the client end, have
functions added to
Calculating Optimal memory for disk based sort is based only on minimizing IO.
A previous post stated we can merge as many subfiles as we want in a single pass,
this is not accurate, as we want to eliminate disk seeks also in the merge phase,
also the merging should be done by reading blocks of
On Fri, 23 Sep 2005, Tom Lane wrote:
postgresql-fe.h defines a ton of stuff that has no business being
visible to libpq's client applications. It's designed to be used by
our *own* client-side code (psql and the like), but we have not made
any attempt to keep it from defining stuff that
Ron Peacetree [EMAIL PROTECTED] writes:
2= No optimal external sorting algorithm should use more than 2 passes.
3= Optimal external sorting algorithms should use 1 pass if at all possible.
A comparison-based sort must use at least N log N operations, so it
would appear to me that if you haven't
Mark Lewis [EMAIL PROTECTED] writes:
operations != passes. If you were clever, you could probably write a
modified bubble-sort algorithm that only made 2 passes. A pass is a
disk scan, operations are then performed (hopefully in memory) on what
you read from the disk. So there's no
The cited book also explains how to use a callback function to perform
arbitrary radix sorts (you simply need a method that returns the
[bucketsize] most significant bits for a given data type, for the length
of the key).
So you can sort fairly arbitrary data in linear time (of course if the
key
64 matches
Mail list logo
