Re: [BUGS] ecpg multidimensional arrays
On Fri, Feb 27, 2004 at 07:24:18PM +0100, Margit Schubert-While wrote:
> exec sql begin declare section;
> static int intcur[50][10] = { 0 };
>
> produces :
> ERROR: No multi-dimensional array support for simple data types
So far so good, but which bug are you reporting?
Michael
--
Michael Meskes
Email: Michael at Fam-Meskes dot De
ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: [EMAIL PROTECTED]
Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL!
---(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: [BUGS] BUG #1161: User permissions are kept, even if user is
Dear Tom,
The "clean" way to handle this would be to extend the bootstrap command
parser to accept a command along the lines of CREATE [SHARED] SEQUENCE
and then add a file in src/include/catalog that defines the shared
user-id-generator sequence. (Look at how pg_shadow is created for
precedent.)
Ok. I'll look into that to evaluate what is the impact.
Not having looked recently, I have no idea how much pain is implied by
the preceding paragraph ;-). I'd be willing to accept cruder
compromises if that approach seems impractical, but please look to see
if it can be done nicely first.
Ok.
For crude stuff, I can contribute simple and efficient ideas:
I was thinking that any integer attribute of any tuple in a shared
relation would be ok to store a sequence value. There are only 3 shared
relations, pg_{database,group,shadow}. Thus, something like a speudo
"next_sysid" user/group could store the next value in the relevant shared
relations.
This approach would be light weight from the implementation point of view.
Not very clean, but that would be easy and would not change much the
catalog.
--
Fabien Coelho - [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: [BUGS] BUG #1161: User permissions are kept, even if user is
Fabien COELHO <[EMAIL PROTECTED]> writes: > I was thinking that any integer attribute of any tuple in a shared > relation would be ok to store a sequence value. Certainly not --- when there are multiple versions of the tuple because of MVCC rules, which do you use? regards, tom lane ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [BUGS] [ADMIN] out of memory error
Jie Liang wrote: Does 7.3* support this? Can you tell me a bit more about it, please? Hash aggregate..? >I had a similar problem after upgrade to 7.4.2, >Try: >SET enable_hashagg = false; >Before you execute that SELECT stmt >If you don't want disable it in postgresql.conf > >Jie Liang > > > -- CONFIDENTIALITY NOTICE -- This message is intended for the sole use of the individual and entity to whom it is addressed, and may contain information that is privileged, confidential and exempt from disclosure under applicable law. If you are not the intended addressee, nor authorized to receive for the intended addressee, you are hereby notified that you may not use, copy, disclose or distribute to anyone the message or any information contained in the message. If you have received this message in error, please immediately advise the sender by reply email, and delete the message. Thank you. ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [BUGS] BUG #1161: User permissions are kept, even if user is
Dear Tom, I was thinking that any integer attribute of any tuple in a shared relation would be ok to store a sequence value. Certainly not --- when there are multiple versions of the tuple because of MVCC rules, which do you use? I understand you concern, but I think the troubles depends on how the value is actually used. I agree it would not be a real sequence with nextval() and so, but the purpose is just to find an non already used sysid. The locking mecanism on the update of this special account would insure that the there is no possible conflict. SELECT usesysid AS old_sysid_value FROM pg_shadow WHERE usename='next_sysid' FOR UPDATE; // iterate to find some new sysid starting from previous value UPDATE usesysid = new_found_sysid WHERE usename='next_sysid'; INSERT new user with old_sysid_value; So the concern I would see is more on the fact that there is a lock that would block concurrent "create user", especially if done in a long transaction, so IMHO this is performance/contention issue, but there is no real semantical issue. What is lost is the no-lock nature of the sequence update with nextval. I'm not sure the performance would be a big trouble, because create user are not issued that often, and I would not expect them to appear within a large transaction. Anyway I'm planing to hace a look at the real thing first (shared seq). So no worry, and thanks for your question. -- Fabien Coelho - [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: [BUGS] BUG #1145: silent REVOKE failures
Bruce Momjian <[EMAIL PROTECTED]> writes: >> For the TODO, I would suggest something general: >> - fix grant/revoke wrt SQL standard, validate errors, warnings and successes. > Tom, is this done? I think so. At least, we're a lot closer to spec than we were. regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [BUGS] BUG #1145: silent REVOKE failures
Fabien COELHO wrote: > > Dear Bruce, > > > > > Well, if I issue a "REVOKE" and the rights are not revoked and could never > > > > have been because I have no right to issue such statement on the object, I > > > > tend to call this deep absence of success a "failure". > > > > > > > If I do the very opposite GRANT, I have a clear "permission denied". > > > > > > Oh, I thought you were complaining that revoking rights not previously > > > granted should be an error. I agree with the above; in fact it's a > > > duplicate of a previous complaint. > > > > Did we resolve this? Is it a TODO? > > No? No? > > There has been a lot of off-line discussion about how to interpret the > standard on this point. I'm not even sure we perfectly agreed in the end, > although our understanding of the issues improved a lot through the > discussion. As a summary, it is pretty subtle, especially as the standard > wording is contrived, and postgres does not do what should be done in a > lot of cases. There are also actual "security" bugs. > > For the TODO, I would suggest something general: > > - fix grant/revoke wrt SQL standard, validate errors, warnings and successes. Tom, is this done? -- 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: [BUGS] BUG #1145: silent REVOKE failures
> >> For the TODO, I would suggest something general: > >> - fix grant/revoke wrt SQL standard, validate errors, warnings and successes. > > > Tom, is this done? > > I think so. At least, we're a lot closer to spec than we were. Indeed. Maybe the validation part could be improved somehow, with test cases build from the sql specification and the expected behavior checked against the actual behavior. What I derived from the many discussion and time I spent on the standard is that there is a lot of subtlety involved. So maybe the following TODO could be kept: - validate grant/revoke (error, warning, success0 wrt sql standard I may be interested in implementing ROLEs someday, and such tests would be welcome just to check that nothing is broken. -- Fabien Coelho - [EMAIL PROTECTED] ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [BUGS] [ADMIN] out of memory error
I had a similar problem after upgrade to 7.4.2, Try: SET enable_hashagg = false; Before you execute that SELECT stmt If you don't want disable it in postgresql.conf Jie Liang -Original Message- From: Adi Alurkar [mailto:[EMAIL PROTECTED] Sent: Monday, June 07, 2004 5:01 PM To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: [ADMIN] out of memory error Greetings, During testing of our application we ran into a very odd error: very randomly during the test the postgresql log file showed a "ERROR: 53200: out of memory" we changed the logging configuration to log statements causing errors and found the error to be caused by a SELECT, here is the relevant info from postgresql log file : ERROR: 53200: out of memory DETAIL: Failed on request of size 188 LOCATION: AllocSetAlloc, aset.c:700 Interestingly the box did not OOM (i.e nothing in /var/log/messages) running RHAS3 with PG 7.4.2 -bash-2.05b$ id uid=26(postgres) gid=26(postgres) groups=26(postgres) -bash-2.05b$ psql -V psql (PostgreSQL) 7.4.2 contains support for command-line editing -bash-2.05b$ cat /etc/redhat-release Red Hat Enterprise Linux ES release 3 (Taroon) -bash-2.05b$ ulimit -a core file size(blocks, -c) unlimited data seg size (kbytes, -d) unlimited file size (blocks, -f) unlimited max locked memory (kbytes, -l) 4 max memory size (kbytes, -m) unlimited open files(-n) 1024 pipe size (512 bytes, -p) 8 stack size(kbytes, -s) 10240 cpu time (seconds, -t) unlimited max user processes(-u) 7168 virtual memory(kbytes, -v) unlimited This happens randomly, when the failing SELECT was run via psql it executed w/o error. Any suggestions on how this can be debugged? -Adi ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[BUGS] Bug with deleteRow() for the ResultSet using PostgreSQL 7.4 (Build 213)driver.
If PostgreSQL failed to compile on your computer or you found a bug that
is likely to be specific to one platform then please fill out this form
and e-mail it to [EMAIL PROTECTED]
To report any other bug, fill out the form below and e-mail it to
[EMAIL PROTECTED]
If you not only found the problem but solved it and generated a patch
then e-mail it to [EMAIL PROTECTED] instead. Please use the
command "diff -c" to generate the patch.
You may also enter a bug report at http://www.postgresql.org/ instead of
e-mail-ing this form.
POSTGRESQL BUG REPORT TEMPLATE
Your name : Chris Pesarchick
Your email address : [EMAIL PROTECTED]
System Configuration
-
Architecture (example: Intel Pentium) : Intel IBM A22m Laptop
Operating System (example: Linux 2.4.18) : Linux
PostgreSQL version (example: PostgreSQL-7.4.2): PostgreSQL-7.4.2
Compiler used (example: gcc 2.95.2) : 3.3-23
JDBC Driver : PostgreSQL 7.4 (Build 213)
Please enter a FULL description of your problem:
I am having an issue with the driver when I do a deleteRow using a
ResultSet record. It skips records.
For example, if I have seven records and I select all of them in a
ResultSet, spin through each one and call deleteRow() the result is wrong.
The 1st, 3rd, 5th, and 7th records are deleted, but the others are not.
Please describe a way to repeat the problem. Please try to provide a
concise reproducible example, if at all possible:
--
/**
* This is an example of using the deleteRow.
* Here are some of the things I found. For this method to work
* there must be a few things done.
* 1. Must use CONCUR_UPDATABLE in the createStatement
* 2. There must be primary keys, if you don't have any, use 'oid'
field
* in the select that creates the resultset.
* @throws SQLException
*/
public void deleteRow() throws SQLException {
System.out.println("Start deleteRow");
Statement statement = null;
ResultSet resultSet = null;
int i = 1;
statement =
connection.createStatement(ResultSet.TYPE_SCROLL_SENSITIVE,ResultSet.CONCUR_UPDATABLE);
String sql = "select oid, * from perf_data where
username='cpesarchick'"; //This can be any select statement
//statement.setFetchSize(1000);
resultSet = statement.executeQuery( sql );
resultSet.last();
System.out.println("row count: " + resultSet.getRow());
resultSet.beforeFirst();
while ( resultSet.next()) {
System.out.println( "row #: " + resultSet.getRow());
System.out.println("Deleting Row:" + i);
resultSet.deleteRow();
System.out.println("Done Deleting Row:" + i);
System.out.println( "row #: " + resultSet.getRow());
i++;
}
resultSet.close();
statement.close();
System.out.println("End deleteRow");
}
If you know how this problem might be fixed, list the solution below:
-
I don't know, but my suspicions are with the Vector which holds all the
rows in the ResultSet.
This electronic message transmission contains information from a member company of
Westfield Group which is privileged, confidential or otherwise the exclusive property
of the intended recipient or that member company of Westfield Group. This information
is intended for the use of the individual or entity that is the intended recipient.
If you are not the designated recipient, please be aware that any dissemination,
distribution or copying of this communication is strictly prohibited. If you have
received this electronic transmission in error, please notify us by telephone at
1.800.243.0210, extension 2153, or by electronic e-mail ([EMAIL PROTECTED]) and
promptly destroy the original transmission.
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faqs/FAQ.html
[BUGS] Identifying cause of "database system shutdown was interrupted" at failed startup
Title: Identifying cause of "database system shutdown was interrupted" at failed startup Hi, We recently encountered a serious database crash that resulted in a significant loss of data… We took down the database server, and when we restarted the backend we got an error 'database system shutdown was interrupted' … 'invalid checkpoint' etc… with missing xlog files (I've appended the log to the end of this post)… I've been trawling list-archives for a few days and this issue has cropped up a number of times, but I've found it hard to identify a single post - or set of posts - that might help explain the cause of such a crash… Hopefully I'll be able to bring together the results of this trawl through the archives in this post - but I'd really appreciate any help or suggestions people have - we currently have a slightly uneasy feeling because we've not quite got to the bottom of the issues, and it would be nice to set our minds at rest! :-) So far I've identified two possible causes of the crash - I've listed them below, and wonder whether people have any comments on them: 1) We were running postgres version 7.3.6-1 (which is the version in RedHat AS3 : redhat EL AS3 kernel-smp-2.4.21-9.0.1EL) The following post suggests that this is a known issue in 7.3.3, but 7.3.4 is safe? I assume, therefore, that 7.3.6-1 is also safe... http://archives.postgresql.org/pgsql-general/2003-09/msg01086.php 2) We are running the database in conjunction with Jboss, connecting to the database server from a different machine via JDBC. The database was taken down *without* stopping Jboss first. Any thoughts would be much apreciated! Below are the relevant bits of the shutdown and startup logs, Best wishes, Crispin -- shutdown log (/var/log/messages): May 28 15:43:35 shutdown: shutting down for system halt May 28 15:43:35 init: Switching to runlevel: 0 May 28 15:43:36 server rhnsd[1694]: Exiting May 28 15:43:36 server rhnsd: rhnsd shutdown succeeded May 28 15:43:36 server atd: atd shutdown succeeded May 28 15:43:36 server cups: cupsd shutdown succeeded May 28 15:43:36 server xfs[1643]: terminating May 28 15:43:36 server xfs: xfs shutdown succeeded May 28 15:43:36 server mysqld: Stopping MySQL: succeeded May 28 15:43:36 server gpm: gpm shutdown succeeded May 28 15:43:37 server rhdb: Stopping PostgreSQL - Red Hat Edition service: May 28 15:43:37 server su(pam_unix)[12400]: session opened for user postgres by (uid=0) May 28 15:43:40 server su(pam_unix)[12400]: session closed for user postgres May 28 15:43:40 server rhdb: ^[[60G[ May 28 15:43:40 server rhdb: May 28 15:43:40 server rc: Stopping rhdb: succeeded ... May 28 15:43:44 server kernel: Kernel logging (proc) stopped. May 28 15:43:44 server kernel: Kernel log daemon terminating. May 28 15:43:45 server syslog: klogd shutdown succeeded May 28 15:43:45 server exiting on signal 15 May 28 16:13:35 server syslogd 1.4.1: restart. - starting messages Jun 1 10:43:55 server postgres[5537]: [30] LOG: database system shutdown was interrupted at 2004-05-28 16:32:08 BST Jun 1 10:43:55 server postgres[5537]: [31] LOG: open of /var/lib/pgsql/data/pg_xlog/ (log file 0, segment 0) failed: No such file or directory Jun 1 10:43:55 server postgres[5537]: [32] LOG: invalid primary checkpoint record Jun 1 10:43:55 server postgres[5537]: [33] LOG: open of /var/lib/pgsql/data/pg_xlog/ (log file 0, segment 0) failed: No such file or directory Jun 1 10:43:55 server postgres[5537]: [34] LOG: invalid secondary checkpoint record Jun 1 10:43:55 server postgres[5537]: [35] PANIC: unable to locate a valid checkpoint record Jun 1 10:43:55 server postgres[5534]: [31] LOG: startup process (pid 5537) was terminated by signal 6 Jun 1 10:43:55 server postgres[5534]: [32] LOG: aborting startup due to startup process failure Jun 1 10:43:56 server rhdb: Starting PostgreSQL - Red Hat Edition service: failed Jun 1 10:44:00 server su(pam_unix)[5554]: session opened for user postgres by (uid=0) Jun 1 10:44:00 server su(pam_unix)[5554]: session closed for user postgres Jun 1 10:44:00 server postgres[5595]: [30] LOG: database system shutdown was interrupted at 2004-05-28 16:32:08 BST Jun 1 10:44:00 server postgres[5595]: [31] LOG: open of /var/lib/pgsql/data/pg_xlog/ (log file 0, segment 0) failed: No such file or directory Jun 1 10:44:00 server postgres[5595]: [32] LOG: invalid primary checkpoint record Jun 1 10:44:00 server postgres[5595]: [33] LOG: open of /var/lib/pgsql/data/pg_xlog/ (log file 0, segment 0) failed: No such file or directory Jun 1 10:44:00 server postgres[5595]: [34] LOG: invalid secondary checkpoint record Jun 1 10:44:00 server postgres[5595]: [35] PANIC: unable to locate a valid checkpoint record Jun 1 10:44:00 server postgres[5592]: [31] LOG: startup process (pid 5595) was terminated by signal 6 Jun 1 1
Re: [BUGS] [GENERAL] bug in 7.4.2, concern unicode and russian content of
On Mon, 2004-06-07 at 12:11, Alexander S. wrote: > There is bug in 7.4.2, concerning unicode and russian letters. For db > in unicode russian data doesn`t order in alphabetical order (rows group > with the same first letter but not in alphabetical order). > SELECT "person" from my_table ORDER BY "person"; > Rows group in such order (approximately): Ð-Ð-Ð-Ð-Ð, but must be : > Ð-Ð-Ð-Ð-Ð. > For english letters all looks fine. For db in koi8r encoding also all > works right. So, I CANNOT use unicode with russian content of db in > postgres. Is it bug or not? What locale was your database initialized with? ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
[BUGS] bug in 7.4.2, concern unicode and russian content of db
There is bug in 7.4.2, concerning unicode and russian letters. For db in unicode russian data doesn`t order in alphabetical order (rows group with the same first letter but not in alphabetical order). SELECT "person" from my_table ORDER BY "person"; Rows group in such order (approximately): Ð-Ð-Ð-Ð-Ð, but must be : Ð-Ð-Ð-Ð-Ð. For english letters all looks fine. For db in koi8r encoding also all works right. So, I CANNOT use unicode with russian content of db in postgres. Is it bug or not? ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
[BUGS] out of memory error
Greetings, During testing of our application we ran into a very odd error: very randomly during the test the postgresql log file showed a "ERROR: 53200: out of memory" we changed the logging configuration to log statements causing errors and found the error to be caused by a SELECT, here is the relevant info from postgresql log file : ERROR: 53200: out of memory DETAIL: Failed on request of size 188 LOCATION: AllocSetAlloc, aset.c:700 Interestingly the box did not OOM (i.e nothing in /var/log/messages) running RHAS3 with PG 7.4.2 -bash-2.05b$ id uid=26(postgres) gid=26(postgres) groups=26(postgres) -bash-2.05b$ psql -V psql (PostgreSQL) 7.4.2 contains support for command-line editing -bash-2.05b$ cat /etc/redhat-release Red Hat Enterprise Linux ES release 3 (Taroon) -bash-2.05b$ ulimit -a core file size(blocks, -c) unlimited data seg size (kbytes, -d) unlimited file size (blocks, -f) unlimited max locked memory (kbytes, -l) 4 max memory size (kbytes, -m) unlimited open files(-n) 1024 pipe size (512 bytes, -p) 8 stack size(kbytes, -s) 10240 cpu time (seconds, -t) unlimited max user processes(-u) 7168 virtual memory(kbytes, -v) unlimited This happens randomly, when the failing SELECT was run via psql it executed w/o error. Any suggestions on how this can be debugged? -Adi ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [BUGS] BUG #1145: silent REVOKE failures
Fabien COELHO wrote: > > > >> For the TODO, I would suggest something general: > > >> - fix grant/revoke wrt SQL standard, validate errors, warnings and successes. > > > > > Tom, is this done? > > > > I think so. At least, we're a lot closer to spec than we were. > > Indeed. > > Maybe the validation part could be improved somehow, with test cases > build from the sql specification and the expected behavior checked > against the actual behavior. > > What I derived from the many discussion and time I spent on the standard > is that there is a lot of subtlety involved. > > So maybe the following TODO could be kept: > > - validate grant/revoke (error, warning, success0 wrt sql standard > > I may be interested in implementing ROLEs someday, and such tests would be > welcome just to check that nothing is broken. Unless someone can say it is wrong I am not inclinded to add a TODO item that is only possible. -- 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]
[BUGS] 7.4.2 initdb core dumping on solaris 2.8
Hi, I built and installed PostgreSQL 7.4.2 on a Solaris 2.8 machine. When I run initdb it core dumps while "vacuuming database template1" in execUtils.c:783. Here are the configure flags I used: configure --with-java --enable-debug --enable-cassert --without-readline --p refix=/opt/foo/pgsql I tried 7.4.1, and got the same problem. ... creating conversions... ok setting privileges on built-in objects... ok creating information schema... ok vacuuming database template1... Segmentation Fault - core dumped ./postgres -F -D/opt/foo/db/pgdatabase -O -c search_path=pg_catalog -c exit_on_error=true template1 bash$ gdb ./postgres GNU gdb 6.0 This GDB was configured as "sparc-sun-solaris2.8"... (gdb) run -F -D/opt/foo/db/pgdatabase -O -c search_path=pg_catalog -c exit_on_error=true template1 Starting program: /opt/foo/pgsql/bin/postgres -F -D/opt/foo/db/pgdatabase -O -c search_path=pg_catalog -c exit_on_error=true template1 POSTGRES backend interactive interface $Revision: 1.375.2.1 $ $Date: 2003/11/24 14:50:02 $ backend> ANALYZE; backend> VACUUM FULL FREEZE; Program received signal SIGSEGV, Segmentation fault. ExecInsertIndexTuples (slot=0x375100, tupleid=0xffbef4bc, estate=0x37b0a8, is_vacuum=1 '\001') at execUtils.c:783 783 numIndices = resultRelInfo->ri_NumIndices; (gdb) where #0 ExecInsertIndexTuples (slot=0x375100, tupleid=0xffbef4bc, estate=0x37b0a8, is_vacuum=1 '\001') at execUtils.c:783 #1 0x000d4f5c in repair_frag (vacrelstats=0xffbed448, onerel=0xffbed454, vacuum_pages=0x0, fraged_pages=0x0, nindexes=0, Irel=0x2f303030) at vacuum.c:2176 #2 0x000d1a7c in full_vacuum_rel (onerel=0x98, vacstmt=0x27a000) at vacuum.c:958 $ uname -a SunOS foo 5.8 Generic_108528-10 sun4u sparc SUNW,Sun-Blade-100 Any ideas? Thanks ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[BUGS] Returned due to virus; was: Re: Re: Thanks!
Here is the file. Title: VIRUS INFECTION ALERT VIRUS INFECTION ALERT The WebShield® e500 Appliance discovered a virus in this file. The file was not cleaned and has been removed. See your system administrator for further information. File name: document.pif Virus name: W32/[EMAIL PROTECTED] Copyright © 1993-2002, Networks Associates Technology, Inc. All Rights Reserved. http://www.mcafeeb2b.com ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [BUGS] Bug in ECPG preprocessor
Your patch has been added to the PostgreSQL unapplied patches list at: http://momjian.postgresql.org/cgi-bin/pgpatches I will try to apply it within the next 48 hours. --- Sergey N. Yatskevich wrote: > ECPG preprocessor for PostgreSQL 7.4.1, 7.4.2 doubles const, > volatile, static, and register keywords before variables, > declared as VARCHAR. > > I attach to this mail example for this, and patch for PostgreSQL > 7.4.1, that solves this problem (this patch also applicable to > PostgreSQL 7.4.2 too) > > -- > Sergey N. Yatskevich <[EMAIL PROTECTED]> > GosNIIAS [ Attachment, skipping... ] [ Attachment, skipping... ] [ Attachment, skipping... ] > > ---(end of broadcast)--- > TIP 5: Have you checked our extensive FAQ? > >http://www.postgresql.org/docs/faqs/FAQ.html -- 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 7: don't forget to increase your free space map settings
