[GENERAL] mailing list/newsgroup disconnect
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 There seems to be a disconnect between the mailing list and the newsgroup right now. I received a bunch of replies via email that did not show up in the newsgroup. (I did not receive any messages that were sent to the mailing list and not to me personally). Is there someone I should mention this to or does he already know? Sim -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkiX/VoACgkQjDX6szCBa+ppsACdHVwJB6oGkX8+xR5U0YYPL08W UI8AoMq8Frkq/dl/Z860ej/n+kFWuKQV =xNYA -END PGP SIGNATURE- -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
[GENERAL] replication only
i read about the replication possibilities with postgresql. If i just need some replication ( without failover stuff ) to 1 standby server, what would be the best option to go with. Slony i presume, although schema chanages are not propagated. thanks jef peeraer -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
[GENERAL] Vacuum Vs Vacuum Full
Hi, I've been trying to get to the bottom of the differences between a vacuum and a vacuum full, it seems to me that the difference is that a vacuum full also recovers disk space(and locks things making it less than useful on production servers). But I believe that both will fix the transaction ID(example message below). "WARNING: database "mydb" must be vacuumed within 177009986 transactions HINT: To avoid a database shutdown, execute a full-database VACUUM in "mydb"."Which is reason I ask the question, is full vacuum backup useful for anything other than reclaiming disk space. On a side note, we doubled our page slots, but they ran out much faster(of course) than we thought, is there a good sql statement that can tell you what your current transaction ID is? Thanks in advance. Cheers, Rob _ Are you paid what you're worth? Find out: SEEK Salary Centre http://a.ninemsn.com.au/b.aspx?URL=http%3A%2F%2Fninemsn%2Eseek%2Ecom%2Eau%2Fcareer%2Dresources%2Fsalary%2Dcentre%2F%3Ftracking%3Dsk%3Ahet%3Asc%3Anine%3A0%3Ahot%3Atext&_t=764565661&_r=OCT07_endtext_salary&_m=EXT
[GENERAL] Returning Cursor
Hello, I am a developer working on postgres. I just wrote a function which ll return a refcurosor as shown below. CREATE OR REPLACE FUNCTION reffunc(refcursor) RETURNS refcursor AS $BODY$ BEGIN OPEN $1 FOR SELECT * FROM SAM1; RETURN $1; END; $BODY$ LANGUAGE 'plpgsql' VOLATILE COST 100; i have problems accessing this function from my middle tier i.e VC++. I wrote a VC statement to retrieve values from this refcursor using a record set. I cant access any of the values that the select statement in the function should retrieve.When we executed the above function from VC we only got the cursor name. We've been trying to access the values for the past one week. Can you please help me by sending me a sample code as to how to get the values in a recordset using this refcursor. Please do reply. This is very urgent. Thanks and regards Ravi Kiran L
Re: [GENERAL] replication only
On 05/08/2008 08:21, Jef Peeraer wrote: would be the best option to go with. Slony i presume, although schema chanages are not propagated. Schema changes *are* propagated in Slony, using the EXECUTE SCRIPT statement: http://www.slony.info/documentation/stmtddlscript.html Ray. -- Raymond O'Donnell, Director of Music, Galway Cathedral, Ireland [EMAIL PROTECTED] Galway Cathedral Recitals: http://www.galwaycathedral.org/recitals -- -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] is a 'pairwise' possible / feasible in SQL?
On Mon, Aug 04, 2008 at 05:00:31PM -0400, Rajarshi Guha wrote: > On Aug 4, 2008, at 4:55 PM, Francisco Reyes wrote: > > select a.cid as ac, b.cid as bc, count(*) from aic_cid a left > >outer join > >aic_cid b on a.cid <>b.cid and a.id = b.id where b.cid is not null > >group by > >a.cid, b.cid order by a.cid; > > > >Is that what you are looking for? > > Thanks a lot - this is very close. Ideally, I'd want unique pairs You just need to change the "a.cid <> b.cid" equality to something non-symmetric, i.e. "a.cid < b.cid". I'm also not sure why an outer join is being used. I've rewritten it to: SELECT a.cid AS ac, b.cid AS bc, count(*) FROM aic_cid a, aic_cid b WHERE a.id = b.id AND a.cid < b.cid GROUP BY a.cid, b.cid ORDER BY a.cid, b.cid; and seem to get similar results. Sam -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
[GENERAL] equivalent of "using namespace" with schema
Is there anything simpler than processing the search_path to obtain the same effect of using namespace XXX or if I'd like to execute the same set of operations on the same "objects" just in a different schema? -- Ivan Sergio Borgonovo http://www.webthatworks.it -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Initdb problem on debian mips cobalt: Bus error
> > "Tom Lane" <[EMAIL PROTECTED]> writes: > > > > > (Rather than trying to browbeat configure into > doing this, I'd suggest > > > manually adjusting CFLAGS in src/Makefile.global, > then "make clean" and > > > rebuild.) > > > > eh? either of these should work fine: > > > > ./configure --enable-debug CFLAGS=-O0 > > CFLAGS=-O0 ./configure --enable-debug > > > > And yes, you have to do make clean. I often forget > that step :( > > I find it easier to create a src/Makefile.custom containing > the > following line: > > CFLAGS := $(patsubst -O2,-O0,$(CFLAGS)) > > When I'm done I just rename the file away to keep it > around for next > time. I'm going to keep things simple and just do as Tom says by editing Makefile.global and we'll see what happens. Hopefully at the very lease it'll compile a little quicker with the optimization off. __ Not happy with your email address?. Get the one you really want - millions of new email addresses available now at Yahoo! http://uk.docs.yahoo.com/ymail/new.html -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Initdb problem on debian mips cobalt: Bus error
"Tom Lane" <[EMAIL PROTECTED]> writes: > Gregory Stark <[EMAIL PROTECTED]> writes: >> "Tom Lane" <[EMAIL PROTECTED]> writes: >>> (Rather than trying to browbeat configure into doing this, I'd suggest >>> manually adjusting CFLAGS in src/Makefile.global, then "make clean" and >>> rebuild.) > >> eh? either of these should work fine: >> ./configure --enable-debug CFLAGS=-O0 >> CFLAGS=-O0 ./configure --enable-debug > > The trouble with that approach is that it overrides *everything* that > configure would normally put into CFLAGS. I only want one thing > changing, please ... this is confusing enough already. Eh? $ ./configure ... configure: using CFLAGS=-O2 -Wall -Wmissing-prototypes -Wpointer-arith -Winline -Wdeclaration-after-statement -Wendif-labels -fno-strict-aliasing -fwrapv configure: using CPPFLAGS= -D_GNU_SOURCE configure: using LDFLAGS= -Wl,--as-needed $ ./configure CFLAGS=-O0 ... configure: using CFLAGS=-O0 -Wall -Wmissing-prototypes -Wpointer-arith -Winline -Wdeclaration-after-statement -Wendif-labels -fno-strict-aliasing -fwrapv configure: using CPPFLAGS= -D_GNU_SOURCE configure: using LDFLAGS= -Wl,--as-needed -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's On-Demand Production Tuning -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] replication only
In response to Jef Peeraer <[EMAIL PROTECTED]>: > > i read about the replication possibilities with postgresql. If i just need > some replication ( without failover stuff ) to 1 standby server, what > would be the best option to go with. Your description of you requirements is very lacking, so much so that any attempt at suggesting a "best" option would be pointless. Provide some more information on your requirements and people will be able to answer intelligently. -- Bill Moran Collaborative Fusion Inc. http://people.collaborativefusion.com/~wmoran/ [EMAIL PROTECTED] Phone: 412-422-3463x4023 -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] replication only
On Tue, 5 Aug 2008, Bill Moran wrote: > In response to Jef Peeraer <[EMAIL PROTECTED]>: > > > > i read about the replication possibilities with postgresql. If i just need > > some replication ( without failover stuff ) to 1 standby server, what > > would be the best option to go with. > > Your description of you requirements is very lacking, so much so that > any attempt at suggesting a "best" option would be pointless. > > Provide some more information on your requirements and people will be > able to answer intelligently. my apology, i tried to be brief. i've got a main database, where all transactions end up. Daily we make a backup (pg_dumpall) and restore the first database in a sort of backup database. This backup database is mainly used to do reporting. To automate this process for the backup database and to minimize the out-of-sync state, i should like to use replication. The second backup database is only used as read-only, except for some third party software that writes to 1 table. jef peeraer > > -- > Bill Moran > Collaborative Fusion Inc. > http://people.collaborativefusion.com/~wmoran/ > > [EMAIL PROTECTED] > Phone: 412-422-3463x4023 > > -- > Sent via pgsql-general mailing list (pgsql-general@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-general > > -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Vacuum Vs Vacuum Full
On Monday 04 August 2008 11:04:00 pm Robert Shaw wrote: > Hi, > > I've been trying to get to the bottom of the differences between a vacuum > and a vacuum full, it seems to me that the difference is that a vacuum full > also recovers disk space(and locks things making it less than useful on > production servers). But I believe that both will fix the transaction > ID(example message below). > > "WARNING: database "mydb" must be vacuumed within 177009986 transactions > HINT: To avoid a database shutdown, execute a full-database VACUUM in > "mydb"."Which is reason I ask the question, is full vacuum backup useful > for anything other than reclaiming disk space. > > On a side note, we doubled our page slots, but they ran out much faster(of > course) than we thought, is there a good sql statement that can tell you > what your current transaction ID is? > > Thanks in advance. > > Cheers, > Rob > Actually its not asking for a VACUUM FULL but a VACUUM of the full database, instead of selected tables. See below for complete details http://www.postgresql.org/docs/8.3/interactive/routine-vacuuming.html#VACUUM-FOR-WRAPAROUND -- Adrian Klaver [EMAIL PROTECTED] -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] replication only
In response to Jef Peeraer <[EMAIL PROTECTED]>: > > On Tue, 5 Aug 2008, Bill Moran wrote: > > > In response to Jef Peeraer <[EMAIL PROTECTED]>: > > > > > > i read about the replication possibilities with postgresql. If i just > > > need > > > some replication ( without failover stuff ) to 1 standby server, what > > > would be the best option to go with. > > > > Your description of you requirements is very lacking, so much so that > > any attempt at suggesting a "best" option would be pointless. > > > > Provide some more information on your requirements and people will be > > able to answer intelligently. > my apology, i tried to be brief. > i've got a main database, where all transactions end up. Daily we make a > backup (pg_dumpall) and restore the first database in a sort of backup > database. This backup database is mainly used to do reporting. > To automate this process for the backup database and to minimize the > out-of-sync state, i should like to use replication. > The second backup database is only used as read-only, > except for some third party software that writes to 1 table. You'd probably be best with Slony, just don't replicate that 1 table that you'll need to write to. -- Bill Moran Collaborative Fusion Inc. http://people.collaborativefusion.com/~wmoran/ [EMAIL PROTECTED] Phone: 412-422-3463x4023 -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Initdb problem on debian mips cobalt: Bus error
Gregory Stark <[EMAIL PROTECTED]> writes: > "Tom Lane" <[EMAIL PROTECTED]> writes: >> The trouble with that approach is that it overrides *everything* that >> configure would normally put into CFLAGS. I only want one thing >> changing, please ... this is confusing enough already. > Eh? Sorry, memory failed me: what gets overridden is CFLAGS set by the platform-specific template file. That's not a big problem on mainstream platforms, but on some it will break your build. regards, tom lane -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
[GENERAL] FTS on patterns
Hello, In our application we need a pattern based text search, that is if user supplies 'foo bar' he receives only documents containing words that begin with 'foo' or 'bar', including themselves (something similar to MySQL '+foo* +bar*' text search query). Currently we use separate table for unique words in document and do LIKE 'foo%' search on that table, combining the results afterwards, and I am not really happy with that solution because of its speed and overcomplication of the queries involved. Does anyone know of a better approach? Could this be achieved with Postgres full text search?
Re: [GENERAL] FTS on patterns
tsearch can help you; i have a system with it ... and its ok. El mar, 05-08-2008 a las 18:03 +0400, Vyacheslav Kalinin escribió: > Hello, > > In our application we need a pattern based text search, that is if > user supplies 'foo bar' he receives only documents containing words > that begin with 'foo' or 'bar', including themselves (something > similar to MySQL '+foo* +bar*' text search query). Currently we use > separate table for unique words in document and do LIKE 'foo%' search > on that table, combining the results afterwards, and I am not really > happy with that solution because of its speed and overcomplication of > the queries involved. Does anyone know of a better approach? Could > this be achieved with Postgres full text search? > > > -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] FTS on patterns
"Vyacheslav Kalinin" <[EMAIL PROTECTED]> writes: > In our application we need a pattern based text search, that is if user > supplies 'foo bar' he receives only documents containing words that begin > with 'foo' or 'bar' There's support for prefix text search in CVS HEAD, but not in any released version ... regards, tom lane -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Vacuum Vs Vacuum Full
Adrian Klaver wrote: On Monday 04 August 2008 11:04:00 pm Robert Shaw wrote: "WARNING: database "mydb" must be vacuumed within 177009986 transactions HINT: To avoid a database shutdown, execute a full-database VACUUM in "mydb"."Which is reason I ask the question, is full vacuum backup useful for anything other than reclaiming disk space. Actually its not asking for a VACUUM FULL but a VACUUM of the full database, instead of selected tables. See below for complete details http://www.postgresql.org/docs/8.3/interactive/routine-vacuuming.html#VACUUM-FOR-WRAPAROUND BTW, what version of PostgreSQL is this? Database-wide vacuum is no longer required for XID wraparound issues. I think this was an 8.3 change but might have happened in 8.2, I don't remember. Matt -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] replication only
On Tue, August 5, 2008 9:21 am, Jef Peeraer wrote: > > i read about the replication possibilities with postgresql. If i just need > some replication ( without failover stuff ) to 1 standby server, what > would be the best option to go with. Slony i presume, although schema > chanages are not propagated. Skytools (http://pgfoundry.org/projects/skytools/) has a considerably lower learning curve compared to Slony. Nothing wrong with Slony, but recovering from replication problems with skytools is far easier, and it's just much simpler to use -- not as flexible and as powerful as Slony, but if all you need to do is replicate some tables with minimum fuss and without having to learn a new language, then Skytools (based on my personal experience with a cluster and Slony versus Skytools) is my recommendation. Regards Henry -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] replication only
On Tue, Aug 5, 2008 at 7:34 AM, Bill Moran <[EMAIL PROTECTED]> wrote: > In response to Jef Peeraer <[EMAIL PROTECTED]>: > > You'd probably be best with Slony, just don't replicate that 1 table > that you'll need to write to. That's one of my favorite things about slony. -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Vacuum Vs Vacuum Full
"Matthew T. O'Connor" <[EMAIL PROTECTED]> writes: >> On Monday 04 August 2008 11:04:00 pm Robert Shaw wrote: >>> "WARNING: database "mydb" must be vacuumed within 177009986 transactions >>> HINT: To avoid a database shutdown, execute a full-database VACUUM in >>> "mydb". > BTW, what version of PostgreSQL is this? Database-wide vacuum is no > longer required for XID wraparound issues. I think this was an 8.3 > change but might have happened in 8.2, I don't remember. 8.2. But you could still get that message, even in CVS HEAD, if autovacuum was failing to complete for some reason (and had been failing for quite a long time). regards, tom lane -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Vacuum Vs Vacuum Full
Tom Lane wrote: "Matthew T. O'Connor" <[EMAIL PROTECTED]> writes: BTW, what version of PostgreSQL is this? Database-wide vacuum is no longer required for XID wraparound issues. I think this was an 8.3 change but might have happened in 8.2, I don't remember. 8.2. But you could still get that message, even in CVS HEAD, if autovacuum was failing to complete for some reason (and had been failing for quite a long time). Should that message to updated since a database-wide vacuum is no longer required, or are you saying that the message is still relevant is some corner cases? -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Vacuum Vs Vacuum Full
"Matthew T. O'Connor" <[EMAIL PROTECTED]> writes: > Tom Lane wrote: >> 8.2. But you could still get that message, even in CVS HEAD, if >> autovacuum was failing to complete for some reason (and had been >> failing for quite a long time). > Should that message to updated since a database-wide vacuum is no longer > required, or are you saying that the message is still relevant is some > corner cases? I think the message is okay as-is, or at least that the code doesn't have the information available to do better --- it knows which database is the most problematic, but not which table(s) within that DB most need vacuuming. So the easiest manual fix is still a DB-wide vacuum. Besides which, if you've got one problem table then you've probably got more than one. The odds of anyone seeing this message in the field in 8.2 or later seem pretty remote anyway, so I'm not feeling like we should expend tremendous effort to make it better. regards, tom lane -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
[GENERAL] max_fsm_relations question
Hi. I have a database that is created and populated by a Perl script. (FWIW, the size of this database is about 12GB, according to pg_database_size()). If, right after the database is built, I connect to it and manually run VACUUM ANALYZE, I get the warning NOTICE: max_fsm_relations(1000) equals the number of relations checked HINT: You have at least 1000 relations. Consider increasing the configuration parameter "max_fsm_relations". I find this puzzling because the database has only 120 relations. Is there a way I can structure the populating of the database to get rid of this message? E.g. would it help to have the script run VACUUM after it populates each new table? Thanks! Kynn
Re: [GENERAL] max_fsm_relations question
In response to "Kynn Jones" <[EMAIL PROTECTED]>: > Hi. I have a database that is created and populated by a Perl script. > (FWIW, the size of this database is about 12GB, according to > pg_database_size()). > > If, right after the database is built, I connect to it and manually run > VACUUM ANALYZE, I get the warning > > NOTICE: max_fsm_relations(1000) equals the number of relations checked > HINT: You have at least 1000 relations. Consider increasing the > configuration parameter "max_fsm_relations". > > I find this puzzling because the database has only 120 relations. How many other databases do you have on that server? fsm_relations has to track all relations in all databases. > Is there a way I can structure the populating of the database to get rid of > this message? E.g. would it help to have the script run VACUUM after it > populates each new table? No. If that parameter is too low you need to raise it, period. -- Bill Moran Collaborative Fusion Inc. http://people.collaborativefusion.com/~wmoran/ [EMAIL PROTECTED] Phone: 412-422-3463x4023 -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
[GENERAL] Installation problem ~!
Hi, I have recently tried to install pgsql on Windows but I get the following error consistently ! Error : " psql : recieved invalid response to SSL negotiation ! " This error is encountered as soon as I try to start psql ! The installation completes fine , but I'm not able to do anything with psql ! Please help ! Another thing I had about six months back installed and used the same thing though a version which is not as new as this one ( I had run 8.3.1 I think ! ) So I dont understand the problem I'm facing now ! Thanking you in anticipation ! - Harshad Pethe Student, Nashik, India
[GENERAL] Moved database question
I had to move my database to a new disk. I dropped the original after a pg_dump and then removed the old directory. I then ran initdb on the new location, created the database and restored from the pg_dump. My problem now is that I have to supply the full pathnames to start or stop the server. Otherwise it still wants to access the old location which no longer exists. What am I missing to make the new (and only existing) location be the Postgres default? Thanks, Bayless
Re: [GENERAL] Moved database question
Bayless Kirtley wrote: I had to move my database to a new disk. I dropped the original after a pg_dump and then removed the old directory. I then ran initdb on the new location, created the database and restored from the pg_dump. My problem now is that I have to supply the full pathnames to start or stop the server. Otherwise it still wants to access the old location which no longer exists. What am I missing to make the new (and only existing) location be the Postgres default? You didn't tell us what platform you're using. What does your startup script have for PGDATA? -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Moved database question
On Tue, Aug 5, 2008 at 12:45 PM, Bayless Kirtley <[EMAIL PROTECTED]> wrote: > I had to move my database to a new disk. I dropped the original after a > pg_dump and then removed the old directory. I then ran initdb on the new > location, created the database and restored from the pg_dump. > > My problem now is that I have to supply the full pathnames to start or stop > the server. Otherwise it still wants to access the old location which no > longer exists. What am I missing to make the new (and only existing) > location be the Postgres default? That very much depends on which OS / version you're on and how you installed postgresql... -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
[GENERAL] Heikki's Visibility Map for postgres 8.4?
Hi, Is Heikki's Visibility Map patch included for the Postgresql 8.4 version http://archives.postgresql.org/pgsql-hackers/2007-11/msg00142.php If not whats the status of that patch? Im especially interested in the index-only scan mentioned there!!! Thanks
[GENERAL] What happen to the VARATT_SIZEP macro in version 8.3?
Hello all, I have C code which defines some user defined postgres functions. This code has been used with Postgres version 7.4 and it uses the VARATT_SIZEP macro. I updated to Postgres version 8.3 and attempted to compile my C code and noticed that the VARATT_SIZEP macro (which my code uses) no longer is defined in the 8.3 code base (which needless to say prevents my code from compiling). The macro use to be defined in postgres.h in version 7.4. What replaces the VARATT_SIZEP macro in version 8.3? I have spent a long time checking the documentation and have not found the answer. Thanks P.S. I posted this question to the wrong mailing list earlier and meant to post it to this list. I apologize to the people who are on both lists that got this message twice.
Re: [GENERAL] Initdb problem on debian mips cobalt: Bus error
http://privatepaste.com/cbY2S4JhtA Very little difference with the -O0 __ Not happy with your email address?. Get the one you really want - millions of new email addresses available now at Yahoo! http://uk.docs.yahoo.com/ymail/new.html -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] replication only
On Tue, Aug 05, 2008 at 06:03:19AM +0200, Henry wrote: > just much simpler to use -- not as flexible and as powerful as Slony, but > if all you need to do is replicate some tables with minimum fuss and > without having to learn a new language, then Skytools (based on my > personal experience with a cluster and Slony versus Skytools) is my > recommendation. This is probably good advice. For simple cases, Slony's sort of a pain in the neck. A -- Andrew Sullivan [EMAIL PROTECTED] +1 503 667 4564 x104 http://www.commandprompt.com/ -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] What happen to the VARATT_SIZEP macro in version 8.3?
On 8/5/08, Don Pannese <[EMAIL PROTECTED]> wrote: > > I have C code which defines some user defined postgres functions. This code > has been used with Postgres version 7.4 and it uses the VARATT_SIZEP macro. > seems that macro was deprecated in 8.3... this is the commit that removed it: http://archives.postgresql.org/pgsql-committers/2007-02/msg00517.php The new comment says: ! * TOASTed. Generally, only the code closely associated with TOAST logic ! * should mess directly with struct varattrib or use the VARATT_FOO macros. Why you need that macro at all? Now, of you really need it maybe you can make your own wrapper in ine of your includes: #define VARATT_SIZEP(_PTR) \ VARATT_SIZEP_DEPRECATED(PTR) -- regards, Jaime Casanova Soporte y capacitación de PostgreSQL Guayaquil - Ecuador Cel. (593) 87171157 -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] What happen to the VARATT_SIZEP macro in version 8.3?
> > What replaces the VARATT_SIZEP macro in version 8.3? I have > spent a long > time checking the documentation and have not found the > answer. > SET_VARSIZE __ Not happy with your email address?. Get the one you really want - millions of new email addresses available now at Yahoo! http://uk.docs.yahoo.com/ymail/new.html -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
[GENERAL] Update tsvector trigger
Hi, i´m trying to do a trigger that its called when update or insert, that update the tsvectors, for text-search. Here´s my code: create table x( cod serial, texto text, vectors tsvector, constraint pk primary key(cod) ); CREATE OR REPLACE FUNCTION atualiza_vectors() RETURNS trigger AS $$ BEGIN IF NEW.texto<>NULL THEN UPDATE x SET vectors = to_tsvector(lower(to_ascii(NEW.texto))) where cod= NEW.cod; END IF; RETURN NEW; END; $$ LANGUAGE plpgsql; CREATE TRIGGER atualiza_vectors AFTER INSERT OR UPDATE ON x FOR EACH ROW EXECUTE PROCEDURE atualiza_vectors(); When the trigger its called, postgre shows the following error: "stack depth limit exceeded". Did anyone knows what its wrong?
Re: [GENERAL] bytea encode performance issues
Sim Zacks <[EMAIL PROTECTED]> writes: > Results below: >> ... but given that, I wonder whether the cost isn't from fetching >> the toasted messageblk data, and nothing directly to do with either >> the encode() call or the ~~ test. It would be interesting to compare >> the results of Okay, so subtracting the totals we've got: 2.7 sec to scan the table proper 248.7 sec to fetch the toasted datums (well, this test also includes an equality comparison, but since the text lengths are generally going to be different, that really should be negligible) 55.2 sec to do the encode() calls 186.4 sec to do the LIKE comparisons So getting rid of the encode() would help a bit, but it's hardly the main source of your problem. We've seen complaints about toast fetch time before. I don't think there's any really simple solution. You could experiment with disabling compression (SET STORAGE external) but I'd bet on that being a net loss unless the data is only poorly compressible. If the table is not updated very often, it's possible that doing a CLUSTER every so often would help. I'm not 100% sure but I think that would result in the toast table being rewritten in the same order as the newly-built main table, which ought to cut down on the cost of fetching. Also, what database encoding are you using? I note from the CVS logs that some post-8.2 work was done to make LIKE faster in multibyte encodings. (Though if you were doing the LIKE directly in bytea, that wouldn't matter ... what was the reason for the encode() call again?) regards, tom lane -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] What happen to the VARATT_SIZEP macro in version 8.3?
Glyn Astill <[EMAIL PROTECTED]> writes: >> What replaces the VARATT_SIZEP macro in version 8.3? I have spent a >> long time checking the documentation and have not found the answer. > SET_VARSIZE Yes; you should always use VARSIZE() to fetch the length and SET_VARSIZE() to set it. If you need your code to still work with pre-8.3 releases, you can make yourself a compatibility macro like this: #ifndef SET_VARSIZE #define SET_VARSIZE(v,l) (VARATT_SIZEP(v) = (l)) #endif Also note that detoasting might be needed in more places than it was in 7.4; if you were cutting corners on a toastable type, you'll have to check your code carefully. See more advice here: http://archives.postgresql.org/pgsql-general/2007-10/msg00604.php regards, tom lane -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] FTS on patterns
On Tue, Aug 5, 2008 at 6:53 PM, Tom Lane <[EMAIL PROTECTED]> wrote: > > There's support for prefix text search in CVS HEAD, but not in any > released version ... > >regards, tom lane > Oh, does that mean it won't be released until 8.4?
[GENERAL] GiST indices and statistical approximations
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, I was reading the Wikipedia entry on GiST (http:// en.wikipedia.org/wiki/GiST) and it mentions """ Although originally designed for answering Boolean selection queries, GiST can also support nearest-neighbor search, and various forms of statistical approximation over large data sets. """ Could anybody provide pointers to papers or online pages that discuss the use of GiST indexes for statistical approximations? Thanks, - --- Rajarshi Guha <[EMAIL PROTECTED]> GPG Fingerprint: D070 5427 CC5B 7938 929C DD13 66A1 922C 51E7 9E84 - --- A memorandum is written not to inform the reader, but to protect the writer. -- Dean Acheson -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAkiZF38ACgkQZqGSLFHnnoQ36QCfeaU6mDid4v5DDH4V2vDMdaZr At8AoJQj9ZHxDbGiarfwNHe9aIYr1pnB =Jrgz -END PGP SIGNATURE- -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] recovery via base + WAL replay failure
Finally figured out what was wrong. The data folder had incorrect permissions after unzipping the base backup. For me, the solution was unchecking the "Inherit from parent the permission entries that apply to child objects" option in the Advanced Security Settings dialog for the data folder & giving the postgres user full control. Nothing appeared in the log when the database failed to startup b/c the permissions were wrong. However, an application error did get reported to Windows which I found using the Event Viewer. --Rob -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Initdb problem on debian mips cobalt: Bus error
Glyn Astill wrote: http://privatepaste.com/cbY2S4JhtA Very little difference with the -O0 FWIW: there also seems to be a fairly indepth discussion on the cobalt related netbsd list from last year about a problem that looks very similiar (at least to you issue with etch): http://www.nabble.com/Strange-segmentation-fault-trying-to-run-postgresql-on-current-to9997129.html Stefan -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Installation problem ~!
Harshad Pethe wrote: > I have recently tried to install pgsql on Windows but > I get the following error consistently ! > > Error : " psql : recieved invalid response to SSL negotiation ! " > > This error is encountered as soon as I try to start psql ! Sounds like an SSL problem. Check the server certificates and the client certificate if they match. Check the "ssl" setting in postgresql.conf. Check the "sslmode" used in the connection string by the client. Yours, Laurenz Albe -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
