Re: [SQL] Random resultset retrieving -> performance bottleneck
> I'm running into a performance problem when considering the following > scenario: I have a fairly large table (1mio rows) related to other smaller > tables (between 100 and 1 rows) and would like to retrieve the joined > data (through a view) in random order. In order to do so, the main table > contains a 'Random' field (which is updated on a regular basis, in order to > re-randomize the data set), on which an index is created: Have you tried adding ORDER BY RANDOM() onto your select query? Chris ---(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: [SQL] What about this?
That's what your crontab is for. Chris - Original Message - From: "Wei Weng" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Saturday, August 03, 2002 5:40 AM Subject: [SQL] What about this? > Why can't postmaster run VACUUM ANALYZE automatically every once in a > while? Since it is a very useful feature... > > > -- > Wei Weng > Network Software Engineer > KenCast Inc. > > > > ---(end of broadcast)--- > TIP 5: Have you checked our extensive FAQ? > > http://www.postgresql.org/users-lounge/docs/faq.html > ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [SQL] [NOVICE] Aggregates and Indexes
Bruce, > I have seen a few mentions in the past weeks about core vs. non-core > developers. I should reiterate that the core group feels there is no > distinction between the opinions of the core people and the other > major > developers. Everyone gets just one vote. Which is why it's important that us peripheral developers make sure you get the respect you deserve, since you're so un-assertive. Why I often make a comment like that in my messages is that, as a strictly *documentation* contributor, I often make mistaken assumptions about why some things in Postgres work the way they do. Heck, even when I'm right, I'm usually just parroting something you, Tom, or Stephan have told me. Or, to put it another way: given the number of questions I field on this list, and the stuff I write for Techdocs and elsewhere, there is a tendency from the public to assume that I am a "big wheel" in the PostgreSQL project. Which I am not. I've been here for a while, yes, but by no means do my contributions equal in scope, importance, or dedication the contributions of you, Tom, Stephan, Peter, Thomas, Joe, or two dozen other contributors whose names don't spring immediately to mind. Further, I do not consult with the PostgreSQL "global development team" before mouthing off; my opinions are mine, not those of the postgresql project. Thus, the comment in so many of my e-mails of "I am not a core developer." Capisce? -Josh Berkus ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
[SQL] Triggers for inserting on VIEWS
Hi, at least with PostgreSQL 7.1 it was possible to create a trigger on a view. 7.2 seems to fail with: psql:t:25: ERROR: CreateTrigger: relation "egg_view" is not a table is there any replacement so that inserting somewhere acts on multiple tables ? Thank you. Code reference: (stupid, real code is more complex and uses multiple tables) DROP TRIGGER t_egg ON egg_view; DROP FUNCTION f_egg_insert (); DROP VIEW egg_view; DROP TABLE egg; DROP SEQUENCE egg_id_seq; CREATE TABLE egg(id SERIAL, description TEXT, UNIQUE(id), PRIMARY KEY(id)); CREATE VIEW egg_view AS SELECT description FROM egg; CREATE FUNCTION f_egg_insert () RETURNS opaque AS 'BEGIN INSERT INTO egg (description) VALUES(NEW.description); END;' LANGUAGE 'plpgsql'; CREATE TRIGGER t_egg BEFORE INSERT ON egg_view FOR EACH ROW EXECUTE PROCEDURE f_egg_insert(); ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [SQL] Triggers for inserting on VIEWS
Marc, > at least with PostgreSQL 7.1 it was possible to create a trigger on a > view. 7.2 seems to fail with: > >psql:t:25: ERROR: CreateTrigger: relation "egg_view" is not a > table > > is there any replacement so that inserting somewhere acts on multiple > tables ? Yes. Use the RULES system, which were a lot like triggers but are better tailored to deal with inserts and updates on VIEWs. See: http://www.us.postgresql.org/users-lounge/docs/7.2/postgres/rules.html -Josh Berkus ---(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: [SQL] Triggers for inserting on VIEWS
Marc SCHAEFER <[EMAIL PROTECTED]> writes: > at least with PostgreSQL 7.1 it was possible to create a trigger on a > view. Use a rule instead. 7.2 will reject an attempt to insert into a view without a replacement rule, so a trigger would do you no good anyhow. (I thought that behavior went back further than 7.2, actually.) regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[SQL] STATISTICS?
Folks, Can anyone point me to documentation on the new STATISTICS features of 7.2? I can't seem to find anything in the online docs, except the barest mention of ALTER TABLE SET STATISTICS (which doesn't explain what to do with the info). -Josh Berkus ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [SQL] STATISTICS?
do you need http://www.postgresql.org/idocs/index.php?monitoring-stats.html ? Folks, > > Can anyone point me to documentation on the new STATISTICS features of 7.2? I can't >seem to > find anything in the online docs, except the barest mention of ALTER TABLE SET >STATISTICS > (which doesn't explain what to do with the info). > > -Josh Berkus > > ---(end of broadcast)--- TIP 6: Have >you > searched our list archives? > > http://archives.postgresql.org - Get your free web based email at trade-india.com. "India's Leading B2B eMarketplace.!" http://www.trade-india.com/ ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [SQL] Triggers for inserting on VIEWS
On Sat, 3 Aug 2002, Marc SCHAEFER wrote:
> is there any replacement so that inserting somewhere acts on multiple
> tables ?
Thanks for the suggestion to use RULES.
My solution (comments welcome):
DROP RULE r_entree_rapide_ecriture_insert;
DROP FUNCTION f_entree_rapide_ecriture_insert(TEXT,
DATE,
TEXT,
DATE,
TEXT,
NUMERIC(10, 2),
INT4,
INT4);
DROP VIEW entree_rapide_ecriture;
DROP TABLE ecriture;
DROP SEQUENCE ecriture_id_seq;
DROP SEQUENCE ecriture_lot_seq;
DROP TABLE piece;
DROP SEQUENCE piece_id_seq;
DROP TABLE compte;
DROP SEQUENCE compte_id_seq;
CREATE TABLE compte(id SERIAL NOT NULL,
libelle TEXT NOT NULL,
montant_initial NUMERIC(10, 2) DEFAULT 0.0 NOT NULL,
UNIQUE(libelle),
PRIMARY KEY(id), UNIQUE(id));
CREATE TABLE piece(id SERIAL NOT NULL,
libelle TEXT NOT NULL,
date DATE NOT NULL DEFAULT CURRENT_DATE,
description TEXT,
UNIQUE(libelle),
PRIMARY KEY(id), UNIQUE(id));
CREATE SEQUENCE ecriture_lot_seq;
CREATE TABLE ecriture(id SERIAL NOT NULL,
piece INT4 REFERENCES piece NOT NULL,
date DATE NOT NULL DEFAULT CURRENT_DATE,
compte INT4 REFERENCES compte NOT NULL,
description TEXT,
montant NUMERIC(10, 2) NOT NULL
CHECK (montant > CAST(0.0 AS NUMERIC(10, 2))),
type CHAR(1) NOT NULL CHECK (type IN ('D', 'A')),
lot INT4 NOT NULL DEFAULT currval('ecriture_lot_seq'),
PRIMARY KEY(id), UNIQUE(id));
CREATE VIEW entree_rapide_ecriture
AS SELECT p.libelle AS piece_libelle,
p.date AS piece_date,
p.description AS piece_descr,
e1.date AS ecriture_date,
e1.description AS ecriture_descr,
e1.montant AS ecriture_montant,
e1.compte AS ecriture_de_compte,
e2.compte AS ecriture_a_compte
FROM piece p, ecriture e1, ecriture e2
WHERE (e1.lot = e2.lot)
AND (e1.date = e2.date)
AND (e1.montant = e2.montant)
AND (e1.piece = e2.piece)
AND (e1.type != e2.type)
AND (e1.piece = p.id)
AND (e1.type = 'D');
CREATE FUNCTION f_entree_rapide_ecriture_insert(TEXT,
DATE,
TEXT,
DATE,
TEXT,
NUMERIC(10, 2),
INT4,
INT4)
RETURNS INT4 -- void
AS 'DECLARE
piece_libelle ALIAS for $1;
piece_date ALIAS for $2;
piece_descr ALIAS for $3;
ecriture_date ALIAS for $4;
ecriture_descr ALIAS for $5;
ecriture_montant ALIAS for $6;
ecriture_de_compte ALIAS for $7;
ecriture_a_compte ALIAS for $8;
lot_id INT4;
piece_id INT4;
BEGIN
SELECT nextval(\'ecriture_lot_seq\') INTO lot_id;
SELECT nextval(\'piece_id_seq\') INTO piece_id;
INSERT INTO piece (id, libelle, date, description)
VALUES(piece_id,
piece_libelle,
piece_date,
piece_descr);
INSERT INTO ecriture(piece,
date,
compte,
description,
montant,
type,
lot)
VALUES(piece_id,
ecriture_date,
ecriture_de_compte,
ecriture_descr,
ecriture_montant,
\'D\',
lot_id);
INSERT INTO ecriture(piece,
date,
compte,
description,
montant,
type,
lot)
VALUES(piece_id,
ecriture_date,
ecriture_a_compte,
ecriture_descr,
ecriture_montant,
\'A\',
lot_id);
RETURN 0; -- Assumes won\'t do anything.
END;'
LANGUAGE 'plpgsql';
-- NOTES
--- Triggers do not w
[SQL] VACUUM not doing its job?
Hi, I have a PostgreSQL 7.2.1 database which normally (just after a pg_restore) takes about 700-800MB of disk space. Now, the problem is that the database grows quite quickly when in use, although we don't put very much data in. Granted, there is quite a few records deleted and inserted, but the total data volume grows only slowly. Three week ago we did a pg_dump/pg_restore, and after pgsql/data/ took about 750MB. Now it uses 2,4GB of disk space! If we do a new complete dump and restore the volume will decrease to about 800MB. We of course do a 'vacuumdb -a -z' every day, but this does not seem to help much unfortunately. The database is in use 24/7 so a full vacuum is not an option. What we do now is simply a full dump/restore about once a month, because the database slows to a crawl as the data volume grows too large (this seems to be because it loads large amouts of data from disk for each query, probably because the data postgre use no longer fit in the disk cache). Anyway, what could be causing this problem and what can we do about it? The dump/restore option is not attractive in the long run for obvious reasons. Regards, Kristian ---(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
[SQL] Bug with dump/restore when using UNION and ORDER BY in views
There seems to be a bug when dumping a view which is a UNION of selects, one of which has an ORDER BY. A pair of paranthesises around the select is missing, and this cause a subsequent restore to fail. This is quite annoying as the backup file must be manually edited before it can be restored, and I would really appreciate a solution in a future version of Postgre. This problem is still present in 7.2.1. Example: CREATE TABLE t (id INT); CREATE VIEW v AS (SELECT id FROM t AS t1 ORDER BY id) UNION SELECT id FROM t AS t2; After a dump it looks like this: CREATE VIEW "v" as SELECT t1.id FROM t t1 ORDER BY t1.id UNION SELECT t2.id FROM t t2; Which is not accepted by postgre. Regards, Kristian ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [SQL] VACUUM not doing its job?
I've run into this myself. Tom lane helped me out. In my case, it was the fact that indexes don't release the space of indexes of deleted rows. So, if you have a table that has a lot of inserts/deletes, your indexes will grow incredibly fast. The way to see what your biggest items are: select * from pg_class order by relpages desc; If your tables are active with lots of inserts/deletes, the biggest things will likely be indexes. The only way that I know to recover this space is to drop the indexes and recreate them. Vacuum didn't touch them for me. -Ken On Sat, 2002-08-03 at 21:53, Kristian Eide wrote: > Three week ago we did a pg_dump/pg_restore, and after pgsql/data/ took about > 750MB. Now it uses 2,4GB of disk space! If we do a new complete dump and > restore the volume will decrease to about 800MB. ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [SQL] VACUUM not doing its job?
> In my case, it was the fact that indexes don't release the space of > indexes of deleted rows. So, if you have a table that has a lot of > inserts/deletes, your indexes will grow incredibly fast. > > The way to see what your biggest items are: > select * from pg_class order by relpages desc; Yes, I already suspected this could be at least part of the reason, and your SQL query confirms it. However, dropping and re-creating my biggest indexes only reclaims about 500MB, this still leaves about 1GB unaccounted for and I can't see how my remaining (small) indexes can be responsible for this (btw: do you know how much diskspace one 'relpage' use?). Given that I have lots of deletes/inserts, is there anything besides the indexes which could use this much space? > The only way that I know to recover this space is to drop the indexes > and recreate them. Vacuum didn't touch them for me. This is not good as the database is in use 24/7, and without the indexes everything comes to a screeching halt. This means I probably will have to stop the programs using the database for the time it takes to re-create the indexes; this is better than having to dump/restore everything however :) Are there any plans to also vacuum the indexes in a future version of Postgre (otherwise an excellent piece of software!) ? Regards, Kristian ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [SQL] VACUUM not doing its job?
Kristian Eide wrote: > This is not good as the database is in use 24/7, and without the indexes > everything comes to a screeching halt. This means I probably will have to > stop the programs using the database for the time it takes to re-create the > indexes; this is better than having to dump/restore everything however :) Try REINDEX. I don't think that precludes (at least) read access. http://www.postgresql.org/idocs/index.php?sql-reindex.html You should also search the archives for threads on free space maps. You most likely need to increase yours. In particular, see: http://archives.postgresql.org/pgsql-general/2002-07/msg00972.php HTH, Joe ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [SQL] VACUUM not doing its job?
> You should also search the archives for threads on free space maps. You > most likely need to increase yours. In particular, see: >http://archives.postgresql.org/pgsql-general/2002-07/msg00972.php Thanks, very helpful, although there does not seem to be much description of what the two free space map options in postgresql.conf actually do. Doing a VACUUM ANALYZE VERBOSE on my largest table gives me: NOTICE: Pages 43681: Changed 208, Empty 0; Tup 1921387: Vac 61669, Keep 0, UnUsed 1362341. I will try to increase the 'max_fsm_pages' option from 1 to 50 and see if that helps. Regards, Kristian ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [SQL] STATISTICS?
Mallah, > do you need > http://www.postgresql.org/idocs/index.php?monitoring-stats.html ? Yes, thank you! That was exactly what I was looking for. -Josh Berkus ---(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: [SQL] VACUUM not doing its job?
Kristian Eide wrote: > Thanks, very helpful, although there does not seem to be much description of > what the two free space map options in postgresql.conf actually do. Doing a > VACUUM ANALYZE VERBOSE on my largest table gives me: > > NOTICE: Pages 43681: Changed 208, Empty 0; Tup 1921387: Vac 61669, Keep 0, > UnUsed 1362341. > > I will try to increase the 'max_fsm_pages' option from 1 to 50 and > see if that helps. > Note that you'll need to do a vacuum full *first* to recover the lost space, since the free space map is populated as the tuples are actually freed, I believe. After that you can adjust 'max_fsm_pages' and your vacuum frequency to achieve an equilibrium. Joe ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [SQL] [NOVICE] Aggregates and Indexes
Oh, sure I understand. There were a number of people mentioning the core issue. What the core/major folks do is more give information about historical or practical ideas behind certain issues, so in that way they do have a strong voice, but only in the way their ideas effect other people's opinions and votes. --- Josh Berkus wrote: > Bruce, > > > I have seen a few mentions in the past weeks about core vs. non-core > > developers. I should reiterate that the core group feels there is no > > distinction between the opinions of the core people and the other > > major > > developers. Everyone gets just one vote. > > Which is why it's important that us peripheral developers make sure you > get the respect you deserve, since you're so un-assertive. > > Why I often make a comment like that in my messages is that, as a > strictly *documentation* contributor, I often make mistaken assumptions > about why some things in Postgres work the way they do. Heck, even > when I'm right, I'm usually just parroting something you, Tom, or > Stephan have told me. > > Or, to put it another way: given the number of questions I field on > this list, and the stuff I write for Techdocs and elsewhere, there is a > tendency from the public to assume that I am a "big wheel" in the > PostgreSQL project. Which I am not. I've been here for a while, > yes, but by no means do my contributions equal in scope, importance, or > dedication the contributions of you, Tom, Stephan, Peter, Thomas, Joe, > or two dozen other contributors whose names don't spring immediately to > mind. > > Further, I do not consult with the PostgreSQL "global development team" > before mouthing off; my opinions are mine, not those of the postgresql > project. > > Thus, the comment in so many of my e-mails of "I am not a core > developer." > > Capisce? > > -Josh Berkus > > ---(end of broadcast)--- > TIP 5: Have you checked our extensive FAQ? > > http://www.postgresql.org/users-lounge/docs/faq.html > -- 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 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [SQL] Bug with dump/restore when using UNION and ORDER BY in views
"Kristian Eide" <[EMAIL PROTECTED]> writes: > There seems to be a bug when dumping a view which is a UNION of selects, one > of which has an ORDER BY. A pair of paranthesises around the select is > missing, and this cause a subsequent restore to fail. Yeah. This is fixed in current sources, and I back-patched it into the REL7_2 branch, but current plans don't seem to include a 7.2.2 release --- we'll be going straight to 7.3 beta instead. If you're sufficiently annoyed to want to install a source patch locally, see rev 1.89.2.1 at http://developer.postgresql.org/cvsweb.cgi/pgsql-server/src/backend/utils/adt/ruleutils.c Note this is a server-side patch; the bug is not in pg_dump. So using a 7.3 pg_dump against your existing server won't help. You might want to apply the back-patch just so that you can dump when the time comes to go to 7.3... regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [SQL] Bug with dump/restore when using UNION and ORDER BY in views
> Yeah. This is fixed in current sources, and I back-patched it into > the REL7_2 branch, but current plans don't seem to include a 7.2.2 > release --- we'll be going straight to 7.3 beta instead. Is it worth doing a 7.2.2 patch that will dump people's foreign keys as ALTER TABLE/ADD FOREIGN KEY instead of a bunch of CREATE CONSTRAINT TRIGGERs, so that they actually become constraints in 7.3? Also Tom - did you check if you can CREATE CONSTRAINT TRIGGER on a dropped column - I think I neglected to look at that in the patch I submitted originally. Chris ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [SQL] Bug with dump/restore when using UNION and ORDER BY in views
"Christopher Kings-Lynne" <[EMAIL PROTECTED]> writes: >> Yeah. This is fixed in current sources, and I back-patched it into >> the REL7_2 branch, but current plans don't seem to include a 7.2.2 >> release --- we'll be going straight to 7.3 beta instead. > Is it worth doing a 7.2.2 patch that will dump people's foreign keys as > ALTER TABLE/ADD FOREIGN KEY instead of a bunch of CREATE CONSTRAINT > TRIGGERs, so that they actually become constraints in 7.3? I don't think it's any easier to do that as a backpatch than as new functionality in 7.3 pg_dump. As far as the general issue of a 7.2.2 release goes, I'm personally in favor of one --- there are several important bugfixes in the 7.2 branch right now --- but I don't do the gruntwork for patch releases, so I can't complain too much. > Also Tom - did you check if you can CREATE CONSTRAINT TRIGGER on a dropped > column - I think I neglected to look at that in the patch I submitted > originally. I'm pretty sure that won't get past the ATTNAME cache patches, but try it... regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [SQL] Bug with dump/restore when using UNION and ORDER BY in views
What is in the 7.2.X CVS that we would want to release? --- Tom Lane wrote: > "Christopher Kings-Lynne" <[EMAIL PROTECTED]> writes: > >> Yeah. This is fixed in current sources, and I back-patched it into > >> the REL7_2 branch, but current plans don't seem to include a 7.2.2 > >> release --- we'll be going straight to 7.3 beta instead. > > > Is it worth doing a 7.2.2 patch that will dump people's foreign keys as > > ALTER TABLE/ADD FOREIGN KEY instead of a bunch of CREATE CONSTRAINT > > TRIGGERs, so that they actually become constraints in 7.3? > > I don't think it's any easier to do that as a backpatch than as new > functionality in 7.3 pg_dump. As far as the general issue of a 7.2.2 > release goes, I'm personally in favor of one --- there are several > important bugfixes in the 7.2 branch right now --- but I don't do the > gruntwork for patch releases, so I can't complain too much. > > > Also Tom - did you check if you can CREATE CONSTRAINT TRIGGER on a dropped > > column - I think I neglected to look at that in the patch I submitted > > originally. > > I'm pretty sure that won't get past the ATTNAME cache patches, but try > it... > > regards, tom lane > > ---(end of broadcast)--- > TIP 5: Have you checked our extensive FAQ? > > http://www.postgresql.org/users-lounge/docs/faq.html > -- 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 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: [SQL] Bug with dump/restore when using UNION and ORDER BY in views
Bruce Momjian <[EMAIL PROTECTED]> writes: > What is in the 7.2.X CVS that we would want to release? CVS logs show the following as post-7.2.1 changes in REL7_2_STABLE branch. Draw your own conclusions ... regards, tom lane 2002-06-15 14:38 tgl * src/backend/utils/adt/ruleutils.c (REL7_2_STABLE): Back-patch 7.3 fix to fully parenthesize UNION/EXCEPT/INTERSECT queries in ruleutils output. The previous partial parenthesization was a hack to get around grammar restrictions that have since been fixed; and as Sam O'Connor pointed out, there were cases where it didn't work. 2002-06-07 17:53 momjian * contrib/intarray/: _int.c, _int.sql.in (REL7_2_STABLE): Please apply attached patch to contrib/intarray (7.2, 7.3). Fixed bug with '=' operator for gist__int_ops and define '=' operator for gist__intbig_ops opclass. Now '=' operator is consistent with standard 'array' type. Thanks Achilleus Mantzios for bug report and suggestion. Oleg Bartunov 2002-05-28 11:40 tgl * src/bin/pg_dump/pg_dump.c (REL7_2_STABLE): Repair incorrect dumping of user-defined aggregate with null initcond. (Already fixed in current, but need a patch for 7.2.2.) 2002-05-28 11:25 tgl * contrib/rtree_gist/rtree_gist.c (REL7_2_STABLE): Fix a bug with building rtree_gist indexes. Patch from Teodor Sigaev. 2002-05-28 11:22 tgl * src/backend/access/gist/gist.c (REL7_2_STABLE): Repair error with not adjusting active scans properly after gistSplit. Patch from Teodor Sigaev. 2002-05-22 13:29 tgl * src/backend/utils/cache/relcache.c (REL7_2_STABLE): Make RelationForgetRelation error out if the relcache entry has nonzero reference count. This avoids leaving dangling pointers around, as in recent bug report against sequences (bug# 671). 2002-05-21 14:50 tgl * src/pl/plpgsql/src/gram.y (REL7_2_STABLE): Repair OPEN cursor(args), which I broke on 11/29/01 with a change to be smarter about parentheses in read_sql_construct(). Sigh. 2002-05-14 14:16 tgl * src/backend/utils/adt/geo_ops.c (REL7_2_STABLE): Remove unnecessary pfree's in geometric operators. At least one of these is actively dangerous, per bug report from Ewald Geschwinde 14-May-02, and several of the rest look suspicious to me. Since there is no longer any significant value in retail pfree's in these functions, just get rid of all of them for safety's sake. 2002-05-13 22:08 ishii * src/bin/: pg_dump/pg_dump.c, psql/startup.c (REL7_2_STABLE): Fix bug in pg_dump and psql (to reproduce the bug, just try pg_dump --nonexistingoption). per report from [EMAIL PROTECTED] on Thu, 09 May 2002 11:57:51 +0900 (JST) at pgsql-patches list. Illegal long options to pg_dump makes core on some systems, since it lacks the last null sentinel of struct option array. Attached is a patch made by Mr. Ishida Akio <[EMAIL PROTECTED]>. 2002-05-05 13:38 tgl * src/pl/plpgsql/src/pl_funcs.c (REL7_2_STABLE): plpgsql_dstring_append was broken for long strings. 2002-04-30 21:27 inoue * src/backend/access/heap/heapam.c (REL7_2_STABLE): Change heap_get_latest_tid() so that a transaction can see changes made by the transaction itself. 2002-04-08 02:21 ishii * src/interfaces/libpq/fe-exec.c (REL7_2_STABLE): A backport patch. Fix PQescapeBytea/PQunescapeBytea so that they handle bytes > 0x7f. This is necessary for mulibyte character sequences. See "[HACKERS] PQescapeBytea is not multibyte aware" thread posted around 2002/04/05 for more details. 2002-04-02 00:12 tgl * src/backend/commands/vacuum.c (REL7_2_STABLE): Fix CLOG truncation code to not do the Wrong Thing when there are already wrapped-around databases. The unvacuumed databases might be fine, or they might not, but things will definitely not be fine if we remove the wrong CLOG segments. Per trouble report from Gary Wolfe, 1-Apr-2002. ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
