[HACKERS] Version-aware psql?
Kind people, I've been digging through the CVS code and trying to figure out the best approach to making one psql that does the right thing for different versions of the back-end. This has come up in a real situation already, where the dev box is 7.3.3 and the production box is (Yikes!) 7.2.1. Connecting from the 7.3.3 side results in a lot of stuff like this: Password: ERROR: parser: parse error at or near . Welcome to psql 7.3.3, the PostgreSQL interactive terminal. Type: \copyright for distribution terms \h for help with SQL commands \? for help on internal slash commands \g or terminate with semicolon to execute query \q to quit template1= \dt ERROR: parser: parse error at or near . template1= Luckily, it works (so far) ok going from 7.2.1 - 7.3.3, though. So which files need consideration to make this reasonably seamless? Are they all in src/bin/psql, or are there others elsewhere that should know? I'm wondering if maybe the Right Thing(TM) might be for all connections to return (optionally?) the version number, but that seems like a giant project with many backward-compatibility snags attached. TIA for any tips, hints or pointers on this :) Cheers, D -- David Fetter [EMAIL PROTECTED] http://fetter.org/ phone: +1 510 893 6100cell: +1 415 235 3778 ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] Version-aware psql?
I'm wondering if maybe the Right Thing(TM) might be for all connections to return (optionally?) the version number, but that seems like a giant project with many backward-compatibility snags attached. I think it would be for psql to check the connection version and then load a shared library containing the implementation of all its functions for that particular database version... Chris ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] 7.4 Pkgconfig
Bruce Momjian writes: Does anyone know anything about pkgconfig? It's basically a generalized version of pg_config and similar tools that works out of a centralized database. I'm not convinced that it solves any real problems without introducing new ones. The idea is alright, but I'm not eager to support pkg-config just to support it. -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] contrib compilation probs
Tom Lane writes: gcc -pipe -O -g -Wall -Wmissing-prototypes -Wmissing-declarations -fpic -DPI C -I. -I. -I./snowball -I./ispell -I./wordparser -I../../src/include -c -o snowball/english_stem.o snowball/english_stem.c -MMD cp: snowball/english_stem.d: No such file or directory gmake[1]: *** [snowball/english_stem.o] Error 1 No idea about this; it doesn't happen here. Anyone? These files are created when --enable-depend is on. The problem appears to be that the Makefile is trying to create files in a directory not its own. You cannot do that; it creates all kinds of problems in complex installation setups. -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] Another nasty pg_dump problem
Tom Lane writes: I've repaired this in CVS tip. While testing it, though, I notice that CVS-tip pg_dump puts out useless commands REVOKE ALL ON SCHEMA public FROM PUBLIC; GRANT ALL ON SCHEMA public TO PUBLIC; which are not generated when dumping from 7.3. The reason evidently is that this check in pg_dump.c no longer works: This could be fixed, but note that elsewhere we use /* * Always start with REVOKE ALL FROM PUBLIC, so that we don't have to * wire-in knowledge about the default public privileges for different * kinds of objects. */ appendPQExpBuffer(firstsql, REVOKE ALL ON %s %s FROM PUBLIC;\n, type, name); So maybe this isn't such a bad state after all. -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
[HACKERS] ECPG: 7.4 and a to Variable
Guys, looking at ecpg from CVS HEAD's 7.4. The following code
fragement:
EXEC SQL INCLUDE sqlca;
EXEC SQL WHENEVER SQLERROR call sqlprint;
void lofsdb_GetMinMaxRxStations(int *from, int *to)
{
EXEC SQL BEGIN DECLARE SECTION;
int l_from = 0;
int l_to = 0;
EXEC SQL END DECLARE SECTION;
*from = 0;
*to = 0;
EXEC SQL BEGIN;
EXEC SQL SELECT MIN(from_station), MAX(to_station)
INTO :l_from, :l_to
FROM attr_tables
WHERE basetab LIKE 'attr_rx_%';
if( sqlca.sqlcode == 0 )
{
*from = l_from;
*to = l_to;
}
EXEC SQL COMMIT;
}
when processed using:
/var/lib/pgsql/74b/bin/ecpg -t -I/var/lib/pgsql/74b/include -o x.c x.pc
results in the following error:
x.pc:4: ERROR: syntax error at or near to
However this works ok on 7.3.x and when the to variable is renamed
(e.g. to to_rx). Obviously TO is an SQL keyword, but it's not being
used within an EXEC SQL definition, so shouldn't break things.
Regards, Lee.
---(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: 7.4 and a to Variable
On Fri, Aug 01, 2003 at 12:06:07PM +0100, Lee Kindness wrote: Guys, looking at ecpg from CVS HEAD's 7.4. The following code fragement: ... Fix just committed. Should work now. Michael -- Michael Meskes Email: Michael at Fam-Meskes dot De ICQ: 179140304, AIM: 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: [HACKERS] SQLSTATEs for warnings
Tom Lane writes: Peter Eisentraut [EMAIL PROTECTED] writes: In other words, an info, notice, or warning must have a class 00, 01, 02. I suspect though that the spec is assuming that the SQLSTATE code is the *only* way for the application to determine whether the message is success, warning, or error. Since we have other signaling mechanisms (the severity field, or even more basically the Error/Notice message type distinction), I'm not convinced we need to be entirely anal about this division. The severity field is useless, because it contains localized text that cannot be evaluated by a program. Also, neither the severity field nor the error/notice message distinction is necessarily available in interfaces that work at a layer above libpq (e.g., embedded SQL). There is no portable (let alone consistent) way right now to detect whether a given condition is success, a warning, or an error. AFAICS the alternative to misusing error-class SQLSTATEs as warnings is that we invent implementation-specific warning codes. I don't see that as being allowed. Is it really worth having two codes for what amounts to the same condition? The same condition shouldn't be a warning in one place and an error in another. Otherwise it's not really the same condition. -- Peter Eisentraut [EMAIL PROTECTED] ---(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: [HACKERS] Another nasty pg_dump problem
Peter Eisentraut [EMAIL PROTECTED] writes:
This could be fixed, but note that elsewhere we use
/*
* Always start with REVOKE ALL FROM PUBLIC, so that we don't have to
* wire-in knowledge about the default public privileges for different
* kinds of objects.
*/
appendPQExpBuffer(firstsql, REVOKE ALL ON %s %s FROM PUBLIC;\n,
type, name);
So maybe this isn't such a bad state after all.
Well, if you want to take that position then the test for {=UC} ought
to be ripped out, so that we are consistent about it across backend
versions.
regards, tom lane
---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] SQLSTATEs for warnings
Peter Eisentraut [EMAIL PROTECTED] writes: Tom Lane writes: I suspect though that the spec is assuming that the SQLSTATE code is the *only* way for the application to determine whether the message is success, warning, or error. The severity field is useless, because it contains localized text that cannot be evaluated by a program. Fair point. Also, neither the severity field nor the error/notice message distinction is necessarily available in interfaces that work at a layer above libpq (e.g., embedded SQL). An interface library would have to really go out of its way to make errors and notices look alike, at least if it's built atop libpq. I think this argument is pretty weak. But you're right about severity. AFAICS the alternative to misusing error-class SQLSTATEs as warnings is that we invent implementation-specific warning codes. I don't see that as being allowed. Hm? Surely we can invent implementation-defined warning codes in the ranges 015xx-019xx and 01Ixx-01Zxx. If not, what other alternative do you propose? regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
[HACKERS] Fwd: Re: [ANNOUNCE] PostgreSQL Weekly News - July 30th 2003
Hey Thierry,
I'm forwarding this on to the hackers group to see if we can get an
authoritative answer, as you don't want to rely on my fuzzy memory. :-)
Anyone know the scoop on this?
Robert Treat
-- Forwarded Message --
Subject: Re: [ANNOUNCE] PostgreSQL Weekly News - July 30th 2003
Date: Thursday 31 July 2003 03:24
From: Thierry Missimilly [EMAIL PROTECTED]
To: Robert Treat [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Hi,
Nothing is said about Multi-threaded use of SQLCA in 7.4.
I have developed a pgBench in PRO*C with each Client symbolized by a User
Thread. It runs on Oracle 9i but, on PostgreSQL, it crashes or hang after a
while due to the the fact that the Postgres ProC 7.3.2 isn't thread-safe.
I have read in the TODO list that SQLCA is planed to be Thread_Safe in 7.4.
Will it be ?
Thierry
Robert Treat wrote:
== PostgreSQL Weekly News - July 30th 2003 ==
--
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
---(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: [HACKERS] Version-aware psql?
David Fetter [EMAIL PROTECTED] writes: I'm wondering if maybe the Right Thing(TM) might be for all connections to return (optionally?) the version number, but that seems like a giant project with many backward-compatibility snags attached. Already done, see PQparameterStatus at http://developer.postgresql.org/docs/postgres/libpq-status.html regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] contrib compilation probs
Peter Eisentraut [EMAIL PROTECTED] writes: These files are created when --enable-depend is on. The problem appears to be that the Makefile is trying to create files in a directory not its own. You cannot do that; it creates all kinds of problems in complex installation setups. I was afraid it was something like that. Can we leave the directory structure as-is and just make the .o (and .d) files get built in the upper directory, that is gcc ... -o english_stem.o snowball/english_stem.c ? Or must we go the full nine yards and make sub-Makefiles in the subdirectories? regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] python interface
What date was the move? I can get you a diff. --- D'Arcy J.M. Cain wrote: On Friday 01 August 2003 00:41, Tom Lane wrote: Marc G. Fournier [EMAIL PROTECTED] writes: Somehow, when we moved it to gborg way back, the 'cvs remove' wasn't done on the mail repository ... there ... cvs remove'd now, so its still part of v7.3.x, but no longer part of v7.4 ... According to the CVS logs, there were several patches applied to src/interfaces/python in the last few months. Somebody should make sure that all of those got propagated to the gborg project (or at least considered and rejected...) Actually, we tried using gborg and ran into problems. Gborg should now just be a redirect to http://www.PyGreSQL.org/ which will be updated shortly. For those that missed the announcement, PyGreSQL and PoPy have merged projects and we are running the combined project from my system. We moved it from the PostgreSQL site at Bruce and Tom's suggestion so that we could add more people with access. If there are any known updates since the move you can send them directly to me or to the mailing list at [EMAIL PROTECTED] -- D'Arcy J.M. Cain PyGreSQL Development Group http://www.PyGreSQL.org -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Fwd: Re: [ANNOUNCE] PostgreSQL Weekly News - July 30th
Yes, ecpg will be thread-safe in 7.4.
---
Robert Treat wrote:
Hey Thierry,
I'm forwarding this on to the hackers group to see if we can get an
authoritative answer, as you don't want to rely on my fuzzy memory. :-)
Anyone know the scoop on this?
Robert Treat
-- Forwarded Message --
Subject: Re: [ANNOUNCE] PostgreSQL Weekly News - July 30th 2003
Date: Thursday 31 July 2003 03:24
From: Thierry Missimilly [EMAIL PROTECTED]
To: Robert Treat [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Hi,
Nothing is said about Multi-threaded use of SQLCA in 7.4.
I have developed a pgBench in PRO*C with each Client symbolized by a User
Thread. It runs on Oracle 9i but, on PostgreSQL, it crashes or hang after a
while due to the the fact that the Postgres ProC 7.3.2 isn't thread-safe.
I have read in the TODO list that SQLCA is planed to be Thread_Safe in 7.4.
Will it be ?
Thierry
Robert Treat wrote:
== PostgreSQL Weekly News - July 30th 2003 ==
--
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
---(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
--
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 8: explain analyze is your friend
Re: [HACKERS] ACCESSING POST GRESQL DATABASE THRU MFCOBOL
On Tue, 29 Jul 2003, vajjhala chakravarthi wrote: HI I am running MFcobol on a linux machine which is having Postgresql. can I access pgsql database thru mfcobol. If it is possible where can I get odbc drivers and what is the procedure help me ODBC driver is available here: http://gborg.postgresql.org/project/psqlodbc/projdisplay.php I'm not sure what to do after installing it though. COBOL is not a language I've ever programmed in. ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] contrib compilation probs
Tom Lane writes: I was afraid it was something like that. Can we leave the directory structure as-is and just make the .o (and .d) files get built in the upper directory, that is gcc ... -o english_stem.o snowball/english_stem.c That will fail for a more basic reason: not all compilers support the -o option. -- Peter Eisentraut [EMAIL PROTECTED] ---(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] python interface
On Friday 01 August 2003 00:41, Tom Lane wrote: Marc G. Fournier [EMAIL PROTECTED] writes: Somehow, when we moved it to gborg way back, the 'cvs remove' wasn't done on the mail repository ... there ... cvs remove'd now, so its still part of v7.3.x, but no longer part of v7.4 ... According to the CVS logs, there were several patches applied to src/interfaces/python in the last few months. Somebody should make sure that all of those got propagated to the gborg project (or at least considered and rejected...) Actually, we tried using gborg and ran into problems. Gborg should now just be a redirect to http://www.PyGreSQL.org/ which will be updated shortly. For those that missed the announcement, PyGreSQL and PoPy have merged projects and we are running the combined project from my system. We moved it from the PostgreSQL site at Bruce and Tom's suggestion so that we could add more people with access. If there are any known updates since the move you can send them directly to me or to the mailing list at [EMAIL PROTECTED] -- D'Arcy J.M. Cain PyGreSQL Development Group http://www.PyGreSQL.org ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
[HACKERS] cvs head compile failure
I'm getting an ecpg related compile failure on cvs tip: gcc -O2 -g -Wall -Wmissing-prototypes -Wmissing-declarations -fpic -I../../../../src/interfaces/ecpg/include -I../../../../src/include/utils -I../../../../src/include -g -c -o timestamp.o timestamp.c -MMD timestamp.c: In function `dttofmtasc_replace': timestamp.c:549: union has no member named `replace_int64' make[4]: *** [timestamp.o] Error 1 make[4]: Leaving directory `/opt/src/pgsql/src/interfaces/ecpg/pgtypeslib' Joe ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] cvs head compile failure
Joe Conway wrote: I'm getting an ecpg related compile failure on cvs tip: gcc -O2 -g -Wall -Wmissing-prototypes -Wmissing-declarations -fpic -I../../../../src/interfaces/ecpg/include -I../../../../src/include/utils -I../../../../src/include -g -c -o timestamp.o timestamp.c -MMD timestamp.c: In function `dttofmtasc_replace': timestamp.c:549: union has no member named `replace_int64' make[4]: *** [timestamp.o] Error 1 make[4]: Leaving directory `/opt/src/pgsql/src/interfaces/ecpg/pgtypeslib' Looks like a simple matter of replacing replace_int64 with int64_val at line 549 in src/interfaces/ecpg/pgtypeslib/timestamp.c Joe Index: src/interfaces/ecpg/pgtypeslib/timestamp.c === RCS file: /opt/src/cvs/pgsql-server/src/interfaces/ecpg/pgtypeslib/timestamp.c,v retrieving revision 1.11 diff -c -r1.11 timestamp.c *** src/interfaces/ecpg/pgtypeslib/timestamp.c 1 Aug 2003 08:21:04 - 1.11 --- src/interfaces/ecpg/pgtypeslib/timestamp.c 1 Aug 2003 17:57:11 - *** *** 546,552 break; case 's': #ifdef HAVE_INT64_TIMESTAMP ! replace_val.replace_int64 = ((*ts - SetEpochTimestamp()) / 100e0); replace_type = PGTYPES_TYPE_INT64; #else replace_val.double_val = *ts - SetEpochTimestamp(); --- 546,552 break; case 's': #ifdef HAVE_INT64_TIMESTAMP ! replace_val.int64_val = ((*ts - SetEpochTimestamp()) / 100e0); replace_type = PGTYPES_TYPE_INT64; #else replace_val.double_val = *ts - SetEpochTimestamp(); ---(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
[HACKERS] PostgreSQL on OS/400 and/or LPAR?
Hackers, Does anyone know if we've been ported to OS/400, ever? And/or does anyone have any experience with Postgres on Linux LPAR (IBM iSeries)? -- Josh Berkus Aglio Database Solutions San Francisco ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] cvs head compile failure
On Fri, Aug 01, 2003 at 10:22:59AM -0700, Joe Conway wrote: Looks like a simple matter of replacing replace_int64 with int64_val at line 549 in src/interfaces/ecpg/pgtypeslib/timestamp.c Yes, it is. Thanks. I didn't have HAVE_INT64_TIMESTAMP defined. In fact there's another one in common.c with an incorrect #define. It's fixed now. Michael -- Michael Meskes Email: Michael at Fam-Meskes dot De ICQ: 179140304, AIM: michaelmeskes, Jabber: [EMAIL PROTECTED] Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL! ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
[HACKERS] Upcoming Release of PostgreSQL, Inc's erserver v1.2 ...
We (PostgreSQL, Inc) are just in the process of tying up some loose ends on eRServer v1.2, to be released OSS on GBorg over the next week or so ... since this is meant to replace rserv, I'd like to remove rserv from the v7.4 source tree ... As far as I know, the only patch made to rserv in the distribution was to extend it to do multi-slave, which eRServer v1.2 already does, *but* eRServer re-wrote rserv in Java, vs perl as it was originally ... Is there anyone actually using rserv who would be adverse to my removing it from the source tar ball? Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy Systems Administrator @ hub.org primary: [EMAIL PROTECTED] secondary: [EMAIL PROTECTED]|postgresql}.org ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] Upcoming Release of PostgreSQL, Inc's erserver v1.2
On Fri, 2003-08-01 at 14:46, The Hermit Hacker wrote:
We (PostgreSQL, Inc) are just in the process of tying up some loose ends
on eRServer v1.2, to be released OSS on GBorg over the next week or so ...
since this is meant to replace rserv, I'd like to remove rserv from the
v7.4 source tree ...
As far as I know, the only patch made to rserv in the distribution was to
extend it to do multi-slave, which eRServer v1.2 already does, *but*
eRServer re-wrote rserv in Java, vs perl as it was originally ...
Is there anyone actually using rserv who would be adverse to my removing
it from the source tar ball?
I'm not actually using it, but I'd be adverse to removing from 7.4 if
only for the fact that their code bases are substantially different and
we have at least a few known users. It seems like it would be much
better to add to the rserv.README information about the rserv gborg
project and note that, unless there is substantial development it will
most likely be dropped from 7.5, perhaps moved to it's own gborg
project.
Robert Treat
--
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
---(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: [HACKERS] Upcoming Release of PostgreSQL, Inc's erserver v1.2
Robert Treat [EMAIL PROTECTED] writes: On Fri, 2003-08-01 at 14:46, The Hermit Hacker wrote: Is there anyone actually using rserv who would be adverse to my removing it from the source tar ball? I'm not actually using it, but I'd be adverse to removing from 7.4 if only for the fact that their code bases are substantially different and we have at least a few known users. I could be wrong about this, but I had the idea that contrib/rserv was already somewhat broken in 7.3, for lack of schema support. Is there anyone actually using it with 7.3? regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] python interface
gborg has the cvs access, bugs, features, etc. listed for the pygresql project. The website link on the gborg page does point to PyGreSQL.org, however. Will these auxilliary links be available from gborg or are you going to manage it all from PyGreSQL.org? In otherwords, if someone is looking for the interface, where is the best place to point them? I'm asking because most projects are accessible to gborg and I think at minimum the link to the project should be maintained. People should be able to cruise gborg and find pygresql easily. But if the cvs access, bugs, features, etc. are not on gborg, those links should be moved or redirected to the proper page on pygresql.org. Also so people can find them more easily. elein On Fri, Aug 01, 2003 at 06:56:35AM -0400, D'Arcy J.M. Cain wrote: On Friday 01 August 2003 00:41, Tom Lane wrote: Marc G. Fournier [EMAIL PROTECTED] writes: Somehow, when we moved it to gborg way back, the 'cvs remove' wasn't done on the mail repository ... there ... cvs remove'd now, so its still part of v7.3.x, but no longer part of v7.4 ... According to the CVS logs, there were several patches applied to src/interfaces/python in the last few months. Somebody should make sure that all of those got propagated to the gborg project (or at least considered and rejected...) Actually, we tried using gborg and ran into problems. Gborg should now just be a redirect to http://www.PyGreSQL.org/ which will be updated shortly. For those that missed the announcement, PyGreSQL and PoPy have merged projects and we are running the combined project from my system. We moved it from the PostgreSQL site at Bruce and Tom's suggestion so that we could add more people with access. If there are any known updates since the move you can send them directly to me or to the mailing list at [EMAIL PROTECTED] -- D'Arcy J.M. Cain PyGreSQL Development Group http://www.PyGreSQL.org ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster ---(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
[HACKERS] IPv6 in pg_hba.conf.sample fails here
Testing a connection that should fail (for lack of pg_hba entry): $ psql -h sss2 tgl psql: FATAL: missing or erroneous pg_hba.conf file HINT: See postmaster log for details. $ Say what? This is with a completely default pg_hba.conf file... looking in the postmaster log as suggested: LOG: could not interpret IP address ::1 in config file: Unknown server error LOG: invalid entry in pg_hba.conf file at line 55, token ::1 FATAL: missing or erroneous pg_hba.conf file HINT: See postmaster log for details. In short, it will not do to put IPv6 addresses into pg_hba.conf by default on machines where IPv6 support is not present. While we could gin up some mechanism to adjust the installed copy of pg_hba.conf.sample depending on whether we detected IPv6 support, I am inclined to simply remove or comment out the IPv6-specific entry in the sample file. I doubt that many people actually need it, and the ones who do can just adjust the sample file. Comments? regards, tom lane ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] IPv6 in pg_hba.conf.sample fails here
Yeah, I'd be very surprised if many need it, and those who do can uncomment it. I think commenting it out is the right thing (tm). andrew Tom Lane wrote: Testing a connection that should fail (for lack of pg_hba entry): $ psql -h sss2 tgl psql: FATAL: missing or erroneous pg_hba.conf file HINT: See postmaster log for details. $ Say what? This is with a completely default pg_hba.conf file... looking in the postmaster log as suggested: LOG: could not interpret IP address ::1 in config file: Unknown server error LOG: invalid entry in pg_hba.conf file at line 55, token ::1 FATAL: missing or erroneous pg_hba.conf file HINT: See postmaster log for details. In short, it will not do to put IPv6 addresses into pg_hba.conf by default on machines where IPv6 support is not present. While we could gin up some mechanism to adjust the installed copy of pg_hba.conf.sample depending on whether we detected IPv6 support, I am inclined to simply remove or comment out the IPv6-specific entry in the sample file. I doubt that many people actually need it, and the ones who do can just adjust the sample file. Comments? regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Upcoming Release of PostgreSQL, Inc's erserver v1.2
On Fri, 2003-08-01 at 15:29, Tom Lane wrote:
Robert Treat [EMAIL PROTECTED] writes:
On Fri, 2003-08-01 at 14:46, The Hermit Hacker wrote:
Is there anyone actually using rserv who would be adverse to my removing
it from the source tar ball?
I'm not actually using it, but I'd be adverse to removing from 7.4 if
only for the fact that their code bases are substantially different and
we have at least a few known users.
I could be wrong about this, but I had the idea that contrib/rserv was
already somewhat broken in 7.3, for lack of schema support. Is there
anyone actually using it with 7.3?
Wasn't Michael Nachbur's recent patch for comment written against 7.3?
It seemed to apply cleanly enough, though I don't know for sure if he
was running this against 7.3... Michael, can you confirm?
Robert Treat
--
Build A Brighter Lamp :: Linux Apache {middleware} 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] IPv6 in pg_hba.conf.sample fails here
Agreed. I wanted to put the ipv6 entry in there only if they compiled with ipv6 suport, but that seemed strange to some, I think. I would comment it out. --- Andrew Dunstan wrote: Yeah, I'd be very surprised if many need it, and those who do can uncomment it. I think commenting it out is the right thing (tm). andrew Tom Lane wrote: Testing a connection that should fail (for lack of pg_hba entry): $ psql -h sss2 tgl psql: FATAL: missing or erroneous pg_hba.conf file HINT: See postmaster log for details. $ Say what? This is with a completely default pg_hba.conf file... looking in the postmaster log as suggested: LOG: could not interpret IP address ::1 in config file: Unknown server error LOG: invalid entry in pg_hba.conf file at line 55, token ::1 FATAL: missing or erroneous pg_hba.conf file HINT: See postmaster log for details. In short, it will not do to put IPv6 addresses into pg_hba.conf by default on machines where IPv6 support is not present. While we could gin up some mechanism to adjust the installed copy of pg_hba.conf.sample depending on whether we detected IPv6 support, I am inclined to simply remove or comment out the IPv6-specific entry in the sample file. I doubt that many people actually need it, and the ones who do can just adjust the sample file. Comments? regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
[HACKERS] 7.4 COPY BINARY Format Change
Guys,
I've been testing 7.4 against an application today. Recompiled
everything against the new libraries. However the application includes
code which builds up a bulkload file in the documented 7.1 format. The
documentation for COPY goes on at length about the format being
forward compatible...
However of course it's changed in 7.4 for the following minor reasons:
1. Header is now PGCOPY\n\377\r\n\0 rather than PGBCOPY\n\377\r\n\0
2. Integers within the header (but not the data itself) are now in
network order, rather than native order
3. The integer layout field has disappeared.
4. typlen is now an int32 rather than an int16 plus an additional
int32 if a varlen type.
I've attached a patch which lets COPY read in the 7.1 format. However
i'm not convinced this is the right way to go - I think the format
which is output by 7.4 should be identical to the 7.1 format. The
integer layout field could be used to determine if byteswapping is
required on reading. The other changes seem to be unnecessary? If the
typlen change is kept it should be flagged in the flags field rather
than requiring a completely new format - this would allow old readers
to gracefully fail and old new files to be read in by 7.4...
It's extremely counter-productive to break backward compatibility for
such whimsical changes! This will hurt those updating to 7.4 once it
is released...
So, I expect the patch below to be rejected - I'll happily rework the
patch to revert 7.4 to a version of the 7.1 format which results in
the same feature gain but without forfeiting backward
compatibility. Let me know.
Thanks. Lee.
Index: src/backend/commands/copy.c
===
RCS file: /projects/cvsroot/pgsql-server/src/backend/commands/copy.c,v
retrieving revision 1.205
diff -c -b -r1.205 copy.c
*** src/backend/commands/copy.c 1 Aug 2003 00:15:19 - 1.205
--- src/backend/commands/copy.c 1 Aug 2003 14:53:35 -
***
*** 91,102
static void CopyFrom(Relation rel, List *attnumlist, bool binary, bool oids,
char *delim, char *null_print);
static char *CopyReadAttribute(const char *delim, CopyReadResult *result);
! static Datum CopyReadBinaryAttribute(int column_no, FmgrInfo *flinfo,
!Oid typelem,
bool *isnull);
static void CopyAttributeOut(char *string, char *delim);
static List *CopyGetAttnums(Relation rel, List *attnamelist);
! static const char BinarySignature[11] = PGCOPY\n\377\r\n\0;
/*
* Static communication variables ... pretty grotty, but COPY has
--- 91,107
static void CopyFrom(Relation rel, List *attnumlist, bool binary, bool oids,
char *delim, char *null_print);
static char *CopyReadAttribute(const char *delim, CopyReadResult *result);
! static Datum CopyReadBinaryAttribute(int version, int column_no,
!FmgrInfo *flinfo, Oid typelem,
!bool *isnull);
static void CopyAttributeOut(char *string, char *delim);
static List *CopyGetAttnums(Relation rel, List *attnamelist);
! static const char BinarySignature74[11] = PGCOPY\n\377\r\n\0;
! static const char BinarySignature71[12] = PGBCOPY\n\377\r\n\0;
! #define BINARY_FMT_74x 740
! #define BINARY_FMT_71x 710
! #define BINARY_FMT_CUR BINARY_FMT_74x
/*
* Static communication variables ... pretty grotty, but COPY has
***
*** 140,148
static intCopyPeekChar(void);
static void CopyDonePeek(int c, bool pickup);
static void CopySendInt32(int32 val);
! static int32 CopyGetInt32(void);
static void CopySendInt16(int16 val);
! static int16 CopyGetInt16(void);
/*
* Send copy start/stop messages for frontend copies. These have changed
--- 145,153
static intCopyPeekChar(void);
static void CopyDonePeek(int c, bool pickup);
static void CopySendInt32(int32 val);
! static int32 CopyGetInt32(int version);
static void CopySendInt16(int16 val);
! static int16 CopyGetInt16(int version);
/*
* Send copy start/stop messages for frontend copies. These have changed
***
*** 571,581
* CopyGetInt32 reads an int32 that appears in network byte order
*/
static int32
! CopyGetInt32(void)
{
uint32 buf;
CopyGetData(buf, sizeof(buf));
return (int32) ntohl(buf);
}
--- 576,589
* CopyGetInt32 reads an int32 that appears in network byte order
*/
static int32
! CopyGetInt32(int version)
{
uint32 buf;
CopyGetData(buf, sizeof(buf));
+ if( version == BINARY_FMT_71x )
+ return buf;
+ else
return (int32) ntohl(buf);
}
***
*** 595,605
* CopyGetInt16 reads an int16 that appears in network byte order
*/
static int16
! CopyGetInt16(void)
{
uint16 buf;
Re: [HACKERS] 7.4 COPY BINARY Format Change
Lee Kindness [EMAIL PROTECTED] writes: I've attached a patch which lets COPY read in the 7.1 format. However i'm not convinced this is the right way to go - I think the format which is output by 7.4 should be identical to the 7.1 format. You are greatly underestimating the changes that occurred in COPY BINARY. If the format difference had been as minor as you think, I would not have gratuitously broken compatibility. The real change that occurred here is that the individual data fields go through per-datatype send/receive routines, which in addition to implementing a mostly machine-independent binary format also provide defenses against bad input data. To continue to read the old COPY BINARY format, we'd have to bypass those routines and allow direct read of the internal data formats. This was a security risk before and would be a much bigger one now, seeing that we allow COPY BINARY FROM STDIN to unprivileged users. It is trivial to crash the backend by feeding it bad internal-format data. (I don't believe that the patch works anyway, given that you aren't doing anything to disable use of the per-datatype receive routine. It might work as-is for text fields, and for integers on bigendian machines, but not for much else.) We are not going back to the pre-7.4 format. Sorry. regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] IPv6 in pg_hba.conf.sample fails here
Bruce Momjian [EMAIL PROTECTED] writes: Agreed. I wanted to put the ipv6 entry in there only if they compiled with ipv6 suport, but that seemed strange to some, I think. I would comment it out. Done. regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] pg_dump ordering
At 11:44 AM 1/08/2003 +0800, Christopher Kings-Lynne wrote: What I'd like to see it do is grab the dependency data in pg_depend and do a topological sort using that. At the end though, we'd need to dump stuff not caught be the topsort, for cases where pg_depend has been messed with. I have made a start of this (months ago), but have not had a chance to get back to it. I you are interested I can send my design plans etc. Or I could try to get back to it, depending on how interested you are in doing the work. In terms of the dependency data, I was planning to dump dependencies as well (a trivial skeleton exists); the ordering should happen at restore-time (except dump should store it in useful-order on the assumption that it will not be possible to re-order at restore-time). This is important since we need to allow requests like: restore table xyz and it's dependencies from a full dump Philip Warner| __---_ Albatross Consulting Pty. Ltd. |/ - \ (A.B.N. 75 008 659 498) | /(@) __---_ Tel: (+61) 0500 83 82 81 | _ \ Fax: (+61) 03 5330 3172 | ___ | Http://www.rhyme.com.au |/ \| |---- PGP key available upon request, | / and from pgp5.ai.mit.edu:11371 |/ ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
[HACKERS] psql \encoding fixed
Does the new protocol fix the fact that psql \encoding doesn't see SET CLIENT_ENCODING changes. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
[HACKERS] granularity of locking
what determines what level of locking(table level, page level or row level) an object is locked in? how do we determine from postgresql code what level a object is locked in? Iam working on a project where i have to display the locks information of all the transactions that have acquired locks in postgresql and i also have to display that granularity(table level, page level, row level)on the locks acquired by these transactions on objects.Which part of postgresql code gives this information.? thanks Jenny _ MSN 8 with e-mail virus protection service: 2 months FREE* http://join.msn.com/?page=features/virus ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
[HACKERS] OSDL DBT-2 for PostgreSQL
Hi everyone, I've just got our DBT-2 workload (TPC-C derivate) working with PostgreSQL using C stored functions and libpq. I'd love to get some feedback. v0.10 is available on SourceForge at: http://prdownloads.sourceforge.net/osdldbt/dbt2-v0.10.tar.gz?download We keep the source in BitKeeper at: bk://developer.osdl.org/dbt2 For anyone interested in more discussion on our workloads, we have a mailing list setup at: [EMAIL PROTECTED] -- Mark Wong - - [EMAIL PROTECTED] Open Source Development Lab Inc - A non-profit corporation 12725 SW Millikan Way - Suite 400 - Beaverton, OR 97005 (503)-626-2455 x 32 (office) (503)-626-2436 (fax) http://www.osdl.org/archive/markw/ ---(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: [HACKERS] OSDL DBT-2 for PostgreSQL
Mark, I've just got our DBT-2 workload (TPC-C derivate) working with PostgreSQL using C stored functions and libpq. I'd love to get some feedback. I'm confused. Jenny Zhang just announced OSDL-DBT3 for Postgres; is this a different test or does one of you have the name wrong? -- -Josh Berkus Aglio Database Solutions San Francisco ---(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: [HACKERS] OSDL DBT-2 for PostgreSQL
On Fri, Aug 01, 2003 at 05:05:18PM -0700, Josh Berkus wrote: Mark, I've just got our DBT-2 workload (TPC-C derivate) working with PostgreSQL using C stored functions and libpq. I'd love to get some feedback. I'm confused. Jenny Zhang just announced OSDL-DBT3 for Postgres; is this a different test or does one of you have the name wrong? Yeah, this is a different test. DBT-3 is based on the TPC-H and DBT-2 is based on the TPC-C. Mark ---(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] OSDL DBT-2 for PostgreSQL
On Fri, 2003-08-01 at 20:32, Mark Wong wrote: On Fri, Aug 01, 2003 at 05:05:18PM -0700, Josh Berkus wrote: Mark, I've just got our DBT-2 workload (TPC-C derivate) working with PostgreSQL using C stored functions and libpq. I'd love to get some feedback. I'm confused. Jenny Zhang just announced OSDL-DBT3 for Postgres; is this a different test or does one of you have the name wrong? Yeah, this is a different test. DBT-3 is based on the TPC-H and DBT-2 is based on the TPC-C. Josh, All 3 (DBT-1 is another style of test) should be included into the benchmark kit. It should be noted that the DBT tests are fairly linux specific at the moment, though that doesn't take much to change. OSDL has been happy to take portability patches. signature.asc Description: This is a digitally signed message part
Re: [HACKERS] psql \encoding fixed
Bruce Momjian [EMAIL PROTECTED] writes: Does the new protocol fix the fact that psql \encoding doesn't see SET CLIENT_ENCODING changes. regression=# \encoding SQL_ASCII regression=# set client_encoding TO unicode; SET regression=# \encoding UNICODE regression=# regards, tom lane ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] psql \encoding fixed
OK, psql docs updated to remove mention of that problem. --- Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: Does the new protocol fix the fact that psql \encoding doesn't see SET CLIENT_ENCODING changes. regression=# \encoding SQL_ASCII regression=# set client_encoding TO unicode; SET regression=# \encoding UNICODE regression=# regards, tom lane ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings -- 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 8: explain analyze is your friend
Re: [HACKERS] psql \encoding fixed
Bruce Momjian [EMAIL PROTECTED] writes: OK, psql docs updated to remove mention of that problem. They already were, I thought. regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] pg_dump ordering
Philip Warner [EMAIL PROTECTED] writes: In terms of the dependency data, I was planning to dump dependencies as well (a trivial skeleton exists); the ordering should happen at restore-time (except dump should store it in useful-order on the assumption that it will not be possible to re-order at restore-time). ISTM that once we have the dependency problem sorted out, the important ordering will always happen during dump, and the facility for re-ordering during restore will become vestigial. This is a good thing, since there are many scenarios where you can't seek backwards. This is important since we need to allow requests like: restore table xyz and it's dependencies from a full dump Right. What will be needed instead will be the ability to know when we are passing over object X in the dump that we must restore it, because the object Y that we were asked to restore depends directly or indirectly on it. So all the dependency info must appear at the front. regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] psql \encoding fixed
Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: OK, psql docs updated to remove mention of that problem. They already were, I thought. It was still mentioned in the psql manual page. I know because I added it in 7.3, and it was still there. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] pg_dump ordering
At 11:07 PM 1/08/2003 -0400, Tom Lane wrote: So all the dependency info must appear at the front. Correct. It currently gets stored in the TOC, which is at the front, and is read into memory at the start of the restore process. Philip Warner| __---_ Albatross Consulting Pty. Ltd. |/ - \ (A.B.N. 75 008 659 498) | /(@) __---_ Tel: (+61) 0500 83 82 81 | _ \ Fax: (+61) 03 5330 3172 | ___ | Http://www.rhyme.com.au |/ \| |---- PGP key available upon request, | / and from pgp5.ai.mit.edu:11371 |/ ---(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
