Re: [HACKERS] beta1 beta2 Windows heavy load
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 reference to the master, and a third table with the same 64K values and an ON DELETE CASCADE reference to the second. It took a little bit of time to delete all the master rows, but memory usage was perfectly steady. Can you provide a concrete test case? regards, tom lane ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] beta1 beta2 Windows heavy load
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 mytable;) There are triggers (after delete) updating 2 or 3 other tables. (there are triggers on this tables too). What language are the triggers written in? Are they just constraints? first everything seems ok but after a short tine postgres starts eating memory. On my mashine one postgres.exe sometimes eates 300MB or more. prob one : everything becomes slow because windows is swapping... main problem : if there is to less virutal memory postgres will abort because of to less memory. For a 56000 row delete you need 500MB of virtual ram or postgres aborts. I noticed the same behavoir when do lets say 75000 rows in a table (triggers updating other tables also). In both situations without transactions. Is this is a bug? Seems that way. Please provide a reproducible test so that others can recreate. Thanks, Gavin ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] SELECT FOR UPDATE NOWAIT and PostgreSQL 8.0
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 got a request for this; and it was
reported that this feature will be used in a huge project.
If there is an unapplied patch that I've missed (even though I didn't see
one in http://momjian.postgresql.org/cgi-bin/pgpatches2), I'd like to
know it -- taking all the risks, surely.
I don't know of any patch done. The solution suggested was to use
statement_timeout before the SELECT FOR UPDATE. I am not 100% excited
about that because there is no way to know if the query is slow because
of a lock or just system slowness, but the logic is that you really
don't care why you have failed to do a lock or not, just that the query
is taking a long time.
Hmm... this seems the exact opposite of how I would tend to think the feature
would be used... ie. you don't really care how long the query takes, just
that you can't get the lock.
--
Robert Treat
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
---(end of broadcast)---
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
Re: [HACKERS] Indexed views?
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 eliminated once the data is read from the actual data pages. a2 - Covered queries are not possible since the data page must be visited to determine visibility a4 - Indexes must be fully vacuumed before vacuuming the corresponding heap entries If mvcc data is replicated to the index entries: b1 - Index seeks will never return invisible tuples, possibly eliminating some page reads b2 - Covered queries are possible b3 - Inserts are not affected performancewise. Deletes must now visit every index entry, which is a larger cost. Updates must visit every index entry too. It may be possible to reduce the cost of update if the indexed data is not affected, since the new index entry will likely end up in the same page as the index entry that must be deleted, so no extra page reads would be necessary in this scenario. b4 - Heap and index pages can be vacuumed independently. Since the great majority of performance issues are related to select queries, the benefit of eliminating invisible tuple page fetches and supporting covered queries probably outweight the extra cost of updating index entries. And once covered queries are supported, it would be possible to build indexed views or multi-table indexes that can address some of the most performance demanding queries out there. I am wondering whether it would be possible to measure the costs of a1 and a2 above and compare with the probable costs for b3. It seems to me that applications for which b3 are most expensive are also those for which a1 would be most expensive, and since selects are much more common than updates, could one offset the other in the long run? Can anyone shed some light on these? If it seems that there are some cases where it's better to have the visibility information in the index and some cases where not, I think we could support both kinds of indexes and let the DBA choose. - Heikki ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] beta1 beta2 Windows heavy load
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 also occurs in this case (empty subtransaction) EXCEPTION WHEN OTHERS THEN PERFORN NULL; END; RETURN new; END'LANGUAGE plpgsql; It seems that this subtransactions allocates mem that is never freed. 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 subtransactions you can have. The shared memory should be freed on failure, though. Is that part reproducible with current sources? regards, tom lane ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
[HACKERS] pgindent vs try/catch
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();
! {
! rc = exec_stmts(estate, block-body);
! }
PG_CATCH();
{
! ErrorData *edata;
PLpgSQL_exceptions *exceptions;
int j;
--- 912,921
SPI_result_code_string(xrc));
PG_TRY();
! rc = exec_stmts(estate, block-body);
PG_CATCH();
{
! ErrorData *edata;
PLpgSQL_exceptions *exceptions;
int j;
*** exec_stmt_block(PLpgSQL_execstate * esta
On the whole I'd prefer that pgindent not suppress unnecessary
brace pairs at all.
regards, tom lane
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
Re: [HACKERS] pgindent vs try/catch
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));
PG_TRY();
! {
! rc = exec_stmts(estate, block-body);
! }
PG_CATCH();
{
! ErrorData *edata;
PLpgSQL_exceptions *exceptions;
int j;
--- 912,921
SPI_result_code_string(xrc));
PG_TRY();
! rc = exec_stmts(estate, block-body);
PG_CATCH();
{
! ErrorData *edata;
PLpgSQL_exceptions *exceptions;
int j;
*** exec_stmt_block(PLpgSQL_execstate * esta
On the whole I'd prefer that pgindent not suppress unnecessary
brace pairs at all.
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 think it knows better than me.
cheers
andrew
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
[HACKERS] security definer on views
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 ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] pgindent vs try/catch
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));
PG_TRY();
! {
! rc = exec_stmts(estate, block-body);
! }
PG_CATCH();
{
! ErrorData *edata;
PLpgSQL_exceptions *exceptions;
int j;
--- 912,921
SPI_result_code_string(xrc));
PG_TRY();
! rc = exec_stmts(estate, block-body);
PG_CATCH();
{
! ErrorData *edata;
PLpgSQL_exceptions *exceptions;
int j;
*** exec_stmt_block(PLpgSQL_execstate * esta
On the whole I'd prefer that pgindent not suppress unnecessary
brace pairs at all.
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 think it knows better than me.
Well I'm not exactly a C coder, I'm a C++ one and it's quite common use the
extra scope in order to reduce the automatic variable life, I don't know how
much the extra scope are used in the C world, however remove an extra scope
like that is not only horrible, is *wrong* and can be cause of future pain:
foo ( int a )
{
...
{
int a;
}
// use the formal parameter
}
if the extra scope is removed the local variable shadow the formal
parameter. Some compilers do not warning you, IIRC the Digital had this funny omission,
( however you can miss the warning ) and hours of debugging are behind the corner.
I hope that Bruce change his mind...
Regards
Gaetano Mendola
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] x86_64 configure problem
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 preconditions of what we're really interested in. We want to find the Python makefile, so let's look for that. The error message if it's not found is perfectly clear. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] x86_64 configure problem
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 the space and the time lost ? The error message if it's not found is perfectly clear. Is it ? The error say no modules named distutils, is the module an external one that I need to have installed or is a bogus error due the previous line: File string, line 1, in ? And most of all why when I wrote about the inability to create the RPM for RH2.1 no one wrote: you need to install the distutils package, after having seen this error: checking Python installation directories... Traceback (innermost last): File string, line 1, in ? ImportError: No module named distutils Traceback (innermost last): File string, line 1, in ? ImportError: No module named distutils /usr/ checking how to link an embedded Python application... no configure: error: Python Makefile not found error: Bad exit status from /var/tmp/rpm-tmp.56347 (%build) may be because the message after all is not concise. Regards Gaetano Mendola ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] pgindent vs try/catch
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 think it knows better than me. I have removed the code from pgindent. Now how do we clean up the try/catch code that got messed up? The original purpose of that code was to clean up the code we inherited from Berkeley that had lots of excessive brace blocks and the pgindent code just remained. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
[HACKERS] oid2name
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 however, so it needs to be fixed now. While I was playing with it, I noticed several shortcomings: - it only works in the PUBLIC schema - it only knows about tables and databases, except when running in show systables mode, and then it will show all indexes, toast tables, etc - it only displays relfilenode and tablename - there's no way to query by relfilenode, only by Oid (note that the last two means the program is somewhat inconsistent) This last one IMHO makes the program somewhat useless, because what the user normally wants to know is what table does a certain file on disk belong to, and the Oid may not provide that. I want to fix this, by providing switches to allow querying by filenode, Oid and tablename; and to show not only filenode and name, but also schema and tablespace. Is this acceptable for this release? Other opinions? -- Alvaro Herrera (alvherre[a]dcc.uchile.cl) This is a foot just waiting to be shot(Andrew Dunstan) ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] beta1 beta2 Windows heavy load
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 BEGIN --prob also occurs in this case (empty subtransaction) EXCEPTION WHEN OTHERS THEN PERFORN NULL; END; RETURN new; END'LANGUAGE plpgsql; It seems that this subtransactions allocates mem that is never freed. 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 subtransactions you can have. You mean 64 (the number of object locks)? Can you clarify why the subtransaction is locked in this case and not others? -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] oid2name
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 can rename it. --- Alvaro Herrera wrote: 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 however, so it needs to be fixed now. While I was playing with it, I noticed several shortcomings: - it only works in the PUBLIC schema - it only knows about tables and databases, except when running in show systables mode, and then it will show all indexes, toast tables, etc - it only displays relfilenode and tablename - there's no way to query by relfilenode, only by Oid (note that the last two means the program is somewhat inconsistent) This last one IMHO makes the program somewhat useless, because what the user normally wants to know is what table does a certain file on disk belong to, and the Oid may not provide that. I want to fix this, by providing switches to allow querying by filenode, Oid and tablename; and to show not only filenode and name, but also schema and tablespace. Is this acceptable for this release? Other opinions? -- Alvaro Herrera (alvherre[a]dcc.uchile.cl) This is a foot just waiting to be shot(Andrew Dunstan) ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] pgindent vs try/catch
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 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] beta1 beta2 Windows heavy load
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 subtransactions you can have. You mean 64 (the number of object locks)? No, max_locks_per_transaction * max_connections. In practice it seems to get unhappy at about 1 locks given default shared-memory sizing. This is because we leave some overhead slop that the locks table can expand into before failing altogether. Can you clarify why the subtransaction is locked in this case and not others? It's locked in all cases. A *failed* subtransaction will release its lock, but a non-failed one will hold the lock till main commit. 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 fails, rather than making them wait around for the parent. Right now I'm not seeing a cure that's not worse than the disease. regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] beta1 beta2 Windows heavy load
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 lock memory, though. It seemed to
release the locks just fine.
*** src/pl/plpgsql/src/pl_exec.c.orig Sun Aug 29 22:58:09 2004
--- src/pl/plpgsql/src/pl_exec.cSun Sep 12 17:04:30 2004
***
*** 897,902
--- 897,903
* sub-transaction
*/
MemoryContext oldcontext = CurrentMemoryContext;
+ ResourceOwner oldowner = CurrentResourceOwner;
volatile bool caught = false;
int xrc;
***
*** 907,918
BeginInternalSubTransaction(NULL);
/* Want to run statements inside function's memory context */
MemoryContextSwitchTo(oldcontext);
if ((xrc = SPI_connect()) != SPI_OK_CONNECT)
elog(ERROR, SPI_connect failed: %s,
SPI_result_code_string(xrc));
PG_TRY();
! rc = exec_stmts(estate, block-body);
PG_CATCH();
{
ErrorData *edata;
--- 908,922
BeginInternalSubTransaction(NULL);
/* Want to run statements inside function's memory context */
MemoryContextSwitchTo(oldcontext);
+
if ((xrc = SPI_connect()) != SPI_OK_CONNECT)
elog(ERROR, SPI_connect failed: %s,
SPI_result_code_string(xrc));
PG_TRY();
! {
! rc = exec_stmts(estate, block-body);
! }
PG_CATCH();
{
ErrorData *edata;
***
*** 927,932
--- 931,937
/* Abort the inner transaction (and inner SPI connection) */
RollbackAndReleaseCurrentSubTransaction();
MemoryContextSwitchTo(oldcontext);
+ CurrentResourceOwner = oldowner;
SPI_pop();
***
*** 958,965
--- 963,973
if ((xrc = SPI_finish()) != SPI_OK_FINISH)
elog(ERROR, SPI_finish failed: %s,
SPI_result_code_string(xrc));
+
ReleaseCurrentSubTransaction();
MemoryContextSwitchTo(oldcontext);
+ CurrentResourceOwner = oldowner;
+
SPI_pop();
}
}
regards, tom lane
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
Re: [HACKERS] pgindent vs try/catch
-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 put braces in my program
|it's for a reason, and the indenter shouldn't think it knows better than me.
|
|Well I'm not exactly a C coder, I'm a C++ one and it's quite common use the
|extra scope in order to reduce the automatic variable life, I don't know how
|much the extra scope are used in the C world, however remove an extra scope
|like that is not only horrible, is *wrong* and can be cause of future pain:
|
|
|foo ( int a )
|{
| ...
| {
| int a;
| }
| // use the formal parameter
|}
|
|if the extra scope is removed the local variable shadow the formal
|parameter. Some compilers do not warning you, IIRC the Digital had this funny
omission,
|( however you can miss the warning ) and hours of debugging are behind the corner.
|I hope that Bruce change his mind...
|
|
| I am a little confused by the above. It only removes braces that have
| one command in them.
This was not clear to me.
| What does use the formal parameter mean?
Emm, the variable argument I mean, is not formal parameter the right name ?
| FYI, C doesn't allow variables to be declared in for() like that, but I am
| still curious how C++ handles such cases.
the { ... } in c++ represent an extra scope this means that at the end of the
scope all variable declared inside are destroyed. A common way to use it is to
surround critical sections:
void foo( int a )
{
~ Mutex m;
~ ...
~ {
~ Lock myLock(m); // The lock is acquired inside the constructor
~ int a = 5;
~ //critical section code follow
~ ...
~ } // The unlock is performed in the destructor
};
at the end of the scope the destructor for the variable myLock is called.
In this way the lock is released ( with the appropriate code in the destructor)
without remember to unlock it and most important the lock is released also if
an exception is thrown; inside that extra scope the variable
a hide the function parameter, this code is perfectly legal in C++.
In the case of the for if you declare for ( A a = ... ) {} the lifespan
for the object a is the for body, and ansi C++ allow the reuse so you can have:
for ( A a = ... ) {}
for ( A a = ... ) {}
| I have no problem in removing this pgindent behavior.
I don't know all the implication in removing it or leave it, however I agree to
leave the extra scope in place.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.4 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFBRNi37UpzwH2SGd4RAgrlAKDo+xL+Vo8+2vyfpnhxmmPyEJOhXwCgpc4h
8cdAPGv/fqWE3UY2bRe4rlI=
=Wbra
-END PGP SIGNATURE-
---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] beta1 beta2 Windows heavy load
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
fails, rather than making them wait around for the parent.
Right now I'm not seeing a cure that's not worse than the disease.
After awhile I thought of a possibly rather crocky solution:
1. During CommitSubTransaction, release the lock on the subtransaction's
XID (but not any of its other locks). This means that the number of
locks held due to just transaction XIDs is no more than the subxact
nesting depth, rather than growing with the number of subcommitted XIDs.
2. XactLockTableWait would have to do something like this:
for (;;)
{
wait for lock associated with xid;
if (!TransactionIdIsInProgress(xid))
break;
xid = SubTransGetParent(xid);
}
This relies on the fact that TransactionIdIsInProgress will return true
for subcommitted children of still-open parents, but not for aborted
children. So once we get past the wait, we check to see which case
applies, and wait for the subxact's parent if necessary. If the subxact
aborted then we need no longer wait.
I'm not totally convinced that this is race-condition-free, but I
haven't been able to poke a hole in it yet.
The other question is whether it's worth some extra overhead in
XactLockTableWait to save on shared memory. I'm inclined to think it
is, mainly because you don't get into XactLockTableWait in the first
place unless you're going to have to block. (I'm pretty sure all paths
leading to it have already determined that the other transaction is or
very recently was InProgress.) So you lose anyway, and losing a few
more microseconds isn't that big a deal.
Comments?
regards, tom lane
---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] pgindent vs try/catch
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.
---
Gaetano Mendola wrote:
[ PGP not available, raw data follows ]
-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 put braces in my program
|it's for a reason, and the indenter shouldn't think it knows better than me.
|
|Well I'm not exactly a C coder, I'm a C++ one and it's quite common use the
|extra scope in order to reduce the automatic variable life, I don't know how
|much the extra scope are used in the C world, however remove an extra scope
|like that is not only horrible, is *wrong* and can be cause of future pain:
|
|
|foo ( int a )
|{
| ...
| {
| int a;
| }
| // use the formal parameter
|}
|
|if the extra scope is removed the local variable shadow the formal
|parameter. Some compilers do not warning you, IIRC the Digital had this funny
omission,
|( however you can miss the warning ) and hours of debugging are behind the corner.
|I hope that Bruce change his mind...
|
|
| I am a little confused by the above. It only removes braces that have
| one command in them.
This was not clear to me.
| What does use the formal parameter mean?
Emm, the variable argument I mean, is not formal parameter the right name ?
| FYI, C doesn't allow variables to be declared in for() like that, but I am
| still curious how C++ handles such cases.
the { ... } in c++ represent an extra scope this means that at the end of the
scope all variable declared inside are destroyed. A common way to use it is to
surround critical sections:
void foo( int a )
{
~ Mutex m;
~ ...
~ {
~ Lock myLock(m); // The lock is acquired inside the constructor
~ int a = 5;
~ //critical section code follow
~ ...
~ } // The unlock is performed in the destructor
};
at the end of the scope the destructor for the variable myLock is called.
In this way the lock is released ( with the appropriate code in the destructor)
without remember to unlock it and most important the lock is released also if
an exception is thrown; inside that extra scope the variable
a hide the function parameter, this code is perfectly legal in C++.
In the case of the for if you declare for ( A a = ... ) {} the lifespan
for the object a is the for body, and ansi C++ allow the reuse so you can have:
for ( A a = ... ) {}
for ( A a = ... ) {}
| I have no problem in removing this pgindent behavior.
I don't know all the implication in removing it or leave it, however I agree to
leave the extra scope in place.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.4 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFBRNi37UpzwH2SGd4RAgrlAKDo+xL+Vo8+2vyfpnhxmmPyEJOhXwCgpc4h
8cdAPGv/fqWE3UY2bRe4rlI=
=Wbra
-END PGP SIGNATURE-
---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings
[ End of raw data]
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED] | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup.| Newtown Square, Pennsylvania 19073
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[HACKERS] CREATE OR REPLACE TRIGGER not supported?
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 Development Center, NTT DATA Corp. http://www.nttdata.co.jp/ ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] CREATE OR REPLACE TRIGGER not supported?
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 it, CREATE OR REPLACE type; ... John ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] CREATE OR REPLACE TRIGGER not supported?
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 opposed to its underlying function), anyway? Sure, given infinite manpower we would support this. But it seems very far down the to-do list to me. regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
