Daniel Schuchardt [EMAIL PROTECTED] writes:
is it is known that postgres 8.0 (beta1 and beta2 both same behavoir)
will eat tons of memory on Windows under heavy load?
No.
I tried setting up a test case with a 64K-row master table, a slave
table with the same 64K rows and an ON DELETE CASCADE
On Sat, 11 Sep 2004, Daniel Schuchardt wrote:
Hi list,
is it is known that postgres 8.0 (beta1 and beta2 both same behavoir)
will eat tons of memory on Windows under heavy load?
I do not believe that this is known.
Scenario:
I have a big delete with about 56000 rows. (DELETE FROM
On Friday 10 September 2004 17:58, Bruce Momjian wrote:
Devrim GUNDUZ wrote:
Hi,
AFAIR there was a thread about SELECT FOR UPDATE NOWAIT availability in
{7.5,8.0}, 7-8 months ago.
Now we have LOCK TABLE ... NOWAIT; but I wonder whether we'll have the
SELECT ... NOWAIT one. Today I
On Sat, 11 Sep 2004, Tiago Wright wrote:
IMHO, it is worth duplicating the mvcc data to all index entries. To
summarize what I understand from this discussion, with the current
method:
a1 - Index seeks must return invisible tuples because mvcc data is not
found in the index. These tuples are
Daniel Schuchardt [EMAIL PROTECTED] writes:
houres later I'v located the problem. Its not heavy load but
subtransactions in Triggers. It's very easy to recreate:
the problem is this Syntax :
CREATE OR REPLACE FUNCTION do_standard_mgc() RETURNS TRIGGER AS'
BEGIN
BEGIN
--prob
I'm fairly displeased with what pgindent has done to single-line PG_TRY
constructs, as in this example from pl_exec.c:
*** exec_stmt_block(PLpgSQL_execstate * esta
*** 911,922
SPI_result_code_string(xrc));
PG_TRY();
!
Tom Lane said:
I'm fairly displeased with what pgindent has done to single-line PG_TRY
constructs, as in this example from pl_exec.c:
*** exec_stmt_block(PLpgSQL_execstate * esta
*** 911,922
SPI_result_code_string(xrc));
Hi all,
one year ago I did this post:
http://archives.postgresql.org/pgsql-admin/2003-04/msg00137.php
however I had no reply att all, do you know why there is not a
concept of: security definer on views too ?
If in that post I was not clear please let me know.
Regards
Gaetano Mendola
Andrew Dunstan wrote:
Tom Lane said:
I'm fairly displeased with what pgindent has done to single-line PG_TRY
constructs, as in this example from pl_exec.c:
*** exec_stmt_block(PLpgSQL_execstate * esta
*** 911,922
SPI_result_code_string(xrc));
Joe Conway wrote:
Perhaps. The first error message seems clear enough to me, but if you
want to send me the necessary distutils test, I can incorporate it.
Any other opinions out there?
It looks like a waste of space and time to me. We can't really check
for everything, let alone
Peter Eisentraut wrote:
Joe Conway wrote:
Perhaps. The first error message seems clear enough to me, but if you
want to send me the necessary distutils test, I can incorporate it.
Any other opinions out there?
It looks like a waste of space and time to me.
Are you serious ? May you quantify
Andrew Dunstan wrote:
I had that argument a while ago with Bruce and lost :-) . It does horrible
things to if/else constructs too. The workaround is to put a comment in the
block. On the whole I agree with you, though. If I put braces in my program
it's for a reason, and the indenter shouldn't
Hackers,
I am in the process of fixing the oid2name contrib module. It needs a
lot of care and feeding. Hopefully for the next release we can move it
to src/bin/scripts so it can use the routines that are in common.c, and
some of the ugliness can go.
I think it will stay in contrib for 8.0
Tom Lane wrote:
Daniel Schuchardt [EMAIL PROTECTED] writes:
houres later I'v located the problem. Its not heavy load but
subtransactions in Triggers. It's very easy to recreate:
the problem is this Syntax :
CREATE OR REPLACE FUNCTION do_standard_mgc() RETURNS TRIGGER AS'
BEGIN
Please submit any improvements you can. It certainly needs attention!
I think it is inconsistent in using oid for lookup. It was originally
written before relfilenode existed (hence the name _oid_2name, while it
should be relfilenode to name or something. Maybe when we move it to
scripts we
Bruce Momjian [EMAIL PROTECTED] writes:
I have removed the code from pgindent. Now how do we clean up the
try/catch code that got messed up?
I've hand-restored the cases that are in the files I'm currently
editing. I'll look for more later.
regards, tom lane
Bruce Momjian [EMAIL PROTECTED] writes:
Well, yes, it has to take a lock on the subtransaction XID, which will
be held until main transaction commit. I'm not sure we have much of a
choice about this --- although it does seem annoying to have a
shared-memory-size constraint on how many
Daniel Schuchardt [EMAIL PROTECTED] writes:
now I get
ERROR: buffer XYZ is not owned by resource owner TopTransaction
Yeah, I ran into that earlier today while trying to reproduce your
problem. It's fixed by this pending patch. I didn't see any freeze-up
of the system after running out of
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Bruce Momjian wrote:
| Gaetano Mendola wrote:
|
|I had that argument a while ago with Bruce and lost :-) . It does horrible
|things to if/else constructs too. The workaround is to put a comment in the
|block. On the whole I agree with you, though. If I
I wrote:
We could revert to Alvaro's initial design in which subxacts didn't take
out separate locks on their XIDs; this would make XactLockTableWait a
lot slower though, and probably subject to unwanted deadlocks. You
really want to release waiters for a subxact as soon as the subxact
OK, it never removed braces from things like:
int x;
{
int x;
x=5;
}
but anyway I think we all agree it was uglifying the code more than it
was clarifying.
---
Hello all,
A few days ago, I found that CREATE OR REPLACE TRIGGER
is not allowed on 7.4.2. However, functions and rules allow
CREATE OR REPLACE statement.
Is threre any reason not to support CREATE OR REPLACE
only for triggers?
Thanks.
--
NAGAYASU Satoshi [EMAIL PROTECTED]
OpenSource
On Mon, 2004-09-13 at 10:52, Satoshi Nagayasu wrote:
A few days ago, I found that CREATE OR REPLACE TRIGGER
is not allowed on 7.4.2. However, functions and rules allow
CREATE OR REPLACE statement.
Is threre any reason not to support CREATE OR REPLACE
only for triggers?
And while we're at
Christopher Kings-Lynne [EMAIL PROTECTED] writes:
Is threre any reason not to support CREATE OR REPLACE
only for triggers?
Because the oid of a trigger doesn't matter. You can go being; drop
trigger; create trigger; commit; atomically.
And how often do you need to redefine a trigger (as
24 matches
Mail list logo
