Re: [HACKERS] FATAL 2: InitRelink(logfile 0 seg 173) failed: No such
Tom Lane wrote: That really should be impossible --- it says that a rename() failed for a file we just created. I judge from the spelling of the error message that you are running 7.1. 7.1.3 However, given that you state a system reboot is necessary and sufficient to make the problem go away, I am going to stick my neck *way* out and suggest that: 1. You have the $PGDATA directory (or at least its pg_xlog subdirectory) mounted via NFS. 2. This is an NFS problem. I am not running NFS on this system. ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] FATAL 2: InitRelink(logfile 0 seg 173) failed: No such
Tom Lane wrote: James Thornton [EMAIL PROTECTED] writes: I am not running NFS on this system. Oh well, scratch that theory. Perhaps you should tell us what you *are* running --- what OS, what hardware? I still believe that this must be a system-level bug and not directly Postgres' fault. [nsadmin@roam proc]$ cat version cpuinfo meminfo pci Linux version 2.4.7-10smp ([EMAIL PROTECTED]) (gcc version 2.96 2731 (Red Hat Linux 7.1 2.96-98)) #1 SMP Thu Sep 6 17:09:31 EDT 2001 processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 7 model name : Pentium III (Katmai) stepping: 3 cpu MHz : 548.324 cache size : 512 KB fdiv_bug: no hlt_bug : no f00f_bug: no coma_bug: no fpu : yes fpu_exception : yes cpuid level : 2 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 mmx fxsr sse bogomips: 1094.45 total:used:free: shared: buffers: cached: Mem: 327278592 321400832 5877760 720896 10825728 52867072 Swap: 271392768 13783040 257609728 MemTotal: 319608 kB MemFree: 5740 kB MemShared: 704 kB Buffers: 10572 kB Cached: 39552 kB SwapCached: 12076 kB Active: 21956 kB Inact_dirty: 40668 kB Inact_clean: 280 kB Inact_target: 480 kB HighTotal: 0 kB HighFree:0 kB LowTotal: 319608 kB LowFree: 5740 kB SwapTotal: 265032 kB SwapFree: 251572 kB NrSwapPages: 62893 pages PCI devices found: Bus 0, device 0, function 0: Host bridge: Intel Corporation 440BX/ZX - 82443BX/ZX Host bridge (rev 3). Master Capable. Latency=64. Prefetchable 32 bit memory at 0xf000 [0xf3ff]. Bus 0, device 1, function 0: PCI bridge: Intel Corporation 440BX/ZX - 82443BX/ZX AGP bridge (rev 3). Master Capable. Latency=64. Min Gnt=136. Bus 0, device 7, function 0: ISA bridge: Intel Corporation 82371AB PIIX4 ISA (rev 2). Bus 0, device 7, function 1: IDE interface: Intel Corporation 82371AB PIIX4 IDE (rev 1). Master Capable. Latency=32. I/O at 0x1000 [0x100f]. Bus 0, device 7, function 2: USB Controller: Intel Corporation 82371AB PIIX4 USB (rev 1). IRQ 14. Master Capable. Latency=64. I/O at 0xdce0 [0xdcff]. Bus 0, device 7, function 3: Bridge: Intel Corporation 82371AB PIIX4 ACPI (rev 2). IRQ 9. Bus 0, device 14, function 0: Ethernet controller: Intel Corporation 82557 [Ethernet Pro 100] (rev 4). IRQ 11. Master Capable. Latency=64. Min Gnt=8.Max Lat=56. Prefetchable 32 bit memory at 0xf700 [0xf7000fff]. I/O at 0xdcc0 [0xdcdf]. Non-prefetchable 32 bit memory at 0xff00 [0xff0f]. Bus 0, device 15, function 0: PCI bridge: Digital Equipment Corporation DECchip 21152 (rev 3). Master Capable. Latency=64. Min Gnt=2. Bus 0, device 17, function 0: Ethernet controller: 3Com Corporation 3c905B 100BaseTX [Cyclone] (rev 36). IRQ 14. Master Capable. Latency=64. Min Gnt=10.Max Lat=10. I/O at 0xdc00 [0xdc7f]. Non-prefetchable 32 bit memory at 0xff10 [0xff10007f]. Bus 1, device 0, function 0: VGA compatible controller: ATI Technologies Inc 3D Rage Pro AGP 1X/2X (rev 92). IRQ 9. Master Capable. Latency=64. Min Gnt=8. Non-prefetchable 32 bit memory at 0xfd00 [0xfdff]. I/O at 0xfc00 [0xfcff]. Non-prefetchable 32 bit memory at 0xfcfff000 [0xfcff]. Bus 2, device 9, function 0: Unknown mass storage controller: Promise Technology, Inc. 20262 (rev 1). IRQ 9. Master Capable. Latency=64. I/O at 0xecf8 [0xecff]. I/O at 0xecf0 [0xecf3]. I/O at 0xece0 [0xece7]. I/O at 0xecd8 [0xecdb]. I/O at 0xec80 [0xecbf]. Non-prefetchable 32 bit memory at 0xfafe [0xfaff]. ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[HACKERS] ECPG won't compile anymore
I finally hit bison's limit and cannot find any easy to remove rules in the ecpg part of the parser anymore. There may be some in the backend part, but I'd like to keep those in sync. For the time being I update my machine to a development snapshot bison 1.49, but that doesn't look like a good solution. After all it hasn't been released yet. Since I suppose almost no one of you outthere uses a development version of bison I cannot commit my changes, or else, you all cannot compile ecpg anymore. So what do we do? Michael -- Michael Meskes [EMAIL PROTECTED] Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL! ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] PostGres Doubt
On Mon, Jun 17, 2002 at 11:27:45AM -0700, Dann Corbit wrote: Here is the complete NIST regression test: ftp://cap.connx.com/pub/chess-engines/new-approach/nist.ZIP You have to use passive ftp to get files from my site because of the firewall. I'm pretty sure my proxy does use passive ftp, but I cannot get through to you. Are you sure you use passive ftp for incoming connections? Anyway, it seems you have to mail it. :-) Michael -- Michael Meskes [EMAIL PROTECTED] Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL! ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] KSQO parameter
Bruce Momjian [EMAIL PROTECTED] writes: Peter Eisentraut wrote: _deadcode is nowadays known as CVS history. Agreed, but _deadcode directories still exist, so I put it there. Personally, I would like to see all those files removed, but I was outvoted last time I asked. Perhaps we need a revote. I don't like _deadcode one bit --- having that stuff in the tree just produces a lot of false hits when I'm searching for things. regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Roadmap for a Win32 port
Dann Corbit wrote: -Original Message- From: Bruce Momjian [mailto:[EMAIL PROTECTED]] Sent: Monday, June 17, 2002 6:20 PM To: Dann Corbit Cc: Jan Wieck; Peter Eisentraut; PostgreSQL-development Subject: Re: [HACKERS] Roadmap for a Win32 port Dann Corbit wrote: It will be at least another copy of the postmaster (dot exe). Yea, I just liked the idea of the postmaster binary somehow reporting the postmaster status. Seems it is in a better position to do that than a shell script. Architectural notion: The Postmaster is about 100x bigger than it needs to be. The Postmaster needs to set up shared memory and launch servers. It does not need to know anything about SQL grammar or any of that rigamarole. It could be a 15K executable. Why not have an itty-bitty Postmaster that does nothing but a spawn or a create process to create threaded Postgres instances? Can't. postmaster/postgres are symlinks to the same file, and we fork() from postmaster to create backends. All the code has to be in the postmaster so the fork works. Is fork() faster than creation of a new process via exec()? After the creation of the shared memory, the information needed to use it could be passed to the Postgres servers on the command line. exec() does NOT create new processes. It loads another executable file into the existing, calling process. fork() duplicates the calling process. In modern unix variants, this is done in a very efficient way, so that the text segment (program code) is shared readonly and everything else (data and stack segments) are shared copy on write. Thus, fork() itself doesn't even cause memory copying. That happens later when one of the now two processes writes to a memory page the first time. Windows does not have these two separate steps. It wants the full blown expensive create process and load executable, or the let's all muck around with the same handles modell, called threading. The startup stuff for PostgreSQL is just a few files. It does not seem insurmountable to change it. But it is none of my business. If it is a major hassle (for reasons which I am not aware) then I see no driving reason to change it. It has to be changed for Windows, it is a major hassle for reasons I wasn't aware of, and I am half way through ;-) Jan -- #==# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #== [EMAIL PROTECTED] # ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] ECPG won't compile anymore
Michael Meskes [EMAIL PROTECTED] writes: I finally hit bison's limit and cannot find any easy to remove rules in the ecpg part of the parser anymore. There may be some in the backend part, but I'd like to keep those in sync. So what do we do? I'd be inclined to say that you don't commit until bison 1.49 is officially released. Got any idea when that will be? regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] PERFORM effects FOUND patch (Was: [GENERAL] I must be
Jan Wieck [EMAIL PROTECTED] writes: Perform has nothing to do with ORACLE. It was added because people tried to call other procedures and didn't want any result back. Well, in that case we can do what we want with it. Does anyone object to making it set FOUND? regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] [SQL] Request for builtin function: Double_quote
Josh Berkus [EMAIL PROTECTED] writes: Given the amount of qoute nesting we do in Postgres, I thought that we need a function that handles automatic doubling of quotes within strings. I've written one in PL/pgSQL (below). I'd really love to see this turned into a builtin C function. What does this do that isn't already done by quote_literal? regards, tom lane ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] SetQuerySnapshot, once again
Hiroshi Inoue [EMAIL PROTECTED] writes: Tom Lane wrote: Sorry, I don't understand ... Let t be a table which is defined as create table t (id serial primary key, dt text); Then is the following function *stable* ? create function f1(int4) returns text as ' declare txt text; begin select dt into txt from t where id = $1; return txt; end ' language plpgsql; I'm not sure exactly what you mean by stable here. And I'm even less sure whether you are arguing for or against adding SetQuerySnapshot calls into plpgsql... regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] FATAL 2: InitRelink(logfile 0 seg 173) failed: No such file or directory
[EMAIL PROTECTED] writes: What if BasicOpenFile() got some other error? Doesn't really matter; anything else would be a problem we can't recover from anyhow. Besides, given that rename is failing with ENOENT, a conflict on the destination name does not appear to be the issue. regards, tom lane ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] Domains and Casting
Rod Taylor [EMAIL PROTECTED] writes: This appears to be due to makeTypeCast() in gram.y which bypasses creating a TypeCast node for simple A_Const. My immediate reaction is that you've probably put the testing of domain constraints in the wrong place. You didn't say exactly what your implementation looked like though ... regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] PostGres Doubt
David Ford [EMAIL PROTECTED] writes:
heakin= \z
Access privileges for database heakin
Table | Access privileges
---+---
interviewers |
heakin= grant select,insert,update on interviewers to heakin;
GRANT
heakin= \z
Access privileges for database heakin
Table | Access privileges
---+
interviewers | {=,heakin=arwdRxt}
I take it heakin is the owner of the table in question. As such,
he implicitly has all privileges --- the initial null privilege list
is a shorthand for what you see explicitly in the second case.
The GRANT man page in current development sources has an example about
this; see the Notes section of
http://developer.postgresql.org/docs/postgres/sql-grant.html
regards, tom lane
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] Roadmap for a Win32 port
Peter Eisentraut [EMAIL PROTECTED] writes: I think eventually pg_ctl should be folded into the postmaster executable. This would remove a great amount of possible misunderstandings between the two programs. Like what? The thing pg_ctl needs to know is where PGDATA is, and that unfortunately isn't going to be known any better just by sharing executables. I don't object to C-ifying pg_ctl, but I don't see that it will automatically improve pg_ctl's robustness materially. regards, tom lane ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] Roadmap for a Win32 port
On Tue, 2002-06-18 at 09:07, Jan Wieck wrote: Dann Corbit wrote: The startup stuff for PostgreSQL is just a few files. It does not seem insurmountable to change it. But it is none of my business. If it is a major hassle (for reasons which I am not aware) then I see no driving reason to change it. It has to be changed for Windows, it is a major hassle for reasons I wasn't aware of, and I am half way through ;-) Well, if you're going to go through the trouble of rewriting postmaster to be win32 specific, you might as well make it hook into the services control panel. If I recall, shared memory is owned by a process in Win32 (please correct as needed...as I've slept since I last looked). That means that the postmaster process not only owns the shared memory but needs to make sure that it's persists as the rest of postgres is expecting. Please provide more details as to the nature of your Win32 changes. I'm certainly curious. If you've already covered them, just say so...I have no problem going back to the archives! :) Greg signature.asc Description: This is a digitally signed message part
Re: [HACKERS] PostGres Doubt
Gotcha. 'twas the first time I encountered it, I wasn't expecting it.
Thank you for the clarification. I hadn't paid attention to that
paragraph when I read over it.
David
Tom Lane wrote:
David Ford [EMAIL PROTECTED] writes:
heakin= \z
Access privileges for database heakin
Table | Access privileges
---+---
interviewers |
heakin= grant select,insert,update on interviewers to heakin;
GRANT
heakin= \z
Access privileges for database heakin
Table | Access privileges
---+
interviewers | {=,heakin=arwdRxt}
I take it heakin is the owner of the table in question. As such,
he implicitly has all privileges --- the initial null privilege list
is a shorthand for what you see explicitly in the second case.
The GRANT man page in current development sources has an example about
this; see the Notes section of
http://developer.postgresql.org/docs/postgres/sql-grant.html
regards, tom lane
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] PostGres Doubt
On Tue, Jun 18, 2002 at 03:24:57PM +0200, Michael Meskes wrote: On Mon, Jun 17, 2002 at 11:27:45AM -0700, Dann Corbit wrote: Here is the complete NIST regression test: ftp://cap.connx.com/pub/chess-engines/new-approach/nist.ZIP You have to use passive ftp to get files from my site because of the firewall. I'm pretty sure my proxy does use passive ftp, but I cannot get through to you. Are you sure you use passive ftp for incoming connections? Anyway, it seems you have to mail it. :-) For future reference (and the archives of the list) the official download site for this code is: http://www.itl.nist.gov/div897/ctg/sql_form.htm And here's the usage statement, regarding incorporation of this work into other works (in short, it's public domain) http://www.itl.nist.gov/div897/ctg/softagre.htm Ross ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] SetQuerySnapshot, once again
-Original Message- From: Tom Lane [mailto:[EMAIL PROTECTED]] Hiroshi Inoue [EMAIL PROTECTED] writes: Tom Lane wrote: Sorry, I don't understand ... Let t be a table which is defined as create table t (id serial primary key, dt text); Then is the following function *stable* ? create function f1(int4) returns text as ' declare txt text; begin select dt into txt from t where id = $1; return txt; end ' language plpgsql; I'm not sure exactly what you mean by "stable" here. Wasn't it you who defined *stable* as Cachable within a single command: given fixed input values, the result will not change if the function were to be repeatedly evaluated within a single SQL command; but the result could change over time. ? And I'm even less sure whether you are arguing for or against adding SetQuerySnapshot calls into plpgsql... I already mentioned an opinion in 2001/09/08. Both the command counters and the snapshots in a function should advance except the leading SELECT statements. regards, Hiroshi Inoue ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [HACKERS] [SQL] Request for builtin function: Double_quote
Chris, Tom:
Yes, thank you Chris, I meant a builtin SQL function.
Given the amount of qoute nesting we do in Postgres, I thought that
we need a
function that handles automatic doubling of quotes within strings.
I've
written one in PL/pgSQL (below). I'd really love to see this
turned into a
builtin C function.
What does this do that isn't already done by quote_literal?
Well, first off, quote_literal isn't in the documentation under
Functions and Operators.So this is the first I've heard about it
-- or probably anyone else outside the core team. How long has it
been around?
Second, double_quote does not return the outside quotes, just the
inside ones ... it's for passing string values to EXECUTE statements.
However, now that I know that quote_literal exists, I can simplify
the double_quote statement considerably.
Therefore, I withdraw my initial request, and request instead that
quote_literal be added to the function documentation in String
Functions and Operators.
I will event supply text for the functions table:
functionreturns
quote_literal(string text) text
explain
Returns the entire string passed to it, including quote marks. Useful
for nesting quotes, such as in the EXECUTEing dynamic queries.
example result
quote_literal('O''Reilly') 'O''Reilly'
-Josh Berkus
-Josh Berkus
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
Re: [HACKERS] Roadmap for a Win32 port
Hello, I am new to PostgreSQL, but I am interested in the Win32 port. I have studied the architecture of other databases like Oracle. They have had to turn their multi-process model used on Unix into a fully multi-threaded one on Win32. I have the feeling that they have had the same debate that the one you have. The CreateProcess() syscall is very costly on Windows. Some improvements have been done in Windows XP but it is still far more costly than a Unix fork(). I have been programming with threads on NT for a long time now. They are quiet robust and efficient. I fear that it is the only successful way to port PostgreSQL. Sorry for this interruption, Serge -Original Message- From: Jan Wieck [mailto:[EMAIL PROTECTED]] Sent: Tuesday, June 18, 2002 16:07 To: Dann Corbit Cc: Bruce Momjian; Peter Eisentraut; PostgreSQL-development Subject: Re: [HACKERS] Roadmap for a Win32 port Dann Corbit wrote: -Original Message- From: Bruce Momjian [mailto:[EMAIL PROTECTED]] Sent: Monday, June 17, 2002 6:20 PM To: Dann Corbit Cc: Jan Wieck; Peter Eisentraut; PostgreSQL-development Subject: Re: [HACKERS] Roadmap for a Win32 port Dann Corbit wrote: It will be at least another copy of the postmaster (dot exe). Yea, I just liked the idea of the postmaster binary somehow reporting the postmaster status. Seems it is in a better position to do that than a shell script. Architectural notion: The Postmaster is about 100x bigger than it needs to be. The Postmaster needs to set up shared memory and launch servers. It does not need to know anything about SQL grammar or any of that rigamarole. It could be a 15K executable. Why not have an itty-bitty Postmaster that does nothing but a spawn or a create process to create threaded Postgres instances? Can't. postmaster/postgres are symlinks to the same file, and we fork() from postmaster to create backends. All the code has to be in the postmaster so the fork works. Is fork() faster than creation of a new process via exec()? After the creation of the shared memory, the information needed to use it could be passed to the Postgres servers on the command line. exec() does NOT create new processes. It loads another executable file into the existing, calling process. fork() duplicates the calling process. In modern unix variants, this is done in a very efficient way, so that the text segment (program code) is shared readonly and everything else (data and stack segments) are shared copy on write. Thus, fork() itself doesn't even cause memory copying. That happens later when one of the now two processes writes to a memory page the first time. Windows does not have these two separate steps. It wants the full blown expensive create process and load executable, or the let's all muck around with the same handles modell, called threading. The startup stuff for PostgreSQL is just a few files. It does not seem insurmountable to change it. But it is none of my business. If it is a major hassle (for reasons which I am not aware) then I see no driving reason to change it. It has to be changed for Windows, it is a major hassle for reasons I wasn't aware of, and I am half way through ;-) Jan -- #==# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #== [EMAIL PROTECTED] # ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED] ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] KSQO parameter
Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: Peter Eisentraut wrote: _deadcode is nowadays known as CVS history. Agreed, but _deadcode directories still exist, so I put it there. Personally, I would like to see all those files removed, but I was outvoted last time I asked. Perhaps we need a revote. I don't like _deadcode one bit --- having that stuff in the tree just produces a lot of false hits when I'm searching for things. Yes, that is my problem too. I can't tell you how many times I have edited backend/optimizer/path/_deadcode/xfunc.c to keep it in sync with the rest of my code changes. OK, we have three who don't like _deadcode directories and want them removed from CVS current (they will still exist in CVS). Does anyone want them? I think Marc wanted them initially. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
[HACKERS] ecpg and bison again
How about we add the preproc.c file generated by bison 1.49 to cvs? Could that create problems elsewhere? The version that is part of the source tree now is generated on the server, isn't it? Michael -- Michael Meskes [EMAIL PROTECTED] Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL! ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] ECPG won't compile anymore
Michael Meskes [EMAIL PROTECTED] writes: On Tue, Jun 18, 2002 at 10:29:10AM -0400, Tom Lane wrote: I'd be inclined to say that you don't commit until bison 1.49 is officially released. Got any idea when that will be? No, that's the problem. ECPG and the backend parser are running out of sync. After all bison's release may be later than our next one. That would be trouble, but considering that we are not even thinking of going beta before late August, is it really a realistic risk? bison seems to be making releases quite frequently lately. They were at 1.30 back in November, according to my archives, so that's 19 releases in the last 8 months. If we get to August and there's no official release of bison with the larger table size, then it will be time to worry, IMHO. regards, tom lane ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] ECPG won't compile anymore
Michael Meskes wrote: On Tue, Jun 18, 2002 at 10:29:10AM -0400, Tom Lane wrote: I'd be inclined to say that you don't commit until bison 1.49 is officially released. Got any idea when that will be? No, that's the problem. ECPG and the backend parser are running out of sync. After all bison's release may be later than our next one. I cannot commit even simple bugfixes anymore as my source tree already has the uncompilable bison file. So I would have to work on two different source trees. I don't exactly like that. Are we the only ones up against this problem? Hard to imagine we are the only ones up against this limit in bison. Are there other options? I don't see how we can distribute ecpg in 7.3 without some kind of fix. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
[HACKERS] String index out of range: 23 problem with timestamp
Hi, We have a timestamp column in one table and we are getting the above problem when the timestamp column has a value upto milliseconds. We are using PostgreSQL 7.2 version stable jdbc driver(pgjdbc2.jar) got from http://jdbc.postgresql.org/download.html. Does anyone know of latest production ready driver that fixes this problem? Thanks Yuva ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
[HACKERS] Why is CacheMemoryContext declared DLLIMPORT in one place and not in another?
PostgreSQL 7.2.1... We have: C:\CYGWIN\USR\SRC\POSTGRESQL-7.2.1-1\src\include\utils\catcache.h(84):ex tern MemoryContext CacheMemoryContext; C:\CYGWIN\USR\SRC\POSTGRESQL-7.2.1-1\src\include\utils\memutils.h(70):ex tern DLLIMPORT MemoryContext CacheMemoryContext; They cannot both be correct. Which is correct? ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
[HACKERS] String index out of range: 23 problem with timestamp milliseconds
Hi, We have a timestamp column in one table and we are getting the above problem when the timestamp column has a value up to milliseconds. We are using stable PostgreSQL 7.2 jdbc driver (pgjdbc2.jar) got from http://jdbc.postgresql.org/download.html. Does anyone know of latest production ready driver that fixes this problem? Thanks Yuva ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] SetQuerySnapshot, once again
Hiroshi Inoue [EMAIL PROTECTED] writes: I'm not sure exactly what you mean by stable here. Wasn't it you who defined *stable* as Cachable within a single command: given fixed input values, the result will not change if the function were to be repeatedly evaluated within a single SQL command; but the result could change over time. Oh, *that* stable ;-) Okay, I get your point now. You are right --- a function that references a table that others might be concurrently changing would not be stable under read-committed rules. (But you could probably get away with marking it stable anyway.) I already mentioned an opinion in 2001/09/08. Both the command counters and the snapshots in a function should advance except the leading SELECT statements. I do not like the idea of treating the first select in a function differently from the rest. And such a rule wouldn't let you build guaranteed-stable functions anyway; what if the outer query was calling both your function, and another one that did cause the snapshot to advance? The behavior of your function would then vary depending on whether the other function was invoked or not. regards, tom lane ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
[HACKERS] Milliseconds problem with PostgreSQL 7.2 jdbc driver (pgjdbc2.jar)
Hi, We observed a String index out of range: 23 problem when we tried to retrieve timestamp field value that has milliseconds. We are trying to find a quick fix for the millisecond problem for Timestamp. We notice there is a beta driver(devpgjdbc2.jar) that contains this fix currently, but was wondering if the fix is issolated to just one or a few classes that we might get from the beta driver and insert into the production driver jar(pgjdbc2.jar). Is this an potential option or is the dependency risk too high? Thanks Yuva Ebates Shopping.com (http://www.ebates.com) ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] ECPG won't compile anymore
-Original Message- From: Bruce Momjian [mailto:[EMAIL PROTECTED]] Sent: Tuesday, June 18, 2002 11:13 AM To: Michael Meskes Cc: PostgreSQL Hacker Subject: Re: [HACKERS] ECPG won't compile anymore Michael Meskes wrote: On Tue, Jun 18, 2002 at 10:29:10AM -0400, Tom Lane wrote: I'd be inclined to say that you don't commit until bison 1.49 is officially released. Got any idea when that will be? No, that's the problem. ECPG and the backend parser are running out of sync. After all bison's release may be later than our next one. I cannot commit even simple bugfixes anymore as my source tree already has the uncompilable bison file. So I would have to work on two different source trees. I don't exactly like that. Are we the only ones up against this problem? Hard to imagine we are the only ones up against this limit in bison. Are there other options? I don't see how we can distribute ecpg in 7.3 without some kind of fix. There are some other freely available parser/generators. I like the Lemmon parser generator. Of course, I have no idea how traumatic it would be to convert a Bison grammar into Lemmon. There is also PCCTS and some other free ones. http://www.hwaci.com/sw/lemon/ ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Roadmap for a Win32 port
Tom Lane writes: Peter Eisentraut [EMAIL PROTECTED] writes: I think eventually pg_ctl should be folded into the postmaster executable. This would remove a great amount of possible misunderstandings between the two programs. Like what? The biggie is that pg_ctl reports the postmaster to have started successfully without ever checking. And the wait option is broken and not trivial to fix. Other problems are the matching of the port numbers and the requirement that admins should be able to enter a password when the server starts (for SSL). The luring prerequisite here is that the postmaster would have to be able to log directly to a file, which now that all communication is guaranteed to go through elog() should be less complicated, at least compared to fixing the wait option. In fact I'm hoping that the Windows porters will run into this same requirement just about pretty soon. -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] SetQuerySnapshot, once again
Tom Lane wrote: "Hiroshi Inoue" [EMAIL PROTECTED] writes: I already mentioned an opinion in 2001/09/08. Both the command counters and the snapshots in a function should advance except the leading SELECT statements. I do not like the idea of treating the first select in a function differently from the rest. And such a rule wouldn't let you build guaranteed-stable functions anyway; AFAIK there has been no analysis where we can get *stable* functions. As far as I see, we can expect SELECT-only functions to be *stable* if and only if they are surrounded by SELECT-only *stable* functions. regards, Hiroshi Inoue http://w2422.nsk.ne.jp/~inoue/ ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [HACKERS] Domains and Casting
Erm... I suppose I didn't really intend to bring up domains at all.
I'm just playing trying to figure out how things work (easiest by
breaking them I think).
I don't understand why the below patch has such an adverse affect on
the system.
Causes:
(p2.pronargs != 3 OR p2.proretset OR p2.proargtypes[2] !=
'int4'::regtype);
! ERROR: Invalid type name 'int4'
or
(p2.oprkind != 'b' OR p2.oprresult != 'bool'::regtype OR
! ERROR: Invalid type name 'bool'
Index: src/backend/parser/gram.y
===
RCS file: /projects/cvsroot/pgsql/src/backend/parser/gram.y,v
retrieving revision 2.314
diff -c -r2.314 gram.y
*** src/backend/parser/gram.y 2002/05/12 20:10:04 2.314
--- src/backend/parser/gram.y 2002/06/19 00:54:44
***
*** 6424,6442
* (We don't want to collapse x::type1::type2 into just x::type2.)
* Otherwise, generate a TypeCast node.
*/
! if (IsA(arg, A_Const)
! ((A_Const *) arg)-typename == NULL)
! {
! ((A_Const *) arg)-typename = typename;
! return arg;
! }
! else
! {
TypeCast *n = makeNode(TypeCast);
n-arg = arg;
n-typename = typename;
return (Node *) n;
! }
}
static Node *
--- 6424,6442
* (We don't want to collapse x::type1::type2 into just x::type2.)
* Otherwise, generate a TypeCast node.
*/
! // if (IsA(arg, A_Const)
! // ((A_Const *) arg)-typename == NULL)
! // {
! // ((A_Const *) arg)-typename = typename;
! // return arg;
! // }
! // else
! // {
TypeCast *n = makeNode(TypeCast);
n-arg = arg;
n-typename = typename;
return (Node *) n;
! // }
}
static Node *
--
Rod
- Original Message -
From: Tom Lane [EMAIL PROTECTED]
To: Rod Taylor [EMAIL PROTECTED]
Cc: Hackers List [EMAIL PROTECTED]
Sent: Tuesday, June 18, 2002 10:58 AM
Subject: Re: [HACKERS] Domains and Casting
Rod Taylor [EMAIL PROTECTED] writes:
This appears to be due to makeTypeCast() in gram.y which bypasses
creating a TypeCast node for simple A_Const.
My immediate reaction is that you've probably put the testing of
domain constraints in the wrong place. You didn't say exactly
what your implementation looked like though ...
regards, tom lane
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/users-lounge/docs/faq.html
Re: [Fwd: [PATCHES] contrib/showguc (was Re: [HACKERS] revised sample
moving back to HACKERS for the discussion Peter Eisentraut wrote: OK, I've been looking at this package for some time through various iterations and I have my doubts about it. What's going to happen to this when SHOW ALL is changed to return a query result? If you want to provide an example of a set-returning function, use something of lasting value, maybe generate some mathematic sequence. Well, I wanted to implement this as a functional equivalent of SHOW ALL, in the backend, but there was no way to bootstrap a builtin SRF that wasn't also too ugly to be acceptable (at least that I could come up with -- any suggestions?). And while SHOW ALL *could* be implemented in a similar fashion to EXPLAIN, with that approach you could not use a WHERE clause, or join the results with any other data. IMHO that significantly reduces the utility of returning SHOW ALL results as a query in the first place. I'd be happy to produce a different function as a reference implementation, but it seemed that there was sufficient demand in the past that this was a useful example. If the consensus is that contrib/showguc (renamed, see below) is a bad idea, then I'll come up with something else. Also, the first place this sort of material should go is the documentation, not hidden somewhere in contrib. No doubt, and there *will* be documentation. I was waiting for the API and example to stabilize a bit first. There is no sense in documenting a moving target. In any case, please don't expose the name GUC to user space. OK. If I replace user space references to GUC with something more palatable, are the guc.c and guc.h changes at least acceptable? With them, user functions can at least read configuration variables. GUC variables are inaccessible otherwise. Please let me know the desired direction for this, and I'll adjust accordingly. Thanks, Joe ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
[HACKERS] COPY syntax improvement
I am working on the TODO item:
o Change syntax to WITH DELIMITER, (keep old syntax around?)
and I have added syntax so COPY can now accept all parameters at the end
using WITH:
COPY table
FROM { 'filename' | stdin }
[ [ WITH ]
[ BINARY ]
[ OIDS ]
[ DELIMITER 'delimiter' ]
[ NULL AS 'null string' ] ]
(COPY TO is similar.)
For portability, it still supports the old syntax of BINARY after COPY,
WITH OIDS after 'table' and USING DELIMITERS after 'filename'. I have
sent the patch to the patches list.
I have not modified pg_dump so that 7.3 dumps can be loaded into =7.2
databases. I have modified psql \copy to _only_ use the new syntax, and
to only send the new syntax to the backends. (We don't usually support
new psql in to older databases anyway.) Not sure if I should document
the old syntax somewhere because pg_dump uses WITH OIDS with the old
syntax.
I have not applied the patch. I am waiting for comments.
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED] | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup.| Drexel Hill, Pennsylvania 19026
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
