Tom Lane [EMAIL PROTECTED] writes:
However, accumulation of zillions of gmon.out files is definitely a
downside of the approach; one that I've noticed myself.
Comments?
All I can add is that I've run into this problem myself too.
--
Gregory Stark
EnterpriseDB
I noticed that processCancelRequest() emits a log message at DEBUG2 when
it receives a cancel request with a bad key or for a non-existent PID.
For example,
ereport(DEBUG2,
(errmsg_internal(bad key in cancel request for process %d,
backendPID)));
I think this ought
On Fri, 2007-11-02 at 11:13 +0100, Florian Weimer wrote:
The documentation doesn't really tell how to disable synchronous
commits for a single commit. I believe the correct command is
SET LOCAL synchronous_commit TO OFF;
just before the COMMIT statement.
Yes, in fact anywhere within
On Fri, 2007-11-02 at 10:54 +, Gregory Stark wrote:
Incidentally I would like to call xlog.c:RecordIsValid() which is currently a
static function. Any objection to exporting it? It doesn't depend on any
external xlog.c state.
You'll have some fun with that because most of the stuff in
On Fri, 2007-11-02 at 13:40 +0100, Hans-Juergen Schoenig wrote:
I think Simon Riggs is already working on that idea. This one is
fairly easy to implement. I think these are some of the features
only a time-stamp based database can implement. I think database
standards were formed during
Marko Kreen wrote:
On 8/24/07, Manuel Sugawara [EMAIL PROTECTED] wrote:
Tom Lane [EMAIL PROTECTED] writes:
Manuel Sugawara [EMAIL PROTECTED] writes:
Marko Kreen [EMAIL PROTECTED] writes:
In 8.0 the pgcrypto functions were non-strict and checked for NULLs.
In 8.1 they were made
Dear Tom,
On Sat, 3 Nov 2007, Tom Lane wrote:
Date: Sat, 03 Nov 2007 21:21:20 -0400
From: Tom Lane [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Cc: Heikki Linnakangas [EMAIL PROTECTED],
pgsql-hackers list pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] should I worry?
[EMAIL
[EMAIL PROTECTED] writes:
I've got two problems:
Looking at the errors, ISTM foreign statement is the over way round :
levt_tevt_cod is in ligne_evt NOT in type_evt
No, that's just how we've worded FK violation errors for some time.
The real question is how did FK violations get into your
[EMAIL PROTECTED] writes:
I've tried it and got those logs:
BTW, is that a complete list of the NOTICEs you got? I'd expect to see
exactly two ignoring messages for each converting message, and it's
a bit worrisome that that's not what you seem to have.
Another thing that's strange is that
On Sat, 03 Nov 2007 15:47:40 -0400
Tom Lane [EMAIL PROTECTED] wrote:
Greg's objection caused me to rethink that. Doing it would be a problem
when transporting dump files across platforms: what if the appropriate
locale name is spelled differently on the new machine? We should
probably leave
On Sat, 3 Nov 2007, Stefan Kaltenbrunner wrote:
there is the various dbt workloads,sysbench, jans tpc-w implementation,
hell even pgbench
The DBT workloads are good for simulating disk-bound operations, but I
don't think they're sufficient by themselves for detecting performance
regressions
Neil Conway [EMAIL PROTECTED] writes:
ereport(DEBUG2,
(errmsg_internal(bad key in cancel request for process %d,
backendPID)));
I think this ought to be logged at a higher level than DEBUG2: for one
thing, it is a potential security issue the DBA might want to be
Joshua D. Drake wrote:
x86_64 is x86_64, regardless of intel or amd.
Not exactly, ask kernel guys ;-). But for user space yes.
Zdenek
---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Sun, 04 Nov 2007 19:28:46 +0100
Zdenek Kotala [EMAIL PROTECTED] wrote:
Joshua D. Drake wrote:
x86_64 is x86_64, regardless of intel or amd.
Not exactly, ask kernel guys ;-). But for user space yes.
For the context of the discussion...
Alvaro Herrera [EMAIL PROTECTED] writes:
No, it isn't. Please add a TODO item about it:
* Prevent long-lived temp tables from causing frozen-Xid advancement
starvation
Jeff Amiel wrote:
Can somebody explain this one to me? because of our auditing technique, we
have many LONG lived temp
On Fri, 2007-11-02 at 17:25 -0700, Mark Wong wrote:
On Fri, 02 Nov 2007 15:20:27 -0400
Tom Lane [EMAIL PROTECTED] wrote:
Joshua D. Drake [EMAIL PROTECTED] writes:
My question is -hackers, is who wants first bite and what do they
want :)
Something I'd like to have back real soon
On Fri, 2007-11-02 at 10:42 -0700, Joshua D. Drake wrote:
The test lab is finally starting to come to fruition. We (the
community) have been donated hardware via MyYearbook and Hi5. It is my
understanding that we may also have some coming from HP.
We are currently setting up a Trac for
Greg Smith wrote:
On Sat, 3 Nov 2007, Stefan Kaltenbrunner wrote:
there is the various dbt workloads,sysbench, jans tpc-w
implementation, hell even pgbench
The DBT workloads are good for simulating disk-bound operations, but I
don't think they're sufficient by themselves for detecting
On Sun, 4 Nov 2007, Tom Lane wrote:
Would it be possible for you to send me (off-list) all of the CREATE
CONSTRAINT TRIGGER commands appearing in the dump?
[done]
Hmm, this is messier than I thought. What evidently has happened is
that at one time or another, one of the two tables involved
This has been saved for the 8.4 release:
http://momjian.postgresql.org/cgi-bin/pgpatches_hold
---
Brendan Jurd wrote:
As discussed on -hackers, I'm trying to get rid of some redundant code
by creating a widely
D'Arcy J.M. Cain wrote:
+ para
+Since the output of this data type is locale-sensitive, it may not
+work to load typemoney/ data into a database that has a different
+setting of varnamelc_monetary/. To avoid problems, before
+restoring a dump make sure varnamelc_monetary/
On Sun, 2007-11-04 at 11:06 -0500, Tom Lane wrote:
No, if it's intended for the log it should be LOG. Your other proposals
are actually *less* likely to get to where the DBA could see them.
Good point. I suggested WARNING because that suggests that something is
awry, whereas LOG is used for
On Sun, 4 Nov 2007 17:24:10 -0500 (EST)
Bruce Momjian [EMAIL PROTECTED] wrote:
D'Arcy J.M. Cain wrote:
+ para
+Since the output of this data type is locale-sensitive, it may not
+work to load typemoney/ data into a database that has a different
+setting of
I wrote:
Hmm, this is messier than I thought. What evidently has happened is
that at one time or another, one of the two tables involved in an FK
relationship has been dropped and re-created. If you'd had proper
FK constraints the constraints would have gone away cleanly, but with
these old
D'Arcy J.M. Cain [EMAIL PROTECTED] writes:
Hmm. I think I like Tom's version better. However, since my primary
goal here is to remove the deprecation I will let you guys duke it out
over the additional clause. :-)
Just pick the wording you like and commit it; we've spent more than
enough
I wrote:
Hmm, this is messier than I thought. What evidently has happened is
that at one time or another, one of the two tables involved in an FK
relationship has been dropped and re-created. If you'd had proper
FK constraints the constraints would have gone away cleanly, but with
these old
This has been saved for the 8.4 release:
http://momjian.postgresql.org/cgi-bin/pgpatches_hold
---
Pavel Stehule wrote:
Hello,
I found lot of discus about this topic.
On Sun, 04 Nov 2007 20:38:11 -0500
Tom Lane [EMAIL PROTECTED] wrote:
D'Arcy J.M. Cain [EMAIL PROTECTED] writes:
Hmm. I think I like Tom's version better. However, since my primary
goal here is to remove the deprecation I will let you guys duke it out
over the additional clause. :-)
On 11/4/07, Simon Riggs [EMAIL PROTECTED] wrote:
On Fri, 2007-11-02 at 13:40 +0100, Hans-Juergen Schoenig wrote:
I think Simon Riggs is already working on that idea. This one is
fairly easy to implement. I think these are some of the features
only a time-stamp based database can
On Mon, 2007-11-05 at 11:58 +0530, Gokulakannan Somasundaram wrote:
The idea was to write a syncpoint every N seconds where we
record the
time and a snapshot of what's in progress.
What exactly is getting recorded here? Will the Syncpoint be similar
to the Undo Log
30 matches
Mail list logo