> May be this is needed to support savepoints/subtransactions? Or is it > something else that i am missing?It's for two-phase commit. A prepared transaction can hold locks that need to be recovered.When a transaction enters (successfully) the prepared state it only retains its exclusive locks and r
On Sat, 17 Jun 2006, paolo romano wrote:
May be this is needed to support savepoints/subtransactions? Or is it
something else that i am missing?
It's for two-phase commit. A prepared transaction can hold locks that need
to be recovered.
- Heikki
---(end of broadcast
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. Furthermo
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 bit
"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 sin
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) mill
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 h
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
> 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 res
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 numbe
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
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
> 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 se
Tom Lane wrote:
Observe the list of "Files changed this run" at
http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=gazelle&dt=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
pgsql
Observe the list of "Files changed this run" at
http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=gazelle&dt=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
pgsql/src/pl/plpgsql/src/g
Bruce Momjian writes:
> Volkan YAZICI wrote:
>> The problem is, AFAICS, it's not possible to distinguish between a tuple
>> returning query (T, ..., C, Z or T, E) and a description of a portal (T,
>> Z). Therefore, I've created a global flag (parsing_row_desc) which is
>> turned on when we receive
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
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 cur
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:
http://www.postgresq
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 sc
Bruce Momjian 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 page that says no_
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 al
Tom Lane wrote:
> Bruce Momjian 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
>
Bruce Momjian 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. One remaining quest
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 s
Tom Lane wrote:
> Bruce Momjian 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
> > #d
Bruce Momjian 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 ERRCODE_ERROR_IN_ASSIGNM
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.
---
Tom Lane wrote:
> Bruce Momjian 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
Bruce Momjian 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 nonstandard cod
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'
>
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.
>
[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
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
> 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 w
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 platform
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
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 da
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
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 teste
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
parser/optimize
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 sy
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 all
Martijn van Oosterhout 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. At the very leas
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 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
On Wed, 2006-06-14 at 20:07 -0400, Tom Lane wrote:
> Josh Berkus 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 for malloc).
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 magic block required in all PostgreSQL-supported libraries
> > is checked to guarantee compatibility. For this reason, non-PostgreSQ
> > 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.
Every
Hi The 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: ter
On Fri, Jun 16, 2006 at 12:01:53AM -0400, Bruce Momjian wrote:
> OK, new text:
>
> The magic 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"?
50 matches
Mail list logo
