Re: [HACKERS] how to extend the catalog?
"kevin" <[EMAIL PROTECTED]> writes: > I want to extend the catalog, What do you want to do *exactly*? > is it enough: > 1. add pg_xxx.h > 2.modify pg_attribute.h, pg_class.h, pg_type.h, catname.h, >indexing.h, indexing.c, Makefile You shouldn't need to touch pg_attribute.h, pg_class.h, pg_type.h, unless you are hacking one of the bootstrapped system tables or adding a new table that has to be known to the bootstrapper. regards, tom lane ---(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] Warning about oid/xid wraparound
Bruce Momjian <[EMAIL PROTECTED]> writes: >> None of it is appropriate anymore... > OID wraparound isn't a problem? Well, it could be a problem if an app is relying on uniqueness of OIDs without having installed an unique index on OIDs. However, I do not think it is the business of the backend to issue nuisance warnings that will come out whether an app is using unsafe practices or not. regards, tom lane ---(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] [JDBC] NULLs and sort order
Peter Eisentraut <[EMAIL PROTECTED]> writes: > Rene Pijlman writes: >> Currently the JDBC driver says: >> - Backend >= 7.2 sorts nulls higher than any other value in a >> domain. In other words: ascending means nulls at the end, >> descending means nulls at the start. >> - Backend < 7.2 puts nulls at the end regardless of sort order. > That is correct. Actually it's more complex than that. 7.2 will provide the above-stated consistent ordering of nulls relative to non-nulls. The problem with earlier versions is that the ordering of nulls depends on what plan the optimizer chooses for the query: sorting based on a scan of a btree index would work the same as is described for 7.2, whereas sorting based on an explicit sort step would put the nulls at the end (for either ASC or DESC sort). So there was *no* consistent behavior at all in prior versions. The fix that's been applied for 7.2 is to make explicit sorts act the same as indexscans already did. regards, tom lane ---(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] Warning about oid/xid wraparound
> Bruce Momjian <[EMAIL PROTECTED]> writes: > > This patch warns about oid/xid wraparound during VACUUM. Apply the part > > people consider appropriate. I may not be around before beta. > > None of it is appropriate anymore... OID wraparound isn't a problem? -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Warning about oid/xid wraparound
Bruce Momjian <[EMAIL PROTECTED]> writes: > This patch warns about oid/xid wraparound during VACUUM. Apply the part > people consider appropriate. I may not be around before beta. None of it is appropriate anymore... regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] querying system catalogs to extract foreign keys
Hi, In addition to this, Joel Burton's paper regarding Hacking the Referential Integrity tables gives very good insight into how to find out exactly what you're looking for, and the final example of SQL code at the end of the article will work as is : http://techdocs.postgresql.org/techdocs/hackingreferentialintegrity.php Modified code to show what you want : SELECT c.relname as "Trigger Table", substr(f.proname, 9) as "Trigger Function", t.tgconstrname as "Constraint Name", c2.relname as "Constraint Table", t.tgdeferrable as "Deferrable?", t.tginitdeferred as "Initially Deferred?", t.tgargs as "Trigger Arguments" FROM pg_trigger t, pg_class c, pg_class c2, pg_proc f WHERE t.tgrelid=c.oid AND t.tgconstrrelid=c2.oid AND tgfoid=f.oid AND t.tgenabled = 't' AND tgname ~ '^RI_' ORDER BY t.oid; Note the "Trigger Arguments" (bytea) column is where you look to find out the fields involved in the RI trigger. :-) Regards and best wishes, Justin Clift Rene Pijlman wrote: > > On 13 Sep 2001 22:56:16 -0700, you wrote: > >I tried to use the getImportedKeys and getExportedKeys of > >java.sql.DatabaseMetadata... But it didnt give any expected > >results... > > This is probably a limitation or bug in the JDBC driver. Please > post details of your problem on [EMAIL PROTECTED] E.g. > what results did you get, and what did you not get? > > >So can anyone tell me how to query the system > >catalogs to extract this info?? > > The system catalogs are documented on > http://www.postgresql.org/idocs/index.php?catalogs.html > > Regards, > René Pijlman <[EMAIL PROTECTED]> > > ---(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 -- "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 6: Have you searched our list archives? http://archives.postgresql.org
[HACKERS] Warning about oid/xid wraparound
This patch warns about oid/xid wraparound during VACUUM. Apply the part
people consider appropriate. I may not be around before beta.
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED] | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup.| Drexel Hill, Pennsylvania 19026
Index: src/backend/commands/vacuum.c
===
RCS file: /home/projects/pgsql/cvsroot/pgsql/src/backend/commands/vacuum.c,v
retrieving revision 1.195
diff -c -r1.195 vacuum.c
*** src/backend/commands/vacuum.c 2001/05/25 15:45:32 1.195
--- src/backend/commands/vacuum.c 2001/06/13 21:01:37
***
*** 17,22
--- 17,23
#include
#include
#include
+ #include
#include
#include
#include
***
*** 159,166
static bool enough_space(VacPage vacpage, Size len);
static void init_rusage(VacRUsage *ru0);
static char *show_rusage(VacRUsage *ru0);
-
/*
* Primary entry point for VACUUM and ANALYZE commands.
*/
--- 160,167
static bool enough_space(VacPage vacpage, Size len);
static void init_rusage(VacRUsage *ru0);
static char *show_rusage(VacRUsage *ru0);
+ static void check_limits(void);
/*
* Primary entry point for VACUUM and ANALYZE commands.
*/
***
*** 236,241
--- 237,243
/* clean up */
vacuum_shutdown();
+ check_limits();
}
/*
***
*** 2645,2648
--- 2647,2674
(int) (ru1.tv.tv_usec - ru0->tv.tv_usec) / 1);
return result;
+ }
+
+ /*
+ *check if we are near OID or XID wraparound
+ */
+ static void check_limits(void)
+ {
+ Oid nextOid;
+
+ /* If we are 75% to the limit, warn the user */
+ if (GetCurrentTransactionId() > UINT_MAX - UINT_MAX / 4)
+ elog(NOTICE,"You are %.0f%% toward the limit for transaction ids.\n"
+ "\t Dumping your databases, running initdb, and reloading will
+reset\n"
+ "\t the transaction id counter.",
+ GetCurrentTransactionId() / (float)UINT_MAX * 100);
+
+ /* If we are 75% to the limit, warn the user */
+ GetNewObjectId(&nextOid);
+ if (nextOid > OID_MAX - OID_MAX / 4)
+ elog(NOTICE,"You are %.0f%% toward the limit for object ids.\n"
+ "\t If you are not using object ids as primary keys, dumping
+your\n"
+ "\t databases, running initdb, and reloading will reset\n"
+ "\t the oid counter.",
+ (float)nextOid / OID_MAX * 100);
}
---(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] [Fwd: [Fwd: [tao-users] FW: HEADS UP: CVSup timestamp bug]]
Got it upgraded on the cvsup.postgresql.org server ... still have to do the other servers ... On Wed, 12 Sep 2001, Thomas Lockhart wrote: > New problems with CVSup. We should all upgrade asap, though I'm not sure > of the current status of builds for non-FreeBSD machines. Marc, could we > possibly install this on the postgresql.org machine(s)? > > - Thomas > > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] > Sent: Sunday, September 09, 2001 19:40 PM > To: [EMAIL PROTECTED] > Subject: HEADS UP: CVSup timestamp bug > > > This morning a bug was discovered in most versions of CVSup up to > and including SNAP_16_1c. The bug causes all newly-updated files to > receive incorrect timestamps. Usually the files receive timestamps > from early in 1970. This bug has been present for a very long time, > but it only began to have an effect when the Unix representation of > the date and time passed 1,000,000,000. That occurred on 9 September > 2001 at 01:46:40 UTC. Yes, other people had Y2K bugs, but I managed > to produce an S1G bug. > > I have fixed the bug and have released a new snapshot of CVSup, > SNAP_16_1d. I have also created binary packages for FreeBSD-4.x which > can be installed using "pkg_add". For information about updating your > CVSup installation, look here: > > http://people.freebsd.org/~jdp/s1g/ > > To fix the bug, both the client and the server need to be upgraded to > SNAP_16_1d. The FreeBSD mirror site maintainers have been working > feverishly to upgrade their installations. Many of them are already > upgraded, and the rest will be upgraded soon. Meanwhile, all CVSup > users should upgrade their CVSup installations. > > I apologize for the inconvenience caused by this bug, and thank you > in advance for your patience. > > John Polstra > ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
[HACKERS] plperl rpm package
just curious, is there any reason why a plperl RPM package isn't included with the "official" distribution (from postgres website)? No incredible deal just to build it myself, just wondering. -rchit ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Status of index location patch
Yes that is exactly what I am going to do for 7.3 (had trouble adding tblNode to pg_class so I stopped for now...) > > Can you explain how I would get the tblNode for an existing database > > index files if it doesn't have the same OID as the database entry in > > pg_databases. > > Well, keeping in mind future tablespace implementation I would > add tblNode to pg_class and in pg_databases I'd have > defaultTblNode and indexTblNode. > If it's too late to do for 7.2 then let's wait till 7.3. > > Vadim > > > > ---(end of broadcast)--- > TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED] > > ---(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] Status of index location patch
> Can you explain how I would get the tblNode for an existing database > index files if it doesn't have the same OID as the database entry in > pg_databases. Well, keeping in mind future tablespace implementation I would add tblNode to pg_class and in pg_databases I'd have defaultTblNode and indexTblNode. If it's too late to do for 7.2 then let's wait till 7.3. Vadim ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Status of index location patch
Vadim, I guess I am still confused... In dbcommands.c resolve_alt_dbpath() takes the db oid as a argument. This number is used to "find" the directory where the data files live. All the patch does is put the indexes into a "db oid"_index directory instead of "db oid" This is for tables snprintf(ret, len, "%s/base/%u", prefix, dboid); This is for indexes snprintf(ret, len, "%s/base/%u_index", prefix, dboid); And in catalog.c tables: sprintf(path, "%s/base/%u/%u", DataDir, rnode.tblNode, rnode.relNode); indexes: sprintf(path, "%s/base/%u_index/%u", DataDir, rnode.tblNode,rnode.relNode); Can you explain how I would get the tblNode for an existing database index files if it doesn't have the same OID as the database entry in pg_databases. Jim > > Just wondering what is the status of this patch. Is seems from comments > > that people like the idea. I have also looked in the archives for other > > people looking for this kind of feature and have found alot of interest. > > > > If you think it is a good idea for 7.2, let me know what needs to be > > changed and I will work on it this weekend. > > Just change index' dir naming as was already discussed. > > Vadim > > ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
[HACKERS] [Fwd: [ADMIN] Transaction Aborting on sql call failure]
Sorry, I forgot to repost in hackers. Stephan Szabo wrote: > > > We are running into a situation where psql is aborting the transaction > > when one call returns an error. Is there a way to continue on with > > transaction or at least save what has already happened (like an Oracle > > Save Point)? > > Not yet, although savepoints have been talked about. (maybe 7.3?) New SMGR opens the way to this *very important* feature. Vadim? Another proposal to solve this was recently proposed, not using WAL. Bruce? I think this issue is rasing in the lists frequently enough, as for giving it top priority. Maybe is isn't so easy. Comments? Thanks Regards, Haroldo. ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Status of index location patch
On Saturday 15 September 2001 03:03, Jim Buttafuoco wrote: > Just wondering what is the status of this patch. Is seems from comments > that people like the idea. I have also looked in the archives for other > people looking for this kind of feature and have found alot of interest. Can we have a web based tracking system for patch tracking? I am ready to volunteer. I may be of some help. Shridhar _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
