Re: [HACKERS] CLUSTER and indisclustered
On Tue, 2002-08-13 at 09:25, Bruce Momjian wrote: There is a web page about star joins used a lot in data warehousing, where you don't know what queries are going to be required and what indexes to create: http://www.dbdomain.com/a100397.htm They show some sample queries, which is good. Here is some interesting text: Star Transformation If there are bitmap indexes on SALES_REP_ID, PRODUCT_ID, and DEPARTMENT_ID in the SALES table, then Oracle can resolve the query using merges of the bitmap indexes. Because Oracle can efficiently merge multiple bitmap indexes, you can create a single bitmap index on each of the foreign-key columns in the fact table rather than on every possible combination of columns. Another way to achive the similar result would be using segmented hash indexes, where each column maps directly to some part of hash value. This lets you support all possible combinations of dimensions without creating an unreasonable number of indexes. --- Hannu ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] VACUUM's No one parent tuple was found, redux
Also, for Mario and Barry: does this test case look anything like what your real applications do? In particular, do you ever do a SELECT FOR UPDATE in a transaction that commits some changes, but does not update or delete the locked-for-update row? If not, it's possible there are yet more bugs lurking in this area. regards, tom lane I've checked the application, when I select for update I will update those tuples, though it might be an update where no real modification is done (e.g. update table set col1=col1). I'm pretty sure I've identified the source of the problem in my application, but in this specific place there is no select for update, but a rollback while another update is in progress. I guess this is triggering the problem now and then. But for the scenario you mention above, I cannot imagine how this might happen in my application, it's not easy to say for sure, it's a quite complex web based content management system and not easy to debug such errors, because I've no clue how to trigger it reproduceable. Best regards, Mario Weilguni ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] anoncvs currently broken
On Mon, Aug 12, 2002 at 09:38:00PM -0300, Marc G. Fournier wrote: should be fixed ... looks like just an ownership issue on a new directory More like I uploaded that directory just as you were rsync'ing to anonymous CVS and a lock file got copied along, but was never deleted on a subsequent rsync. Or so it's been suggested to me. Jeroen ---(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] SQL99 CONVERT() function
Hello,
The attached patch adds CONVERSION stuff for cyrillic and
win874/1250/1251/1256 encodings.
Thank you.
From: Tatsuo Ishii [EMAIL PROTECTED]
Subject: [HACKERS] SQL99 CONVERT() function
Date: Tue, 06 Aug 2002 14:55:04 +0900 (JST)
Message-ID: [EMAIL PROTECTED]
I have added SQL99's CONVERT() function. docs and regression tests
also updated. Our own convert() functions can also be used. Example
usage of CONVERT():
convert('PostgreSQL' using iso8859_1_to_utf8)
will return 'PostgreSQL' in UTF-8 encoding. See String Functions and
Operators section of Users's guide for more details and currently
available (predefined) conversions.
I believe remaining work for CONVERSION stuffs is some conversions for
cyrillic and win874/1250/1251/1256 encodings.
--
Tatsuo Ishii
---
Kaori Inaba
[EMAIL PROTECTED]
pgsql.patch.gz
Description: Binary data
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [PATCHES] [HACKERS] SQL99 CONVERT() function
The attached patch adds CONVERSION stuff for cyrillic and win874/1250/1251/1256 encodings. Thanks. I'll take care of this. -- Tatsuo Ishii ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [GENERAL] [HACKERS] Linux Largefile Support In Postgresql RPMS
Andrew Sullivan wrote: On Sat, Aug 10, 2002 at 09:21:07AM -0500, Greg Copeland wrote: I'm actually amazed that postgres isn't already using large file support. Especially for tools like dump. Except it would only cause confusion if you ran such a program on a system that didn't itself have largefile support. Better to make the admin turn all these things on on purpose, until everyone is running 64 bit systems everywhere. A Ah yes ... extremely good point - I had not considered that. I am pretty sure all reasonably current (kernel = 2.4) Linux distros support largefile out of the box - so it should be safe for them. Other operating systems where 64 bit file access can be disabled or unconfigured require more care - possibly (sigh) 2 binary RPMS with a distinctive 32 and 64 bit label ...(I think the big O does this for Solaris). Cheers Mark ---(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] Is contrib/rserv/Makefile broken?
Hi all, In 7.2.1, MasterInit script (rserv command) does not work correctly, because $libdir is not defined in it. I think $libdir should be replaced in Makefile as below. Is it correct? --- MakefileMon Mar 11 13:39:14 2002 +++ /tmp/Makefile Tue Aug 13 18:19:21 2002 @@ -22,10 +22,10 @@ all: $(SQLS) $(TCLS) $(PERLS) $(SCRIPTS) $(SONAME) %.sql: %.sql.in - sed 's,@MODULE_FILENAME@,$$libdir/$(NAME),g' $ $@ + sed 's,@MODULE_FILENAME@,$(libdir)/$(NAME),g' $ $@ $(PERLS) $(TCLS) $(SCRIPTS): %: %.in - sed -e 's,@MODULE_FILENAME@,$$libdir/$(NAME),g' \ + sed -e 's,@MODULE_FILENAME@,$(libdir)/$(NAME),g' \ -e 's:@SQLDIR@:$(datadir)/contrib:g' \ -e 's:@BINDIR@:$(bindir):g' \ -e 's:@LIBDIR@:$(datadir)/contrib:g' $ $@ -- NAGAYASU Satoshi [EMAIL PROTECTED] ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] [PATCHES] CREATE OR REPLACE TRIGGER
Le Dimanche 11 Août 2002 17:53, Tom Lane a écrit : Hmm. I remember Poure asking repeatedly for CREATE OR REPLACE VIEW, and that makes a lot of sense to me, because other things *can* depend on a view. (Unfortunately, by the same token it's a lot harder to do.) The use-case for replacing a trigger is not visible to the naked eye. Dear Tom, Replacing a trigger is interesting, for several reasons: - you may need to temporary disable a trigger. In pgAdmin2, you may move the view to a temporary table. This can be done by other means, but none is standard. By the way, a DISSABLE TRIGGER would be usefull. - you may need to choose another function or change events. - systems with server-side code need to be UPGRADED. Look at Compiere for example. When the database schema evolves, a scripts shall be able to run server-side and upgrade the database safely. - newbees like to play around just as if they were in Access, Excel or MySQL. In pgAdmin2, the graphical presentation enables them to create, move, alter and delete objects. This is very important for someone who learns databases. Learning becomes a game. Inside PostgreSQL backend, I see no reason why this should not be done by a DROP/CREATE. Last of all, if all objects could be REPLACED or ALTERED inside PostgreSQL, it would become interesting to create automatic Diff between revisions of a schema. Then, PostgreSQL itself sould be able to write the upgrade script. What do you think of this advanced feature? Do you think it is possible to store schema dumps inside postgreSQL and generate upgrade scripts between revisions? Cheers, Jean-Michel ---(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: [GENERAL] [HACKERS] Linux Largefile Support In Postgresql RPMS
On Tue, 2002-08-13 at 03:57, Greg Copeland wrote: Are there any filesystems in common use (not including windows ones) that don't support 32-bit filesizes? Linux (ext2) I know supports by default at least to 2TB (2^32 x 512bytes), probably much more. What about the BSDs? XFS? etc Ext2 3 should be okay. XFS (very sure) and JFS (reasonably sure) should also be okay...IIRC. NFS and SMB are probably problematic, but I can't see anyone really wanting to do this. Hmm. Whereas I can't see many people putting their database files on an NFS mount, I can readily see them using pg_dump to one, and pg_dump is the program where large files are really likely to be needed. -- Oliver Elphick[EMAIL PROTECTED] Isle of Wight, UK http://www.lfix.co.uk/oliver GPG: 1024D/3E1D0C1C: CA12 09E0 E8D5 8870 5839 932A 614D 4C34 3E1D 0C1C Watch ye therefore, and pray always, that ye may be accounted worthy to escape all these things that shall come to pass, and to stand before the Son of man. Luke 21:36 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] [COMMITTERS] pgsql-server/src backend/tcop/postgres.cbacke
OK, seeing as no one voted, and only Tom and I objected originally, we will keep the code as Thomas has applied it, namely that PGXLOG/-X is recognized by initdb, postmaster, postgres, and pg_ctl. We will? It looks to me like Thomas lost the vote 2-to-1. Unless there are more votes, I'm going to *insist* that this code be changed. It's dangerous and offers no offsetting benefit. XLOG location should be settable at initdb, noplace later. 2 would get my vote too. My approach though would be that initdb simply creates a symlink. I like to find the files without resorting to additional utilities or an sql, at least on platforms that support symlinks. This makes the task of knowing what needs to be backed up easier. My approach to tablespaces would probably also have symlinks in the datadir. Andreas ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
[HACKERS] db partial dumping with pg_dump
We have a patch for pg_dump which adds a possibility to dump a part of table, for example: dump Top.Science.Astronomy heirarchy from dmoz catalog pg_dump -d -t dmoz -w select * from dmoz where path @ 'Top.Science.Astronomy' dmoz We found it's very useful. We'd like to extend it to use also with COPY but it has no support for select (of course it will works only for special case when ALL columns retrieved). The question is: Is't worth to submit patch for pg_dump and look into copy code ? Regards, Oleg _ Oleg Bartunov, sci.researcher, hostmaster of AstroNet, Sternberg Astronomical Institute, Moscow University (Russia) Internet: [EMAIL PROTECTED], http://www.sai.msu.su/~megera/ phone: +007(095)939-16-83, +007(095)939-23-83 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
[HACKERS] Temporary Views
Hi all, I'm thinking that temporary views should be pretty trivial to implement. * Allow temporary views This should be as simple as modifying gram.y (to set ViewStmt-view-istemp) and some logic in RemoveTempRelations() to remove the view's rule * Require view using temporary tables to be temporary views This is the non-trivial part. If you are creating a view on just a temporary table there's no problem. But what happens when do the following? CREATE VIEW abc AS select * from tab1,tab2,temp_tab3 ... SQL99 avoids this with syntax rule 6 of 11.21 view definition No table reference generally contained in the query expression shall identify any declared local temporary table. There are a few ways it could be implemented: 1) SQL99 2) Views whose query epression contains one or more table references to temporary tables are created as temporary views 3) Views whose query epression contains one or more table references to temporary tables must be explicitly include the TEMP[ORARY] syntax. Thoughts? Gavin ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] anoncvs currently broken
On Tue, 2002-08-13 at 02:47, Jeroen T. Vermeulen wrote: On Mon, Aug 12, 2002 at 09:38:00PM -0300, Marc G. Fournier wrote: should be fixed ... looks like just an ownership issue on a new directory More like I uploaded that directory just as you were rsync'ing to anonymous CVS and a lock file got copied along, but was never deleted on a subsequent rsync. Or so it's been suggested to me. That was based on a number of assumptions. Of course Marc knows exactly what was wrong because he had to fix it :) ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] db partial dumping with pg_dump
On Tue, 2002-08-13 at 07:49, Oleg Bartunov wrote: We have a patch for pg_dump which adds a possibility to dump a part of table, for example: dump Top.Science.Astronomy heirarchy from dmoz catalog pg_dump -d -t dmoz -w select * from dmoz where path @ 'Top.Science.Astronomy' dmoz We found it's very useful. We'd like to extend it to use also with COPY but it has no support for select (of course it will works only for special case when ALL columns retrieved). The question is: Is't worth to submit patch for pg_dump and look into copy code ? I've been asked by co-workers for information on how to do this type of thing. They do partial table dumps to a development system for the purpose of finding / eliminating bugs. That said, it may be smart to make the 'select * from table' part yourself, and let the user supply a where clause. ---(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] db partial dumping with pg_dump
On 13 Aug 2002, Rod Taylor wrote:
On Tue, 2002-08-13 at 07:49, Oleg Bartunov wrote:
We have a patch for pg_dump which adds a possibility to dump
a part of table, for example:
dump Top.Science.Astronomy heirarchy from dmoz catalog
pg_dump -d -t dmoz -w select * from dmoz where path @ 'Top.Science.Astronomy'
dmoz
We found it's very useful. We'd like to extend it to use also with COPY
but it has no support for select (of course it will works only for
special case when ALL columns retrieved).
The question is: Is't worth to submit patch for pg_dump and look into
copy code ?
I've been asked by co-workers for information on how to do this type of
thing. They do partial table dumps to a development system for the
purpose of finding / eliminating bugs.
That said, it may be smart to make the 'select * from table' part
yourself, and let the user supply a where clause.
find patch (7.2) in attachement. Note, it works with -d (insert mode) option.
---(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
Regards,
Oleg
_
Oleg Bartunov, sci.researcher, hostmaster of AstroNet,
Sternberg Astronomical Institute, Moscow University (Russia)
Internet: [EMAIL PROTECTED], http://www.sai.msu.su/~megera/
phone: +007(095)939-16-83, +007(095)939-23-83
--- pg_dump.c.old Fri Aug 9 19:41:08 2002
+++ pg_dump.c Fri Aug 9 19:28:34 2002
@@ -128,6 +128,7 @@
TableInfo *tblinfo;
int tblidx;
booloids;
+ const char *select_command;
} DumpContext;
static void
@@ -390,6 +391,7 @@
{
const DumpContext *dctx = (DumpContext *) dctxv;
const char *classname = dctx-tblinfo[dctx-tblidx].relname;
+ const char *select_command = dctx-select_command;
PGresult *res;
PQExpBuffer q = createPQExpBuffer();
@@ -397,9 +399,23 @@
int field;
if (fout-remoteVersion = 70100)
- appendPQExpBuffer(q, DECLARE _pg_dump_cursor CURSOR FOR SELECT * FROM
ONLY %s, fmtId(classname, force_quotes));
+ if (select_command)
+ {
+ appendPQExpBuffer(q, DECLARE _pg_dump_cursor CURSOR FOR %s,
+select_command);
+ }
+ else
+ {
+ appendPQExpBuffer(q, DECLARE _pg_dump_cursor CURSOR FOR
+SELECT * FROM ONLY %s, fmtId(classname, force_quotes));
+ }
else
- appendPQExpBuffer(q, DECLARE _pg_dump_cursor CURSOR FOR SELECT * FROM
%s, fmtId(classname, force_quotes));
+ if (select_command)
+ {
+ appendPQExpBuffer(q, DECLARE _pg_dump_cursor CURSOR FOR %s,
+select_command);
+ }
+ else
+ {
+ appendPQExpBuffer(q, DECLARE _pg_dump_cursor CURSOR FOR
+SELECT * FROM %s, fmtId(classname, force_quotes));
+ }
res = PQexec(g_conn, q-data);
if (!res ||
@@ -547,7 +563,7 @@
*/
static void
dumpClasses(const TableInfo *tblinfo, const int numTables, Archive *fout,
-const char *onlytable, const bool oids, const bool force_quotes)
+const char *onlytable, const bool oids, const bool force_quotes,
+const char *select_command)
{
int i;
DataDumperPtr dumpFn;
@@ -587,6 +603,7 @@
dumpCtx-tblinfo = (TableInfo *) tblinfo;
dumpCtx-tblidx = i;
dumpCtx-oids = oids;
+ dumpCtx-select_command = NULL;
if (!dumpData)
{
@@ -602,6 +619,10 @@
/* Restore using INSERT */
dumpFn = dumpClasses_dumpData;
copyStmt = NULL;
+ if (onlytable (strcmp(classname, onlytable) == 0))
+ {
+ dumpCtx-select_command = select_command;
+ }
}
ArchiveEntry(fout, tblinfo[i].oid, tblinfo[i].relname,
@@ -648,6 +669,7 @@
const char *pghost = NULL;
const char *pgport = NULL;
const char *username = NULL;
+ const char *select_command = NULL;
char *tablename = NULL;
booloids = false;
TableInfo *tblinfo;
@@ -694,6 +716,7 @@
{no-privileges, no_argument, NULL, 'x'},
{no-acl, no_argument, NULL, 'x'},
{compress,
Re: [GENERAL] [HACKERS] Linux Largefile Support In Postgresql RPMS
On Mon, 2002-08-12 at 21:07, Peter Eisentraut wrote: This is not the only issue. You really need to check all uses of off_t (for example printf(%ld, off_t) will crash) and all places where off_t should have been used in the first place. Furthermore you might need to replace ftell() and fseek() by ftello() and fseeko(), especially if you want pg_dump to support large archives. Searching for fseek, ftell and off_t yields only 12 files in the whole source tree, so fortunately the impact is not enormous. As expected, pg_dump is the main program involved. There seem to be several places in the pg_dump code where int is used instead of long int to receive the output of ftell(). I presume these ought to be cleaned up as well. Looking at how to deal with this, is the following going to be portable?: in pg_dump/Makefile: CFLAGS += -D_LARGEFILE_SOURCE -D_OFFSET_BITS=64 in pg_dump.h: #ifdef _LARGEFILE_SOURCE #define FSEEK fseeko #define FTELL ftello #define OFF_T_FORMAT %Ld typedef off_t OFF_T; #else #define FSEEK fseek #define FTELL ftell #define OFF_T_FORMAT %ld typedef long int OFF_T; #endif In pg_dump/*.c: change relevant occurrences of fseek and ftell to FSEEK and FTELL change all file offset parameters used or returned by fseek and ftell to OFF_T (usually from int) construct printf formats with OFF_T_FORMAT in appropriate places Still, most of the configuration work is already done in Autoconf (see AC_FUNC_FSEEKO and AC_SYS_LARGEFILE), so the work might be significantly less than the time spent debating the merits of large files on these lists. ;-) Since running autoconf isn't part of a normal build, I'm not familiar with that. Can autoconf make any of the above unnecessary? -- Oliver Elphick[EMAIL PROTECTED] Isle of Wight, UK http://www.lfix.co.uk/oliver GPG: 1024D/3E1D0C1C: CA12 09E0 E8D5 8870 5839 932A 614D 4C34 3E1D 0C1C Watch ye therefore, and pray always, that ye may be accounted worthy to escape all these things that shall come to pass, and to stand before the Son of man. Luke 21:36 ---(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] [COMMITTERS] pgsql-server/src backend/tcop/postgres.cbacke
Bruce Momjian [EMAIL PROTECTED] writes: Tom Lane wrote: We will? It looks to me like Thomas lost the vote 2-to-1. Well, you didn't vote again in my follow up email, I thought my vote was obvious already ... Can two guys override another guy if he is doing the work? I usually like to have a larger margin than that. I don't know what to do. I'm not pleased about it either; I'd have preferred to see a few more opinions given (and I'm surprised that no one else bothered to weigh in; lack of opinions is usually not a problem for pghackers ;-)). But I really seriously feel that this feature is a bad idea as presently implemented. If necessary, I'll volunteer to change it the way I think it should be (viz, initdb can set up a symlink to a specified xlog directory; no change from previous behavior anywhere else). regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [GENERAL] [HACKERS] Linux Largefile Support In Postgresql RPMS
On Tue, 2002-08-13 at 03:42, Mark Kirkwood wrote: Andrew Sullivan wrote: On Sat, Aug 10, 2002 at 09:21:07AM -0500, Greg Copeland wrote: I'm actually amazed that postgres isn't already using large file support. Especially for tools like dump. Except it would only cause confusion if you ran such a program on a system that didn't itself have largefile support. Better to make the admin turn all these things on on purpose, until everyone is running 64 bit systems everywhere. A Ah yes ... extremely good point - I had not considered that. I am pretty sure all reasonably current (kernel = 2.4) Linux distros support largefile out of the box - so it should be safe for them. Other operating systems where 64 bit file access can be disabled or unconfigured require more care - possibly (sigh) 2 binary RPMS with a distinctive 32 and 64 bit label ...(I think the big O does this for Solaris). Then, of course, there are systems where Largefiles support is a filesystem by filesystem (read mountpoint by mountpoint) option (E.G. OpenUNIX). I think this is going to be a pandoras box. -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 ---(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] [COMMITTERS] pgsql-server/src
But I really seriously feel that this feature is a bad idea as presently implemented. If necessary, I'll volunteer to change it the way I think it should be (viz, initdb can set up a symlink to a specified xlog directory; no change from previous behavior anywhere else). Neither solution is a particularly good one. Symlinks seem to break all over the place (windows, novell, os/2), environment variables are clumsy, arguments are easily forgotten by a new admin starting up the system manually without reading documentation first, and postgresql.conf changes are implemented via HUP (which we don't want -- has to be a full restart?). I'm going to vote a postgresql.conf entry similar to the LC_ vars thats initialized by initdb BUT is configurable with a big warning above it describing what needs to be done when changing it. ---(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] [COMMITTERS] pgsql-server/src
Marc G. Fournier [EMAIL PROTECTED] writes: I think Tom is on to something here. I meant to ask but never got around to it. Why would anyone need to move the XLOG after you've inited the db? I just determined that disk I/O is terrible, so want to move the XLOG over to a different file system that is currently totally idle ... Sure, needing to manually move the xlog directory is a plausible thing, but *you can already do it*. The current procedure is 1. shut down postmaster 2. cp -p -r xlog directory to new location 3. rm -rf old xlog directory 4. ln -s new xlog directory to $PGDATA/xlog 5. start postmaster With the patch it's almost the same, but you can instead of (4) substitute (4a) Change PGXLOG environment variable or -X argument in start script. That is *not* materially easier than an ln in my book. And it's fraught with all the risks we've come to know and not love over the years: it's just way too easy to start a postmaster with the wrong set of environment variables. (Hand start vs start from boot script, etc, etc, etc.) But this time the penalty for getting it wrong is, very possibly, irrecoverable corruption of your database. I see a serious downside to doing it this way, and not enough upside to justify taking the risk. We should continue to keep the where's the xlog information in the database directory itself. While a symlink isn't the only possible way to do that (a configuration-file item might do instead), I just don't think it's a good idea to allow it to be specified externally. regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [GENERAL] [HACKERS] Linux Largefile Support In Postgresql RPMS
On Tue, Aug 13, 2002 at 08:02:05AM -0500, Larry Rosenman wrote: On Tue, 2002-08-13 at 03:42, Mark Kirkwood wrote: Other operating systems where 64 bit file access can be disabled or unconfigured require more care - possibly (sigh) 2 binary RPMS with a distinctive 32 and 64 bit label ...(I think the big O does this for Solaris). Then, of course, there are systems where Largefiles support is a filesystem by filesystem (read mountpoint by mountpoint) option (E.G. OpenUNIX). I think this is going to be a pandoras box. I don't understand. Why would you want large-file support enabled on a per-filesystem basis? All your system programs would have to support the lowest common denomitor (ie, with large file support). Is it to make the kernel enforce a limit for the purposes of compatability? I'd suggest making it as simple as --enable-large-files and make it default in a year or two. -- Martijn van Oosterhout [EMAIL PROTECTED] http://svana.org/kleptog/ There are 10 kinds of people in the world, those that can do binary arithmetic and those that can't. ---(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] [COMMITTERS] pgsql-server/src backend/tcop/postgres.cbacke
Thomas Lockhart [EMAIL PROTECTED] writes: In the spirit of gratutious overstatement, I'll point out again: symlinks are evil. Please justify that claim. They work really nicely in my experience... and I don't know of any modern Unix system that doesn't rely on them *heavily*. Possibly more to the point, I can assert environment variables are evil with at least as much foundation. We have seen many many reports of trouble from people who were bit by environment-variable problems with Postgres. Do I need to trawl the archives for examples? However, as I just commented to Marc the real issue in my mind is that the xlog needs to be solidly tied to the data directory, because we can't risk starting a postmaster with the wrong combination. I do not think that external specification of the xlog as a separate env-var or postmaster command-line arg gives the appropriate amount of safety. But there's more than one way to record the xlog location in the data directory. If you don't like a symlink, what of putting it in postgresql.conf as a postmaster-start-time-only config option? regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [GENERAL] [HACKERS] Linux Largefile Support In Postgresql RPMS
Looking at how to deal with this, is the following going to be portable?: in pg_dump/Makefile: CFLAGS += -D_LARGEFILE_SOURCE -D_OFFSET_BITS=64 in pg_dump.h: #ifdef _LARGEFILE_SOURCE #define FSEEK fseeko #define FTELL ftello #define OFF_T_FORMAT %Ld typedef off_t OFF_T; #else #define FSEEK fseek #define FTELL ftell #define OFF_T_FORMAT %ld typedef long int OFF_T; #endif No, look at the int8 code to see how to make it portable. On AIX e.g it is %lld and long long int. Andreas ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] [COMMITTERS] pgsql-server/src backend/tcop/postgres.cbacke
Marc G. Fournier [EMAIL PROTECTED] writes: One thought at the back of my mind is why not have something like a 'PG_VERSION' for XLOG? Maybe something so simple as a text file in both the data and xlog directory that just contains a timestamp from the initdb? then, when you startup postmaster with a -X option, it compares the two files and makes sure that they belong to each other? While that isn't a bad idea, it seems to me that it's adding mechanism to get around a problem that we don't need to have in the first place. The only reason this risk exists is that the patch changes a monolithic postmaster option (-D) into two independent options (-D/-X) that in reality should never be independent. Essentially, you're proposing Kevlar shoes as a solution for the problem that you want to walk around carrying a loaded gun aimed at your foot. The shoes might be a good idea anyway, but the primary problem is elsewhere... regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[HACKERS] OpenFTS 0.33 Release
Hi, this is an announcement of OpenFTS 0.33 release. Please, find archive in download area at openfts.sourceforge.net This is a major release ! It has a lot of enhancements. It's required PostgreSQL 7.2.1 (7.2.2 from CVS would be better) Some major changes: 1. We moved from using contrib/intarray module to our new module contrib/tsearch, which is available from contrib directory of PostgreSQL distribution since 7.2 release. tsearch module provides special text data type suitable for text indexing. It uses words 'as is' without hashing to integers and provides search interface in more natural way. For example, it's possible now to test fulltext search from psql. Read documentation in contrib/tsearch module for more details. 2. We changes interfaces to dictionaries to conform changes in 1. Methods provided by dictionaries should work with lexems instead of integers as before: lemms method instead of lemmsid, is_stoplexem instead of is_stoplemm. 3. We've added a possibility to drop OpenFTS instances: drop - removes all OpenFTS tables, indices, dictionaries (if dictionary provides 'drop' method); drop_index - it's opposite to method 'create_index', removes all OpenFTS indices on index tables (INDEX1,,,INDEXN) and GiST index on base table (the table where the documents are stored together with its primary key). It's very convenient for adminstration and maintaince. 4. We've added generic interfaces to ISpell dictionaries and Snowball stemmers. ISpell dictionaries are free and available for many languages and could be used to return base forms for a word. It's very important for inflective languages, i.e. russian language. Snowball stemmers (available from snowball.sourceforge.net) could be use to stemm a word, i.e. to cut a words endings and use remains stem for indexing and searching. Unfortunately, documentation is not completely updated. There is Crash-Course in example directory which should be enough to start. As always, your questions and comments are welcome. Please, use openfts-general mailing list [EMAIL PROTECTED] We are looking for documentation manager ! Please, contact Oleg Bartunov [EMAIL PROTECTED] if you're willing to join the OpenFTS project. Regards, Oleg _ Oleg Bartunov, sci.researcher, hostmaster of AstroNet, Sternberg Astronomical Institute, Moscow University (Russia) Internet: [EMAIL PROTECTED], http://www.sai.msu.su/~megera/ phone: +007(095)939-16-83, +007(095)939-23-83 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] [COMMITTERS] pgsql-server/src
On Tue, 2002-08-13 at 08:15, Tom Lane wrote: Marc G. Fournier [EMAIL PROTECTED] writes: I think Tom is on to something here. I meant to ask but never got around to it. Why would anyone need to move the XLOG after you've inited the db? I just determined that disk I/O is terrible, so want to move the XLOG over to a different file system that is currently totally idle ... Sure, needing to manually move the xlog directory is a plausible thing, but *you can already do it*. The current procedure is 1. shut down postmaster 2. cp -p -r xlog directory to new location 3. rm -rf old xlog directory 4. ln -s new xlog directory to $PGDATA/xlog 5. start postmaster With the patch it's almost the same, but you can instead of (4) substitute Why not simply create a script which does this? Creation of movexlog or some such beast which anally checked everything it did. As options, you could simply pass it the src and dest and let it take care of the rest. Greg signature.asc Description: This is a digitally signed message part
Re: [HACKERS] OOP real life example (was Re: Why is MySQL more
Greg Copeland wrote: On Tue, 2002-08-13 at 00:16, Curt Sampson wrote: I will revise my opinion the instant someone shows me something that I can't do relationally, or is easy to implement with inheritance, and difficult with relational methods. The traditional view approach requires unnecessary joins, and there's no getting around it. And yes I know he's not reading my mail and no, don't bother repeating this to him, he'll just continue to ignore the point. -- Don Baccus Portland, OR http://donb.photo.net, http://birdnotes.net, http://openacs.org ---(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] [COMMITTERS] pgsql-server/src
On Tue, 2002-08-13 at 14:15, Tom Lane wrote: 4. ln -s new xlog directory to $PGDATA/xlog With the patch it's almost the same, but you can instead of (4) substitute (4a) Change PGXLOG environment variable or -X argument in start script. That is *not* materially easier than an ln in my book. And it's fraught with all the risks we've come to know and not love over the years: it's just way too easy to start a postmaster with the wrong set of environment variables. (Hand start vs start from boot script, etc, etc, etc.) But this time the penalty for getting it wrong is, very possibly, irrecoverable corruption of your database. I see a serious downside to doing it this way, and not enough upside to justify taking the risk. We should continue to keep the where's the xlog information in the database directory itself. While a symlink isn't the only possible way to do that (a configuration-file item might do instead), I just don't think it's a good idea to allow it to be specified externally. Since the xlog is so closely linked with the database, I would be unhappy for its location to be determined by a parameter in a file that could be edited by an ignorant or careless administrator. Thomas does not like symlinks. Equally I don't like the idea of an environment variable, which is even more vulnerable to misuse. Could you not store the location of the xlog directory as an entry in $PGDATA/global/pg_control? The xlog is as closely tied in with the database as is its locale, which is already stored in pg_control. To let the directory be moved, there should then be a standalone program that would shut down the server, copy the xlog directory to the new location and set its access permissions; on a successful copy, change the control entry, delete the old xlog directory and finally restart the server. Use of such a program would protect against other possible errors, such as pointing two different databases to the same xlog. -- Oliver Elphick[EMAIL PROTECTED] Isle of Wight, UK http://www.lfix.co.uk/oliver GPG: 1024D/3E1D0C1C: CA12 09E0 E8D5 8870 5839 932A 614D 4C34 3E1D 0C1C Watch ye therefore, and pray always, that ye may be accounted worthy to escape all these things that shall come to pass, and to stand before the Son of man. Luke 21:36 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] [COMMITTERS] pgsql-server/src backend/tcop/postgres.cbacke
Rod Taylor [EMAIL PROTECTED] writes: Symlinks seem to break all over the place (windows, novell, os/2), The portability argument carries little weight with me. Recent versions of Windows have symlinks. If anyone wants to run a PG installation on a symlink-less platform, okay; they just won't have the option to move the xlog directory. That's probably not the only functionality they lose by using such an inadequate filesystem... regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [GENERAL] [HACKERS] Linux Largefile Support In Postgresql RPMS
On Tue, 2002-08-13 at 14:26, Zeugswetter Andreas SB SD wrote: Looking at how to deal with this, is the following going to be portable?: No, look at the int8 code to see how to make it portable. On AIX e.g it is %lld and long long int. OK. %lld is usable by glibc, so amend %Ld to %lld. Any other comments? -- Oliver Elphick[EMAIL PROTECTED] Isle of Wight, UK http://www.lfix.co.uk/oliver GPG: 1024D/3E1D0C1C: CA12 09E0 E8D5 8870 5839 932A 614D 4C34 3E1D 0C1C Watch ye therefore, and pray always, that ye may be accounted worthy to escape all these things that shall come to pass, and to stand before the Son of man. Luke 21:36 ---(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] [COMMITTERS] pgsql-server/src
On Tue, 2002-08-13 at 14:24, Tom Lane wrote: ... But there's more than one way to record the xlog location in the data directory. If you don't like a symlink, what of putting it in postgresql.conf as a postmaster-start-time-only config option? Please don't! The Debian package at least provides a default postgresql.conf and it will be all too easy for someone installing an updated package to let the default file overwrite the existing configuration. That could be disastrous. -- Oliver Elphick[EMAIL PROTECTED] Isle of Wight, UK http://www.lfix.co.uk/oliver GPG: 1024D/3E1D0C1C: CA12 09E0 E8D5 8870 5839 932A 614D 4C34 3E1D 0C1C Watch ye therefore, and pray always, that ye may be accounted worthy to escape all these things that shall come to pass, and to stand before the Son of man. Luke 21:36 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] OOP real life example (was Re: Why is MySQL more
On Tuesday 13 August 2002 01:40 am, Greg Copeland wrote: On Tue, 2002-08-13 at 00:33, Curt Sampson wrote: On Mon, 12 Aug 2002, Don Baccus wrote: Give it up. You're acting like a turkey. If you aren't, skin yourself a new non-turkey skin. Since he appears not to be able to avoid abusive ad hominem attacks, I'm now sending mail with [EMAIL PROTECTED] in the From: header to /dev/null. If there's a technical point in one of his messages that relates to the discussion that I need to answer, someone should please mention it on the list or forward it to me. Curt, I think his reply stems from his frustration of chosen content in many emails that originate from you. We all pretty well understand postgres has a broken feature. We all understand you see zero value in Knowing Don to some extent, I can say with some assurance that his 'attacks' are never unprovoked. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] [COMMITTERS] pgsql-server/src
Oliver Elphick [EMAIL PROTECTED] writes: Could you not store the location of the xlog directory as an entry in $PGDATA/global/pg_control? We could do that *only* if we were to produce an xlog-moving program immediately; otherwise we've regressed in functionality compared to prior releases. I do not think it's necessary to be quite that anal about tying the two directories together --- the manual symlinking procedure I described has been around for two releases now, and while doubtless not that many people have actually done it, we've not heard any reports of failures. The thing is that if the DBA has to do this himself, he is very well aware that he's performing a critical procedure, and he's not likely to muck it up. I think that from a safety point of view either a symlink or a config-file entry are perfectly acceptable, and in general I prefer plain-text config files to those which are not. (Right now, pg_control is *not* a config file: there is not anything in it that you might want to edit in normal system maintenance. It should stay that way.) Marc's idea of matching signature files would be a better safety-checking mechanism than just making the data directory's xlog link hard to get at. regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] [COMMITTERS] pgsql-server/src backend/tcop/postgres.cbacke
Oliver Elphick [EMAIL PROTECTED] writes: On Tue, 2002-08-13 at 14:24, Tom Lane wrote: But there's more than one way to record the xlog location in the data directory. If you don't like a symlink, what of putting it in postgresql.conf as a postmaster-start-time-only config option? Please don't! The Debian package at least provides a default postgresql.conf and it will be all too easy for someone installing an updated package to let the default file overwrite the existing configuration. That could be disastrous. Ouch. That's a mighty good point ... although if we were to implement Marc's idea of matching signature files, we'd certainly catch the error. If we didn't, we'd need to use a separate, one-purpose config file that just records the xlog location. Curiously enough, that seems to me to be exactly what a symlink does, except that the symlink is OS-level code rather than something we have to write for ourselves. So I'm back to thinking that a symlink is a perfectly respectable answer. regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] [COMMITTERS] pgsql-server/src
On Tue, 2002-08-13 at 15:00, Tom Lane wrote: Oliver Elphick [EMAIL PROTECTED] writes: Could you not store the location of the xlog directory as an entry in $PGDATA/global/pg_control? We could do that *only* if we were to produce an xlog-moving program immediately; otherwise we've regressed in functionality compared to prior releases. If it doesn't have to edit pg_control (accepting your point below) it can be a shell script - half an hour to write and test it. I'll do it tonight if you choose to go this way ... I think that from a safety point of view either a symlink or a config-file entry are perfectly acceptable, and in general I prefer plain-text config files to those which are not. (Right now, pg_control is *not* a config file: there is not anything in it that you might want to edit in normal system maintenance. It should stay that way.) I suggested pg_control because it's already there. It could just as well be a *private* configuration file containing the pathname. Just don't put it in with postgresql.conf. As a producer of a binary distribution, I don't want to deal with the consequences of people ignorantly changing it. I'm sure you remember those mails from people who said, I wanted to save space so I deleted this log file... Marc's idea of matching signature files would be a better safety-checking mechanism than just making the data directory's xlog link hard to get at. When dealing with unknown numbers of package users, some of whom have only just converted from being Windows users, I want to be defensive. I cannot afford to assume that administrators know what they are doing! I have to try to pick up the pieces after those that don't. I would like to have Marc's safeguards as well. -- Oliver Elphick[EMAIL PROTECTED] Isle of Wight, UK http://www.lfix.co.uk/oliver GPG: 1024D/3E1D0C1C: CA12 09E0 E8D5 8870 5839 932A 614D 4C34 3E1D 0C1C Watch ye therefore, and pray always, that ye may be accounted worthy to escape all these things that shall come to pass, and to stand before the Son of man. Luke 21:36 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [GENERAL] [HACKERS] Linux Largefile Support In Postgresql RPMS
Oliver Elphick [EMAIL PROTECTED] writes: Looking at how to deal with this, is the following going to be portable?: #define OFF_T_FORMAT %Ld That certainly will not be. Use INT64_FORMAT from pg_config.h. typedef long int OFF_T; Why not just use off_t? In both cases? regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [GENERAL] [HACKERS] Linux Largefile Support In Postgresql RPMS
On Tue, 2002-08-13 at 15:23, Tom Lane wrote: typedef long int OFF_T; Why not just use off_t? In both cases? The prototype for fseek() is long int; I had assumed that off_t was not defined if _LARGEFILE_SOURCE was not defined. -- Oliver Elphick[EMAIL PROTECTED] Isle of Wight, UK http://www.lfix.co.uk/oliver GPG: 1024D/3E1D0C1C: CA12 09E0 E8D5 8870 5839 932A 614D 4C34 3E1D 0C1C Watch ye therefore, and pray always, that ye may be accounted worthy to escape all these things that shall come to pass, and to stand before the Son of man. Luke 21:36 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] [COMMITTERS] pgsql-server/src
Oliver Elphick [EMAIL PROTECTED] writes: Marc's idea of matching signature files would be a better safety-checking mechanism than just making the data directory's xlog link hard to get at. I would like to have Marc's safeguards as well. Yeah, I was lukewarm about that at first, but the more I think about it the better it seems. That does not change my opinion about the -X/PGXLOG switch though --- having a backup safety check is not an excuse for having a fundamentally insecure set of startup options. regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] [COMMITTERS] pgsql-server/src backend/tcop/postgres.cbacke
Yea, the problem with postgresql.conf is that we don't have any automatic modifications of that file, and I don't think we want to start just to avoid symlinks. I personally like symlinks too. I use them all the time. What is the problem with them, exactly? Can someone show me some commands that cause problems? And the problem with a separate file is that when the move pg_xlog, it isn't going to be obvious what they need to change to find the new directory. Of course, they could just create a symlink and leave the file unchanged. Aside from the arg bloat problem, the real danger is that someone is going to forget PGDATA and PGXLOG, try to start the postmaster, add -D for PGDATA, then when they see that they need PGXLOG, they may just create data/pg_xlog as an empty directory and start the postmaster. That is a very real possibility. I just tried it and it does complain about the missing checkpoint records so maybe it isn't as bad as I thought, but still, it opens a place for error where none existed before. --- Tom Lane wrote: Oliver Elphick [EMAIL PROTECTED] writes: On Tue, 2002-08-13 at 14:24, Tom Lane wrote: But there's more than one way to record the xlog location in the data directory. If you don't like a symlink, what of putting it in postgresql.conf as a postmaster-start-time-only config option? Please don't! The Debian package at least provides a default postgresql.conf and it will be all too easy for someone installing an updated package to let the default file overwrite the existing configuration. That could be disastrous. Ouch. That's a mighty good point ... although if we were to implement Marc's idea of matching signature files, we'd certainly catch the error. If we didn't, we'd need to use a separate, one-purpose config file that just records the xlog location. Curiously enough, that seems to me to be exactly what a symlink does, except that the symlink is OS-level code rather than something we have to write for ourselves. So I'm back to thinking that a symlink is a perfectly respectable answer. regards, tom lane ---(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 4: Don't 'kill -9' the postmaster
Re: [GENERAL] [HACKERS] Linux Largefile Support In Postgresql RPMS
Oliver Elphick [EMAIL PROTECTED] writes: On Tue, 2002-08-13 at 15:23, Tom Lane wrote: Why not just use off_t? In both cases? The prototype for fseek() is long int; I had assumed that off_t was not defined if _LARGEFILE_SOURCE was not defined. Oh, you're right. A quick look at HPUX shows it's the same way: ftell returns long int, ftello returns off_t (which presumably is an alias for long long int). Okay, OFF_T seems a reasonable answer. regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Temporary Views
Gavin Sherry wrote: Hi all, I'm thinking that temporary views should be pretty trivial to implement. * Allow temporary views This should be as simple as modifying gram.y (to set ViewStmt-view-istemp) and some logic in RemoveTempRelations() to remove the view's rule Yep, pretty simple. * Require view using temporary tables to be temporary views This is the non-trivial part. If you are creating a view on just a temporary table there's no problem. But what happens when do the following? CREATE VIEW abc AS select * from tab1,tab2,temp_tab3 ... SQL99 avoids this with syntax rule 6 of 11.21 view definition No table reference generally contained in the query expression shall identify any declared local temporary table. There are a few ways it could be implemented: 1) SQL99 2) Views whose query epression contains one or more table references to temporary tables are created as temporary views 3) Views whose query epression contains one or more table references to temporary tables must be explicitly include the TEMP[ORARY] syntax. The idea is that if the temp table goes away, we don't want the view continuing to exist. I think if there are any temp tables in the view, the view _has_ to be specified by the user as temporary, or we throw an error telling them it has to be temporary. -- 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 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] Temporary Views
Gavin Sherry [EMAIL PROTECTED] writes: I'm thinking that temporary views should be pretty trivial to implement. ... except not so trivial, per the rest of your note. Do we actually need any such feature? Views on temp tables already work correctly in CVS tip: the implicit DROP CASCADE on temp tables at backend exit makes such views go 'way too. regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Temporary Views
On Tue, 2002-08-13 at 11:11, Tom Lane wrote: Gavin Sherry [EMAIL PROTECTED] writes: I'm thinking that temporary views should be pretty trivial to implement. ... except not so trivial, per the rest of your note. Do we actually need any such feature? Views on temp tables already work correctly in CVS tip: the implicit DROP CASCADE on temp tables at backend exit makes such views go 'way too. I was playing with this a while back (when I had initially added CASCADE to tables). I believe that in the event of a crash the temp tables are not removed until their next use. This means that stale *real* items may litter the system but the temp table no longer exists in these rare occurrences. However, having all temporary items removed during backend startup would remove this case. ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
[HACKERS] Please, apply patch for contrib/tsearch
CHANGES: August 13, 2002 Use parser of OpenFTS v0.33. -- Teodor Sigaev [EMAIL PROTECTED] tsearch_patch.gz Description: application/gzip ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Please, apply patch for contrib/tsearch
to current CVS, of course. Sorry -- Teodor Sigaev [EMAIL PROTECTED] ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Temporary Views
Tom Lane wrote: Gavin Sherry [EMAIL PROTECTED] writes: I'm thinking that temporary views should be pretty trivial to implement. ... except not so trivial, per the rest of your note. Do we actually need any such feature? Views on temp tables already work correctly in CVS tip: the implicit DROP CASCADE on temp tables at backend exit makes such views go 'way too. Oh. but RESTRICT is the default. Seems like the view should go away no matter what, and if they mix temp and non-temp tables, is it obvious that the view will disappear if they didn't specify TEMP on view creation. I can go either way, but I want to make sure we agree so I can modify the TODO accordingly. -- 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] Temporary Views
Rod Taylor [EMAIL PROTECTED] writes: I was playing with this a while back (when I had initially added CASCADE to tables). I believe that in the event of a crash the temp tables are not removed until their next use. This means that stale *real* items may litter the system but the temp table no longer exists in these rare occurrences. Huh? The view goes away at exactly the same time the temp table does. If you suffer a backend crash then that may be postponed ... but the view continues to work up till the instant that it's removed. regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Temporary Views
On Tue, 2002-08-13 at 12:22, Tom Lane wrote: Rod Taylor [EMAIL PROTECTED] writes: I was playing with this a while back (when I had initially added CASCADE to tables). I believe that in the event of a crash the temp tables are not removed until their next use. This means that stale *real* items may litter the system but the temp table no longer exists in these rare occurrences. Huh? The view goes away at exactly the same time the temp table does. If you suffer a backend crash then that may be postponed ... but the view continues to work up till the instant that it's removed. After a backend crash the temp tables exist, but are not usable by the current backend as it is different than the one which originally created the temp table (the crash causing a restart and everything). So non-temp items which depend on the no longer usable temp table will be broken until they are scrubbed, which does not happen until the next time a temp table is created. Not that it really matters, but moving a temp-table destruction event into the startup sequence would solve it. ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Temporary Views
On Tue, 2002-08-13 at 11:18, Bruce Momjian wrote: Tom Lane wrote: Gavin Sherry [EMAIL PROTECTED] writes: I'm thinking that temporary views should be pretty trivial to implement. ... except not so trivial, per the rest of your note. Do we actually need any such feature? Views on temp tables already work correctly in CVS tip: the implicit DROP CASCADE on temp tables at backend exit makes such views go 'way too. Oh. but RESTRICT is the default. Seems like the view should go away no matter what, and if they mix temp and non-temp tables, is it obvious that the view will disappear if they didn't specify TEMP on view creation. When the backend exits the code that removes temp tables is CASCADE by default and anything depending on it will disappear. ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] db partial dumping with pg_dump
This patch seems extremely messy to me. Unless I'm missing something, -w just plain fails except when you are dumping a specific table (ie, -t must be given as well). And heaven help you if you specify a different table in -t than the one -w is selecting from. This isn't well thought out. I'm not at all convinced that such a thing belongs in pg_dump anyway. It'd be more useful as a manually-invokable feature, I think. You can almost do this in psql with select * from table where something \g outfile but I don't think you can get psql to emit the data in a form that can be reloaded reliably (it won't quote data characters that look the same as column delimiters, for instance). What would seem to make sense is adding a WHERE-clause option to COPY TO, and then you could go COPY table TO 'myfile' WHERE ... We already have column-list support in COPY, so we can already slice the table vertically --- WHERE would let you slice it horizontally, which seems a natural extension. (BTW, has anyone taught psql's \copy about column lists? AFAIR the original patch was only against the backend.) I'm finding it hard to visualize situations where I'd want the extra baggage of pg_dump for something like this. If I want the schema at all, I'll probably want it separate from the data so that I can hack the schema conveniently --- so I'd want to do a pg_dump -s -t table and then do the selective copying separately. regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] [COMMITTERS] pgsql-server/src backend/tcop/postgres.cbacke
On Mon, 12 Aug 2002, Thomas Lockhart wrote: If you move pg_xlog, you have to create a symlink in /data that points to the new location. Initdb would do that automatically, but if you move it after initdb, you would have to create the symlink yourself. With Thomas's current code, you would add/change PGXLOG instead to point to the new location, rather than modify the symlink. There is no the symlink, but of course that tinkering is in no way precluded by the new code. Although some seem to like symlinks, others (including myself) see no good engineering practice in making them the only foundation for distributing files across file systems. Why? You often say you don't like them, but I have yet to see you say why you don't like them. The patches as-is follow existing PostgreSQL practice, using environmental variables is a practice we should discontinue if possible, and use as little as possible. They ARE a security hole waiting to happen. have complete and perfect backward compatibility, and do not preclude changes in underlying implementation in the future if those who are objecting choose to do a complete and thorough job of meeting my objections to the current counter-suggestions. As an example, two lines of code in initdb would add the beloved symlink to $PGDATA, eliminating one objection though (of course) one I don't support. One thought at the back of my mind is why not have something like a 'PG_VERSION' for XLOG? Maybe something so simple as a text file in both the data and xlog directory that just contains a timestamp from the initdb? then, when you startup postmaster with a -X option, it compares the two files and makes sure that they belong to each other? Uh, seems it could get messy, but, yea, that would work. It means adding a file to pg_xlog and /data and somehow matching them. My feeling was that the symlink was unambiguous and allowed for fewer mistakes. I think that was Tom's opinion too. In the spirit of gratutious overstatement, I'll point out again: symlinks are evil. Any sense of a job well done is misplaced if our underpinnings rely on them for distributing files across file systems. As an ad hoc hack to work around current limitations they may have some utility. Why are symlinks evil? They exist on every major OS I know of, and they work. They allow the user to quickly point the postgresql engine in different places, and they are simple and easy to use. I found the use of environmental variables far more confusing when I first started using postgresql than symlinks. In particular, which operating systems does Postgresql run don't have symlink capability? Anyway, istm that this is way too much discussion for a small extension of capability, and it has likely cost a table and index with location implementation for the upcoming release just due to time wasted discussing it. Hope it was worth it :/ Well, if it averts a security problem, or makes the database easier to use in the long run, then it probably was. It may seem like too much discussion for such a simple topic, but it's not. My non-coding vote goes with Tom Lane on this. initdb can set pg_xlog, and if you need to change it, use symlinks. They're safe, secure, and they just plain work. The only argument I can possibly think of against the symlink boogie is if there is an os we run on that can't do symlinks. And then I'd still think it would belong in postgresql.conf, be set by initdb, and not be an environmental variable. Of course that's just my opinion, I could be wrong (with apologies to Dennis Miller) Scott Marlowe ---(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] Temporary Views
Rod Taylor wrote: On Tue, 2002-08-13 at 11:18, Bruce Momjian wrote: Tom Lane wrote: Gavin Sherry [EMAIL PROTECTED] writes: I'm thinking that temporary views should be pretty trivial to implement. ... except not so trivial, per the rest of your note. Do we actually need any such feature? Views on temp tables already work correctly in CVS tip: the implicit DROP CASCADE on temp tables at backend exit makes such views go 'way too. Oh. but RESTRICT is the default. Seems like the view should go away no matter what, and if they mix temp and non-temp tables, is it obvious that the view will disappear if they didn't specify TEMP on view creation. When the backend exits the code that removes temp tables is CASCADE by default and anything depending on it will disappear. Oh, OK, that is interesting. So that only leaves the issue of not specifying TEMP in a case of views using mixed temp/non-temp tables. We don't specify TEMP when creating an index on a temp table, and it is auto-destroyed. I guess it is OK that we don't specify TEMP on a view creation using a temp table, except that the view can have a mix of temp and non-temp while an index is just on one table. I can go either way on this. -- 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] Temporary Views
Bruce Momjian [EMAIL PROTECTED] writes: I can go either way on this. AFAICS create temp view would have some small advantage of keeping the view's name out of possibly-public permanent namespaces, so the step of just adding the TEMP option to CREATE VIEW may be worth doing. The advantage isn't very big but neither is the amount of work. Trying to prohibit non-temp views on temp tables strikes me as more work than it's worth; that TODO item was written before we had dependencies, and I think it's obsolete. Basically the point of the TODO was to avoid having broken views --- and we have solved that problem. regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Temporary Views
Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: I can go either way on this. AFAICS create temp view would have some small advantage of keeping the view's name out of possibly-public permanent namespaces, so the step of just adding the TEMP option to CREATE VIEW may be worth doing. The advantage isn't very big but neither is the amount of work. What about indexes? Do indexes on temp tables exist in the temp namespace? I would think they should by default, as well as views based on temp tables. Certainly no one else should be able to see the temp index/views. Trying to prohibit non-temp views on temp tables strikes me as more work than it's worth; that TODO item was written before we had dependencies, and I think it's obsolete. Basically the point of the TODO was to avoid having broken views --- and we have solved that problem. Yes, if it auto-temps because it is based on a temp object, that is fine by me. However, based on your comments above, I think it should auto-temp fully, rather than just auto-destroy. -- 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 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [GENERAL] [HACKERS] Linux Largefile Support In Postgresql RPMS
Oliver Elphick wrote: On Tue, 2002-08-13 at 03:57, Greg Copeland wrote: Ext2 3 should be okay. XFS (very sure) and JFS (reasonably sure) should also be okay...IIRC. NFS and SMB are probably problematic, but I can't see anyone really wanting to do this. Hmm. Whereas I can't see many people putting their database files on an NFS mount, I can readily see them using pg_dump to one, and pg_dump is the program where large files are really likely to be needed. I wouldn't totally discount using NFS for large databases. Believe it or not, with an Oracle database and a Network Appliance for storage, NFS is exactly what is used. We've found that we get better performance with a (properly tuned) NFS mounted NetApp volume than with attached storage on our HPUX box with several 100+GB databases. Joe ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] VACUUM's No one parent tuple was found, redux
Tom Lane wrote: Also, for Mario and Barry: does this test case look anything like what your real applications do? In particular, do you ever do a SELECT FOR UPDATE in a transaction that commits some changes, but does not update or delete the locked-for-update row? If not, it's possible there are yet more bugs lurking in this. This certainly seems plausible for my application. --Barry ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Temporary Views
Bruce Momjian [EMAIL PROTECTED] writes: What about indexes? Do indexes on temp tables exist in the temp namespace? Yes, a fortiori: any index exists in its table's namespace. Seems pretty irrelevant to the point at hand, though. 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 contrib/tsearch
Your patch has been added to the PostgreSQL unapplied patches list at: http://candle.pha.pa.us/cgi-bin/pgpatches I will try to apply it within the next 48 hours. --- Teodor Sigaev wrote: CHANGES: August 13, 2002 Use parser of OpenFTS v0.33. -- Teodor Sigaev [EMAIL PROTECTED] [ application/gzip is not supported, skipping... ] ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster -- 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] db partial dumping with pg_dump
On Tue, 13 Aug 2002, Tom Lane wrote: This patch seems extremely messy to me. Unless I'm missing something, -w just plain fails except when you are dumping a specific table (ie, -t must be given as well). And heaven help you if you specify a different table in -t than the one -w is selecting from. This isn't well thought out. You're right. The patch I've sent was no way for submitting to sources ! I just asked about the feature and attached to message for Rod Taylor. I'm not at all convinced that such a thing belongs in pg_dump anyway. It'd be more useful as a manually-invokable feature, I think. You can almost do this in psql with select * from table where something \g outfile but I don't think you can get psql to emit the data in a form that can be reloaded reliably (it won't quote data characters that look the same as column delimiters, for instance). that was the reason we don't use psql for dumping What would seem to make sense is adding a WHERE-clause option to COPY TO, and then you could go COPY table TO 'myfile' WHERE ... We already have column-list support in COPY, so we can already slice the table vertically --- WHERE would let you slice it horizontally, which seems a natural extension. (BTW, has anyone taught psql's \copy about column lists? AFAIR the original patch was only against the backend.) I'm finding it hard to visualize situations where I'd want the extra baggage of pg_dump for something like this. If I want the schema at all, I'll probably want it separate from the data so that I can hack the schema conveniently --- so I'd want to do a pg_dump -s -t table and then do the selective copying separately. that'd be nice ! I often need such a feature because db at work are often too large to play at home :-) regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED] Regards, Oleg _ Oleg Bartunov, sci.researcher, hostmaster of AstroNet, Sternberg Astronomical Institute, Moscow University (Russia) Internet: [EMAIL PROTECTED], http://www.sai.msu.su/~megera/ phone: +007(095)939-16-83, +007(095)939-23-83 ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
[HACKERS] Possible enhancement : replace view ?
Dear all, The current implementation of views uses OIDs, not table/view names. As a consequence, when you happen to replace (drop then create) an underlying table or view, you also have to drop and recreate all views using this table|view (and this recursively, of course ...). I stumbled on this while doing repeat analyses (involving repeated uses of aggregation) of the same dataset using slight variations of the subset of interest. When my dataset was small, I used to do that in (yuck !) MS-Access by creating a view defining the subset of interest, then creating views based on this view, and so on... Now that my dataset is too large to be Access-manageable, I migrated it to PostgreSQL (which, BTW, gave me nice performance enhancements), but I had to change my working habits. I have now to create a script defining my views, then to run it at each and every variation of the subset of interest ... To be able to conserve existing views would definitely be a bonus. Of course, the overhead is necessary to handle the general case. However, there is a special case where this is unnecessary : when the new table or view class definition is a (possibly improper) subclass of the original one, or, if you prefer, when the column set of the new definition is a (possibly improper) superset of the old one. For tables, this case is already handled by a judicious use of alter table, at least in its present form (adding DROP COLUMN, which might be an interesting feature for other reasons, entails the risk of invalidating existing views ...). However, there is currently no easily reachable way to do that for a view (I suppose that the special case of modifying the definition of a view creating the same columns in the old and new definitions might be possible with a clever (ab)use of system catalogs, but I tend to be *very* wary of such hacks ...). Of course, I am aware that view definitions aren't just stored, but that a lot of rewriting is involved before storing the actual execution plan.Modifying a view definition would entail re-processing of other view definitions. But so is the case with the modification of a table ... What do you think ? -- Emmanuel Charpentier ---(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] Possible enhancement : replace view ?
Emmanuel Charpentier [EMAIL PROTECTED] writes: What do you think ? I think Gavin Sherry is already working on this. regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Possible enhancement : replace view ?
Hannu Krosing wrote: On Wed, 2002-08-14 at 04:08, Emmanuel Charpentier wrote: Dear all, ... Of course, I am aware that view definitions aren't just stored, but that a lot of rewriting is involved before storing the actual execution plan.Modifying a view definition would entail re-processing of other view definitions. But so is the case with the modification of a table ... What do you think ? I'm trying to propose a scenario where 1. The SELECT clause defining the view is preserved 2. DROP of undrlying table/column will _not_ drop the view, but just mark it dirty 3. Using the view checks for the dirty flag and if it is set tries to recreate the view from its plaintext definition. I might be dense, but why not try to recreate it directly after the table/column modification ? --- Hannu ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Possible enhancement : replace view ?
Tom, I submitted a patch for this a few days ago. Did it not hit pgsql-patches? Gavin On Tue, 13 Aug 2002, Tom Lane wrote: Emmanuel Charpentier [EMAIL PROTECTED] writes: What do you think ? I think Gavin Sherry is already working on this. regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Temporary Views
Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: What about indexes? Do indexes on temp tables exist in the temp namespace? Yes, a fortiori: any index exists in its table's namespace. Seems pretty irrelevant to the point at hand, though. Just checking. So the index exists in the same namespace as the table. Makes sense. Same with sequences, I assume. Of course, views can represent multiple tables so I think they should go into the names space with the temp tables. -- 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 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Possible enhancement : replace view ?
Hannu Krosing wrote:
On Wed, 2002-08-14 at 04:23, Emmanuel Charpentier wrote:
Hannu Krosing wrote:
I'm trying to propose a scenario where
1. The SELECT clause defining the view is preserved
2. DROP of undrlying table/column will _not_ drop the view, but just
mark it dirty
3. Using the view checks for the dirty flag and if it is set tries to
recreate the view from its plaintext definition.
I might be dense, but why not try to recreate it directly after the
table/column modification ?
If it is a DROP TABLE/CREATE TABLE sequence you have no idea that you
have to recreate a view.
Right. But I was wary of delaying recreation : views are more often than
not created by programmers/DBAs/someone somewhat competent in DB design
and use, in order to be used by people not necessarily aware of the real
struxture of data (that's the whole point of having views, BTW).
Delaying recreation entails the risk of overlooking a problem and
getting a nice phone call at 2 AM from the maintainance guy stuttering
that he can no longer access its (vital, of course) data ...
Tradeoffs, again ... What about emitting warnings after table drop
(easy)/creation (not so easy !) ?
BTW : since drop column and alter various attributes (not null, primary
key, etc ...) will be possible, shoudn't the need to drop/recteate a
table drastically decrease ?
E. g. : I recently created a log table wit a field date timestamptz
default now(), only to discover that, due to current limitations of the
ODBC driver, I should have used timestamptz[0] (ODBC doesn't like
fraction of seconds in datetime). I kludged away bby updating (set
date=date_trunc('second',date)) and altering default to
date_trunc('second',date) (Yuck !), but the real solution would have
been of course to recreate the column with the right attribute, which
currently involves dropping/recreating the table, therefore losing all
defined views.
What a ten-thumbs programmer such as me would love to see in such a
scenario would be something along the lines of :
# Create table T (date as timestamp defailt now(), ...) ...;
CREATE
# Create view X as select date, ... from T join ...;
CREATE
# Create view Y as select anthing but date ... from T where ...;
CREATE
Create view Z as select date, ... from T join ...;
# CREATE
Create view U as select ... from Z left outer join ...;
---
--- Insert data here
---
...
---
--- Later ! Insert ODBC epiphany here
---
# alter table T add column newdate timestamptz[0];
ALTER --- I can't remember the exact acknowledgement sent for alter column
update T set newdate=date;
UPDATE (somenumber) 0
alter table T rename column date to olddate;
ALTER --- ditto
WARNING : View X might have become invalid. Please check it or drop it !
WARNING : View Z might have become invalid. Please check it or drop it !
WARNING : View U might have become invalid. Please check it or drop it !
alter table T rename newdate to date;
ALTER --- ditto;
WARNING : View X successfully recreated from it's original SQL
definition. Please check it or drop it !
WARNING : View Z successfully recreated from it's original SQL
definition. Please check it or drop it !
WARNING : View U successfully recreated from it's original SQL
definition. Please check it or drop it !
Alter table T drop column olddate;
ALTER
Exercise left for the reader : what about inheritance ?
Another exercise : what about adding/dropping indices (indexes ?) ?
Your thoughs ?
__
Emmanuel Charpentier
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Possible enhancement : replace view ?
Tradeoffs, again ... What about emitting warnings after table drop (easy)/creation (not so easy !) ? The warnings are certainly there now. Dependency code won't let you do such a thing without specifying CASCADE. Hopefully CREATE OR REPLACE VIEW will be applied soon, which solves part two of the problem. ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [GENERAL] [HACKERS] Linux Largefile Support In Postgresql RPMS
On Tue, 2002-08-13 at 17:11, Rod Taylor wrote: I wouldn't totally discount using NFS for large databases. Believe it or not, with an Oracle database and a Network Appliance for storage, NFS is exactly what is used. We've found that we get better performance with a (properly tuned) NFS mounted NetApp volume than with attached storage on our HPUX box with several 100+GB databases. We've also tended to keep logs local on raid 1 and the data on a pair of custered netapps for PostgreSQL. But large file support is not really an issue for the database itself, since table files are split at 1Gb. Unless that changes, the database is not a problem. -- Oliver Elphick[EMAIL PROTECTED] Isle of Wight, UK http://www.lfix.co.uk/oliver GPG: 1024D/3E1D0C1C: CA12 09E0 E8D5 8870 5839 932A 614D 4C34 3E1D 0C1C Watch ye therefore, and pray always, that ye may be accounted worthy to escape all these things that shall come to pass, and to stand before the Son of man. Luke 21:36 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [GENERAL] [HACKERS] Linux Largefile Support In Postgresql RPMS
Oliver Elphick [EMAIL PROTECTED] writes: But large file support is not really an issue for the database itself, since table files are split at 1Gb. Unless that changes, the database is not a problem. I see no really good reason to change the file-split logic. The places where the backend might possibly need large-file support are * backend-side COPY to or from a large file * postmaster log to stderr --- does this fail if log output exceeds 2G? There might be some other similar issues, but that's all that comes to mind offhand. On a system where building with large-file support is reasonably standard, I agree that PG should be built that way too. Where it's not so standard, I agree with Andrew Sullivan's concerns ... regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [GENERAL] [HACKERS] Linux Largefile Support In Postgresql RPMS
On Tue, Aug 13, 2002 at 01:04:02PM -0400, Tom Lane wrote: I see no really good reason to change the file-split logic. The places where the backend might possibly need large-file support are * backend-side COPY to or from a large file I _think_ this causes a crash. At least, I _think_ that's what caused it one day (I was doing one of those jackhammer-the-server sorts of tests, and it was one of about 50 things I was doing at the time, to see if I could make it fall over. I did, but not where I expected, and way beyond any real load we could anticipate). * postmaster log to stderr --- does this fail if log output exceeds 2G? Yes, definitely, at least on Solaris. A -- Andrew Sullivan 87 Mowat Avenue Liberty RMS Toronto, Ontario Canada [EMAIL PROTECTED] M6K 3E3 +1 416 646 3304 x110 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] libpqxx
Marc G. Fournier writes: Okay, but if we are going to pull libpqxx, what about the other lib's too? Certain things apply to libpqxx that don't all apply to the others libs: It is maintained and developed independently anyway. It's new and not integrated yet. It's a different programming language. It's a non-standard interface. It's big. If there is ever going to be any motion toward separating parts of the source tree, libpqxx has to be the start. -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
[HACKERS] Everything is now required by the database system
With the new dependency system we have the entire system catalog content pinned down and unchangeable. This is a tiny dent in the nice extensible nature of the system. Would it be feasible to identify the non-essential parts of the built-in objects (say, inet type, numeric type, associated functions, etc.) and declare those with regular SQL commands in initdb? In the end, the system catalog contents in include/catalog/ would only contain the bootstrap content. For example, the pg_proc content could be made more manageable that way. Not sure if this is worth considering for this release, but it might be a medium-term project. Comments? -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] [COMMITTERS] pgsql-server/src
On Tue, 13 Aug 2002, Bruce Momjian wrote: Marc G. Fournier wrote: I think Tom is on to something here. I meant to ask but never got around to it. Why would anyone need to move the XLOG after you've inited the db? I just determined that disk I/O is terrible, so want to move the XLOG over to a different file system that is currently totally idle ... Yep, and you are going to do it using symlinks. Let us know how it goes? This was purely an fictional example ... ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Everything is now required by the database system
Peter Eisentraut wrote: With the new dependency system we have the entire system catalog content pinned down and unchangeable. This is a tiny dent in the nice extensible nature of the system. Would it be feasible to identify the non-essential parts of the built-in objects (say, inet type, numeric type, associated functions, etc.) and declare those with regular SQL commands in initdb? In the end, the system catalog contents in include/catalog/ would only contain the bootstrap content. For example, the pg_proc content could be made more manageable that way. Not sure if this is worth considering for this release, but it might be a medium-term project. Uh, some tools rely on those oids being fixed values, don't they? For example, I see ecpg using NUMERICOID. -- 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 4: Don't 'kill -9' the postmaster
Re: [HACKERS] libpqxx
Peter Eisentraut [EMAIL PROTECTED] writes: Marc G. Fournier writes: Okay, but if we are going to pull libpqxx, what about the other lib's too? Certain things apply to libpqxx that don't all apply to the others libs: It is maintained and developed independently anyway. It's new and not integrated yet. It's a different programming language. It's a non-standard interface. It's big. If there is ever going to be any motion toward separating parts of the source tree, libpqxx has to be the start. I agree with Peter's points here --- but separating libpqxx alone isn't the right answer. We need to pull both libpqxx and libpq++ at the same time, else we'll be creating the wrong impression about what we think of libpqxx. Another thing that would be reasonable to separate out in the near term is interfaces/perl5, which is not favored over the DBI driver. JDBC and ODBC are almost separate projects already, and perhaps should be cut loose so they can have their own release cycles. I'd defer to the maintainers of those interfaces about what they want to do, though. I'm not particularly concerned about removing the other interfaces such as libpgtcl and python. They're not large and they're (AFAIK) the only alternatives for their languages. regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Everything is now required by the database system
Peter Eisentraut [EMAIL PROTECTED] writes: With the new dependency system we have the entire system catalog content pinned down and unchangeable. This is a tiny dent in the nice extensible nature of the system. It's still extensible, it's just not so easily contractible... I'm not sure that this matters, as I've never heard of anyone actually troubling to remove unused datatypes etc. Would it be feasible to identify the non-essential parts of the built-in objects (say, inet type, numeric type, associated functions, etc.) and declare those with regular SQL commands in initdb? In the end, the system catalog contents in include/catalog/ would only contain the bootstrap content. For example, the pg_proc content could be made more manageable that way. No, it would become a lot less manageable because we'd have a harder time controlling OIDs for builtin types and functions. We'd end up having to push everything we deemed inessential out to non-builtin status (compare the contrib items that create new types). While there's some stuff like money and the geometric types that maybe deserve such demotion, there's not enough to get me excited about trimming it. While reviewing the pg_depend patch I was hoping that we could pin just a subset of the initial catalog contents, but eventually decided it was (a) tricky and (b) not worth the trouble. regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [GENERAL] [HACKERS] Linux Largefile Support In Postgresql RPMS
On Tue, Aug 13, 2002 at 01:04:02PM -0400, Tom Lane wrote: On a system where building with large-file support is reasonably standard, I agree that PG should be built that way too. Where it's not so standard, I agree with Andrew Sullivan's concerns ... What do you mean by standard? That only some filesystems are supported? In Linux the vfat filesystem doesn't support largefiles, so the behaviour is the same as if the application didn't specify O_LARGEFILE to open(2): As Helge Bahmann pointed out, kernel will refuse to write files larger than 2GB. In current Linux, a signal (SIGXFSZ) is sent to the application that then dumps core. So, the use of O_LARGEFILE is nullified by the lack of support by the filesystem, but no problem is introduced by the application supporting largefiles, it already existed before. All the crashes and problems presented on these lists occur when largefile support isn't compiled, I didn't see one occuring from any application having the support, but not the filesystem. (Your not so standard support?) The changes to postgresql doesn't seem complicated, I can try to make them myself (fcntl on stdout, stdin; add check to autoconf; etc.) if no one else volunteers. Regards, Luciano Rocha -- Consciousness: that annoying time between naps. ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [GENERAL] [HACKERS] Linux Largefile Support In Postgresql RPMS
On Tue, Aug 13, 2002 at 06:45:59PM +0100, [EMAIL PROTECTED] wrote: support isn't compiled, I didn't see one occuring from any application having the support, but not the filesystem. (Your not so standard Wrong. The symptom is _exactly the same_ if the program doesn't have the support, the filesystem doesn't have the support, or both, at least on Solaris. I've checked. A -- Andrew Sullivan 87 Mowat Avenue Liberty RMS Toronto, Ontario Canada [EMAIL PROTECTED] M6K 3E3 +1 416 646 3304 x110 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [GENERAL] [HACKERS] Linux Largefile Support In Postgresql RPMS
On Tue, 2002-08-13 at 12:45, [EMAIL PROTECTED] wrote: On Tue, Aug 13, 2002 at 01:04:02PM -0400, Tom Lane wrote: On a system where building with large-file support is reasonably standard, I agree that PG should be built that way too. Where it's not so standard, I agree with Andrew Sullivan's concerns ... What do you mean by standard? That only some filesystems are supported? In Linux the vfat filesystem doesn't support largefiles, so the behaviour is the same as if the application didn't specify O_LARGEFILE to open(2): As Helge Bahmann pointed out, kernel will refuse to write files larger than 2GB. In current Linux, a signal (SIGXFSZ) is sent to the application that then dumps core. So, the use of O_LARGEFILE is nullified by the lack of support by the filesystem, but no problem is introduced by the application supporting largefiles, it already existed before. Thank you. That's a point that I previously pointed out...you just did a much better job of it. Specifically, want to stress that enabling large file support is not dangerous. Greg signature.asc Description: This is a digitally signed message part
Re: [GENERAL] [HACKERS] Linux Largefile Support In Postgresql RPMS
On Tue, 2002-08-13 at 12:04, Tom Lane wrote: On a system where building with large-file support is reasonably standard, I agree that PG should be built that way too. Where it's not so standard, I agree with Andrew Sullivan's concerns ... Agreed. This is what I originally asked for. Greg signature.asc Description: This is a digitally signed message part
Re: [HACKERS] FUNC_MAX_ARGS benchmarks
I am working on a patch to increase these as agreed. I found this interesting, from the 6.3 release notes: Increase 16 char limit on system table/index names to 32 characters(Bruce) The limited to be 16 chars until 6.3 in 1998-03-01. --- Christopher Kings-Lynne wrote: NAMEDATALEN will be 64 or 128 in 7.3. At this point, we better decide which one we prefer. The conservative approach would be to go for 64 and perhaps increase it again in 7.4 after we get feedback and real-world usage. If we go to 128, we will have trouble decreasing it if there are performance problems. I guess I'd also agree with: FUNC_MAX_ARGS 32 NAMEDATALEN 64 and work on the performance issues for 7.4. I agree too. Chris ---(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 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Temporary Views
On Tue, 2002-08-13 at 20:43, Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: I can go either way on this. AFAICS create temp view would have some small advantage of keeping the view's name out of possibly-public permanent namespaces, so the step of just adding the TEMP option to CREATE VIEW may be worth doing. The advantage isn't very big but neither is the amount of work. Actually I think that having the views on any temp table also temp is mandatory, or else these views will be broken in all other backends than the one that created them (or expose other backends temp tables and are thereby a security risk). Trying to prohibit non-temp views on temp tables strikes me as more work than it's worth; What I would expect (if I had not read this thread and did not know anything about PG's view implementation) would be that if view on temp table was not defined temp itself, it would be automatically recompiled on first use after the temp table was created in current session. So forcing it to be explicitly declared TEMP would save me from that mistake. I'd expect automatic recompilation of view to be done sometime in future via saving view definition text, so that 'select * from t' would still return all columns after alter table t add column k that TODO item was written before we had dependencies, and I think it's obsolete. Basically the point of the TODO was to avoid having broken views --- and we have solved that problem. We may have broken views again when alter table drop column gets done . -- Hannu ---(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] db partial dumping with pg_dump
On Tue, 2002-08-13 at 20:24, Tom Lane wrote: What would seem to make sense is adding a WHERE-clause option to COPY TO, and then you could go COPY table TO 'myfile' WHERE ... What about : COPY table TO 'myfile' [ WHERE cond ] [ AS INSERT [ WITH COLUMN ] ]; to get the data as INSERT INTO statements (pg_dump -d), with optional column list (pg_dump -D) Hannu ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [GENERAL] [HACKERS] Linux Largefile Support In Postgresql RPMS
On Tue, Aug 13, 2002 at 02:09:07PM -0400, Andrew Sullivan wrote: On Tue, Aug 13, 2002 at 06:45:59PM +0100, [EMAIL PROTECTED] wrote: support isn't compiled, I didn't see one occuring from any application having the support, but not the filesystem. (Your not so standard Wrong. The symptom is _exactly the same_ if the program doesn't have the support, the filesystem doesn't have the support, or both, at least on Solaris. I've checked. ?? My point is that: Having postgresql the support doesn't bring NEW errors. I never said postgresql would automagically gain support on filesystems that don't support largfiles, I said no one mentioned an error caused by postgresql *having* the support, but *not the filesystem*. Maybe I wasn't clear, but I meant *new* errors. As it seams, adding support to largefiles doesn't break anything. Regards, Luciano Rocha -- Consciousness: that annoying time between naps. ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] db partial dumping with pg_dump
Actually, loading all this stuff into COPY is not the way to go, I think. Informix had: UNLOAD TO 'filename' SELECT ... I have to admit, this is a superior way to do thing compared to what we have. Is is possible for us to get: COPY TO 'filename' SELECT ... It allows any arbitrary table, group by, even order by combination. --- Hannu Krosing wrote: On Tue, 2002-08-13 at 20:24, Tom Lane wrote: What would seem to make sense is adding a WHERE-clause option to COPY TO, and then you could go COPY table TO 'myfile' WHERE ... What about : COPY table TO 'myfile' [ WHERE cond ] [ AS INSERT [ WITH COLUMN ] ]; to get the data as INSERT INTO statements (pg_dump -d), with optional column list (pg_dump -D) Hannu ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster -- 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] Temporary Views
that TODO item was written before we had dependencies, and I think it's obsolete. Basically the point of the TODO was to avoid having broken views --- and we have solved that problem. We may have broken views again when alter table drop column gets done Any view depending on a column which is dropped should also be removed via the dependency code. Views won't break but you can't drop a column that is used in a view without specifying cascade. This is a case where create or replace view is useful. Change the view definition to no longer be dependent on the object you wish to drop. ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Everything is now required by the database system
On Tue, 2002-08-13 at 22:38, Tom Lane wrote: Peter Eisentraut [EMAIL PROTECTED] writes: With the new dependency system we have the entire system catalog content pinned down and unchangeable. This is a tiny dent in the nice extensible nature of the system. It's still extensible, it's just not so easily contractible... I'm not sure that this matters, as I've never heard of anyone actually troubling to remove unused datatypes etc. It could become an issue if PostgreSQL became populat in embedded systems, but then it can of course be done in include/catalog/. Would it be feasible to identify the non-essential parts of the built-in objects (say, inet type, numeric type, associated functions, etc.) and declare those with regular SQL commands in initdb? In the end, the system catalog contents in include/catalog/ would only contain the bootstrap content. For example, the pg_proc content could be made more manageable that way. No, it would become a lot less manageable because we'd have a harder time controlling OIDs for builtin types and functions. We have COPY ... WITH OIDS for some time already. Maybe we should also allow setting OID in INSERT and UPDATE ? It could be a good idea to give out OID ranges for contrib modules so that frontends would not need to worry about changing binary formats for same types. That could also suggest that the new int8-based datetime type should have a separate OID from the old one. We'd end up having to push everything we deemed inessential out to non-builtin status (compare the contrib items that create new types). While there's some stuff like money and the geometric types It would be nice if for example GEOMETRY could be a separate installable package (a datablade in Illustra parlance). IP types (cidr, macadr) are also a good candidate for non-builtin type money type could be a package by its own ;) that maybe deserve such demotion, there's not enough to get me excited about trimming it. While reviewing the pg_depend patch I was hoping that we could pin just a subset of the initial catalog contents, but eventually decided it was (a) tricky True (b) not worth the trouble. But it could still be something to watch out for doing in the future. Of course we will have then package dependency issues, but most likely at least the GEOMETRY,IP and MONEY packages don't need each other. There are also two kinds of builtins - things that are almost exclusively used by system (smgr, oidvector, int2vector, tid, xid, cid, regproc, refcursor, aclitem, name) and basic types of general utility (int, date, text, ...) Probably every type not used in system tables themselves could be made loadable after initdb. - Hannu ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] OOP real life example (was Re: Why is MySQL more
On Tue, 2002-08-13 at 18:48, Don Baccus wrote: Greg Copeland wrote: On Tue, 2002-08-13 at 00:16, Curt Sampson wrote: ... And yes I know he's not reading my mail and no, don't bother repeating this to him, he'll just continue to ignore the point. I suspect that he will still read your (partial) comments in replies to your mails and has to look the originals up in archives in case he gets interested in what the other guys respond to ;) - Hannu ---(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] Temporary Views
On Wed, 2002-08-14 at 00:10, Rod Taylor wrote: that TODO item was written before we had dependencies, and I think it's obsolete. Basically the point of the TODO was to avoid having broken views --- and we have solved that problem. We may have broken views again when alter table drop column gets done Any view depending on a column which is dropped should also be removed via the dependency code. Views won't break but you can't drop a column that is used in a view without specifying cascade. This is a case where create or replace view is useful. Change the view definition to no longer be dependent on the object you wish to drop. in case of a 'SELECT *' view it could just be an (automatic) recompile. the same in case column type gets changed. --- Hannu ---(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] Temporary Views
Hannu Krosing [EMAIL PROTECTED] writes: We may have broken views again when alter table drop column gets done It is done, and we do not have broken views. regression=# create table t (f1 int, f2 int, f3 int); CREATE TABLE regression=# create view v as select f1,f2 from t; CREATE VIEW regression=# alter table t drop column f3; ALTER TABLE regression=# alter table t drop column f2; NOTICE: rule _RETURN on view v depends on table t column f2 NOTICE: view v depends on rule _RETURN on view v ERROR: Cannot drop table t column f2 because other objects depend on it Use DROP ... CASCADE to drop the dependent objects too regression=# regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] db partial dumping with pg_dump
On Wed, 2002-08-14 at 00:03, Bruce Momjian wrote: Actually, loading all this stuff into COPY is not the way to go, I think. Informix had: UNLOAD TO 'filename' SELECT ... I have to admit, this is a superior way to do thing compared to what we have. Is is possible for us to get: COPY TO 'filename' SELECT ... It allows any arbitrary table, group by, even order by combination. It would be more in line with the rest of the system to just allow subselect as 'table' COPY (select in,name from mystuff wher id 10) over10stuff TO stdout; - Hannu ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] db partial dumping with pg_dump
Hannu Krosing wrote: On Wed, 2002-08-14 at 00:03, Bruce Momjian wrote: Actually, loading all this stuff into COPY is not the way to go, I think. Informix had: UNLOAD TO 'filename' SELECT ... I have to admit, this is a superior way to do thing compared to what we have. Is is possible for us to get: COPY TO 'filename' SELECT ... It allows any arbitrary table, group by, even order by combination. It would be more in line with the rest of the system to just allow subselect as 'table' COPY (select in,name from mystuff wher id 10) over10stuff TO stdout; Yep, that would work too. Clearly, we should shoot for something that leverages the existing SELECT code rather than hang more clauses off of COPY. -- 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 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Everything is now required by the database system
Hannu Krosing [EMAIL PROTECTED] writes: On Tue, 2002-08-13 at 22:38, Tom Lane wrote: It's still extensible, it's just not so easily contractible... I'm not sure that this matters, as I've never heard of anyone actually troubling to remove unused datatypes etc. It could become an issue if PostgreSQL became populat in embedded systems, but then it can of course be done in include/catalog/. For an embedded system I'd think you'd want to strip out the support code for the unwanted types (ie, the utils/adt/ file(s)), not only the catalog entries. So it's source code changes in any case. The catalog entries alone occupy so little space that it's not even worth anyone's trouble to remove them, AFAICS. Probably every type not used in system tables themselves could be made loadable after initdb. It certainly *could* be done. Whether it's worth the trouble is highly doubtful. I'd also be concerned about the performance hit (loadable functions are noticeably slower than built-ins). Again, when was the last time you heard of anyone actually bothering to remove built-in entries from pg_proc or pg_type? I can't see expending a considerable amount of work on a feature that no one will use. regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] db partial dumping with pg_dump
Bruce Momjian [EMAIL PROTECTED] writes: Clearly, we should shoot for something that leverages the existing SELECT code rather than hang more clauses off of COPY. Yeah, that's a good point. COPY IN is still a special case, I think, but seems like COPY OUT could be reimplemented as a special tuple destination for the regular executor machinery. Q: how much performance hit would we be taking? If this slows down pg_dump a lot, the extra code is worth keeping. regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] regression test failure
Tatsuo Ishii writes: The $libdir variable is defined at the compile time and it points to $prefix/lib. Apparently it points to different place while doing regression tests. One idea is replacing $lindir with the absolute path to $prefix/lib. However I wonder this would break some installations, for example RPM. You can replace the string '$libdir' in the conversions_create.sql file with an absolute directory name during the standalone regression test run. This could be done in the regression test driver, where the correct path is available as $pkglibdir. Other, less messy solutions don't occur to me offhand. -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Is contrib/rserv/Makefile broken?
Satoshi Nagayasu writes: I think $libdir should be replaced in Makefile as below. No, it's correct as is. Read the documentation. -- 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: [PATCHES] [HACKERS] SQL99 CONVERT() function
The attached patch adds CONVERSION stuff for cyrillic and win874/1250/1251/1256 encodings. Thanks. I'll take care of this. Done. Documents and regression tests have been updated also. I think now we have implemented all encoding conversions for 7.3 release. -- Tatsuo Ishii ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] [COMMITTERS] pgsql-server/src
Tom Lane writes: That does not change my opinion about the -X/PGXLOG switch though --- having a backup safety check is not an excuse for having a fundamentally insecure set of startup options. OK, so: 1. Leave -X option in initdb. Remove all other -X options. 2. Remove all uses of PGXLOG. 3. Symlink from PGDATA to desired location. 4. Implement pg_mvxlog to move xlog if server is shut down. (So no one needs to know about 3.) In the future: Combine pg_mvxlog, pg_controldata, pg_resetxlog into pg_srvadm. Sounds good. -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [GENERAL] [HACKERS] Linux Largefile Support In Postgresql RPMS
Tom Lane writes: The prototype for fseek() is long int; I had assumed that off_t was not defined if _LARGEFILE_SOURCE was not defined. All that _LARGEFILE_SOURCE does is make fseeko() and ftello() visible on some systems, but on some systems they should be available by default. Oh, you're right. A quick look at HPUX shows it's the same way: ftell returns long int, ftello returns off_t (which presumably is an alias for long long int). Okay, OFF_T seems a reasonable answer. fseek() and ftell() using long int for the offset was a mistake, therefore fseeko() and ftello() were invented. (This is independent of whether the large file interface is used.) To activate the large file interface you define _FILE_OFFSET_BITS=64, which transparently replaces off_t and everything that uses it with a 64 bit version. There is no need to use any of the proposed macro tricks (because that exact macro trick is already provided by the OS). -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [GENERAL] [HACKERS] Linux Largefile Support In Postgresql RPMS
Tom Lane writes: * postmaster log to stderr --- does this fail if log output exceeds 2G? That would be an issue of the shell, not the postmaster. -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] [COMMITTERS] pgsql-server/src
Sounds good to me, but I have proven very unreliable in guessing others opinions on this issue. --- Peter Eisentraut wrote: Tom Lane writes: That does not change my opinion about the -X/PGXLOG switch though --- having a backup safety check is not an excuse for having a fundamentally insecure set of startup options. OK, so: 1. Leave -X option in initdb. Remove all other -X options. 2. Remove all uses of PGXLOG. 3. Symlink from PGDATA to desired location. 4. Implement pg_mvxlog to move xlog if server is shut down. (So no one needs to know about 3.) In the future: Combine pg_mvxlog, pg_controldata, pg_resetxlog into pg_srvadm. Sounds good. -- Peter Eisentraut [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 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
