[HACKERS] Jaguar is up
Hmm, isn't 4h22m a LONG time for it even with clobbered cache? All my tests so far have last less than 2h.. Regards -- Olivier PRENANT Tel: +33-5-61-50-97-00 (Work) 15, Chemin des Monges+33-5-61-50-97-01 (Fax) 31190 AUTERIVE +33-6-07-63-80-64 (GSM) FRANCE Email: [EMAIL PROTECTED] -- Make your life a dream, make your dream a reality. (St Exupery) -- Forwarded message -- Date: Thu, 29 Nov 2007 05:00:02 +0100 (CET) From: Cron Daemon [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Cron [EMAIL PROTECTED] cd /home/ohp/build-farm ./run_build.pl --verbose [05:00:02] checking out source ... [05:01:00] checking if build run needed ... [05:01:04] copying source to pgsql.10004 ... [05:01:29] running configure ... [05:01:59] running make ... [05:05:28] running make check ... [06:28:20] running make contrib ... [06:28:44] running make install ... [06:28:49] setting up db cluster ... [06:35:17] starting db ... [06:35:18] running make installcheck ... [08:25:54] restarting db ... [08:25:56] running make PL installcheck ... [08:29:48] restarting db ... [08:29:50] running make contrib install ... [08:29:53] running make contrib installcheck ... [09:08:26] stopping db ... [09:08:27] running make ecpg check ... [09:22:01] OK ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [pgsql-www] [HACKERS] Time to update list of contributors
On Wed, Nov 28, 2007 at 04:21:56PM -0700, Kris Jurka wrote: Magnus Hagander wrote: Where in the US? We generally list at least the state for ppl int he US - most often both city+state. (shows up only for people listed as major developers for the time being, which is why nobody asked for it before) Denver, CO Ok, I've updated the current database. (It doesn't show where you're listed, but it'll automatically get there if that's changed) //Magnus ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] 8.3devel slower than 8.2 under read-only load
For archives, Tom commited the patch yesterday: http://archives.postgresql.org/pgsql-committers/2007-11/msg00552.php -- Guillaume ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [HACKERS] quote_literal(integer) does not exist
Tom Lane wrote: I don't offhand see anything else I'd consider weakening the casting rules for. If anyone else is interested, I took ... substring(text,integer) | substring(text,integer,integer) | substring(text,text) | substring(text,text,text) | texticlike(text,text) | ~~* texticnlike(text,text)| !~~* texticregexeq(text,text) | ~* texticregexne(text,text) | !~* textlike(text,text) | ~~ textnlike(text,text) | !~~ textregexeq(text,text)| ~ textregexne(text,text)| !~ upper(text) | Thoughts? In one of our applications, we have some numbers (e.g. product numbers) that have meaning attached to individual digits. Product numbers usually contain letters, too, but for historical reasons they do not in this application. So we put them into integer columns for efficiency. We still want to run queries like product_no LIKE '51%' on them. Well, for the application, I don't see much of a problem here. This will probably cost 3-5 lines of code in the whole application. It will just cause some inconvenience when working with psql interactively. And I have not yet seen another DBMS that does not accept almost any input type for the typical string operations such as substring or LIKE. It feels a little bit strange that I will have to do all that typecasting now. Just my $0.02. Best Regards Michael Paesold ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] quotas once again
After reading the thread of 2004 regarding user quotas, I understand why the discussion moved towards having a tablespace quota as a solution. My reason to start this discussion was due the need of controlling database size. Having tablespace quotas could allow one to create a database in a given tablespace and then limit the size of the tablespace. Gevik Babakhani PostgreSQL NL http://www.postgresql.nl TrueSoftware BV http://www.truesoftware.nl -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jonah H. Harris Sent: Thursday, November 29, 2007 3:55 AM To: Alvaro Herrera Cc: Gevik Babakhani; pgsql-hackers@postgresql.org Subject: Re: [HACKERS] quotas once again On Nov 28, 2007 8:09 PM, Alvaro Herrera [EMAIL PROTECTED] wrote: Did you publish it in pgsql-patches? If so, it can be fished from there. Unfortunately, no. IIRC, I believe the topic moved to being non-user-based quotas and more tablespace-oriented. -- Jonah H. Harris, Sr. Software Architect | phone: 732.331.1324 EnterpriseDB Corporation| fax: 732.331.1301 499 Thornall Street, 2nd Floor | [EMAIL PROTECTED] Edison, NJ 08837| http://www.enterprisedb.com/ ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [HACKERS] pgwin32_open returning EINVAL
On Wed, Nov 28, 2007 at 05:20:46PM +0100, Magnus Hagander wrote:
On Wed, Nov 28, 2007 at 12:24:26PM -0300, Alvaro Herrera wrote:
Martijn van Oosterhout wrote:
On Wed, Nov 28, 2007 at 11:57:35AM -0300, Alvaro Herrera wrote:
Can we do something like this to report the Win32 error code so that the
user has a higher chance of figuring out what's going on?
We already do something very similar to what you're donig in
backend/port/wni32/socket.c :: TranslateSocketError().
So I think it's a good idea to do it, yes.
Thinking about this some more, I think this is a better patch - we already
have a function that takes care of this, including both error and debug
logging. Anybody disagree? If not, I'll go ahead and apply it...
//Magnus
Index: src/port/open.c
===
RCS file: /projects/cvsroot/pgsql/src/port/open.c,v
retrieving revision 1.21
diff -c -r1.21 open.c
*** src/port/open.c 15 Nov 2007 21:14:46 - 1.21
--- src/port/open.c 29 Nov 2007 11:44:46 -
***
*** 88,109
((fileFlags O_DSYNC) ?
FILE_FLAG_WRITE_THROUGH : 0),
NULL)) == INVALID_HANDLE_VALUE)
{
! switch (GetLastError())
! {
! /* EMFILE, ENFILE should not occur from
CreateFile. */
! case ERROR_PATH_NOT_FOUND:
! case ERROR_FILE_NOT_FOUND:
! errno = ENOENT;
! break;
! case ERROR_FILE_EXISTS:
! errno = EEXIST;
! break;
! case ERROR_ACCESS_DENIED:
! errno = EACCES;
! break;
! default:
! errno = EINVAL;
! }
return -1;
}
--- 88,94
((fileFlags O_DSYNC) ?
FILE_FLAG_WRITE_THROUGH : 0),
NULL)) == INVALID_HANDLE_VALUE)
{
! _dosmaperr(GetLastError());
return -1;
}
---(end of broadcast)---
TIP 1: 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] PG 7.3 is five years old today
+1 On Nov 29, 2007 4:09 AM, Andreas 'ads' Scherbaum [EMAIL PROTECTED] wrote: On Tue, 27 Nov 2007 15:37:04 -0500 Tom Lane wrote: Andreas 'ads' Scherbaum [EMAIL PROTECTED] writes: On Tue, 27 Nov 2007 11:08:58 -0800 Joshua D. Drake wrote: Release 7.3.21 with and EOL addendum :). E.g; this is the last release of 7.3 and 7.3 is now considered unsupported. I know at least one customer who is using RHEL-3 and PG 7.3 on dozens machines worldwide. Are they running 7.3.20? Will they update to 7.3.21 promptly when we ship it? Or are they using whatever Red Hat includes in RHEL-3? (which is still 7.3.19 I believe) I'm not sure, which micro version they are using right now. I only know, they have 7.3.x, cause i already had to take care of this on some projects. One of the reasons for losing interest in frequent updates is that it seems most of the people we hear from who are running 7.3.x are running a pretty obsolete x. If we produce an update and no one actually installs it, we're just wasting time with make-work. I said: we should not disband support of 7.3 today, release a final version next week and that's it. Something like 3, 4 month of pre-announce seems to be ok for me and i don't think, this makes much difference. Kind regards -- Andreas 'ads' Scherbaum Failure is not an option. It comes bundled with your Microsoft product. (Ferenc Mantfeld) ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] pgwin32_open returning EINVAL
On Thu, Nov 29, 2007 at 09:09:47AM -0300, Alvaro Herrera wrote: Magnus Hagander wrote: On Wed, Nov 28, 2007 at 05:20:46PM +0100, Magnus Hagander wrote: On Wed, Nov 28, 2007 at 12:24:26PM -0300, Alvaro Herrera wrote: Martijn van Oosterhout wrote: On Wed, Nov 28, 2007 at 11:57:35AM -0300, Alvaro Herrera wrote: Can we do something like this to report the Win32 error code so that the user has a higher chance of figuring out what's going on? We already do something very similar to what you're donig in backend/port/wni32/socket.c :: TranslateSocketError(). So I think it's a good idea to do it, yes. Thinking about this some more, I think this is a better patch - we already have a function that takes care of this, including both error and debug logging. Anybody disagree? If not, I'll go ahead and apply it... Hmm, but this still mixes some error codes. To absolutely get the Windows error code you would have to be running with DEBUG5, which I don't think is acceptable for a production system during any interesting length of time ... Can we have that DEBUG5 message changed to LOG instead? Maybe. I'm concerned we might end up logging a whole lot more, for cases where it's not an actual error. For example, a file that doesn't exist doesn't necessarily mean it's an error... I don't want to have to go through all code-paths that end up calling that function to see if that may be so... We can safely drop it to some lower level DEBUG though, maybe DEBUG1? But it is true that we have mixed error codes. But we only do that when we know they're actually there. If we have an unknown code, we don't just return it as EINVAL without logging (as open did before) - and that log goes out as LOG. (the open code already mixed two win32 codes into ENOENT already, btw) Or maybe have _dosmaperr receive the elevel with which to report the message as a parameter, and have current callers use DEBUG5, and pgwin32_open use LOG. That way we can backpatch it to 8.2 without changing current behavior. I don't think we can, or at least should, touch the signature for _dosmaperr(). It's a system replacment, I think we should keep the same signature for it. //Magnus ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] [GENERAL] plperl and regexps with accented characters - incompatible?
On Thu, Nov 29, 2007 at 12:39:30AM -0500, Andrew Dunstan wrote:
The attached patch works for me to eliminate the errors. Please test ASAP.
tested, works for me:
#v+
# CREATE OR REPLACE FUNCTION test(TEXT) RETURNS bool language plperl as $$
return (shift =~ /[a-ząćęłńóśźżĄĆĘŁŃŚÓŹŻ0-9_-]+/i) || 0;
$$;
CREATE FUNCTION
# select test('depesz');
test
--
t
(1 row)
# select test('depesząćęł');
test
--
t
(1 row)
# select test('depesząćęł$');
test
--
t
(1 row)
# select test('dePEsząĆęł$');
test
--
t
(1 row)
#v-
depesz
--
quicksil1er: postgres is excellent, but like any DB it requires a
highly paid DBA. here's my CV! :)
http://www.depesz.com/ - blog dla ciebie (i moje CV)
---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
Re: [HACKERS] pgwin32_open returning EINVAL
Magnus Hagander wrote: On Wed, Nov 28, 2007 at 05:20:46PM +0100, Magnus Hagander wrote: On Wed, Nov 28, 2007 at 12:24:26PM -0300, Alvaro Herrera wrote: Martijn van Oosterhout wrote: On Wed, Nov 28, 2007 at 11:57:35AM -0300, Alvaro Herrera wrote: Can we do something like this to report the Win32 error code so that the user has a higher chance of figuring out what's going on? We already do something very similar to what you're donig in backend/port/wni32/socket.c :: TranslateSocketError(). So I think it's a good idea to do it, yes. Thinking about this some more, I think this is a better patch - we already have a function that takes care of this, including both error and debug logging. Anybody disagree? If not, I'll go ahead and apply it... Hmm, but this still mixes some error codes. To absolutely get the Windows error code you would have to be running with DEBUG5, which I don't think is acceptable for a production system during any interesting length of time ... Can we have that DEBUG5 message changed to LOG instead? Or maybe have _dosmaperr receive the elevel with which to report the message as a parameter, and have current callers use DEBUG5, and pgwin32_open use LOG. That way we can backpatch it to 8.2 without changing current behavior. -- Alvaro Herrera Valdivia, Chile ICBM: S 39º 49' 18.1, W 73º 13' 56.4 Prefiero omelette con amigos que caviar con tontos (Alain Nonnet) ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [HACKERS] pgwin32_open returning EINVAL
On Thu, Nov 29, 2007 at 09:43:30AM -0300, Alvaro Herrera wrote: Magnus Hagander wrote: On Thu, Nov 29, 2007 at 09:09:47AM -0300, Alvaro Herrera wrote: Magnus Hagander wrote: On Wed, Nov 28, 2007 at 05:20:46PM +0100, Magnus Hagander wrote: On Wed, Nov 28, 2007 at 12:24:26PM -0300, Alvaro Herrera wrote: Martijn van Oosterhout wrote: On Wed, Nov 28, 2007 at 11:57:35AM -0300, Alvaro Herrera wrote: Can we do something like this to report the Win32 error code so that the user has a higher chance of figuring out what's going on? We already do something very similar to what you're donig in backend/port/wni32/socket.c :: TranslateSocketError(). So I think it's a good idea to do it, yes. Thinking about this some more, I think this is a better patch - we already have a function that takes care of this, including both error and debug logging. Anybody disagree? If not, I'll go ahead and apply it... Hmm, but this still mixes some error codes. To absolutely get the Windows error code you would have to be running with DEBUG5, which I don't think is acceptable for a production system during any interesting length of time ... Can we have that DEBUG5 message changed to LOG instead? Maybe. I'm concerned we might end up logging a whole lot more, for cases where it's not an actual error. For example, a file that doesn't exist doesn't necessarily mean it's an error... I don't want to have to go through all code-paths that end up calling that function to see if that may be so... I just checked. I see there are only five callers. In three cases (two in file/fd.c and one in port/dirent.c), there is at a single error code which is possibly expected. It is taken care of without calling _dosmaperr at all. In syslogger.c there are two possibly expected error codes, dealt with in the same way. And the last caller is port/getrusage.c, which has no possibly-expected error code. So I don't think this is a concern -- whenever _dosmaperr is called, a true error message is already going to be logged. What about all points that call readdir() which maps to that acll in port/dirent.c? If we can disregard that problem, then I think it's good to increase the level of logging for that one to either NOTICE or LOG. (The only case where a message would be logged inappropriately would be in file/fd.c if _dosmaperr returned EINTR, but AFAICS we don't map any code to that). No, we don't - the concept of EINTR doesn't really exist on win32, since there are no signals.. But it is true that we have mixed error codes. But we only do that when we know they're actually there. If we have an unknown code, we don't just return it as EINVAL without logging (as open did before) - and that log goes out as LOG. Yeah, I understand. But for example there are several different cases that are mapped to EACCES. In the cases we're currently following, having the exact error code could prove crucial to determining the cause of the error. Yeah, agreed. //Magnus ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] pgwin32_open returning EINVAL
Magnus Hagander wrote: On Thu, Nov 29, 2007 at 09:09:47AM -0300, Alvaro Herrera wrote: Magnus Hagander wrote: On Wed, Nov 28, 2007 at 05:20:46PM +0100, Magnus Hagander wrote: On Wed, Nov 28, 2007 at 12:24:26PM -0300, Alvaro Herrera wrote: Martijn van Oosterhout wrote: On Wed, Nov 28, 2007 at 11:57:35AM -0300, Alvaro Herrera wrote: Can we do something like this to report the Win32 error code so that the user has a higher chance of figuring out what's going on? We already do something very similar to what you're donig in backend/port/wni32/socket.c :: TranslateSocketError(). So I think it's a good idea to do it, yes. Thinking about this some more, I think this is a better patch - we already have a function that takes care of this, including both error and debug logging. Anybody disagree? If not, I'll go ahead and apply it... Hmm, but this still mixes some error codes. To absolutely get the Windows error code you would have to be running with DEBUG5, which I don't think is acceptable for a production system during any interesting length of time ... Can we have that DEBUG5 message changed to LOG instead? Maybe. I'm concerned we might end up logging a whole lot more, for cases where it's not an actual error. For example, a file that doesn't exist doesn't necessarily mean it's an error... I don't want to have to go through all code-paths that end up calling that function to see if that may be so... I just checked. I see there are only five callers. In three cases (two in file/fd.c and one in port/dirent.c), there is at a single error code which is possibly expected. It is taken care of without calling _dosmaperr at all. In syslogger.c there are two possibly expected error codes, dealt with in the same way. And the last caller is port/getrusage.c, which has no possibly-expected error code. So I don't think this is a concern -- whenever _dosmaperr is called, a true error message is already going to be logged. (The only case where a message would be logged inappropriately would be in file/fd.c if _dosmaperr returned EINTR, but AFAICS we don't map any code to that). But it is true that we have mixed error codes. But we only do that when we know they're actually there. If we have an unknown code, we don't just return it as EINVAL without logging (as open did before) - and that log goes out as LOG. Yeah, I understand. But for example there are several different cases that are mapped to EACCES. In the cases we're currently following, having the exact error code could prove crucial to determining the cause of the error. (the open code already mixed two win32 codes into ENOENT already, btw) Yeah, I saw that, but it's not really a problem because the errors are file does not exist and dir does not exist, and it can be very easily confirmed whether the file and dir actually exist or not. But if you have ERROR_LOCK_VIOLATION reported identically to ERROR_SHARING_VIOLATION, or whatever, there's no way you can tell which one actually occured. Or maybe have _dosmaperr receive the elevel with which to report the message as a parameter, and have current callers use DEBUG5, and pgwin32_open use LOG. That way we can backpatch it to 8.2 without changing current behavior. I don't think we can, or at least should, touch the signature for _dosmaperr(). It's a system replacment, I think we should keep the same signature for it. Good point. If this were truly a problem we could make another routine with the same code called differently, but I don't think it's really important. -- Alvaro Herrera http://www.amazon.com/gp/registry/CTMLCN8V17R4 I dream about dreams about dreams, sang the nightingale under the pale moon (Sandman) ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
[HACKERS] lo_export and lo_import: paths and servers
Hi, The PostgreSQL 8.3 documentation[1] says this about lo_export and lo_import paths and servers: Import: Note that the file is read by the client interface library, not by the server; so it must exist in the client file system and be readable by the client application. Export: Note that the file is written by the client interface library, not by the server. The way I read this is that both for lo_import and lo_export, the files should be placed (and be readable) on the local file system for the client. However, the behaviour I see when I run pg_regress and the large in client/server mode over two different hosts, is that pg_export works against the server file system (the file is written there), while pg_import work against the client file system (the file is not there when it tries to read it), leading to the result below. Problem between keyboard and chair, in doc, libpq, psql or elsewhere? -8--8--8--8--8 SELECT lo_export(loid, '/export/home/tmp/jagtmp/ja155679pgRegress/install/share/regress/results/lotest.txt') FROM lotest_stash_values; lo_export --- 1 (1 row) \lo_import '/export/home/tmp/jagtmp/ja155679pgRegress/install/share/regress/results/lotest.txt' could not open file /export/home/tmp/jagtmp/ja155679pgRegress/install/share/regress/results/lotest.txt: No such file or directory \set newloid :LASTOID -- just make sure \lo_export does not barf \lo_export :newloid '/export/home/tmp/jagtmp/ja155679pgRegress/install/share/regress/results/lotest2.txt' ERROR: large object 0 does not exist -8--8--8--8--8 [1] http://www.postgresql.org/docs/8.3/static/lo-interfaces.html -J -- Jørgen Austvik, Software Engineering - QA Sun Microsystems Database Technology Group begin:vcard fn;quoted-printable:J=C3=B8rgen Austvik n;quoted-printable:Austvik;J=C3=B8rgen org:Sun Microsystems;Database Technology Group adr:;;Haakon VIII gt. 7b;Trondheim;;NO-7485;Norway email;internet:[EMAIL PROTECTED] title:Senior Engineer tel;work:+47 73 84 21 10 tel;fax:+47 73 84 21 01 tel;cell:+47 901 97 886 x-mozilla-html:FALSE url:http://www.sun.com/ version:2.1 end:vcard ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] lo_export and lo_import: paths and servers
Jorgen Austvik - Sun Norway wrote: Problem between keyboard and chair, in doc, libpq, psql or elsewhere? Sorry, the psql documentation is clear on this: \lo_export Note that this is subtly different from the server function lo_export, which acts with the permissions of the user that the database server runs as and on the server's file system. \lo_import Note that this command is subtly different from the server-side lo_import because it acts as the local user on the local file system, rather than the server's user and file system. -J -- Jørgen Austvik, Software Engineering - QA Sun Microsystems Database Technology Group begin:vcard fn;quoted-printable:J=C3=B8rgen Austvik n;quoted-printable:Austvik;J=C3=B8rgen org:Sun Microsystems;Database Technology Group adr:;;Haakon VIII gt. 7b;Trondheim;;NO-7485;Norway email;internet:[EMAIL PROTECTED] title:Senior Engineer tel;work:+47 73 84 21 10 tel;fax:+47 73 84 21 01 tel;cell:+47 901 97 886 x-mozilla-html:FALSE url:http://www.sun.com/ version:2.1 end:vcard ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [HACKERS] Table inheritance, unique constraints and foreign key problem
Tom Lane [EMAIL PROTECTED] writes: Gregory Stark [EMAIL PROTECTED] writes: I'm a bit puzzled myself why this affects SELECT FOR UPDATE/SHARE but not straight UPDATES and DELETES. In straight UPDATE/DELETE we have enough structure in the query to know how to associate each tuple returned to the executor top level with exactly one tuple in exactly one target table (which is where to apply the tuple lock operation). We don't have that much structure in general SELECT --- for example, what to do with null-filled rows in a LEFT JOIN, or cases where one row gives rise to more than one joined row, or aggregation or UNION? Some of these cases can probably be rejected as unsupportable, but it'll still take a lot of work. This seems like the same kind of work that would be required to support queries like UPDATE (SELECT a, t1.b AS src, t2.b AS dest FROM t1 join t2 USING (a) ) SET dest = src; We currently support such plans using the FROM clause but handling arbitrary queries (where they make sense) would be far more flexible. It would also let us support updateable views in a much more flexible way than trying to reverse engineer the view to generate rules. Instead the rules would be straightforward substitutions just like the select rules: UPDATE view SET ... would just become: UPDATE (view-definition) SET ... And it would be up to the executor to determine whether which table the target columns came from and whether they're updateable or the query should throw an error. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's 24x7 Postgres support! ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [HACKERS] pgwin32_open returning EINVAL
Magnus Hagander wrote: On Thu, Nov 29, 2007 at 09:43:30AM -0300, Alvaro Herrera wrote: Magnus Hagander wrote: Maybe. I'm concerned we might end up logging a whole lot more, for cases where it's not an actual error. For example, a file that doesn't exist doesn't necessarily mean it's an error... I don't want to have to go through all code-paths that end up calling that function to see if that may be so... I just checked. I see there are only five callers. In three cases (two in file/fd.c and one in port/dirent.c), there is at a single error code which is possibly expected. It is taken care of without calling _dosmaperr at all. In syslogger.c there are two possibly expected error codes, dealt with in the same way. And the last caller is port/getrusage.c, which has no possibly-expected error code. So I don't think this is a concern -- whenever _dosmaperr is called, a true error message is already going to be logged. What about all points that call readdir() which maps to that acll in port/dirent.c? Sorry, I don't follow. I think the expected case is that FindNextFile fails with ERROR_NO_MORE_FILES when there are no more files, on which case we don't call _dosmaperr. ... Oh, I see what you mean: for the unexpected cases that readdir() does call _dosmaperr, readdir returns NULL but what does the caller do? The good news is that most callers of readdir are in frontend programs: pg_standby, initdb, pg_resetxlog. There are two callers in the backend: file/fd.c again, which already calls ereport(ERROR) if anything weird happen, and pgfnames() which also logs a WARNING. Callers in frontend programs are not a problem, because the current _dosmaperr already calls fprintf(stderr) with the code mapping message in all cases. Hmm, I just noticed a bug in those fprintf calls -- they are missing the terminating newline. Please change that too if you're going to patch this part of the code. In order to avoid translation problems, I think it should be like this: fprintf(stderr, _(mapped win32 error code %lu to %d \n), e, errno); Thanks! -- Alvaro Herrera http://www.amazon.com/gp/registry/CTMLCN8V17R4 One man's impedance mismatch is another man's layer of abstraction. (Lincoln Yeoh) ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [pgsql-www] [HACKERS] Time to update list of contributors
Apologies, if some of you receive duplicates of this email. I am not subscribed to -www, so sending this to - hackers again. Hi, On Wed, 2007-11-28 at 11:44 +0530, Pavan Deolasee wrote: Nikhil S Nikhil is from India, EnterpriseDB. What is his surname? I think we need that for adding to web page. Yes, agreed. We had someone else who wanted to be listed by alias some time back (year+, don't remember whom it was) and that was turned down. Agreed :), for the record, my name is Nikhil Sontakke. Regard, Nikhils -- EnterpriseDB http://www.enterprisedb.com
[HACKERS] convert int to bytea
Hi all, I'm trying to write a trigger that converts integer to bytea. My schema is like this: Create table xx ( id int, ... data bytea); the first 3 bytes of data are the binary representation of id (id is extracted from data by the application) I can occur that id change in that case data has to change too! select 124::bytea doesn't work Is there an other way? (preferabily simple :) Regards -- Olivier PRENANT Tel: +33-5-61-50-97-00 (Work) 15, Chemin des Monges+33-5-61-50-97-01 (Fax) 31190 AUTERIVE +33-6-07-63-80-64 (GSM) FRANCE Email: [EMAIL PROTECTED] -- Make your life a dream, make your dream a reality. (St Exupery) ---(end of broadcast)--- TIP 1: 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: [PATCHES] Re: [HACKERS] [GENERAL] plperl and regexps with accented characters - incompatible?
Tom Lane wrote: Andrew Dunstan [EMAIL PROTECTED] writes: +* Fill in just enough information to set up this perl +* function in the safe container and call it. +* For some reason not entirely clear, it prevents errors that +* can arise from the regex code later trying to load +* utf8 modules. How many versions of Perl have you tried this against? Only one :-( I don't have a farm of perl versions hanging round. That's one of the reasons I asked that people test it. The version I tested against is 5.8.8 - the latest stable release. The 5.8 series started in 2003 from what I can see - if anyone has a sufficiently old system that they can test on 5.6.2 that will be useful. I spent an hour wrestling unsuccessfully with it this morning but I don't have more time to spend on it. Systems older than 5.6 don't matter, as we don't do any UTF8 mangling on those. cheers andrew ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] convert int to bytea
Hi Gregory On Thu, 29 Nov 2007, Gregory Stark wrote: Date: Thu, 29 Nov 2007 14:34:57 + From: Gregory Stark [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: pgsql-hackers list pgsql-hackers@postgresql.org Subject: Re: convert int to bytea [EMAIL PROTECTED] writes: select 124::bytea doesn't work Is there an other way? (preferabily simple :) This kind of question would be more appropriate on pgsql-general. I know, I should subscribe :) What do you want the resulting bytea to look like? example : id = 9 , bytea = '\000\000\011' IIRC -- Olivier PRENANT Tel: +33-5-61-50-97-00 (Work) 15, Chemin des Monges+33-5-61-50-97-01 (Fax) 31190 AUTERIVE +33-6-07-63-80-64 (GSM) FRANCE Email: [EMAIL PROTECTED] -- Make your life a dream, make your dream a reality. (St Exupery) ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] convert int to bytea
[EMAIL PROTECTED] writes: select 124::bytea doesn't work Is there an other way? (preferabily simple :) This kind of question would be more appropriate on pgsql-general. What do you want the resulting bytea to look like? -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Get trained by Bruce Momjian - ask me about EnterpriseDB's PostgreSQL training! ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] pgwin32_open returning EINVAL
Alvaro Herrera [EMAIL PROTECTED] writes: Magnus Hagander wrote: Maybe. I'm concerned we might end up logging a whole lot more, for cases where it's not an actual error. I'm very concerned about that too, and think that DEBUG5 is just fine. Hmm, I just noticed a bug in those fprintf calls -- they are missing the terminating newline. Please change that too if you're going to patch this part of the code. In order to avoid translation problems, I think it should be like this: fprintf(stderr, _(mapped win32 error code %lu to %d \n), e, errno); That's both unreadable and useless, because gettext will smash it to one string anyway. regards, tom lane ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] Jaguar is up
[EMAIL PROTECTED] writes: Hmm, isn't 4h22m a LONG time for it even with clobbered cache? All my tests so far have last less than 2h.. I'm sure that yesterday' LookupOpclassInfo change would have made it even more mind-bogglingly slow than before... regards, tom lane ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] convert int to bytea
On 11/29/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: On Thu, 29 Nov 2007, Gregory Stark wrote: What do you want the resulting bytea to look like? example : id = 9 , bytea = '\000\000\011' IIRC What do you expect to happen when server and client are differently-endian? -Doug ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] convert int to bytea
Does it matter if you have written an explicit cast for int to bytea? On Nov 29, 2007 9:00 PM, Douglas McNaught [EMAIL PROTECTED] wrote: On 11/29/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: On Thu, 29 Nov 2007, Gregory Stark wrote: What do you want the resulting bytea to look like? example : id = 9 , bytea = '\000\000\011' IIRC What do you expect to happen when server and client are differently-endian? -Doug ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq -- Usama Munir Dar http://linkedin.com/in/usamadar Consultant Architect Cell:+92 321 5020666 Skype: usamadar
Re: [HACKERS] pgwin32_open returning EINVAL
Tom Lane wrote: Alvaro Herrera [EMAIL PROTECTED] writes: Magnus Hagander wrote: Maybe. I'm concerned we might end up logging a whole lot more, for cases where it's not an actual error. I'm very concerned about that too, and think that DEBUG5 is just fine. Well, the analysis was already done which says this shouldn't be a problem. Hmm, I just noticed a bug in those fprintf calls -- they are missing the terminating newline. Please change that too if you're going to patch this part of the code. In order to avoid translation problems, I think it should be like this: fprintf(stderr, _(mapped win32 error code %lu to %d \n), e, errno); That's both unreadable and useless, because gettext will smash it to one string anyway. Huh, right. I meant to have the second string outside the _() call, but I don't think that can be made to work easily. -- Alvaro Herrera http://www.amazon.com/gp/registry/5ZYLFMCVHXC Puedes elegir el color de tu auto -- siempre y cuando sea negro. (Henry Ford) ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
[HACKERS] Status report on 8.3 release
I wanted to give everyone an overview of where we are for 8.3. We have addressed almost every major issue for 8.3 but we are getting a steady stream of minor cleanups. These cleanups are vital to keep the quality of Postgres at a high level. It allows us to make major changes in every release but continue to produce a very reliable database system. 8.3 is going to be a watershed release, like 8.0, so it is not surprising we have cleaning up to do. Please keep up that activity. I expect these cleanups to continue for at least another week or two. Once they slow we will schedule RC1. Of course, we are getting near Christmas, so that might affect the final release schedule as well. Based on everything above, it is likely that 8.3 final will not be until the first week of January. I know everyone wanted this to be a short release schedule but the feature set just kept growing, so while we have the normal year-to-year release schedule, we do have a blockbuster release that we can all be proud of. -- Bruce Momjian [EMAIL PROTECTED]http://momjian.us EnterpriseDB http://postgres.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] pgwin32_open returning EINVAL
Alvaro Herrera [EMAIL PROTECTED] writes: Tom Lane wrote: I'm very concerned about that too, and think that DEBUG5 is just fine. Well, the analysis was already done which says this shouldn't be a problem. That analysis is full of holes --- FileRead and FileWrite for starters. regards, tom lane ---(end of broadcast)--- TIP 1: 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] convert int to bytea
Hi, please don't top post to someone who didn't used this convention in answering you. It's impolite. I edited the mail a bit to return sanity. On Nov 29, 2007 9:00 PM, Douglas McNaught [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: On 11/29/07, [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: On Thu, 29 Nov 2007, Gregory Stark wrote: What do you want the resulting bytea to look like? example : id = 9 , bytea = '\000\000\011' IIRC What do you expect to happen when server and client are differently-endian? -Doug Usama Dar írta: Does it matter if you have written an explicit cast for int to bytea? You don't know what't endianness is, do you? Say, you have a number: 0x12345678. This is stored differently depending on the endianness. Big-endian (like Sparc, Motorola, etc): 0x12 0x34 0x56 0x78 Little-endian (Intel-compatibles, etc): 0x78 0x56 0x34 0x12 So, how do you want your number to come out as a byte array? Since a bytea is a sequence of bytes as stored in memory, you may have different meaning for an int-bytea conversion. It's your homework to look up what's network order is. :-) But it would give you consistent answer no matter what CPU your server uses. -- -- Zoltán Böszörményi Cybertec Schönig Schönig GmbH http://www.postgresql.at/ ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] pgwin32_open returning EINVAL
Tom Lane wrote: Alvaro Herrera [EMAIL PROTECTED] writes: Tom Lane wrote: I'm very concerned about that too, and think that DEBUG5 is just fine. Well, the analysis was already done which says this shouldn't be a problem. That analysis is full of holes --- FileRead and FileWrite for starters. I already did. The case where they retry do not call _dosmaperr. -- Alvaro Herrera Developer, http://www.PostgreSQL.org/ No es bueno caminar con un hombre muerto ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [HACKERS] convert int to bytea
On Nov 29, 2007 9:35 PM, Zoltan Boszormenyi [EMAIL PROTECTED] wrote: Hi, please don't top post to someone who didn't used this convention in answering you. It's impolite. I edited the mail a bit to return sanity. On Nov 29, 2007 9:00 PM, Douglas McNaught [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: On 11/29/07, [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: On Thu, 29 Nov 2007, Gregory Stark wrote: What do you want the resulting bytea to look like? example : id = 9 , bytea = '\000\000\011' IIRC What do you expect to happen when server and client are differently-endian? -Doug Usama Dar írta: Does it matter if you have written an explicit cast for int to bytea? You don't know what't endianness is, do you? Say, you have a number: 0x12345678. This is stored differently depending on the endianness. Big-endian (like Sparc, Motorola, etc): 0x12 0x34 0x56 0x78 Little-endian (Intel-compatibles, etc): 0x78 0x56 0x34 0x12 So, how do you want your number to come out as a byte array? Since a bytea is a sequence of bytes as stored in memory, you may have different meaning for an int-bytea conversion. It's your homework to look up what's network order is. :-) But it would give you consistent answer no matter what CPU your server uses. 1) i wasn't aware people are sensitive to top email reply vs inline, apologies if it offended you 2) i know what a byte order is , i just thought your interface i.e. libpq would convert it to the local byte order. -- -- Zoltán Böszörményi Cybertec Schönig Schönig GmbH http://www.postgresql.at/ -- Usama Munir Dar http://linkedin.com/in/usamadar Consultant Architect Cell:+92 321 5020666 Skype: usamadar
Re: [HACKERS] convert int to bytea
Usama Dar wrote: 2) i know what a byte order is , i just thought your interface i.e. libpq would convert it to the local byte order. You haven't thought this through. Data traveling over libpq is still text, not binary, in most cases, so byte order is irrelevant at that time. The translation to a bytea (if possible) would be done after the data was already on the server and the int was in its native, architecture dependent form. The short answer is thus still that there is no sane consistent cast from int to bytea. If you want a bytea then it's really up to you to contruct the byte array. cheers andrew ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Re: pgsql: New versions of mingw have gettimeofday(), so add an autoconf
On Wed, Nov 21, 2007 at 03:33:53PM -0500, Tom Lane wrote: Magnus Hagander [EMAIL PROTECTED] writes: On Mon, 2007-11-19 at 02:50 -0700, Kris Jurka wrote: Can we backport this fix? I'm trying to setup a new windows build environment and this is currently halting my progress for back branches. Technically, it's fairly easy. And given that it's been working for a couple of betas of 8.3, it seems it should be safe. OTOH, the official build for 8.3 doesn't use it, so binary testers haven't seen it. But any issues should've been build issues rather than runtime ones, I think. So yeah, it would be reasonably easy to do, and probably a good idea. Anybody think we shouldn't? Given that we're abandoning support for 8.0 and 8.1 on Windows, I'd say +1 for fixing 8.2, but not for any older branches. Done. //Magnus ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [HACKERS] pgwin32_open returning EINVAL
Alvaro Herrera [EMAIL PROTECTED] writes: Tom Lane wrote: That analysis is full of holes --- FileRead and FileWrite for starters. I already did. The case where they retry do not call _dosmaperr. What's retry got to do with it? What's displeasing me is the idea of LOG messages showing up during perfectly normal operation. regards, tom lane ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] pgwin32_open returning EINVAL
Tom Lane wrote: Alvaro Herrera [EMAIL PROTECTED] writes: Tom Lane wrote: That analysis is full of holes --- FileRead and FileWrite for starters. I already did. The case where they retry do not call _dosmaperr. What's retry got to do with it? What's displeasing me is the idea of LOG messages showing up during perfectly normal operation. Oh, I see your point. It's that those routines will sometimes be called, they return an error, and this is *ignored* by the caller. In the case of FileRead, the only such caller is ExecHashJoinGetSavedTuple. In the case of FileWrite, the thing is quite a bit more difficult to follow, but it goes through BufFileWrite and BufFileFlush. So yeah, it seems there is valid code trying to call FileRead and FileWrite, have it error out, and silently ignore the error. I'm not going to argue this late in the cycle that all that code be changed, so I think a reasonable compromise is to turn the ereport() in _dosmaperr to DEBUG1 instead. That way it won't clutter any log by default, and in the cases where we're actually interested in tracking the problematic situation, we don't need to get huge amounts of log traffic coming from other parts of the system. All the cases where BufFileFlush is called and it ignores an error are bugs. I think it's quite safe to modify BufFileFlush to ereport(ERROR) if it cannot do what it was asked. And all the callers of BufFileWrite immediately ereport() if it cannot write the specified amount of bytes. So there is exactly one case where these routines would be unnecessarily noisy, and that is ExecHashJoinGetSavedTuple. -- Alvaro Herrera http://www.amazon.com/gp/registry/DXLWNGRJD34J No necesitamos banderas No reconocemos fronteras (Jorge González) ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] [GENERAL] Empty arrays with ARRAY[]
Hi folks, The patch is coming along nicely now. I do have a couple of questions about the implementation in transformArrayExpr though. 1) How should we determine whether the array is multidimensional if we know the type in advance? Currently, transformArrayExpr uses the results of its search for a common element type to figure out whether the array is multidimensional. If we know the type in advance, we don't need to do the common type search (a nice side-effect), so we need some other way of figuring out how to set ArrayExpr-multidims on the new node. I could just check the nodeTag of the elements as they are transformed, but I'm concerned that the existing code might be relying on select_common_type to catch stupid input, like a mixture of scalar and array elements. If that's the case it might be unwise to bypass select_common_type or, at least, I'd need to come up with something else to provide the same level of sanity assurance in both code paths. 2) Should the typecast propagate downwards into nested array elements? If we have a nested array written as, say, ARRAY[ARRAY[1, 2], ARRAY[3, 4], ARRAY[5, 6]]::float[], should we treat the inner arrays the same way as the outer array (with the advance knowledge that the array type should be float[])? If I'm reading the code correctly, the end result should be much the same, because the inner arrays will end up being coerced to float[] anyway. But shortcutting the coercion could save some cycles. Comments? Regards, BJ ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] [GENERAL] Empty arrays with ARRAY[]
On Fri, Nov 30, 2007 at 06:13:20AM +1100, Brendan Jurd wrote: Hi folks, The patch is coming along nicely now. I do have a couple of questions about the implementation in transformArrayExpr though. Awesome. 1) How should we determine whether the array is multidimensional if we know the type in advance? Well, given the array should be regular you should be able to just look at the first element, if it's a array look at it's first element, etc to determine the dimensions. This'll be fairly quick. 2) Should the typecast propagate downwards into nested array elements? IMHO yes, you have th einfo you may as well use it. If we have a nested array written as, say, ARRAY[ARRAY[1, 2], ARRAY[3, 4], ARRAY[5, 6]]::float[], should we treat the inner arrays the same way as the outer array (with the advance knowledge that the array type should be float[])? TBH, I think you're going to have to go through the whole array to coerce them and check, so you may as well determine the dimensions at the same time. In general I think it's better to mark the type up front. In don't know if you should actually do the conversion straight away, but at least you don't need to guess the type anymore. Hope this helps, Have a nice day, -- Martijn van Oosterhout [EMAIL PROTECTED] http://svana.org/kleptog/ Those who make peaceful revolution impossible will make violent revolution inevitable. -- John F Kennedy signature.asc Description: Digital signature
Re: [HACKERS] PG 7.3 is five years old today
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu, 29 Nov 2007 12:00:51 -0800 Andrew Hammond [EMAIL PROTECTED] wrote: software. I doubt there are any plans to trim the 7.3 branch from CVS and I imagine that the community will be happy to work with anyone Considering we still have Postgres95 in the tree I would bet you are right :) Joshua D. Drake - -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 24x7/Emergency: +1.800.492.2240 PostgreSQL solutions since 1997 http://www.commandprompt.com/ UNIQUE NOT NULL Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate PostgreSQL Replication: http://www.commandprompt.com/products/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHTxsCATb/zqfZUUQRAh+fAJ9l8Z/Al4IYfCTzhkjp5WcMiktSqACffjxy p5zktLRONzoGWiTxwJspiVA= =sxSk -END PGP SIGNATURE- ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] PG 7.3 is five years old today
On Nov 29, 2007 11:11 AM, Ron Mayer [EMAIL PROTECTED] wrote: Robert Treat wrote: On Tuesday 27 November 2007 15:07, Simon Riggs wrote: On Tue, 2007-11-27 at 14:02 -0500, Tom Lane wrote: There has been some discussion of making a project policy of dropping support for old releases after five years. Should we consider formally instituting that? ... Perhaps we should ask for volunteers to maintain that branch? ... +1 to see if anyone else wants to take over management of the branch. I also think we should be a bit more generous on the EOL notice. One thing that could soften the blow is if the EOL notice mentions which commercial organizations will provide paid support for longer than the community does. I assume that's one of the benefits of going with the commercial support organizations? I bet there's plenty. Perhaps calling it an EOL is a mistake since the concept does not perfectly map between OSS and commercial software. I doubt there are any plans to trim the 7.3 branch from CVS and I imagine that the community will be happy to work with anyone who wishes to back-port patches, up to and perhaps including rolling their patch into CVS. This is very different from a traditional EOL. Perhaps Switching over to passive / user driven support is a better way to phrase this? We can of course emphasize the availability of commercial organizations that are willing to take over active support for anyone willing to pay for it. Do we have any numbers on the downloads of 7.3.x for the last few values of x? That might be a good indicator of how many people are actually following the upgrade path. Andrew
[HACKERS] CommandCounterIncrement versus plan caching
I was able to reproduce the problem complained of here http://archives.postgresql.org/pgsql-bugs/2007-11/msg00322.php with this function: create or replace function foo() returns int as $$ declare r int; begin drop table if exists temptable cascade; create temp table temptable as select * from generate_series(1,4) f1; create temp view vv as select * from temptable; -- perform 2+2; for r in select * from vv loop raise notice '%', r; end loop; return 0; end$$ language plpgsql; regression=# select foo(); NOTICE: table temptable does not exist, skipping CONTEXT: SQL statement drop table if exists temptable cascade PL/pgSQL function foo line 3 at SQL statement NOTICE: 1 NOTICE: 2 NOTICE: 3 NOTICE: 4 foo - 0 (1 row) regression=# select foo(); NOTICE: drop cascades to rule _RETURN on view vv CONTEXT: SQL statement drop table if exists temptable cascade PL/pgSQL function foo line 3 at SQL statement NOTICE: drop cascades to view vv CONTEXT: SQL statement drop table if exists temptable cascade PL/pgSQL function foo line 3 at SQL statement ERROR: could not open relation 1663/121218/145930: No such file or directory CONTEXT: PL/pgSQL function foo line 7 at FOR over SELECT rows The problem goes away if there's any SQL action between the CREATE VIEW and the FOR command, eg if you uncomment the PERFORM shown above. What is happening is that the last step of CREATE VIEW, namely DefineViewRules(), isn't visible at the time we try to re-validate the cached plan for the FOR command, because no CommandCounterIncrement has happened between. So the plan gets regenerated as a simple seqscan of the view relation, which of course fails for lack of any underlying storage. This is not CREATE VIEW's fault, since no utility command expects that it should do a final CommandCounterIncrement (henceforth CCI) internally; CCI calls are supposed to be done between commands by system control logic when needed. Moreover inserting a CCI at the end of DefineView would only fix this particular manifestation, and not other cases of DDL immediately before re-use of a plan. One fairly simple answer is to insert a CCI call at the start of RevalidateCachedPlan. I dislike that solution, at least by itself, on two grounds: * A patch of that form would approximately double the number of CCI calls involved in executing a plpgsql function; which quite aside from any performance cost would halve the distance to the 2^32-commands-per-transaction horizon. We've already heard from people who ran into that limit, so I don't want to bring it closer. * This would result in executing CCI calls even during stable/immutable PL functions. I'm not sure that would have any bad semantic side-effects, but I'm not convinced it wouldn't, either. And it also gives back whatever command count limit savings we bought when we fixed things so that stable/immutable functions don't call CCI. I've also thought about rearranging the current conventions for where to call CCI. This particular form of the problem would go away if SPI command execution did CCI after, instead of before, each non-read-only command. Or perhaps safer, before each such command and after the last one. I'm a bit worried though about whether that leaves any code paths in which we're still missing a needed CCI. An idea we could use in combination with either of the above is to make command ID assignment lazy in a similar sense to what we did for XID assignment recently; that is, fix things so that CCI is a no-op if no database change actually happened since the last one. This would greatly reduce the command-limit disadvantages of having a scheme that executes unnecessary CCI's. Comments, better ideas? regards, tom lane ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] pgwin32_open returning EINVAL
Alvaro Herrera [EMAIL PROTECTED] writes: I think a reasonable compromise is to turn the ereport() in _dosmaperr to DEBUG1 instead. That way it won't clutter any log by default, and in the cases where we're actually interested in tracking the problematic situation, we don't need to get huge amounts of log traffic coming from other parts of the system. I'm still not convinced what you think the problematic situation is. It's already the case (and reasonable, I think) that _dosmaperr issues a LOG message if it sees a GetLastError code it doesn't recognize; that addresses the problem that this thread started with. Why do we need to make the success case chattier? regards, tom lane ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] pgwin32_open returning EINVAL
Magnus Hagander [EMAIL PROTECTED] writes: Tom Lane wrote: I'm still not convinced what you think the problematic situation is. I believe Alvaros point is that several different GetLastError codes map to the same errno code, making it impossible to see the difference between those errors. (1) If we need to know the difference, then we shouldn't be mapping them to the same thing. (2) Do we have any live cases where we must know this? Much less enough cases to justify a global increase in the log chattiness? It's not like we cannot get the information if we really need it. regards, tom lane ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] [GENERAL] Empty arrays with ARRAY[]
Martijn van Oosterhout [EMAIL PROTECTED] writes: 1) How should we determine whether the array is multidimensional if we know the type in advance? Well, given the array should be regular you should be able to just look at the first element, if it's a array look at it's first element, etc to determine the dimensions. This'll be fairly quick. How does that work with non-constant array constructor members? regards, tom lane ---(end of broadcast)--- TIP 1: 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] pgwin32_open returning EINVAL
Tom Lane wrote: Alvaro Herrera [EMAIL PROTECTED] writes: I think a reasonable compromise is to turn the ereport() in _dosmaperr to DEBUG1 instead. That way it won't clutter any log by default, and in the cases where we're actually interested in tracking the problematic situation, we don't need to get huge amounts of log traffic coming from other parts of the system. I'm still not convinced what you think the problematic situation is. It's already the case (and reasonable, I think) that _dosmaperr issues a LOG message if it sees a GetLastError code it doesn't recognize; that addresses the problem that this thread started with. Why do we need to make the success case chattier? I believe Alvaros point is that several different GetLastError codes map to the same errno code, making it impossible to see the difference between those errors. //Magnus ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] pgwin32_open returning EINVAL
Tom Lane wrote: Magnus Hagander [EMAIL PROTECTED] writes: Tom Lane wrote: I'm still not convinced what you think the problematic situation is. I believe Alvaros point is that several different GetLastError codes map to the same errno code, making it impossible to see the difference between those errors. (1) If we need to know the difference, then we shouldn't be mapping them to the same thing. I totally agree with that, but the problem is the API is not very flexible in this regard. We can only use error codes that strerror() is going to recognize. A radical idea would be to store the Windows error code from GetLastError in a new field in ErrorData, and display it in the next ereport(). Perhaps use a special error callback to add an errcontext in the possibly problematic cases. (2) Do we have any live cases where we must know this? Much less enough cases to justify a global increase in the log chattiness? It's not like we cannot get the information if we really need it. Yes. This thread shows the problem: http://archives.postgresql.org/pgsql-es-ayuda/2007-11/msg00354.php Basically he is getting this error: 2007-11-16 14:54:16 ERROR: could not open relation 1663/16403/16487: Invalid argument and no further indication of what's going on. I did some searching a couple of days ago and none of the cases I could find got a resolution. http://archives.free.net.ph/message/20060930.223306.6ac7d657.en.html http://www.mydatabasesupport.com/forums/postgresql/314656-general-postgre-crash-currval-problem-help.html -- Alvaro Herrerahttp://www.advogato.org/person/alvherre Doing what he did amounts to sticking his fingers under the hood of the implementation; if he gets his fingers burnt, it's his problem. (Tom Lane) ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [HACKERS] pgwin32_open returning EINVAL
Alvaro Herrera [EMAIL PROTECTED] writes: Tom Lane wrote: (2) Do we have any live cases where we must know this? Yes. This thread shows the problem: http://archives.postgresql.org/pgsql-es-ayuda/2007-11/msg00354.php Basically he is getting this error: 2007-11-16 14:54:16 ERROR: could not open relation 1663/16403/16487: Invalid argument Well, since EINVAL is the default result from _dosmaperr, and none of the cases it represents are expected, why don't we just remove all of the explicit mappings to EINVAL from doserrors[]? Then we will get the LOG message you need, and we won't have to increase the chattiness level for anything else. regards, tom lane ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Status report on 8.3 release
On Thu, 2007-11-29 at 11:26 -0500, Bruce Momjian wrote: I expect these cleanups to continue for at least another week or two. Once they slow we will schedule RC1. So are there no plans for an additional beta? Given the recent addition of changes like http://archives.postgresql.org/pgsql-committers/2007-11/msg00552.php http://archives.postgresql.org/pgsql-committers/2007-11/msg00532.php I wonder if another beta before RC1 would be warranted. -Neil ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [PATCHES] Re: [HACKERS] [GENERAL] plperl and regexps with accented characters - incompatible?
On Thu, 29 Nov 2007, Andrew Dunstan wrote: The version I tested against is 5.8.8 - the latest stable release. The 5.8 series started in 2003 from what I can see - if anyone has a sufficiently old system that they can test on 5.6.2 that will be useful. I've got a 5.6.1 perl here, but it wasn't built shared, so I can't test plperl. I ran the test case Greg posted to the perl bug tracker and it doesn't fail, so unless you're concerned that your change will break 5.6, then it doesn't look like 5.6 needs a fix. Kris Jurka ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] Status report on 8.3 release
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu, 29 Nov 2007 14:01:11 -0800 Neil Conway [EMAIL PROTECTED] wrote: On Thu, 2007-11-29 at 11:26 -0500, Bruce Momjian wrote: I expect these cleanups to continue for at least another week or two. Once they slow we will schedule RC1. So are there no plans for an additional beta? Given the recent addition of changes like http://archives.postgresql.org/pgsql-committers/2007-11/msg00552.php http://archives.postgresql.org/pgsql-committers/2007-11/msg00532.php I wonder if another beta before RC1 would be warranted. I think the email is not quite clear :). There is a Beta 4 coming, the problem is packagers aren't really available this week so if it comes it will be next week. At least that is last I heard. Joshua D. Drake -Neil ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster - -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 24x7/Emergency: +1.800.492.2240 PostgreSQL solutions since 1997 http://www.commandprompt.com/ UNIQUE NOT NULL Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate PostgreSQL Replication: http://www.commandprompt.com/products/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHTzhHATb/zqfZUUQRAiZlAJ0Tj/Kzn0cFnfm7pB9YFvKQm4txpQCfTCo6 s6FF7Ey5GMISxNmwxTlgi7g= =KypU -END PGP SIGNATURE- ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Status report on 8.3 release
Neil Conway [EMAIL PROTECTED] writes: So are there no plans for an additional beta? Yes, there are, but not till we do something about http://archives.postgresql.org/pgsql-hackers/2007-11/msg01302.php regards, tom lane ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] PG 7.3 is five years old today
Robert Treat wrote: On Tuesday 27 November 2007 15:07, Simon Riggs wrote: On Tue, 2007-11-27 at 14:02 -0500, Tom Lane wrote: There has been some discussion of making a project policy of dropping support for old releases after five years. Should we consider formally instituting that? ... Perhaps we should ask for volunteers to maintain that branch? ... +1 to see if anyone else wants to take over management of the branch. I also think we should be a bit more generous on the EOL notice. One thing that could soften the blow is if the EOL notice mentions which commercial organizations will provide paid support for longer than the community does. I assume that's one of the benefits of going with the commercial support organizations? ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] pgwin32_open returning EINVAL
Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
Tom Lane wrote:
(2) Do we have any live cases where we must know this?
Yes. This thread shows the problem:
http://archives.postgresql.org/pgsql-es-ayuda/2007-11/msg00354.php
Basically he is getting this error:
2007-11-16 14:54:16 ERROR: could not open relation 1663/16403/16487:
Invalid argument
Well, since EINVAL is the default result from _dosmaperr, and none of
the cases it represents are expected, why don't we just remove all of
the explicit mappings to EINVAL from doserrors[]? Then we will get the
LOG message you need, and we won't have to increase the chattiness level
for anything else.
Well, the problematic routine is not already using _dosmaperr currently.
It is doing it's own mapping and neglecting to report anything. In
fact, after all the problems that appeared after Magnus proposed to use
_dosmaperr, I'm inclined to go with my original suggestion: don't use
_dosmaperr at all and instead add an ereport(LOG) with the Windows error
code.
The routine I'm talking about (pgwin32_open) has this:
switch (err)
{
/* EMFILE, ENFILE should not occur from CreateFile. */
case ERROR_PATH_NOT_FOUND:
case ERROR_FILE_NOT_FOUND:
errno = ENOENT;
break;
case ERROR_FILE_EXISTS:
errno = EEXIST;
break;
case ERROR_ACCESS_DENIED:
errno = EACCES;
break;
default:
errno = EINVAL;
}
So _anything_ could be EINVAL. Including the several cases that
_dosmaperr treat as EACCES. So I'm afraid that for this experiment to
be successful, we would have to remove not only the EINVAL cases from
doserrors[], but also any other code that appears more than once on it.
Otherwise the output could be ambiguous.
--
Alvaro Herrera http://www.PlanetPostgreSQL.org/
El Maquinismo fue proscrito so pena de cosquilleo hasta la muerte
(Ijon Tichy en Viajes, Stanislaw Lem)
---(end of broadcast)---
TIP 1: 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] pgwin32_open returning EINVAL
Alvaro Herrera wrote:
Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
Tom Lane wrote:
(2) Do we have any live cases where we must know this?
Yes. This thread shows the problem:
http://archives.postgresql.org/pgsql-es-ayuda/2007-11/msg00354.php
Basically he is getting this error:
2007-11-16 14:54:16 ERROR: could not open relation 1663/16403/16487:
Invalid argument
Well, since EINVAL is the default result from _dosmaperr, and none of
the cases it represents are expected, why don't we just remove all of
the explicit mappings to EINVAL from doserrors[]? Then we will get the
LOG message you need, and we won't have to increase the chattiness level
for anything else.
Well, the problematic routine is not already using _dosmaperr currently.
It is doing it's own mapping and neglecting to report anything. In
fact, after all the problems that appeared after Magnus proposed to use
_dosmaperr, I'm inclined to go with my original suggestion: don't use
_dosmaperr at all and instead add an ereport(LOG) with the Windows error
code.
That'll just cause the same problem in a different location, no? We'd
still be logging too often?
If we want to avoid duplicate code, we could go around to your idea of
being able to specify the elog level, by creating a _dosmaperr_internal
that takes that as parameter, and then have _dosmaperr call it with
DEBUG5 as argument... But that's only if we think it's ok for
pgwin32_open() to log that much - I thought we didn't like that?
The routine I'm talking about (pgwin32_open) has this:
switch (err)
{
/* EMFILE, ENFILE should not occur from CreateFile. */
case ERROR_PATH_NOT_FOUND:
case ERROR_FILE_NOT_FOUND:
errno = ENOENT;
break;
case ERROR_FILE_EXISTS:
errno = EEXIST;
break;
case ERROR_ACCESS_DENIED:
errno = EACCES;
break;
default:
errno = EINVAL;
}
So _anything_ could be EINVAL. Including the several cases that
_dosmaperr treat as EACCES. So I'm afraid that for this experiment to
be successful, we would have to remove not only the EINVAL cases from
doserrors[], but also any other code that appears more than once on it.
Otherwise the output could be ambiguous.
Could be, but may not be :P
//Magnus
---(end of broadcast)---
TIP 7: You can help support the PostgreSQL project by donating at
http://www.postgresql.org/about/donate
Re: [HACKERS] pgwin32_open returning EINVAL
Alvaro Herrera [EMAIL PROTECTED] writes: Tom Lane wrote: Well, since EINVAL is the default result from _dosmaperr, and none of the cases it represents are expected, why don't we just remove all of the explicit mappings to EINVAL from doserrors[]? Well, the problematic routine is not already using _dosmaperr currently. It is doing it's own mapping and neglecting to report anything. Oh, well then why are we arguing? There is no reason at all to assume that _dosmaperr wouldn't give us a sufficiently good fix on the error if it were only being used. At the very least, I think we should put in Magnus' patch and find out whether it gives sufficient information. If it doesn't, then we can think about changing to a higher log level. regards, tom lane ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Status report on 8.3 release
Andreas 'ads' Scherbaum [EMAIL PROTECTED] writes: i would also like to test another Beta, if we do something about this problem: http://archives.postgresql.org/pgsql-hackers/2007-11/msg00960.php That's already done, it would be in the next beta. You could check out a copy from CVS HEAD if you want to test it now. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's PostGIS support! ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] CommandCounterIncrement versus plan caching
Tom Lane [EMAIL PROTECTED] writes: One fairly simple answer is to insert a CCI call at the start of RevalidateCachedPlan. I dislike that solution, at least by itself, on two grounds: * A patch of that form would approximately double the number of CCI calls involved in executing a plpgsql function; which quite aside from any performance cost would halve the distance to the 2^32-commands-per-transaction horizon. We've already heard from people who ran into that limit, so I don't want to bring it closer. Wait, shouldn't it be sufficient to do a CCI only in the if (!plan) case? Ie, before actually replanning a query? That would only cause an additional CCI the first time through a plpgsql query. Presumably if you're nearing the 4-billion mark it's because you're going through a loop. It's still kind of ugly though. And it wouldn't help any if you're looping around some dynamic SQL. I didn't trace through all your logic so I'm not sure if only doing the CCI if you actually invalidate a previously planned query would help any. * This would result in executing CCI calls even during stable/immutable PL functions. I'm not sure that would have any bad semantic side-effects, but I'm not convinced it wouldn't, either. And it also gives back whatever command count limit savings we bought when we fixed things so that stable/immutable functions don't call CCI. Hm, if you have a stable function which looks up some value from a table then would doing a CCI might screw up something like this? postgres=# create table tab(id integer, val text); CREATE TABLE postgres=# insert into tab values (1,'a'); INSERT 0 1 postgres=# insert into tab values (2,'b'); INSERT 0 1 postgres=# insert into tab values (3,'c'); INSERT 0 1 postgres=# create function lookup(integer) returns text as 'select val from tab where id = $1' language sql stable; CREATE FUNCTION postgres=# update tab set val = lookup(id-1); UPDATE 3 postgres=# select * from tab; id | val +- 1 | 2 | a 3 | b (3 rows) -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Get trained by Bruce Momjian - ask me about EnterpriseDB's PostgreSQL training! ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] Status report on 8.3 release
Hello, On Thu, 29 Nov 2007 17:21:09 -0500 Tom Lane wrote: Neil Conway [EMAIL PROTECTED] writes: So are there no plans for an additional beta? Yes, there are, but not till we do something about http://archives.postgresql.org/pgsql-hackers/2007-11/msg01302.php i would also like to test another Beta, if we do something about this problem: http://archives.postgresql.org/pgsql-hackers/2007-11/msg00960.php Kind regards -- Andreas 'ads' Scherbaum German PostgreSQL User Group ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] Status report on 8.3 releaset
Joshua D. Drake wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu, 29 Nov 2007 14:01:11 -0800 Neil Conway [EMAIL PROTECTED] wrote: On Thu, 2007-11-29 at 11:26 -0500, Bruce Momjian wrote: I expect these cleanups to continue for at least another week or two. Once they slow we will schedule RC1. So are there no plans for an additional beta? Given the recent addition of changes like http://archives.postgresql.org/pgsql-committers/2007-11/msg00552.php http://archives.postgresql.org/pgsql-committers/2007-11/msg00532.php I wonder if another beta before RC1 would be warranted. I think the email is not quite clear :). There is a Beta 4 coming, the problem is packagers aren't really available this week so if it comes it will be next week. Yes, there will be another beta before RC1. -- Bruce Momjian [EMAIL PROTECTED]http://momjian.us EnterpriseDB http://postgres.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Status report on 8.3 release
On Nov 30, 2007 11:10 AM, Andreas 'ads' Scherbaum [EMAIL PROTECTED] wrote: i would also like to test another Beta, if we do something about this problem: http://archives.postgresql.org/pgsql-hackers/2007-11/msg00960.php Hi Andreas, Tom's already committed the quote_literal(anyelement) function. http://archives.postgresql.org/pgsql-committers/2007-11/msg00530.php Cheers BJ ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [HACKERS] Status report on 8.3 release
On Fri, 30 Nov 2007 11:26:35 +1100 Brendan Jurd wrote: On Nov 30, 2007 11:10 AM, Andreas 'ads' Scherbaum [EMAIL PROTECTED] wrote: i would also like to test another Beta, if we do something about this problem: http://archives.postgresql.org/pgsql-hackers/2007-11/msg00960.php Hi Andreas, Tom's already committed the quote_literal(anyelement) function. http://archives.postgresql.org/pgsql-committers/2007-11/msg00530.php Ups, i've overseen this one. Forget my posting and i will keep testing the next beta ;-) Kind regards -- Andreas 'ads' Scherbaum German PostgreSQL User Group ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] CommandCounterIncrement versus plan caching
Gregory Stark [EMAIL PROTECTED] writes: Wait, shouldn't it be sufficient to do a CCI only in the if (!plan) case? No. The problem is that if you don't do the CCI then you don't get the invalidation events that might-or-might-not be pending in the inval queue. So testing for whether the plan is still valid is meaningless unless that queue's been flushed. regards, tom lane ---(end of broadcast)--- TIP 6: explain analyze is your friend
[HACKERS] Release Note Changes
Few proposals - Can we say smoothed rather than distributed checkpoints? Smoothed checkpoints greatly reduce checkpoint I/O spikes - Heap-Only Tuples (HOT) accelerate space reuse for UPDATEs change to Heap-Only Tuples (HOT) improve performance of frequent UPDATEs I also notice that two performance features have disappeared from the release notes. (Presumably they have been removed from source). Both of them have changes that can be seen by users, so can't see why we would want them removed. - Merge Join performance has been substantially improved by ring buffer which avoids materializing the previous sort step. (Simon, Greg) More info, not for release notes: The materialization of the prior sort step would generally double the time taken for the sort, so avoiding this effectively gives a 50% performance gain on sorts that are part of large merge joins. - WAL file switches don't update controlfile any longer. Recovery now refers to the last checkpoint time, which may be many minutes earlier than time previously mentioned. (Simon, Tom) More info, not for release notes: WAL file switches were performed holding important LWLocks, so this improves scalability on high end systems as well as reducing response time spikes under heavy load on all kinds of hardware. -- Simon Riggs 2ndQuadrant http://www.2ndQuadrant.com ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] [BUGS] BUG #3774: create table like including index doesn't update pg_constraints with primary key
Hi, The following bug has been logged online: Bug reference: 3774 Logged by: guillaume (ioguix) de Rorthais Email address: [EMAIL PROTECTED] PostgreSQL version: 8.3 beta3 Operating system: mac os x 10.4.10 Description:create table like including index doesn't update pg_constraints with primary key Details: When creating a table using the create table ... (like ... inluding indexes...) syntaxe, pg_catalog.pg_constraint is not updated with the PK constraints which actually is setted in pg_index. I'm not sure if this issue is actually a bug or if there a logic behind this, but as the primary key is a constraint, I would expect it to be setted in pg_constraint, shouldn't it ? This can be handled by setting index-isconstraint appropriately inside generateClonedIndexStmt(). The fundamental question though is should we allow primary, unique CONSTRAINTS which use the index mechanism just as an implementation to be created using the INCLUDING INDEXES mechanism. As per the discussion here: http://www.nabble.com/Re%3A-CREATE-TABLE-LIKE-INCLUDING-INDEXES-support-p10683716.html maybe we should not? In other words INCLUDING INDEXES should only create those indexes which do not have isconstraint set to TRUE. Comments? Regards, Nikhils -- EnterpriseDB http://www.enterprisedb.com
