On Fri, Jun 16, 2006 at 12:01:53AM -0400, Bruce Momjian wrote:
OK, new text:
The quotemagic block/ required in all PostgreSQL-supported libraries
is checked to guarantee compatibility. For this reason, non-PostgreSQL
libraries cannot be loaded in this way.
Heh. guarantee?
HiThe O/S is Win 2K Server SP4 and PG version is 8.0. Here's the log file from the latest incident:2006-06-16 09:40:01 LOG: 0: server process (PID 4744) was terminated by signal 125 2006-06-16 09:40:01 LOCATION: LogChildExit, postmaster.c:2335 2006-06-16 09:40:01 LOG: 0:
I did have dbt2 pretty close to functional on FreeBSD a year ago but
it's probably gone back into linuxisms since then.
:(
I won't have the chance to work on this further for another 2 months,
but if you have patches I could see about picking up on them when I
get back.
Everything has
Martijn van Oosterhout wrote:
-- Start of PGP signed section.
On Fri, Jun 16, 2006 at 12:01:53AM -0400, Bruce Momjian wrote:
OK, new text:
The quotemagic block/ required in all PostgreSQL-supported libraries
is checked to guarantee compatibility. For this reason, non-PostgreSQL
On Wed, 2006-06-14 at 20:07 -0400, Tom Lane wrote:
Josh Berkus josh@agliodbs.com writes:
I just noticed (the hard way) that in 8.2CVS, the PG_MODULE_MAGIC header is
now *required* for all loadable modules. This includes non-pg modules,
such as Solaris' libumem (performance improvement
On Fri, Jun 16, 2006 at 02:51:41PM +0100, Simon Riggs wrote:
On Wed, 2006-06-14 at 20:07 -0400, Tom Lane wrote:
Josh Berkus josh@agliodbs.com writes:
I just noticed (the hard way) that in 8.2CVS, the PG_MODULE_MAGIC header
is
now *required* for all loadable modules. This includes
Martijn van Oosterhout kleptog@svana.org writes:
However, thinking about it, what they're doing can't possibly work. To
override malloc/free, you need to load the library *before* the C
library. Having the postmaster do it after startup is way too late.
Yeah, I was wondering about that too.
Tom Lane wrote:
* I'm inclined to make the Red Hat RPMs default to ident on socket and
md5 on localhost ... any comments about that?
I typically use something like this on RH platforms and friends for the
system db cluster:
local all postgres ident sameuser
local all all md5
host
I am thrill to inform you all that Sun has just donated a fully loaded
T2000 system to the PostgreSQL community, and it's being setup by Corey
Shields at OSL (osuosl.org) and should be online probably early next
week. The system has
* 8 cores, 4 hw threads/core @ 1.2 GHz. Solaris sees the
OK, based on reports I have seen, generally stats_query_string adds 50%
to the total runtime of a SELECT 1 query, and the patch reduces the
overhead to 25%.
However, that 25% is still much too large. Consider that SELECT 1 has
to travel from psql to the server, go through the
Bruce Momjian wrote:
OK, based on reports I have seen, generally stats_query_string adds 50%
to the total runtime of a SELECT 1 query, and the patch reduces the
overhead to 25%.
that is actually not true for both of the platforms(a slow OpenBSD
3.9/x86 and a very fast Linux/x86_64) I tested
Stefan Kaltenbrunner wrote:
Bruce Momjian wrote:
OK, based on reports I have seen, generally stats_query_string adds 50%
to the total runtime of a SELECT 1 query, and the patch reduces the
overhead to 25%.
that is actually not true for both of the platforms(a slow OpenBSD
3.9/x86 and a
On Wed, Jun 14, 2006 at 15:47:16 +0900,
Michael Glaesemann [EMAIL PROTECTED] wrote:
On Jun 13, 2006, at 13:25 , Bruno Wolff III wrote:
Date ranges are really closed open as well (as finite sets of
isolated points
are both open and closed). The only oddity would be that the date
used
Folks,
I am thrill to inform you all that Sun has just donated a fully loaded
T2000 system to the PostgreSQL community, and it's being setup by Corey
Shields at OSL (osuosl.org) and should be online probably early next
week. The system has
So this system will be hosted by Open Source Lab in
Bruce Momjian wrote:
Stefan Kaltenbrunner wrote:
Bruce Momjian wrote:
OK, based on reports I have seen, generally stats_query_string adds 50%
to the total runtime of a SELECT 1 query, and the patch reduces the
overhead to 25%.
that is actually not true for both of the platforms(a slow
Chris Campbell [EMAIL PROTECTED] writes:
I heard an interesting feature request today: preventing the
execution of a DELETE or UPDATE query that does not have a WHERE clause.
These syntaxes are required by the SQL spec. Furthermore, it's easy
to imagine far-more-probable cases in which the
URL added to TODO. I assume there has been no more progress on this patch.
---
Bernd Helmle wrote:
Hi folks,
Please find attached a patch that implements SQL92-compatible updatable
views. The patch introduces new
[EMAIL PROTECTED] (Bruce Momjian) writes:
Add STRICT to PL/pgSQL SELECT INTO, so exceptions are thrown if more or
less than one row is returned by the SELECT, for Oracle PL/SQL
compatibility.
I've got a couple of problems with the error codes used by this patch.
In the first place, you can't
Tom Lane wrote:
[EMAIL PROTECTED] (Bruce Momjian) writes:
Add STRICT to PL/pgSQL SELECT INTO, so exceptions are thrown if more or
less than one row is returned by the SELECT, for Oracle PL/SQL
compatibility.
I've got a couple of problems with the error codes used by this patch.
In the
Volkan YAZICI wrote:
To mention about the followed implementation, it needed some hack on
pqParseInput3() code to make it understand if a received message is
a reponse to a Describe ('D') query or to another tuple returning
query. To summarize problem, there're two possible forms of a 'D'
Bruce Momjian pgman@candle.pha.pa.us writes:
Tom Lane wrote:
Do we actually need different error codes for too few and too many rows?
It looks to me like the only relevant standard error condition is
CARDINALITY_VIOLATION, so either we throw CARDINALITY_VIOLATION for both
cases or we invent
Tom Lane wrote:
Bruce Momjian pgman@candle.pha.pa.us writes:
Tom Lane wrote:
Do we actually need different error codes for too few and too many rows?
It looks to me like the only relevant standard error condition is
CARDINALITY_VIOLATION, so either we throw CARDINALITY_VIOLATION for both
Someday we can move this to /port, but for now, let's get it into CVS.
Your patch has been added to the PostgreSQL unapplied patches list at:
http://momjian.postgresql.org/cgi-bin/pgpatches
It will be applied as soon as one of the PostgreSQL committers reviews
and approves it.
Bruce Momjian pgman@candle.pha.pa.us writes:
Tom Lane wrote:
Plan B is to invent new errcodes to match the Oracle spellings. If
that's what we want to do, it's not that hard.
We could use:
#define ERRCODE_DATA_EXCEPTION MAKE_SQLSTATE('2','2',
or
#define
Tom Lane wrote:
Bruce Momjian pgman@candle.pha.pa.us writes:
Tom Lane wrote:
Plan B is to invent new errcodes to match the Oracle spellings. If
that's what we want to do, it's not that hard.
We could use:
#define ERRCODE_DATA_EXCEPTION MAKE_SQLSTATE('2','2',
or
Added to TODO list, with URL.
---
Fabien COELHO wrote:
Dear PostgreSQL developer.
Although it is allowed to create a cast for a domain, it seems that there
is no way to trigger it. You can find attached an sql
Bruce Momjian pgman@candle.pha.pa.us writes:
If we go with that how does the caller check between not found and too
many? And if we go with Oracle names, I need different codes to match
with the two Oracle names.
I think we should just go with two new codes and use the Oracle names
for them.
Tom Lane wrote:
Bruce Momjian pgman@candle.pha.pa.us writes:
If we go with that how does the caller check between not found and too
many? And if we go with Oracle names, I need different codes to match
with the two Oracle names.
I think we should just go with two new codes and use the
On 16-6-2006 17:18, Robert Lor wrote:
I think this system is well suited for PG scalability testing, among
others. We did an informal test using an internal OLTP benchmark and
noticed that PG can scale to around 8 CPUs. Would be really cool if all
32 virtual CPUs can be utilized!!!
I can
Bruce Momjian pgman@candle.pha.pa.us writes:
Tom Lane wrote:
Actually ... does Oracle have SQLSTATEs assigned to these errors?
If so, maybe we should use theirs. I had the idea they were still
stuck on non-spec-compatible error numbers, though.
Anyone?
I did some googling and found one
Arjen,
I can already confirm very good scalability (with our workload) on
postgresql on that machine. We've been testing a 32thread/16G-version
and it shows near-linear scaling when enabling 1, 2, 4, 6 and 8 cores
(with all four threads enabled).
Keen. We're trying to keep the linear
All,
As many of you know, PostgreSQL is now fundraising via Software in the
Public Interest. One of the things this means is that PostgreSQL
contributors are eligible for SPI Contributing Membership, which allows
you to vote in SPI elections. If your name is listed here:
I am working on a possible extension of postgresql mvcc to support very timely failure masking in the context of three-tier applications so i am currently studying Postgresql internals...I am wondering what are the reasons why both the MultiXactIds and the corresponding OFFSETs and MEMBERs are
paolo romano [EMAIL PROTECTED] writes:
The point i am missing is the need to be able to completely recover
multixacts offsets and members data. These carry information about
current transactions holding shared locks on db tuples, which should
not be essential for recovery purposes.
This might
Observe the list of Files changed this run at
http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=gazelledt=2006-06-17%2000:30:01
The links to the core-system files are OK but the plpgsql files are not
correct, eg
pgsql/src/gram.y 1.93
where it should be
Tom Lane wrote:
Observe the list of Files changed this run at
http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=gazelledt=2006-06-17%2000:30:01
The links to the core-system files are OK but the plpgsql files are not
correct, eg
pgsql/src/gram.y 1.93
where it should be
I am thrill to inform you all that Sun has just donated a fully loaded
T2000 system to the PostgreSQL community, and it's being setup by Corey
Shields at OSL (osuosl.org) and should be online probably early next
week. The system has
* 8 cores, 4 hw threads/core @ 1.2 GHz. Solaris sees
Andrew Dunstan [EMAIL PROTECTED] writes:
I think the simplest fix would be just to require a / before the
filename capture:
That sounds like it would work. I was thinking you might need a
minimal-munch instead of maximal-munch quantifier before the pgsql
pattern, but that's not a good idea
Tatsuo Ishii [EMAIL PROTECTED] writes:
Interesting. We (some Japanese companies including SRA OSS,
Inc. Japan) did some PG scalability testing using a Unisys's big 16
(physical) CPU machine and found PG scales up to 8 CPUs. However
beyond 8 CPU PG does not scale anymore. The result can be
This thread:
http://archives.postgresql.org/pgsql-ports/2006-06/msg5.php
points up that if a client program would like to refer to datatype
OIDs by means of the pg_type.h macros (ie, write INT4OID and not
23), it's currently forced to include postgres.h, which is not
a good idea for a number
Tatsuo Ishii [EMAIL PROTECTED] writes:
Interesting. We (some Japanese companies including SRA OSS,
Inc. Japan) did some PG scalability testing using a Unisys's big 16
(physical) CPU machine and found PG scales up to 8 CPUs. However
beyond 8 CPU PG does not scale anymore. The result can be
On Thu, Jun 15, 2006 at 11:34:52PM -0400, Rod Taylor wrote:
On Tue, 2006-06-13 at 14:18 -0400, Kris Kennaway wrote:
On Tue, Jun 13, 2006 at 12:29:14PM -0500, Jim C. Nasby wrote:
Unless supersmack has improved substantially, you're unlikely to find
much interest. Last I heard it was a
On Fri, Jun 16, 2006 at 07:56:30AM -0400, Rod Taylor wrote:
I did have dbt2 pretty close to functional on FreeBSD a year ago but
it's probably gone back into linuxisms since then.
:(
I won't have the chance to work on this further for another 2 months,
but if you have patches I
How much work would it be to implement and how valuable would people
find the following additions to pg_stat_activity?
1) # of transactions committed on this connection since start
2) # of transactions rolled back
3) milliseconds used processing requests
4) milliseconds idle in transaction
5)
Andrew Hammond [EMAIL PROTECTED] writes:
How much work would it be to implement and how valuable would people
find the following additions to pg_stat_activity?
I won't speak to the how valuable bit, but as far as costs go,
I think:
1) # of transactions committed on this connection since start
Arjen van der Meijden wrote:
I can already confirm very good scalability (with our workload) on
postgresql on that machine. We've been testing a 32thread/16G-version
and it shows near-linear scaling when enabling 1, 2, 4, 6 and 8 cores
(with all four threads enabled).
The threads are a
On 6/16/06, Mark Woodward [EMAIL PROTECTED] wrote:
Chris Campbell [EMAIL PROTECTED] writes:
I heard an interesting feature request today: preventing the
execution of a DELETE or UPDATE query that does not have a WHERE clause.
These syntaxes are required by the SQL spec. Furthermore, it's
47 matches
Mail list logo
