[HACKERS] MARKED_FOR_UPDATE XMAX_COMMITTED == XMAX_INVALID ?
If a transaction marks a tuple for update and later commits without
actually having updated the tuple, do we still need the information
that the tuple has once been reserved for an update or can we simply
set the HEAP_XMAX_INVALID hint bit of the tuple?
In other words, is this snippet from a patch I'm working on a valid
modification to HeapTupleSatisfiesVacuum in tqual.c?
{
if (TransactionIdIsInProgress(HeapTupleHeaderGetXmax(tuple)))
return HEAPTUPLE_LIVE;
- if (TransactionIdDidCommit(HeapTupleHeaderGetXmax(tuple)))
- tuple-t_infomask |= HEAP_XMAX_COMMITTED;
- else
-/* it's either aborted or crashed */
- tuple-t_infomask |= HEAP_XMAX_INVALID;
+ /*
+* We don't really care whether xmax did commit, abort or
+* crash. We know that xmax did mark the tuple for update,
+* but it did not and will never actually update it.
+*/
+ tuple-t_infomask |= HEAP_XMAX_INVALID;
}
return HEAPTUPLE_LIVE;
There are a few more places in tqual.c which could be simplified like
that.
Servus
Manfred
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] Function returns composite type
It works fine. But is there way not to point 'as c(qq int4, qq1 int4)'?
If you mean, is there a way to leave out the 'as c(qq int4, qq1 int4)',
the answer is no. You need to either declare the function to return a
determinate data type, or you have to specify the data type at runtime
in the query string.
it's a great pity :(.
But in function I already make TupleDesc:
tupdesc = CreateTemplateTupleDesc(attnum, false);
for (i = 0; i attnum; i++) {
sprintf(attname, z%d, i+1);
TupleDescInitEntry(tupdesc, i+1, attname, INT4OID, -1, 0, false);
}
As I understand, this code makes full description of returning value, including
types and column's names.
Is this info used anywhere?
--
Teodor Sigaev E-mail: [EMAIL PROTECTED]
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] PostgreSQL under Windows
On Tue, Jun 10, 2003 at 22:34:04 -0700, P.M [EMAIL PROTECTED] wrote: I was thinking that PostgreSQL could help me to reduce the cost of a such software. But i would like to know what is the status of the PostGreSQL version under Windows ? I mean, i know that some of you are trying to do an installer version under Windows for PostGreSQL and i would like to know if a beta version already exist or not There will be a beta native windows port available in about 3 weeks. It is currently possible to run postgresql on windows using cygwin. ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
[HACKERS] Okay, one mailing list problem still left...
... pgsql-committers is not propagating. Bruce evidently applied a ton of patches last night, and I see no committers messages for any of 'em. regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] MARKED_FOR_UPDATE XMAX_COMMITTED == XMAX_INVALID ?
Manfred Koizar [EMAIL PROTECTED] writes: If a transaction marks a tuple for update and later commits without actually having updated the tuple, do we still need the information that the tuple has once been reserved for an update or can we simply set the HEAP_XMAX_INVALID hint bit of the tuple? AFAICS this is a reasonable thing to do. Eventually we might also be able to remove the bits of logic that check for MARKED_FOR_UPDATE in a committed tuple, but that would not be backwards-compatible so I'd vote against doing it immediately. regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Okay, one mailing list problem still left...
shoujld be fixed now On Wed, 11 Jun 2003, Tom Lane wrote: ... pgsql-committers is not propagating. Bruce evidently applied a ton of patches last night, and I see no committers messages for any of 'em. regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy Systems Administrator @ hub.org primary: [EMAIL PROTECTED] secondary: [EMAIL PROTECTED]|postgresql}.org ---(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] PostgreSQL under Windows
Hi, I'm new in this mailing list and in the world of PostGreSQL. I need to create a C++ application under Windows which will use a very huge database... I was thinking that PostgreSQL could help me to reduce the cost of a such software. But i would like to know what is the status of the PostGreSQL version under Windows ? I mean, i know that some of you are trying to do an installer version under Windows for PostGreSQL and i would like to know if a beta version already exist or not Because i was thinking to build one from my side, but if it already exists, it's better for me. I wrote a Windows installer a while back, I think it has been incorporated into gborg, but I'm not sure. The one caveat to the system is that it should previously contain a cygwin installation. ---(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] Anonymous CVS *is* up again
BTW, in case anyone else besides me wasn't up to speed, the anonymous-CVS mirror is functioning again. It is at the same place as before: :pserver:[EMAIL PROTECTED]:/projects/cvsroot The only change from previously published instructions is that you have to give some nonempty password (doesn't matter what) during cvs login. I had mistakenly told people that the path would change to just /cvsroot, but Marc decided to stick with a mirrored setup for security reasons. regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] SELECT TAKES A LOOOONG TIME
Hi, could somebody explain me please why following select SELECT docid FROM prod.guids GROUP BY docid HAVING( COUNT(docid) 1 ) taking 15 min on 2 Proc Box on 1M rows, where number of duplicates around 300K, and docid indexed and not null and char(16). May be I am doing something wrong? Thank you. I would first perform an explain on the query to have the database show you where it is spending its time. Second, you are performing a full table scan. Try this: select count(docid) from prod.guids See how long that takes, that's about as fast as your system will handle that query. If that query is fast, you may need to play with the tuning parameters of PostgreSQL like sort memory. Have you adjusted any parameters in your postgresql.conf file? ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[HACKERS] Pre-allocation of shared memory ...
There is a problem which occurs from time to time and which is a bit nasty in business environments. When the shared memory is eaten up by some application such as Apache PostgreSQL will refuse to do what it should do because there is no memory around. To many people this looks like a problem relatd to stability. Also, it influences availability of the database itself. I was thinking of a solution which might help to get around this problem: If we had a flag to tell PostgreSQL that XXX Megs of shared memory should be preallocated by PostgreSQL. The database would the sure that there is always enough memory around. The problem is that PostgreSQL had to care more about memory consumption. Of course, the best solution is to put PostgreSQL on a separate machine but many people don't do it so we have to live with memory leaks caused by other software (we have just seen a nasty one in mod_perl). Does it make sense? Regards, Hans -- Cybertec Geschwinde u Schoenig Ludo-Hartmannplatz 1/14, A-1160 Vienna, Austria Tel: +43/2952/30706; +43/664/233 90 75 www.cybertec.at, www.postgresql.at, kernel.cybertec.at ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] Function returns composite type
Teodor Sigaev wrote:
it's a great pity :(.
But in function I already make TupleDesc:
tupdesc = CreateTemplateTupleDesc(attnum, false);
for (i = 0; i attnum; i++) {
sprintf(attname, z%d, i+1);
TupleDescInitEntry(tupdesc, i+1, attname, INT4OID, -1,
0, false);
}
As I understand, this code makes full description of returning value,
including types and column's names.
Is this info used anywhere?
You could actually get the tupdesc from the caller if you wanted. See,
for example crosstab_hash() in contrib/tablefunc:
snip
/* check to see if caller supports us returning a tuplestore */
if (!rsinfo || !(rsinfo-allowedModes SFRM_Materialize))
elog(ERROR, crosstab: materialize mode required, but it is not
allowed in this context);
per_query_ctx = rsinfo-econtext-ecxt_per_query_memory;
oldcontext = MemoryContextSwitchTo(per_query_ctx);
/* get the requested return tuple description */
tupdesc = CreateTupleDescCopy(rsinfo-expectedDesc);
/snip
The problem is that the parser needs the column data types long before
your function gets called by the executor. Therefore you either need the
predetermined return type, or the query string definition.
We've discussed a couple of times allowing the parser to interrogate
the function at parse time to let it determine what the runtime tupdesc
will be, but I haven't been able to come up with a good way to do that.
Joe
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] Pre-allocation of shared memory ...
We already pre-allocate all shared memory and resources on postmaster start. --- Hans-Jürgen Schönig wrote: There is a problem which occurs from time to time and which is a bit nasty in business environments. When the shared memory is eaten up by some application such as Apache PostgreSQL will refuse to do what it should do because there is no memory around. To many people this looks like a problem relatd to stability. Also, it influences availability of the database itself. I was thinking of a solution which might help to get around this problem: If we had a flag to tell PostgreSQL that XXX Megs of shared memory should be preallocated by PostgreSQL. The database would the sure that there is always enough memory around. The problem is that PostgreSQL had to care more about memory consumption. Of course, the best solution is to put PostgreSQL on a separate machine but many people don't do it so we have to live with memory leaks caused by other software (we have just seen a nasty one in mod_perl). Does it make sense? Regards, Hans -- Cybertec Geschwinde u Schoenig Ludo-Hartmannplatz 1/14, A-1160 Vienna, Austria Tel: +43/2952/30706; +43/664/233 90 75 www.cybertec.at, www.postgresql.at, kernel.cybertec.at ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html -- 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
Re: [HACKERS] Function returns composite type
You could actually get the tupdesc from the caller if you wanted. See, for example crosstab_hash() in contrib/tablefunc: snip /* check to see if caller supports us returning a tuplestore */ if (!rsinfo || !(rsinfo-allowedModes SFRM_Materialize)) elog(ERROR, crosstab: materialize mode required, but it is not allowed in this context); per_query_ctx = rsinfo-econtext-ecxt_per_query_memory; oldcontext = MemoryContextSwitchTo(per_query_ctx); /* get the requested return tuple description */ tupdesc = CreateTupleDescCopy(rsinfo-expectedDesc); /snip Thank you for point. The problem is that the parser needs the column data types long before your function gets called by the executor. Therefore you either need the predetermined return type, or the query string definition. Ok, I see We've discussed a couple of times allowing the parser to interrogate the function at parse time to let it determine what the runtime tupdesc will be, but I haven't been able to come up with a good way to do that. Can we make follow: Functions, returning record and called in sql without description, ??lled with specific arguments (as is done for SRF by SRF_IS_FIRSTCALL()). With this arguments it should return TupleDesc. As I see, the place to such call is addRangeTableEntryForFunction at src/parser/parse_relation.c near lines N921-964. In this place we have all that we need. Am I wrong? -- Teodor Sigaev E-mail: [EMAIL PROTECTED] ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Function returns composite type
We've discussed a couple of times allowing the parser to interrogate the function at parse time to let it determine what the runtime tupdesc will be, but I haven't been able to come up with a good way to do that. This seems fairly unworkable to me, as in interesting cases the parser could not find out what parameter values to pass to the function, so the function wouldn't have enough information to know what it will return either. regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] [GENERAL] How to enumerate foreign key constraints after migrating from 7.1.3?
Rod Taylor [EMAIL PROTECTED] wrote: Unfortunately, having all my users run contrib/adddepend isn't an option for me. However, that script does contain a good deal of information that I may be able to use for detecting old-style foreign key constraints in my own code. I assume you're doing the database upgrade for them or providing instructions? Could this be a mandatory portion of that process? We're referring users to chapter 9.3 of the PostgreSQL Administrator's Guide for data migration. Even the standard postgres dump/restore procedure is nearly too much for our users. Anything more would be asking for trouble. Okay, more questions: I see that adddepend detects old-style foreign key constraints by looking for groups of 3 triggers having 6 or more identical function arguments. Is that the best way to do it? It occurs to me that an alternative might be to find triggers that call RI_FKey_check_ins() and have the tgisconstraint flag set. Will either approach be safe in postgres 7.4? Perhaps a combination of the two would be best? Yes, a combination of the two would probably be better. You would need to be careful about function call names for FKeys, there are a fair number of them. Checking for 3 triggers with the function name starting with RI_FKey* would probably be better. Will the tgisconstraint flag always be set for these triggers? Will the function names still be RI_FKey* once these databases are migrated to postgres 7.4 or later? ---(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] SELECT blocking on ALTER TABLE ADD FOREIGN KEY
Is it really necessary to block reads on a table that is affected by adding a foreign key constraint? I can see why you wouldn't want UPDATES or INSERTS on the child table or DELETEs on the parent, but select should be fine on both tables, no? -- Jim C. Nasby (aka Decibel!)[EMAIL PROTECTED] Member: Triangle Fraternity, Sports Car Club of America Give your computer some brain candy! www.distributed.net Team #1828 Windows: Where do you want to go today? Linux: Where do you want to go tomorrow? FreeBSD: Are you guys coming, or what? ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Please, apply patch for current CVS
Patch applied. You patch indicated _int.c should be removed from CVS, so I have done so. --- Teodor Sigaev wrote: Patch for contrib/intarray and contrib/ltree modules. Download from: http://www.sai.msu.su/~megera/postgres/gist/patches/intarray_ltree.patch.gz Changes: 1 intarray: bugfix for int[]-int[] operation 2 intarray: split _int.c to several files (_int.c now is unused) 3 ntarray (gist__intbig_ops opclass): use special type for index storage 4 ltree (gist__ltree_ops opclass), intarray (gist__intbig_ops): optimize GiST's penalty and picksplit interface functions, now use Hemming distance. Thank you. -- Teodor Sigaev E-mail: [EMAIL PROTECTED] ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org -- 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
Re: [HACKERS] No more RH7.3 RPMs?
On Thursday 29 May 2003 17:41, Sander Steffann wrote: Someone else has already built RPMs for RH73 and Lamar has already uploaded them to ftp.postgresql.org. I just completed the RH62 packages. Lamar will put them on the FTP server, but until then they can be picked up from http://www.steffann.nl/PostgreSQL/v7.3.3/ if somebody needs them quickly. Uploading now. Thanks, Sander, and Thanks, Timothy! -- Lamar Owen WGCR Internet Radio 1 Peter 4:11 If you want I can upload somewhere Postgres 7.3.3 for RH 7.2 Regards Gaetano Mendola ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] [GENERAL] Postgresql AMD x86-64
Hi folks, We recently built a dual K8D-based Opteron box running Linux in 64-bit mode (Debian 'testing' distribution with newly compiled binutils, gcc, and various support libraries for amd64 architecture). The Postgres 7.3.3 port was simply a matter of setting the appropriate flags to take of the biarchectecture nature of the Linux port. (that is, -m64 to generate 64 bit code and either gcc -m64 or ld -melf_x86_64 for linking). There were no other issues in the compile. In the install, I had to re-init due to the incompatibility of pg_control. All the regression tests went smoothly (the one failure was in geometry and is due to round off in the least sig figs of the doubles in the Point structure or machine zero differences). I compared a simple query on local data in both 32bit mode and 64bit mode; the execute time difference was not significant but this was not a compute intensive verification (summing up column values in a table). We have some other 32-bit amd machines here; I would be happy to try a few other tests. Good job, developers!!! On Mon, 07 Apr 2003 18:34:05 +0800 Justin Clift [EMAIL PROTECTED] wrote: Hi guys, Does anyone want remote access to the upcoming AMD 64 bit architecture, to make sure PostgreSQL runs well on it? It's only via remote access at present, but the AMD guys are willing to help us out here. Regards and best wishes, Justin Clift Original Message Subject: RE: Postgresql AMD x86-64 Date: Fri, 4 Apr 2003 10:29:24 -0800 From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] CC: [EMAIL PROTECTED], [EMAIL PROTECTED] Justin, I apologize for the delayed response. Unfortunately, at the moment I don't have a system available to send you. If I could get you access to a machine remotely, would that be useful to you? I will need to check machine availability before I can promise you anything, but I'm willing to be your sponsor in the AMD Developer Center and approve a request for access. -Original Message- From: Justin Clift [mailto:[EMAIL PROTECTED] Sent: Monday, March 10, 2003 7:31 PM To: Andreas Jaeger Subject: Re: AMD x86-64 Hi Andreas, Have you heard anything back from the AMD guys in relation to this? We've not heard a single thing from them. :-( Regards and best wishes, Justin Clift Andreas Jaeger wrote: Justin Clift [EMAIL PROTECTED] writes: snip Yep, the aim is to allow PostgreSQL developers access to a system running x86-64 hardware as needed. Trying to get ahead of the ballgame these days. :) If you have hammer Hardware, I can provide you with a prerelease of our software, That would be cool Andreas, thanks. Now, just need to secure the hardware somehow. Personally, I feel that an email forwarded from you to the right people at AMD may help that significantly. At least, people from AMD should get in contact with us to see if something beneficial can be arranged. Ok, I forwarded your note and let's see whether they're interested (there're already a few commercial database like IBM DB2 ported). From past experience, it might be difficult to get hardware directly but let's wait for their answer. If you don't hear anything this week, feel free to ask me again, Andreas -- My grandfather once told me that there are two kinds of people: those who work and those who take the credit. He told me to try to be in the first group; there was less competition there. - Indira Gandhi ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster -- Martin Weinberg Phone: (413) 545-3821 Dept. of Astronomy FAX: (413) 545-4223 530 Graduate Research Tower [EMAIL PROTECTED] University of Massachusetts http://www.astro.umass.edu/~weinberg/ Amherst, MA 01003-4525 ---(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] Please, apply patch for current CVS
Bruce Momjian [EMAIL PROTECTED] writes: Patch applied. You patch indicated _int.c should be removed from CVS, so I have done so. This patch causes contrib/intarray to fail to build. $ make sed 's,MODULE_PATHNAME,$libdir/_int,g' _int.sql.in _int.sql make: *** No rule to make target `_int_bool.o', needed by `lib_int.a'. Stop. $ regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Groups and roles
Tom Lane wrote: Peter Eisentraut [EMAIL PROTECTED] writes: ... Therefore I ask whether everyone agrees that groups and roles are basically equivalent concepts (and perhaps that we might in the future strive to make groups more compatible with the roles as defined in the SQL standard). Or does anyone see that roles might be implemented separately from groups sometime? Just reading section 4.31.3 of the SQL99 draft, it seems that roles are pretty much interchangeable with groups, except that a role can be a member of another role while we don't presently allow groups to be members of other groups. So it seems that your question breaks down to: 1. Do we want to someday allow groups to have groups as members? (Seems reasonable to me.) Makes sense ... 2. Are there any other differences between groups and roles? (I'm not sure about this one.) To me some differences would make sense sense if we had additional priviledges. In Oracle a user needs a punch of rights to connect, to execute SQL, and so forth. If we had these features it would make sense to treat roles and groups seperately because: Imagine having groups having rights on dozens of tables. If these groups were assigned to a role it would be an easy task to block numerous groups from executing SQL at once. Currently a user has all rights of all groups he belongs to so it is damn hard to say that 1000 users should not be allowed to do anything for a period of time (because of maintenance or so). If all those users (but the superuser) had a certain role, the role could be modified instead of those 1000 users/groups (eg. REVOKE login, execute_sql FROM some_role). Currently roles don't make too much sense to me because we don't have the permissions for making roles useful (personally I don't think that it makes to have this stuff anyway). I guess adding a simple field to the system tables would be enough. If we had a field active (bool) in pg_shadow and pg_group we could solve some basic problems such as banning 1 groups at once more easily. This is the only problem we have from time to time. If there is too much user rights stuff around administering will be more painful (see Oracle). Regards, Hans -- Cybertec Geschwinde u Schoenig Ludo-Hartmannplatz 1/14, A-1160 Vienna, Austria Tel: +43/2952/30706; +43/664/233 90 75 www.cybertec.at, www.postgresql.at, kernel.cybertec.at ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] SELECT blocking on ALTER TABLE ADD FOREIGN KEY
Jim C. Nasby [EMAIL PROTECTED] writes: Is it really necessary to block reads on a table that is affected by adding a foreign key constraint? It's trickier than you seem to think. The command is adding an index, which at some point is going to affect plans for SELECTs on the table. It might be safe --- I don't think other processes can see the index until the ALTER commits --- but in general we do not risk doing schema modifications on tables with less than exclusive lock. You'd also have to think about whether this wouldn't increase the risk of deadlocks. For example, if you are doing several ALTERs in a transaction, what happens when a later ALTER of the same table *does* need exclusive lock? Upgrading a lock is a sure ticket to deadlock problems. 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])
Re: [HACKERS] Please, apply patch for current CVS
Thanks. Fixed. --- Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: Patch applied. You patch indicated _int.c should be removed from CVS, so I have done so. This patch causes contrib/intarray to fail to build. $ make sed 's,MODULE_PATHNAME,$libdir/_int,g' _int.sql.in _int.sql make: *** No rule to make target `_int_bool.o', needed by `lib_int.a'. Stop. $ regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org -- 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 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] [GENERAL] How to enumerate foreign key constraints after
Yes, a combination of the two would probably be better. You would need to be careful about function call names for FKeys, there are a fair number of them. Checking for 3 triggers with the function name starting with RI_FKey* would probably be better. Will the tgisconstraint flag always be set for these triggers? Will the function names still be RI_FKey* once these databases are migrated to postgres 7.4 or later? Until someone has a good reason to change things, they'll probably stay the same, so you will probably get a release or two out of it. But it is much easier to change the internal structures now, as PostgreSQL doesn't have nearly as much of a backward compatibility issue anymore. -- Rod Taylor [EMAIL PROTECTED] PGP Key: http://www.rbt.ca/rbtpub.asc signature.asc Description: This is a digitally signed message part
Re: [HACKERS] Pre-allocation of shared memory ...
=?ISO-8859-1?Q?Hans-J=FCrgen_Sch=F6nig?= [EMAIL PROTECTED] writes: I have two explanations for the following behaviour: a. a bug b. not enough shared memory WARNING: Message from PostgreSQL backend: The Postmaster has informed me that some other backend died abnormally and possibly corrupted shared memory. Is this a Linux machine? If so, the true explanation is probably (c): the kernel is kill 9'ing randomly-chosen database processes whenever it starts to feel low on memory. I would suggest checking the postmaster log to determine the signal number the failed backends are dying with. The client-side message does not give nearly enough info to debug such problems. There is also possibility (d): you have some bad RAM that is located in an address range that doesn't get used until the machine is under full load. But if the backends are dying with signal 9 then I'll take the kernel-kill theory. AFAIK the only good way around this problem is to use another OS with a more rational design for handling low-memory situations. No other Unix does anything remotely as brain-dead as what Linux does. Or bug your favorite Linux kernel hacker to fix the kernel. 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])
Re: [HACKERS] Pre-allocation of shared memory ...
Tom Lane wrote: =?ISO-8859-1?Q?Hans-J=FCrgen_Sch=F6nig?= [EMAIL PROTECTED] writes: I have two explanations for the following behaviour: a. a bug b. not enough shared memory WARNING: Message from PostgreSQL backend: The Postmaster has informed me that some other backend died abnormally and possibly corrupted shared memory. Is this a Linux machine? If so, the true explanation is probably (c): the kernel is kill 9'ing randomly-chosen database processes whenever it starts to feel low on memory. I would suggest checking the postmaster log to determine the signal number the failed backends are dying with. The client-side message does not give nearly enough info to debug such problems. There is also possibility (d): you have some bad RAM that is located in an address range that doesn't get used until the machine is under full load. But if the backends are dying with signal 9 then I'll take the kernel-kill theory. AFAIK the only good way around this problem is to use another OS with a more rational design for handling low-memory situations. No other Unix does anything remotely as brain-dead as what Linux does. Or bug your favorite Linux kernel hacker to fix the kernel. Is there no sysctl way to disable such kills? -- 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
Re: [HACKERS] PostgreSQL under Windows
On Wed, 2003-06-11 at 08:03, Bruno Wolff III wrote:
On Tue, Jun 10, 2003 at 22:34:04 -0700,
P.M [EMAIL PROTECTED] wrote:
I was thinking that PostgreSQL could help me to reduce
the cost of a such software. But i would like to know
what is the status of the PostGreSQL version under
Windows ?
I mean, i know that some of you are trying to do an
installer version under Windows for PostGreSQL and i
would like to know if a beta version already exist or
not
There will be a beta native windows port available in about 3 weeks.
It is currently possible to run postgresql on windows using cygwin.
If you don't want to wait and not big on cygwin, you can get a proof of
concept build at
http://sourceforge.net/project/showfiles.php?group_id=9764release_id=136623
It's not supported by anyone and I can't even say if it will work for
you, but it has worked for some in the past and might be a good way to
get your feet wet.
Once you get up and running be sure to come back and help us beta test!
:-)
Robert Treat
--
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] Pre-allocation of shared memory ...
Bruce Momjian [EMAIL PROTECTED] writes: Tom Lane wrote: AFAIK the only good way around this problem is to use another OS with a more rational design for handling low-memory situations. No other Unix does anything remotely as brain-dead as what Linux does. Or bug your favorite Linux kernel hacker to fix the kernel. Is there no sysctl way to disable such kills? The -ac kernel patches from Alan Cox have a sysctl to control memory overcommit--you can set it to track memory usage and fail allocations when memory runs out, rather than the random kill behavior. I'm not sure whether those have made it into the stock kernel yet, but the vendor kernels (such as Red Hat's) might have it too. -Doug ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Pre-allocation of shared memory ...
On Wed, Jun 11, 2003 at 07:35:20PM -0400, Doug McNaught wrote: Bruce Momjian [EMAIL PROTECTED] writes: Is there no sysctl way to disable such kills? The -ac kernel patches from Alan Cox have a sysctl to control memory overcommit--you can set it to track memory usage and fail allocations when memory runs out, rather than the random kill behavior. I'm not sure whether those have made it into the stock kernel yet, but the vendor kernels (such as Red Hat's) might have it too. Yeah, I see it in the Mandrake kernel. But it's not in stock 2.4.19, so you can't assume everybody has it. -- Alvaro Herrera (alvherre[a]dcc.uchile.cl) ¿Qué importan los años? Lo que realmente importa es comprobar que a fin de cuentas la mejor edad de la vida es estar vivo (Mafalda) ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Question about simple function folding optimization
sorry for delay ... installing opensp right now ... On Sun, 1 Jun 2003, Peter Eisentraut wrote: Tom Lane writes: (the documentation build at developer.postgresql.org doesn't seem to have updated since before the server move :-() The program called onsgmls (or maybe nsgmls) is missing. Marc, can you please install it? It should be in a package called opensp. -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] Linux startup script
Patch applied. Thanks. --- Darko Prenosil wrote: I have noticed that after /etc/init.d/postgresql restart, postmaster is no longer writes to serverlog. (RedHat 9). Here is fixed restart section. restart) echo -n Restarting PostgreSQL: su - $PGUSER -c $DAEMON restart -D '$PGDATA' -s -m fast -l $PGLOG echo ok ;; In version 7.3.3 is missing -l $PGLOG at the end of $DAEMON restart command. Regards ! ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED] -- 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
