Re: [HACKERS] psql: core dumped
Mario wrote: I'd like to help :-) I wanted to avoid a core dumped but you told me that's a normal thing for a SIGQUIT signal. Did you try running `ulimit -c 0` first? That should do what you want - prevent generation of the dump file. Regards, Philip. -- Philip Yarra Senior Software Engineer, Utiba Pty Ltd [EMAIL PROTECTED] ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] psql: core dumped
Mario wrote: Even if you get a core dumped every time you press CTRL+\ ? why? Try ulimit -c 0, then run it (you should get no core dump) Then ulimit -c 50, then run it (you should get a core dump) SIGQUIT is supposed to dump core. Ulimit settings can suppress generation of core files. The difference between your machine and your friend's is likely just the ulimit settings. Regards, Philip. -- Philip Yarra Senior Software Engineer, Utiba Pty Ltd [EMAIL PROTECTED] ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] psql \c error
On Mon, 3 Apr 2006 06:13 am, Neil Conway wrote: I've committed a patch to HEAD that should improve this behavior. Let me know if the current behavior is still unsatisfactory. Yes, thanks, it fixes the stuff that bugged me: [EMAIL PROTECTED] pgsql]$ psql -p5434 -dpyarra [snip opening car chase] pyarra=# \c foo You are now connected to database foo. foo=# \c philip - - 5432 You are now connected to database philip at port 5432. philip=# Regards, Philip. -- Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it. - Brian W. Kernighan - Utiba Pty Ltd This message has been scanned for viruses and dangerous content by Utiba mail server and is believed to be clean. ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Tablespaces oddity?
On Wed, 29 Mar 2006 08:46 am, Philip Yarra wrote: OK, how about on \d+, if the object is not on pg_default or pg_global, print the tablespace that this object is on? That way, people not using tablespaces won't ever see it. Tom, does this answer your objection? If so, I'll produce a patch for it. Regards, Philip. ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] Tablespaces oddity?
On Wed, 29 Mar 2006 08:46 am, Philip Yarra wrote: OK, how about on \d+, if the object is not on pg_default or pg_global, print the tablespace that this object is on? That way, people not using tablespaces won't ever see it. Tom, does this answer your objection? If so, I'll produce a patch for it. Regards, Philip. PS: sorry about duplicate post, accidentally sent from other email account. -- Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it. - Brian W. Kernighan - Utiba Pty Ltd This message has been scanned for viruses and dangerous content by Utiba mail server and is believed to be clean. ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
[HACKERS] psql \c error
Hi folks, I've found that CVS HEAD psql's \c doesn't quite behave as expected when postmaster is listening on non-default port. In this case I have postmaster listening on port 5434: [EMAIL PROTECTED] pgsql]$ /usr/local/pgsql-cvs-head/bin/psql -p5434 -dpyarra Welcome to psql 8.2devel, the PostgreSQL interactive terminal. Type: \copyright for distribution terms \h for help with SQL commands \? for help with psql commands \g or terminate with semicolon to execute query \q to quit pyarra=# \d No relations found. (correct, nothing in DB 'pyarra') pyarra=# \l List of databases Name| Owner | Encoding ---++-- postgres | pyarra | LATIN1 pyarra| pyarra | LATIN1 spctest | pyarra | LATIN1 template0 | pyarra | LATIN1 template1 | pyarra | LATIN1 (5 rows) pyarra=# \c spctest could not connect to server: No such file or directory Is the server running locally and accepting connections on Unix domain socket /tmp/.s.PGSQL.5432? Previous connection kept pyarra=# \c spctest - - 5434 You are now connected to database spctest as user pyarra on host (null) at port 5434. could not connect to server: No such file or directory Is the server running locally and accepting connections on Unix domain socket /tmp/.s.PGSQL.5432? Previous connection kept could not connect to server: No such file or directory Is the server running locally and accepting connections on Unix domain socket /tmp/.s.PGSQL.5432? Previous connection kept spctest=# \d List of relations Schema | Name | Type | Owner +--+---+ public | foo | table | pyarra (1 row) (correct, one table in DB 'spctest') The comments in src/bin/psql/command.c, starting at line 192, indicate the new connection should use the current port (5434) but this is not happening. Also note that when port is explicitly specified (\c spctest - - 5434) it does connect to the new DB on the right port, but still prints a spurious error. The comments further down say default instead of current when the dash is used, so the comments may not be quite right. What behaviour was this change (http://archives.postgresql.org/pgsql-patches/2006-03/msg00154.php) actually supposed to give us? Regards, Philip. -- Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it. - Brian W. Kernighan - Utiba Pty Ltd This message has been scanned for viruses and dangerous content by Utiba mail server and is believed to be clean. ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Tablespaces oddity?
On Wed, 29 Mar 2006 01:36 am, Tom Lane wrote: Philip Yarra [EMAIL PROTECTED] writes: Someone else might be able to see a better way to write this query, but I think it would be good if \d could show this information, when you really want to know which tablespace an object is on. If \d doesn't say anything then the table is in the database's default tablespace. I see nothing wrong with that, and I do object to cluttering \d output with information that will be of no interest to people not using tablespaces. OK, how about on \d+, if the object is not on pg_default or pg_global, print the tablespace that this object is on? That way, people not using tablespaces won't ever see it. Note also that \l won't show you the tablespace for a DB, so you need to query pg_database to even know which is the default tablespace for a DB. I wouldn't object to adding default tablespace to \l output, or maybe \l+. OK, not fussed which one it's on, so long as it's there - this should do it for \l+ SELECT d.datname as Name, r.rolname as Owner, pg_catalog.pg_encoding_to_char(d.encoding) as Encoding, pg_catalog.obj_description(d.oid, 'pg_database') as Description, t.spcname as Tablespace FROM pg_catalog.pg_database d LEFT JOIN pg_catalog.pg_roles r ON d.datdba = r.oid LEFT JOIN pg_catalog.pg_tablespace t on d.dattablespace = t.oid; On a related note: is there a simple way to show all objects on a given tablespace? If not, would other people also see this as useful? Regards, Philip. -- Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it. - Brian W. Kernighan - Utiba Pty Ltd This message has been scanned for viruses and dangerous content by Utiba mail server and is believed to be clean. ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
[HACKERS] Tablespaces oddity?
Hi folks after discussing this on IRC today (thanks G_SabinoMullane!), I'm still surprised by this behaviour on 8.1.3: pyarra=# create TABLESPACE spctables location '/mnt/pg_tables/data'; CREATE TABLESPACE pyarra=# create table foo(id int) tablespace spctables; CREATE TABLE pyarra=# \d foo Table public.foo Column | Type | Modifiers +-+--- id | integer | Tablespace: spctables So far, so good... pyarra=# CREATE DATABASE spctest TABLESPACE spctables; CREATE DATABASE pyarra=# \c spctest; You are now connected to database spctest. spctest=# create table foo(id int) tablespace spctables; CREATE TABLE spctest=# create table bar(id int); CREATE TABLE spctest=# \d foo Table public.foo Column | Type | Modifiers +-+--- id | integer | spctest=# \d bar Table public.bar Column | Type | Modifiers +-+--- id | integer | I hoped that these last two tables would also be listed as being on spctables. I think the issue is that pg_class.reltablespace = 0 where these objects are created on the default tablespace for this database. I can find out which tablespace the objects are really on with: select relname, COALESCE(t.spcname,(select spcname from pg_tablespace where oid = (select dattablespace from pg_database where datname =current_database( as tablespace from pg_class c left join pg_tablespace t on (t.oid = c.reltablespace) Someone else might be able to see a better way to write this query, but I think it would be good if \d could show this information, when you really want to know which tablespace an object is on. Note also that \l won't show you the tablespace for a DB, so you need to query pg_database to even know which is the default tablespace for a DB. It's not impossible, just harder than it needs to be, I reckon. Any thoughts? Regards, Philip. -- Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it. - Brian W. Kernighan - Utiba Pty Ltd This message has been scanned for viruses and dangerous content by Utiba mail server and is believed to be clean. ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] tablespaces and non-empty directories
On Wed, 23 Nov 2005 11:23 am, Gavin Sherry wrote: Along those lines, is there anything else that would benefit from being moved? pg_clog and pg_subtrans come to mind; but maybe pg_multixact and pg_twophase are candidates as well? pgsql_tmp Does anyone have any recommendations about which of these would contend with each other for disk IO? I'm looking to put together a doco addition about multi-disk setup, so far I have something like: /mnt/pg_base /mnt/pg_xlog /mnt/pg_tab1 /mnt/pg_idx1 ...but is there significant gain in moving other bits from pg_base to a different spindle? If so, what can be safely combined, and what would definitely cause contention? I know that the answer would vary for different types of DB activity, but any rough guides would be a handy place to start. Regards, Philip. -- Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it. - Brian W. Kernighan - Utiba Pty Ltd This message has been scanned for viruses and dangerous content by Utiba mail server and is believed to be clean. ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Optional postgres database not so optional in 8.1
On Fri, 18 Nov 2005 05:29 am, Tom Lane wrote: It does seem a bit inconsistent that psql wouldn't connect to the specified database in order to do -l, if one is specified. Anyone want to look and see if it's easy to change? It also breaks the ability to psql -l against older installations: e.g. this is psql 8.1 trying to list databases on a 8.0.3 DB server: $ psql -l -hdev2 -dtemplate1 psql: FATAL: database postgres does not exist I'm told we never promise to make \l and \d work across client/server versions, but if this is related, it'd be nice if the fix made this work again too. Regards, Philip. -- Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it. - Brian W. Kernighan - Utiba Pty Ltd This message has been scanned for viruses and dangerous content by Utiba mail server and is believed to be clean. ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
[HACKERS] tablespaces and non-empty directories
I assume CREATE TABLESPACE refuses to use a non-empty directory because of the risk of trashing existing files. Makes sense, but consider the following: # mkfs -t ext2 /dev/sdc1 # mount -t ext2 /dev/sdc1 /mnt/pg_tables # chown postgres /mnt/pg_tables # su -c psql pyarra pyarra=# CREATE TABLESPACE spc_tables LOCATION '/mnt/pg_tables/'; ERROR: directory /mnt/pg_tables is not empty This is because lost+found exists. Since lost+found would be a reasonably common directory to find at a mount-point on Unix-like OSs*, would it make sense for CREATE TABLESPACE to ignore it if present? Of course this isn't hard to get around: # mkdir /mnt/pg_tables/data # chown postgres /mnt/pg_tables/data CREATE TABLESPACE spc_tables LOCATION '/mnt/pg_tables/data/'; If consensus is that it is a bad idea to treat lost+found as a special case, would it be worth putting an explicit mention in the doco about the preferred way to set up a database with multiple disks? Related question: are there plans afoot to allow specifying an alternate location for pg_xlog (or pg_delete-me-not) to save doing the shutdown-DB, mv directory to other disk, symlink, start-DB dance? Regards, Philip. * Solaris 9 and Linux both use lost+found, Tru64 v4.0f does not seem to (and has extra guff for quota management too). I doubt we could cater to every possible Unix OS and the administrative files it creates at mount points, however since lost+found is so common, if it's there, we could ignore it. -- Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it. - Brian W. Kernighan - Utiba Pty Ltd This message has been scanned for viruses and dangerous content by Utiba mail server and is believed to be clean. ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
[HACKERS] pl/pgsql breakage in 8.1b4?
Just testing pl/pgsql functions in 8.1beta4, I see failures for syntax that works in 8.0.3. The simplest test case for this is: create table ptest(foo int, bar varchar(10)); create or replace function modify_ptest( foo int, bar varchar) returns numeric as $$ declare res numeric; begin update ptest set bar = modify_ptest.bar where foo = modify_ptest.foo; res := 0; return res; end; $$ LANGUAGE plpgsql; The error message from psql is: ERROR: syntax error at or near $1 at character 19 QUERY: update ptest set $1 = modify_ptest.bar where $2 = modify_ptest.foo CONTEXT: SQL statement in PL/PgSQL function modify_ptest near line 7 LINE 1: update ptest set $1 = modify_ptest.bar where $2 = modify... ^ I assume what I'm trying should still work, though I couldn't find comparable examples in the doco. Looks to me like a problem with parameter aliasing. Regards, Philip. - Utiba Pty Ltd This message has been scanned for viruses and dangerous content by Utiba mail server and is believed to be clean. ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] pl/pgsql breakage in 8.1b4?
On Fri, 28 Oct 2005 01:37 pm, Stephan Szabo wrote: The function below fails for me similarly in 8.0.3 on execution. 8.1 merely tells you at creation time. Ah, good point... works for very small values of works then :-) My mistake. Using bar and foo as both parameter names and the field names doesn't really work. Fair enough. I was fooled because it works this way in Oracle (well, at any rate, that's what's in the stored procs I'm porting) and it didn't fail at create time in 8.0.3. Without really wishing to volunteer myself: should plpgsql allow using parameters with the same name as the columns being referred to within the function, provided they're qualified as function_name.parameter? Philip. - Utiba Pty Ltd This message has been scanned for viruses and dangerous content by Utiba mail server and is believed to be clean. ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] pl/pgsql breakage in 8.1b4?
On Fri, 28 Oct 2005 02:10 pm, Tom Lane wrote: Without really wishing to volunteer myself: should plpgsql allow using parameters with the same name as the columns being referred to within the function, provided they're qualified as function_name.parameter? No, because that just changes where the ambiguity is. The function name could easily conflict with a table name. Yup, I guess it could. It's a mighty weird-looking convention anyway --- on what grounds would you argue that the function is a structure having parameter names as fields? I wasn't arguing either way, I was just curious. Hmmm... is it feasible to make the error message a little more useful? People who didn't use the old-style positional parameters might not understand where $1 and $2 are coming from. Regards, Philip. - Utiba Pty Ltd This message has been scanned for viruses and dangerous content by Utiba mail server and is believed to be clean. ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] pl/pgsql breakage in 8.1b4?
On Fri, 28 Oct 2005 03:03 pm, Tom Lane wrote: Philip Yarra [EMAIL PROTECTED] writes: Hmmm... is it feasible to make the error message a little more useful? People who didn't use the old-style positional parameters might not understand where $1 and $2 are coming from. Not sure how --- the arm's-length relationship between plpgsql and the main parser hurts us here. Yeah, I had a suspicion the answer might be along those lines. Well, here's a minor doco patch against HEAD to at least record this with the Oracle PL/sql - PL/pgSQL porting notes. Regards, Philip. - Utiba Pty Ltd This message has been scanned for viruses and dangerous content by Utiba mail server and is believed to be clean. Index: doc/src/sgml/plpgsql.sgml === RCS file: /projects/cvsroot/pgsql/doc/src/sgml/plpgsql.sgml,v retrieving revision 1.79 diff -c -r1.79 plpgsql.sgml *** doc/src/sgml/plpgsql.sgml 21 Oct 2005 05:11:23 - 1.79 --- doc/src/sgml/plpgsql.sgml 28 Oct 2005 05:20:54 - *** *** 3132,3137 --- 3132,3144 state in temporary tables, instead. /para /listitem + listitem + para +You cannot use parameter names that are the same as columns +that are referenced in the function. Oracle does allow you to do this +if you qualify the parameter name as function_name.paramater_name + /para + /listitem /itemizedlist /para ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [Slony1-general] Re: [HACKERS] Slony RPM issue
On Thu, 6 Oct 2005 05:10 am, elein wrote: Generally a short sed (or perl if you like) script will fix these up. But it is really pretty obscure trail for people to find the exact problem. Yeah, it's not that it's hard to fix when you know where to look, but my aim is to produce a site installation checklist for other people to follow. The simpler it is, the better the chance of it being successful. I'd prefer a site installation to be: - install PostgreSQL RPMs - unpack our specific postgresql.conf and pg_hba.conf - set up database from scripts - install Slony RPM - unpack our specific slony config files - run minimal commands to get Slony going - profit! (or at least I don't get woken up by phone calls at 3am) That's why I'm so keen on the RPMs working out of the box, with minimal need for post-installation tweaks/fixes. Regards, Philip. ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
[HACKERS] Slony RPM issue
Hi Devrim, I ran into another RPM issue, this time with Slony. I grabbed the RPM from http://developer.postgresql.org/~devrim/slony/1.1.0/rpms/PG8.0.3/ Trying to run slon_start, I got errors such as: $ slon_start --config /etc/slon_tools.conf 2 Invoke slon for node 2 - @@@/slon -s 1000 -d2 -g 80 replication 'host=dev2 dbname=booktown user=postgres port=5432' 21 /var/log/slony/slony1/node2/booktown-2005-10-05_16:23:53.log sh: line 1: @@@/slon: No such file or directory Slon failed to start for cluster replication, node node2 This turned out to be because /usr/lib/pgsql/slon-tools.pm contained several un-expanded @@PGBINDIR@@ prefixes - once I replaced them with /usr/bin it all ran just fine. Please let me know if I can assist in fixing these issues. Also, thanks to David and Gavin for their help on IRC - it made a big difference to my day! Regards, Philip. -- Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it. - Brian W. Kernighan - Utiba Pty Ltd This message has been scanned for viruses and dangerous content by Utiba mail server and is believed to be clean. ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] Slony RPM issue
Hi Devrim, On Thu, 6 Oct 2005 12:32 am, Devrim GUNDUZ wrote: Thanks for the report. It will fixed in CVS and all the RPM sets later today. Always feel free to send me a patch if you want, I can apply your patch, too. OK, you got my previous email about why pgsql-libs was dependent on compat-libs RPM? I don't even know where to start with fixing RPM issues, but I guess I can learn if you would like help? BTW, could you please report the possible Slony problems to slony1-general@gborg.postgresql.org later? Sure will. Ermmm, there isn't something you want to tell me is there? :-) I'd rather hear about gotchas now rather than finding them myself at the eleventh hour. Regards, Philip. -- Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it. - Brian W. Kernighan - Utiba Pty Ltd This message has been scanned for viruses and dangerous content by Utiba mail server and is believed to be clean. ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
[HACKERS] RPMs for RedHat ES3.0
Devrim, I had some problems installing on RedHat ES3.0 with the RPMs. This issue turned out to be that I needed the compat libs to provide the old libs before I could install the new libs. I found a link to http://developer.PostgreSQL.org/~devrim/compat-postgresql-libs-3-3PGDG.i686.rpm in an archived post from -hackers. It wasn't all that obvious what was required though, so is it possible that this RPM could actually be put with the downloads for the main RPMs? I'm not sure anyone's installation would succeed without that RPM on RedHat ES3.0. Please let me know if I'm missing something. As an aside: is it possible to actually to just include the contents of compat-libs in postgresql-libs, since they actually seem to be required? It'd save me some hassles for future installations. Probably other folks too. Regards, Philip. Boring details: 1) removed all previous traces of postgresql: [EMAIL PROTECTED] root]# rpm -e `rpm -qa | grep postgres` \ perl-DBD-Pg-1.21-2 mod_auth_pgsql-2.0.1-4.ent php-pgsql-4.3.2-19.ent 2) Grabbed 8.0.3 binaries from: http://www.postgresql.org/ftp/binary/v8.0.3/linux/rpms/redhat/rhel-es-3.0/ 3) Try to install: [EMAIL PROTECTED] 8.x]# rpm -i postgresql-8.0.3-1PGDG.i686.rpm error: Failed dependencies: libpq.so.4 is needed by postgresql-8.0.3-1PGDG [EMAIL PROTECTED] 8.x]# rpm -i postgresql-libs-8.0.3-1PGDG.i686.rpm error: Failed dependencies: libecpg.so.4 is needed by postgresql-libs-8.0.3-1PGDG libpgtypes.so.1 is needed by postgresql-libs-8.0.3-1PGDG libpq.so.3 is needed by postgresql-libs-8.0.3-1PGDG Suggested resolutions: rh-postgresql-libs-7.3.8-2.i386.rpm 4) Install http://developer.postgresql.org/~devrim/compat-postgresql-libs-3-3PGDG.i686.rpm , repeat step 3 and suddenly life gets a whole lot better :-) - Utiba Pty Ltd This message has been scanned for viruses and dangerous content by Utiba mail server and is believed to be clean. ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] RPMs for RedHat ES3.0
Hi Devrim, thanks for the quick response. We haven't discussed it before, but I think we can't put the RPM among PGDG RPMs. The main reason is that this is not a piece of software that's included within that release of PostgreSQL. Also, this compat RPM is not needed if you don't have a software that needs that RPM. Have a look at my original post: I was unable to install any of the PGDG RPMs as they have a dependency on the contents of the compat RPM. E.g.: [EMAIL PROTECTED] 8.x]# rpm -i postgresql-libs-8.0.3-1PGDG.i686.rpm error: Failed dependencies: libecpg.so.4 is needed by postgresql-libs-8.0.3-1PGDG libpgtypes.so.1 is needed by postgresql-libs-8.0.3-1PGDG libpq.so.3 is needed by postgresql-libs-8.0.3-1PGDG Once I installed the compat RPM, I could then install postgresql-libs-8.0.3-1PGDG. So the software that needs the compat RPM is the PGDG RPMs. Please tell me if I have missed something here, I'm not claiming any great insight, just what rpm seems to be telling me, and what worked to get me through the installation. Also remember that this will be probably 'solved' in RHEL 5 (and FC 5), so merging compat with main libs package is not a good idea. Our clients are still on ES3.0, then they *might* migrate to 4.0 one day. RHEL5 is a long way off for us, I assure you :-) so I'm happy to lend any help I can to resolve this issue for ES3.0. I don't quite understand how the compat libs can be counted as not part of this release if the release packages require it. Is it maybe just an issue with rpm creating automatic dependiencies for those .so files? (sorry, this is me at my vaguest, rpm is something of an unknown to me, but I suspect I'm about to learn). Regards, Philip. - Utiba Pty Ltd This message has been scanned for viruses and dangerous content by Utiba mail server and is believed to be clean. ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] RPMs for RedHat ES3.0
Hi Tom, On Tue, 4 Oct 2005 11:36 am, Tom Lane wrote: I think there's no question that this represents an RPM-building error. We haven't entirely figured out what's causing it though. Right, gotcha. I think this may be the issue: [EMAIL PROTECTED] 8.x]# rpm -ql postgresql-libs-8.0.3-1PGDG [snip] /usr/lib/libecpg_compat.so.2 [snip] [EMAIL PROTECTED] 8.x]# ldd /usr/lib/libecpg_compat.so.2 libecpg.so.4 = /usr/lib/libecpg.so.4 (0x007ba000) libpgtypes.so.1 = /usr/lib/libpgtypes.so.1 (0x00e0e000) libpq.so.3 = /usr/lib/libpq.so.3 (0x00efa000) [EMAIL PROTECTED] 8.x]# rpm -q --whatprovides /usr/lib/libpq.so.3 compat-postgresql-libs-3-3PGDG Including /usr/lib/libecpg_compat.so.2 in postgresql-libs-8.0.3-1PGDG causes automatic dependency (http://www.rpm.org/max-rpm/s1-rpm-depend-auto-depend.html) on those .so files which are only included in compat RPM. Regards, Philip. - Utiba Pty Ltd This message has been scanned for viruses and dangerous content by Utiba mail server and is believed to be clean. ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] SETOF function call
sizeof(Datum) == sizeof(long) - is that compatible with %d formatting (I'm
guessing something like vsprintf takes place in elog)? Wouldn't this need %ld
or %lu?
Sorry if this misses the point, I wasn't clear from original post if the
segfault was on elog or after it.
Regards, Philip.
On Tuesday 19 April 2005 11:53, Tom Lane wrote:
Olivier Thauvin [EMAIL PROTECTED] writes:
Datum
header_querytxt(PG_FUNCTION_ARGS)
{
elog(NOTICE, querytxt);
Datum tag;
/* converting TEXT value to integer one */
tag = DirectFunctionCall1(rpmtagvalue, PG_GETARG_TEXT_P(1));
elog(NOTICE, querytxt %d, tag);
/* header_query = function accepting integer instead text)
PG_RETURN_POINTER(DirectFunctionCall2(header_query,
PG_GETARG_BYTEA_P_COPY(0), tag));
}
If that's a cut-and-paste, then you seem to be short a */ on the second
comment ...
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
-
Utiba Pty Ltd
This message has been scanned for viruses and
dangerous content by Utiba mail server and is
believed to be clean.
-
Utiba Pty Ltd
This message has been scanned for viruses and
dangerous content by Utiba mail server and is
believed to be clean.
---(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] Need help woth thread support in ecpglib
Hi Michael, I'll have a look at it this afternoon, unless Lee wants first go.
Regards, Philip.
On Tuesday 12 April 2005 00:28, Michael Meskes wrote:
Hi,
I recently got the following bug report. It appears to be a bug in
pthread implementation in ecpglib/connect.c where
pthread_getspecific(actual_connection_key);
doesn't return the value of actual_connection, the variable used for
non-threaded mode. Problem is I never really used threading in my apps
and didn't do the threading patches. Maybe someone with more knowledge
than me could have a look at this. Thanks.
Michael
---
When using postgresql 8.0 compiled with --enable-thread-safety, new threads
no longer see the default ecpg connection. That was not the case in 7.4.x
compiled with or without --enable-thread-safety.
TEST CASE
The program at the end of this mail sets up a database table named
dbthreadtest in the default database. It then spawns 5 threads which each
do a select from that table using the default connection.
If the program is saved as dbthreadtest.pgc, compile with:
ecpg -t -o dbthreadtest.c dbthreadtest.pgc
gcc -Wall -o dbthreadtest dbthreadtest.c -lecpg -lpthread
Results under 7.4.x / 8.0 without --enable-thread-safety:
got id = 1
got id = 1
got id = 1
got id = 1
got id = 1
Results under 8.0 with --enable-thread-safety:
'No such connection NULL in line 76.', sqlcode = -220 select id
TEST PROGRAM
/* -*-C-*- */
#include stdlib.h
#include pthread.h
#define CHECK_SQL(fmt, args...) \
do\
{ \
if (sqlca.sqlcode != ECPG_NO_ERROR) \
{ \
fprintf (stderr, '%s', sqlcode = %ld fmt \n, \
sqlca.sqlerrm.sqlerrmc, \
sqlca.sqlcode, ## args); \
exit (1); \
} \
}\
while (0)
#define FATAL(fmt, args...) \
do\
{ \
fprintf (stderr, fmt \n, ## args);\
exit (1); \
} \
while (0)
pthread_mutex_t global_lock;
pthread_t global_threads[5];
void
setup_db ()
{
exec sql begin declare section;
const char *_user;
exec sql end declare section;
pthread_mutex_lock (global_lock);
_user = getenv (LOGNAME);
exec sql connect to :_user;
CHECK_SQL (connect);
exec sql create table dbthreadtest (id int);
CHECK_SQL (create dbthreadtest);
exec sql insert into dbthreadtest (id) values (1);
CHECK_SQL (insert 1);
pthread_mutex_unlock (global_lock);
}
void
teardown_db ()
{
pthread_mutex_lock (global_lock);
exec sql drop table dbthreadtest;
CHECK_SQL (drop dbthreadtest);
exec sql disconnect;
CHECK_SQL (disconnect);
pthread_mutex_unlock (global_lock);
}
void *query_db (void *ignorep)
{
exec sql begin declare section;
int _id;
exec sql end declare section;
pthread_mutex_lock (global_lock);
exec sql select id into :_id from dbthreadtest;
CHECK_SQL (select id);
fprintf (stdout, got id = %d\n, _id);
pthread_mutex_unlock (global_lock);
return NULL;
}
int
main ()
{
int i;
pthread_mutex_init (global_lock, NULL);
setup_db ();
for (i = 0; i sizeof (global_threads) / sizeof (global_threads[0]);
++i)
{
if (pthread_create (global_threads[i], NULL, query_db, NULL))
FATAL (pthread_create %d failed, i);
}
for (i = 0; i sizeof (global_threads) / sizeof (global_threads[0]);
++i)
{
if (pthread_join (global_threads[i], NULL))
FATAL (pthread_join %d failed, i);
}
teardown_db ();
return 0;
}
- End forwarded message -
--
Michael Meskes
Email: Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: [EMAIL PROTECTED]
Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL!
---(end of broadcast)---
TIP 8: explain analyze is your friend
-
Utiba Pty Ltd
This message has been scanned for viruses and
dangerous content by Utiba mail server and is
believed to be clean.
-
Utiba Pty Ltd
This message has been scanned for viruses and
dangerous content by Utiba mail server and is
believed to be clean.
---(end of broadcast)---
TIP 8: explain analyze is your friend
[HACKERS] 7.4.6 build failures on Solaris 9 with Sun cc
Hi all, before I delve too deeply into this, has anyone else tried building
7.4.6 on Solaris 9 (sparc) ? I'm seeing build failures using Sun's cc:
make[4]: Entering directory `/tmp/postgresql-7.4.6/src/backend/access/heap'
cc -Xa -O -v -I../../../../src/include -c -o tuptoaster.o tuptoaster.c
tuptoaster.c, line 831: member can not have variably modified type: data
tuptoaster.c, line 937: cannot recover from previous errors
cc: acomp failed for tuptoaster.c
Which is:
struct
{
struct varlena hdr;
chardata[TOAST_MAX_CHUNK_SIZE];
} chunk_data;
The compiler is cc: Sun C 5.6 2004/06/02 (Sun Studio 9)
If no-one's seen this before, I'll do some digging.
Regards, Philip.
---(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] 7.4.6 build failures on Solaris 9 with Sun cc
On Fri, 3 Dec 2004 01:43 pm, Michael Fuhr wrote: gcc 3.4.2 on Solaris 9 doesn't complain about this. Yes, I found Tom's response to the issue from March here: http://archives.postgresql.org/pgsql-ports/2004-03/msg9.php and this on the Sun CC forum, confirming that the compiler is borked: http://forum.sun.com/thread.jspa?threadID=20947tstart=0 It'd be handy if they said what ID the bug had been assigned so I knew what patch to download to fix it. I'll post the info once I can find it so there's a simple Apply patch # answer in future. I ended up building with gcc 3.4.0, no problem. Thanks for following up. Regards, Philip. ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] [COMMITTERS] pgsql-server: Rearrange pg_subtrans handling
On Wed, 25 Aug 2004 03:54 pm, Mark Kirkwood wrote: Greg Stark wrote: It's only allowed when the transaction is in READ UNCOMMITTED isolation level. Something Postgres doesn't currently support. In fact I'm not aware of any SQL database that supports it, though I'm sure there's one somewhere. FYI - DB2 supports this isolation level, I don't know of any others (tho Informix is a possibility). Sybase ASE (and by derivation MS SQL Server) also have dirty reads. Regards, Philip. ---(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] enabling tcpip_socket by default
On Mon, 17 May 2004 05:29 pm, Marko Karppinen wrote: If the default will be to listen on all interfaces, not just 127.0.0.1, then this IS a security risk. And if that's not the plan, what good does this change do? Any real use of tcp would still require a configuration change anyway. From what I have read today, localhost is the only one planned to be on by default. Listening on a TCP/IP socket on localhost will allow JDBC connections to work out of the box (this exact problem tripped me up, and I'm sure this is the case for other users). I suspect other cross-platform APIs (PHP for example) need TCP/IP sockets to connect too. Regards, Philip. ---(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] Use of 'cp -r' in CREATE DATABASE
On Fri, 12 Dec 2003 10:36 am, Bruce Momjian wrote: I think we should switch to -R in our code. Both -r and -R are supported on Linux (fileutils 4.1), Tru64 v4.0 and Solaris (at least as far back as 2.6) so no complaints here. Regards, Philip. ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] Executable files in CVS
On Mon, 24 Nov 2003 11:41 am, Bruce Momjian wrote: find pgsql-server/ -type f -perm +0333 -ls That command doesn't seem to work for me. I see: I think that should be -perm +0111: from man find: -perm +mode Any of the permission bits mode are set for the file. This would find all executable files (by u,g,o). +0333 would also find writable files (as in your example) Regards, Philip. ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Fwd: Re: [HACKERS] Call for port reports
I've just tried the latest CVS on Tru64 (OSF) and I'm getting a surprising number of failures. I've tested using gcc 2.95 and compaq's cc (both the same number of failures, can provide regression.* and make.out from /bin/cc run if required). The attached results are from gcc, which appears to be default unless I `export CC=/bin/cc` $ uname -a OSF1 hostname V4.0 1229 alpha [that's Tru64 v4.0F ] $ ./configure --with-thread-safety make clean check [snip] = 18 of 93 tests failed, 1 of these failures ignored. = I've attached regression.diffs and regression.out - the same CVS snapshot passed `make check` perfectly on Linux, BTW I saw Alessio's results from Tru64 v4.0g this morning - no problems there, so I wonder if I am doing something wrong... can anyone provide further suggestions? There may be some wierdness on my build host, so when time permits I'll try on a different alpha machine. I've also attached make.out.gz - the output of make. Regards, Philip Yarra. regression.out.gz Description: GNU Zip compressed data regression.diffs.gz Description: GNU Zip compressed data make.out.gz Description: GNU Zip compressed data ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] Bison 1.875 for SuSE Linux 8.1?
On Fri, 17 Oct 2003 09:43 am, Josh Berkus wrote: (I predict that we're going to get many more questions about Bison after we release 7.4, since many major Linux distros don't yet include 1.875) You only need bison if you are building from CVS - tarballs include the bison output files (AFAIK - correct me if I am mistaken anyone). Regards, Philip. ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] [COMMITTERS] pgsql-server/src/template bsdi freebsd netbsd ...
On Fri, 10 Oct 2003 12:45 am, Bruce Momjian wrote: My gcc 2.95.3 manual says: -pipe Use pipes rather than temporary files for communi- [snip] so it looks like we can't use it on all platforms without testing. I will enable it for linux. Do people want to test other platforms? I saw your message that it was disabled for all builds (I assume you meant all, not all BSDs), but for the sake of completeness: $ uname -a OSF1 hostname V4.0 1229 alpha $ cc -pipe main.c ld: -pipe: Unknown flag ld: Usage: ld [options] file [...] $ gcc -pipe main.c as: Error: no source, object or ucode file specified main.c:46: output pipe has been closed Regards, Philip Yarra. ---(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] feature request: show pgsql version when running initdb
On Fri, 26 Sep 2003 04:51 pm, Christopher Kings-Lynne wrote: Yes I do, but sometimes as different users you don't know what the path is. I guess I can just go --version. Perhaps add alias initdb='initdb --version; initdb' to /etc/profile so that all accounts get an alias? Regards, Philip Yarra. ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] [pgsql-www] NuSphere and PostgreSQL for windows
On Fri, 26 Sep 2003 01:18 am, Greg Stark wrote: Well if you're only going to do one threading API you may as well pick the POSIX standard. Windows threading is only useful for windows, POSIX threading would work on every other OS, Solaris, Linux, BSD, etc. Is there a POSIX threads wrapper for windows? Yes and no... there's no native POSIX thread wrapper, if that's what you mean (say like pthreads on OSF wraps DECThreads AFAIK). There's a development effort here (http://sources.redhat.com/pthreads-win32/) to help those using Windows, but if it was me, I'd probably stick to native Windows threads. It's not going to be on people's machines by default. Regards, Philip. ---(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] PostgreSQL not ACID compliant?
It's funny timing - I had to prepare a comparison between PostgreSQL and MySQL recently, explaining why we would prefer PostgreSQL. I know some people here have issues with the MySQL crashme test results, but I have to say I found it possibly one of the best postgreSQL advertisements available. A 4-way comparison between Sybase, Oracle, MySQL and PostgreSQL shows PostgreSQL in an extremely flattering light. Given the missing features in MySQL (column constraints and views, for god's sake!) I had to conclude that we couldn't implement most of our projects in MySQL, even if we wanted to. I have trouble believing MySQL was suggested as a viable alternative. I know I'm preaching to the choir here, but thought you might find it of interest. Regards, Philip Yarra. ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Unixware Patch (Was: Re: Beta2 Tag'd and Bundled ...)
On Wed, 10 Sep 2003 02:39 pm, Tom Lane wrote: A thread-safe implementation of libpq is of zero value to an application unless it also has thread-safe implementations of the other libraries it depends on. Not necessarily so - we've managed okay so far (several years) working on platforms that don't fall into that short list. It can be done. Thus far we have had to use Sybase or Informix because they do support thread-safe C interfaces. Any app that might want to use libpq is going to hit those same bugs, and so in the long run the only useful answer is for the platform to fix its libc. The useful answer (so far) is to not use PostgreSQL for these applications, but to stick with a database that does support a threadsafe C interface. I think that's a pity. I agree, it would make life easier if vendors supported threadsafe libc functions. The real bottom line here is: who is going to try to build threaded apps on platforms with un-thread-safe libc? The company I work for. I got involved in this issue so we could port from Sybase and Informix to PostgreSQL. I assume there are other people out there who'd be interested as well. And why should we be the ones to try to save them from suffering the pain they deserve? 1) Leave users to cope with their own code issues, but make sure the database's C interface isn't one of them. 2) Because it's good enough for (Oracle|Informix|Sybase) So moving forward: do we try Bruce's idea of libpq_r and ecpg_r? If people want to risk the overhead of wrapped libc calls, they can build the threaded lib versions and link against those. Would that be acceptable to people? Regards, Philip. ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Unixware Patch (Was: Re: Beta2 Tag'd and Bundled ...)
On Thu, 4 Sep 2003 05:36 am, Bruce Momjian wrote: I would like every operating system that supports thread-safety to run this program and report back the results. Okay, here's results from the machines I have access to... I think what you're going to find is that an awful lot of platforms that do support pthreads do not necessarily provide thread-safe libc functions. Is it possible to identify which functions are likely to be called by multiple threads and create our own mutex-wrapper functions for them? Disabling thread-safety seems pretty drastic simply because of a lack of getpwuid_r() or thread-safe getpwuid(). Or do I misunderstand your concerns? Regards, Philip. $ uname -a OSF1 hostname V4.0 1229 alpha $ ./a.out Your getpwuid() changes the static memory area between calls Your strerror() is _not_ thread-safe Your functions are _not_ all thread-safe There are older _r functions, but they're deprecated as the non _r are now thread-safe. $ uname -a SunOS hostname 5.6 Generic_105181-05 sun4m sparc SUNW,SPARCstation-4 $ gcc -lpthread -lnsl test.c # this works $ ./a.out Your gethostbyname() is _not_ thread-safe Your getpwuid() is _not_ thread-safe Your functions are _not_ all thread-safe getpwduid_r provided gethostbyname_r not provided FreeBSD 5.1 (i386) $ cc -pthread test.c $ ./a.out Your gethostbyname() is _not_ thread-safe Your getpwuid() is _not_ thread-safe Your functions are _not_ all thread-safe manpage notes BUGS These functions use static data storage; if the data is needed for future use, it should be copied before any subsequent calls overwrite it. FreeBSD 4.8 (i386) $ cc -pthread test.c $ ./a.out Your gethostbyname() is _not_ thread-safe Your getpwuid() is _not_ thread-safe Your functions are _not_ all thread-safe manpage notes BUGS These functions use static data storage; if the data is needed for future use, it should be copied before any subsequent calls overwrite it. Linux 2.4.18-3 (i686) $ ./a.out Your gethostbyname() is _not_ thread-safe Your getpwuid() is _not_ thread-safe Your functions are _not_ all thread-safe manpage notes The functions gethostbyname() and gethostbyaddr() may return pointers to static data, which may be over- written by later calls. Copying the struct hostent does not suffice, since it contains pointers - a deep copy is required. Glibc2 also has reentrant versions gethostbyname_r() and gethostbyname2_r(). These return 0 on success and nonzero on error. The result of the call is now stored in the struct with address ret. After the call, *result will be NULL on error or point to the result on success. Auxiliary data is stored in the buffer buf of length buflen. (If the buffer is too small, these functions will return ERANGE.) No global vari- able h_errno is modified, but the address of a variable in which to store error numbers is passed in h_errnop. ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] Unixware Patch (Was: Re: Beta2 Tag'd and Bundled ...)
On Wed, 10 Sep 2003 11:46 am, Bruce Momjian wrote: I see --- looks bad failures below for OSF, Solaris, and FreeBSD below. Actually, I am not sure the OSF failure is correctly reported... your test app had me a little baffled in that case. We would have to get some thread mutex, make the function call, copy the return values into the passed pointer, and release the mutex? Do we test to see if we are in thread mode before doing the locking? Is that test even possible or desirable? I guess as with the threading stuff in ECPG: #ifdef SOME_DEF (sorry, have to check the ECPG source on that one) pthread_mutex_lock(my_mutex) #endif /* do stuff */ #ifdef SOME_DEF pthread_mutex_unlock(my_mutex) #endif Seems we will need to rename the config variable to be NON_REENTRANT_FUNC_NAMES_THREADSAFE, and add configure checks for each *_r function, and fall back to the mutex if both settings are false. Yeah, or you could just always use the wrapper and not try to do all the test in configure... doubtless less efficient, but maybe better for the mental health... This part has me concerned too: Copying the struct hostent does not suffice, since it contains pointers - a deep copy is required. Would someone with thread mutex experience assist me? Ummm... replace /* do stuff /* above with a deep copy of the hostent struct. I'll give that a shot if you like. Regards, Philip. ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] Unixware Patch (Was: Re: Beta2 Tag'd and Bundled ...)
On Wed, 10 Sep 2003 12:29 pm, Bruce Momjian wrote: --- anyway, it is probably threadsafe, but strerror isn't, so we are dead anyway. :-) Oh, I see. Yep, good point. Strange that strerror isn't threadsafe when everything else is... maybe Strange is OSF's middle name. #ifdef SOME_DEF (sorry, have to check the ECPG source on that one) pthread_mutex_lock(my_mutex) #endif /* do stuff */ #ifdef SOME_DEF pthread_mutex_unlock(my_mutex) #endif Yep. Ugly but required. Could be worse - at least creating a wrapper function keeps the aesthetically-offensive code away from most of the code, and everyone else could just call pg_gethostbyname() or whatever... Yeah, or you could just always use the wrapper and not try to do all the test in configure... doubtless less efficient, but maybe better for the mental health... True. In fact, on platforms with non-*_r functions that are thread-safe, those locks are already done in libc anyway. The problem is that on platforms that don't have non *_r thread-safe, and don't have all the *_r functions, we would be adding overhead to libpq that isn't already part of libc on that platform, and that seems wrong to me. Double-yuck. No, correct me if I'm wrong, but the #ifdef'd code is removed by the pre-processor, so platforms without thread support would gain only the overhead of a single function call? That doesn't seem so steep. The actual copying of the structs wouldn't be needed in this case, so handle that like: #ifdef SOME_DEF /* copy structure and set return pointer to this copy /* #else /* set return pointer to global buffer */ #endif It's only a penalty for platforms with thread-safe functions called within the mutex_locked section... and if we're talking about functions like gethostbyname() (which may well be making a network call to a DNS server) I doubt the second mutex_lock would be a noticeable penalty. Making copies of structures is some penalty, that's true... I might try some timings to see how much of a penalty. Are these functions likely to see such heavy use that the additional times are a problem? We might have to produce a libpq_r and ecpg_r (yuck) on those platforms. I beg you, stay away from this idea! Informix does this, and it isn't pretty. I have the core files to prove it. Ummm... replace /* do stuff /* above with a deep copy of the hostent struct. I'll give that a shot if you like. Tripple-yuck. :-) Hey, are you impugning my coding style? If so, you'll have to join the queue. :-) Do you want me to have a try at the gethostbyname() wrappers, or is it going to be a waste of time? Regards, Philip. ---(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] Unixware Patch (Was: Re: Beta2 Tag'd and Bundled ...)
On Wed, 10 Sep 2003 02:15 pm, Bruce Momjian wrote: Tom Lane wrote: It doesn't seem to me that we should take on the job of providing thread-safe implementations of basic libc functions. If a particular OS cannot manage to offer that functionality, then we should mark it not-thread-safe and move on. This would be a pretty short list unless I count wrong! This excludes all releases of FreeBSD (and I'm willing to bet other BSDs), Solaris (at least the old version I have), OSF, Linux, and who knows what else? MacOS X? Persons unhappy with this labeling must take it up with their OS developers, not us. Surely the development of PostgreSQL has seen lots of platform shortcomings found and worked-around? Why not this as well? Are these non-threadsafe functions really going to be so heavily-used that we can't live with the wrappers? I mean, AFAIK these threading issues are only in ECPG and libpq - it's not like re-writing the backend code is required. ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] thread safety
On Tue, 2 Sep 2003 03:06 am, Mendola Gaetano wrote: May be I'm wrong but I'd like know why thread safety was so necessary. It bugged Lee enough that he went and wrote a patch for it. It bugged me enough that I couldn't use it on our choice of platform (older Linux) that I did some little fixes for that. I worked on what I needed. If you need a justification for ECPG threading support: people porting from Sybase/Informix/Oracle would probably expect ECPG to support threads, and will get a nasty surprise when their ported application abruptly dies. I expected it to just work and was unpleasantly surprised when it didn't. Best Regards, Philip Yarra. ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
[HACKERS] SCO support in GCC
I thought some of you might find this interesting in light of recent issues with SCO cc: http://gcc.gnu.org/ml/gcc-patches/2003-08/msg00191.html In short, the FSF is discussing the possibility of dropping support for SCO Unix in GCC. ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] threading and FreeBSD
Something odd going on with the list - I never saw the original that Chris is replying to. Philip. On Fri, 15 Aug 2003 12:22 pm, Christopher Kings-Lynne wrote: I've been doing all my freebsd/alpha build with --enable-thread-safety for weeks and I haven't seen any compile or running problems... Configure doesn't see it tho: checking pthread.h usability... yes checking pthread.h presence... yes checking for pthread.h... yes checking for strerror_r... yes checking for getpwuid_r... no checking for gethostbyname_r... no Chris - Original Message - From: Bruce Momjian [EMAIL PROTECTED] To: PostgreSQL-development [EMAIL PROTECTED] Sent: Friday, August 15, 2003 6:43 AM Subject: [HACKERS] threading and FreeBSD Our current template/freebsd has: CFLAGS='-pipe' case $host_cpu in alpha*) CFLAGS=$CFLAGS -O ;; esac SUPPORTS_THREADS=yes case $host_os in freebsd2*|freebsd3*|freebsd4*) THREAD_CFLAGS=-pthread NEED_REENTRANT_FUNC_NAMES=yes ;; *) THREAD_LIBS=-lc_r NEED_REENTRANT_FUNC_NAMES=yes ;; esac Now, this says FreeBSD needs reentrant named functions for all versions. However, our main server (4.8-STABLE FreeBSD) doesn't have any mention of getpwuid_r(). Would some FreeBSD folks test the --enable-thread-safey and let us know how things work? -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED]) ---(end of broadcast)--- TIP 8: explain analyze is your friend ---(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] Make clean fails
On Mon, 28 Jul 2003 04:27 pm, [EMAIL PROTECTED] wrote: Just part of the baptism of fire for a newbie, I guess. :-) I've found the learning curve pretty steep too. Is it worth putting together some of these 'gotchas' into a neophyte-developer-FAQ? As a side note: anyone else noticed that developer.postgresql.org is displaying an apache test page? I assume this might be an indicator of work in progress. Regards, Philip Yarra. ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] OSF build fixed
On Wed, 16 Jul 2003 03:56 am, Tom Lane wrote: osf-template.patch: adds pthread support for OSF tested on OSF (uname -a: OSF1 hostname V4.0 1229 alpha) Applied; it would be a good idea to get some more testing of it, but that's what beta is for ... Yes, I only have access to one version of Tru64, so all I can assert is that it works for me, and that is only for a fairly simple test case so far. I'd be much more comfortable if other OSF users could test too. I can supply the simple ECPG app I've been using. Regards, Philip. [back from holidays and catching up on a staggering volume of PostgreSQL mail] ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Possible psql bug
On Thu, 10 Jul 2003 12:35 pm, Christopher Kings-Lynne wrote: When I run psql on freebsd/alpha with latest CVS and no postmaster running, I get this: bizarre socket name Interesting... I'm running OSF on Alpha and I get the usual /tmp/.s.PGSQL.5432. Perhaps it's related to IPv6 socket changes? I'm pretty sure we don't have IPv6 support, so it would make sense it doesn't show up here if I guess right. What's your `uname -a`? FreeBSD has had IPv6 support for a while, IIRC. Regards, Philip. ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] Possible psql bug
On Thu, 10 Jul 2003 01:33 pm, Christopher Kings-Lynne wrote: FreeBSD alpha.cacheboy.net 4.7-STABLE FreeBSD 4.7-STABLE #0: Mon Feb 3 Hmm... I have 7.4devel built on FreeBSD 4.8 Intel running ipv6 at home - I'll try the same tonight. It might help determine if it's architecture or OS. Regards, Philip. ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] OSF build fixed
Patches: int64-pqcomm.patch: changes int64_t to int64 in src/include/libpq/pqcomm.h tested on RedHat Linux 7.3 and OSF osf-template.patch: adds pthread support for OSF tested on OSF (uname -a: OSF1 hostname V4.0 1229 alpha) If these are okay, can someone apply them? Can someone with access to different OSF versions test pthread-safety as well? Regards, Philip Yarra.*** pgsql-old/src/include/libpq/pqcomm.h Wed Jun 25 10:42:16 2003 --- pgsql/src/include/libpq/pqcomm.h Mon Jul 7 17:30:11 2003 *** *** 38,44 * Desired design of maximum size and alignment */ #define _SS_MAXSIZE128 /* Implementation specific max size */ ! #define _SS_ALIGNSIZE (sizeof (int64_t)) /* Implementation specific desired alignment */ /* * Definitions used for sockaddr_storage structure paddings design. --- 38,44 * Desired design of maximum size and alignment */ #define _SS_MAXSIZE128 /* Implementation specific max size */ ! #define _SS_ALIGNSIZE (sizeof (int64)) /* Implementation specific desired alignment */ /* * Definitions used for sockaddr_storage structure paddings design. *** *** 61,67 /* 6 byte pad, this is to make implementation * specific pad up to alignment field that * follows explicit in the data structure */ ! int64_t __ss_align; /* field to force desired structure * storage alignment */ char __ss_pad2[_SS_PAD2SIZE]; --- 61,67 /* 6 byte pad, this is to make implementation * specific pad up to alignment field that * follows explicit in the data structure */ ! int64 __ss_align; /* field to force desired structure * storage alignment */ char __ss_pad2[_SS_PAD2SIZE]; *** pgsql-old/src/template/osf Thu Sep 5 08:54:18 2002 --- pgsql/src/template/osf Mon Jul 7 17:30:59 2003 *** *** 4,6 --- 4,9 CC=$CC -std CFLAGS='-O4 -Olimit 2000' fi + SUPPORTS_THREADS=yes + THREAD_CFLAGS=-pthread + ---(end of broadcast)--- TIP 8: explain analyze is your friend
[HACKERS] OSF build broken
I did a fresh CVS get (2003-07-07 12:30 UTC +10:00), attempted to build on OSF1 V4.0 1229 alpha (Tru64 running on alpha) but build failed with: In file included from ../../../../src/include/libpq/libpq-be.h:22, from ../../../../src/include/libpq/libpq.h:21, from printtup.c:20: ../../../../src/include/libpq/pqcomm.h:60: `int64_t' undeclared here (not in a function) ../../../../src/include/libpq/pqcomm.h:64: parse error before `int64_t' ../../../../src/include/libpq/pqcomm.h:64: warning: no semicolon at end of struct or union ../../../../src/include/libpq/pqcomm.h:67: `int64_t' undeclared here (not in a function) ../../../../src/include/libpq/pqcomm.h:67: `int64_t' undeclared here (not in a function) ../../../../src/include/libpq/pqcomm.h:71: parse error before `}' ../../../../src/include/libpq/pqcomm.h:81: field `addr' has incomplete type gmake[4]: *** [printtup.o] Error 1 gmake[4]: Leaving directory `/files1/home/philip/install/pgsql/src/backend/access/common' gmake[3]: *** [common-recursive] Error 2 gmake[3]: Leaving directory `/files1/home/philip/install/pgsql/src/backend/access' gmake[2]: *** [access-recursive] Error 2 gmake[2]: Leaving directory `/files1/home/philip/install/pgsql/src/backend' gmake[1]: *** [all] Error 2 gmake[1]: Leaving directory `/files1/home/philip/install/pgsql/src' gmake: *** [all] Error 2 Any ideas how I can resolve this? Regards, Philip Yarra. ---(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] OSF build broken
On Mon, 7 Jul 2003 02:19 pm, Tom Lane wrote:
Is type int64_t defined anywhere in your system headers? If so, where?
Er... no... this:
int main()
{
printf(sizeof is: %d\n, sizeof(int64_t));
}
fails with:
cc: Error: l.c, line 2: In this statement, int64_t is not declared.
(undeclared)
printf(t is: %d\n, sizeof(int64_t));
^
But then, it doesn't work on Linux (intel 32-bit) either... What's this
int64_t supposed to be? We're not just talking about a long long are we?
Regards, Philip.
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] OSF build broken
On Mon, 7 Jul 2003 02:53 pm, you wrote: Without some #include's, I'd expect it to fail, because int64_t isn't built into the C compiler. The question is exactly which #include are we missing. Okay, got it: db.h ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] OSF build broken
On Mon, 7 Jul 2003 03:09 pm, Joe Conway wrote: I found it on my Red Hat 9 box in sys/types.h: snip # if __GLIBC_HAVE_LONG_LONG __extension__ typedef long long int int64_t; # endif And on RedHat 7.3 it's in stdint.h - they must move it around to keep the snipers guessing. If you haven't hit this problem trying to build, it sounds like the right things are getting included for your platform. What's the best (most portable) way to fix this? Would something like: #ifdef OSF #include db.h #endif work? I'm guessing this sort of issue comes up regularly. ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] 7.4 feature freeze is here
On Fri, 4 Jul 2003 04:03 pm, Josh Berkus wrote: I don't quite understand this. This doesn't mean that *postgresql* is threaded, does it? I was just referring to the client interfaces ECPG and libpq. AFAIK the back-end is not threaded (and I'm beginning to understand why not). So my app starts multiple threads of execution through the ECPG libs... the ECPG libs (and libpq) start multiple sockets to the back-end - one for each thread. No changes to the back-end. That's my understanding - Lee did most of the work, so maybe he can confirm that. Regards, Philip Yarra. ---(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] 7.4 feature freeze is here
On Thu, 3 Jul 2003 12:14 am, you wrote: I usually do it, but it might take a week to put together. You might like to mention that (as far as I can tell) ECPG is now safe for pthreads on Linux and FreeBSD. The recursive mutex locks are removed, so even platforms that implement the earlier version of pthreads ought to work as well, once configure supports them (anyone care to actually test this assertion?) I don't know if other people think this is a killer feature but it means people porting from embedded SQL platforms where thread support has existed for some time (like Informix and Sybase) will have an easier time of it. Regards, Philip Yarra. ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
[HACKERS] ECPG thread success (kind of) on Linux
On Thu, 26 Jun 2003 11:19 am, Philip Yarra wrote: there appears to still be a problem occurring at EXEC SQL DISCONNECT con_name. I'll look into it tonight if I can. I did some more poking around last night, and believe I have found the issue: RedHat Linux 7.3 (the only distro I have access to currently) ships with a fairly challenged pthreads inplementation. The default mutex type (which you get from PTHREAD_MUTEX_INITIALIZER) is, according the the man page, PTHREAD_MUTEX_FAST_NP which is not a recursive mutex. If a thread owns a mutex and attempts to lock the mutex again, it will hang. By replacing PTHREAD_MUTEX_INITIALIZER with PTHREAD_MUTEX_RECURSIVE_NP for the two mutexes that are used recursively (debug_mutex and connections_mutex) I got my sample app to work flawlessly on Linux RedHat 7.3 Sadly, the _NP suffix is used to indicate non-portable, so of course my FreeBSD box steadfastly refused to compile it. Darn. The correct way to do this appears to be: pthread_mutexattr_t *mattr; pthread_mutexattr_settype(mattr, PTHREAD_MUTEX_RECURSIVE); (will verify this against FreeBSD when I get home, and Tru64 man page indicates support for this too, so I'll test that later). It won't work on RedHat Linux 7.3... I guess something like: #ifdef DODGY_PTHREADS #define PTHREAD_MUTEX_RECURSIVE = PTHREAD_MUTEX_RECURSIVE_NP #endif might do it... if we could detect the problem during configure. How is this sort of detection handled in other cases (such as long long, etc)? The other solution I can think of is to eradicate the two recursive locks I found. One is simple: ECPGlog calls ECPGdebug, which share debug_mutex - it ought to be okay to use different mutexes for each of these functions (there's a risk someone might call ECPGdebug while someone else is running through ECPGlog, but I think it is less likely, since it is a debug mechanism.) The second recursive lock I found is ECPGdisconnect calling ECPGget_connection, both of which share a mutex. Would it be okay if we did the following: ECPGdisconnect() still locks connections_mutex, but calls ECPGget_connection_nr() instead of ECPGget_connection() ECPGget_connection() becomes a locking wrapper, which locks connections_mutex then calls ECPGget_connection_nr() ECPGget_connection_nr() is a non-locking function which implements what ECPGget_connection() currently does. I'm not sure if this sort of thing is okay (and there may be other recursive locking scenarios that I haven't exercised yet). What approach should I take? I'm leaning towards eradicating recursive locks, unless someone has a good reason not to. All this does kinda raise the interesting question of why it worked at all on FreeBSD... probably different scheduling and blind luck, I suppose. FreeBSD 4.8 must have PTHREAD_MUTEX_RECURSIVE as default mutex type. I'm a bit concerned about FreeBSD 4.2 though - I noticed (before I blew it away in favour of 4.8) that its pthreads implementation came from a package called linuxthreads.tgz - it might have inherited the same problematic behaviour. Could someone with access to or knowledge of FreeBSD 4.2 check what the default mutex type is there? Regards, Philip. I can just see the ad for 7.3's pthreads impementation Fast mutexes: zero to deadlock in 6.9 milliseconds! ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] ECPG thread success (kind of) on Linux
On Fri, 27 Jun 2003 11:58 am, AgentM wrote: According to POSIX 1003.1c-1995, no such mutex-altering function exists. Thanks for the info - useful to know. lock the mutex- potentially again). Either that or the recursive locks can be eliminated. Avoiding recursive locks is my preference - the only two I have found ought to be easy to avoid. Just for the record, OS X, Solaris 5.8, FreeBSD 4.8, and LinuxThreads support the UNIX98 version, so perhaps this isn't so important after all. Add Tru64 (aka OSF1, aka DEC Unix) to that list. Just checked it. Regards, Philip. ---(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] ECPG still having thread problems - follow-up
On Wed, 18 Jun 2003 02:58 pm, Philip Yarra wrote: Hi all, it looks like Lee's ECPG (and libpq) thread-safety patches have been applied, and configure --with-threads is also added. I have been doing some testing, and I still encounter a threading problem. For those interested, I tested this on FreeBSD 4.8, and it works fine (as in, no threads hang). I'm not sure what to make of that. Sounds like something more might be required for pthreads on Linux. Regards, Philip. ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
[HACKERS] ECPG still having thread problems
Hi all, it looks like Lee's ECPG (and libpq) thread-safety patches
have been applied, and configure --with-threads is also added. I
have been doing some testing, and I still encounter a
threading problem.
I have done the following:
1) cvs update
2) ./configure --with-threads make su -c make install
3) compiled cn.pgc as follows:
a) ecpg -t cn.pgc
b) gcc -I/usr/local/pgsql/include -L/usr/local/pgsql/lib \
-lecpg -lpgtypes -lpthread cn.c
4) ./a.out - one thread runs to completion (inserts 5 records),
the other hangs (manages one insert, then blocks forever)
Using gdb, I attached to the LWP that has locked up, and the backtrace
looks like this:
(gdb) backtrace
#0 0x420e0187 in poll () from /lib/i686/libc.so.6
#1 0x4007d8cc in pqSocketPoll () from /usr/local/pgsql/lib/libpq.so.3
#2 0x4007d7ed in pqSocketCheck () from /usr/local/pgsql/lib/libpq.so.3
#3 0x4007d71f in pqWaitTimed () from /usr/local/pgsql/lib/libpq.so.3
#4 0x4007d6f5 in pqWait () from /usr/local/pgsql/lib/libpq.so.3
#5 0x4007bb53 in PQgetResult () from /usr/local/pgsql/lib/libpq.so.3
#6 0x4007bcbb in PQexec () from /usr/local/pgsql/lib/libpq.so.3
#7 0x40026d81 in ECPGexecute () from /usr/local/pgsql/lib/libecpg.so.4
#8 0x4002724c in ECPGdo () from /usr/local/pgsql/lib/libecpg.so.4
#9 0x08048927 in ins2 ()
#10 0x40043faf in pthread_start_thread () from /lib/i686/libpthread.so.0
(The other threads are waiting to pthread_join)
I'd really appreciate it if someone could try this sample app to
confirm whether I am doing something wrong, or my environment is
faulty, or if there is still a thread problem.
Build env:
Linux 2.4.18-3
gcc version 2.96 2731 (Red Hat Linux 7.3 2.96-113)
Philip Yarra.
/* on linux, you can compile with:
ecpg cn.pgc gcc -I/usr/local/pgsql/include -L/usr/local/pgsql/lib -lpgtypes -lecpg -lpthread cn.c
and you'll need this table:
CREATE TABLE foo (
message character(40)
);
*/
#include pthread.h
int main();
void ins1();
void ins2();
int main()
{
pthread_t thread1, thread2;
pthread_create(thread1, NULL, (void *) ins1, NULL);
pthread_create(thread2, NULL, (void *) ins2, NULL);
pthread_join(thread1, NULL);
pthread_join(thread2, NULL);
printf(Done!);
return 0;
}
void ins1()
{
int i;
EXEC SQL BEGIN DECLARE SECTION;
char* cs = [EMAIL PROTECTED];
char* bar = one!;
EXEC SQL END DECLARE SECTION;
EXEC SQL WHENEVER sqlerror sqlprint;
EXEC SQL CONNECT TO :cs AS test1;
EXEC SQL SET AUTOCOMMIT TO ON;
for (i = 0; i 5; i++)
{
printf(thread1 inserting\n);
EXEC SQL INSERT INTO foo VALUES(:bar);
printf(==thread1 insert done\n);
}
EXEC SQL DISCONNECT test1;
printf(done!\n);
}
void ins2()
{
int i;
EXEC SQL BEGIN DECLARE SECTION;
char* cs = [EMAIL PROTECTED];
char* bar = two!;
EXEC SQL END DECLARE SECTION;
EXEC SQL WHENEVER sqlerror sqlprint;
EXEC SQL CONNECT TO :cs AS test2;
EXEC SQL SET AUTOCOMMIT TO ON;
for (i = 0; i 5; i++)
{
printf(thread2 inserting\n);
EXEC SQL INSERT INTO foo VALUES(:bar);
printf(==thread2 insert done\n);
}
EXEC SQL DISCONNECT test2;
printf(done!\n);
}
---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] Feature freeze date
On Wed, 11 Jun 2003 12:10 pm, The Hermit Hacker wrote: you have to give it a password ... any password, but a password non the less ... someone else asked me this also, and if I enter no passwd, I can get the same error message ... The reason for the confusion might be because here: http://developer.postgresql.org/docs/postgres/cvs.html#ANONCVS the instructions state You will be prompted for a password; just press ENTER. which previously worked for me. For those of us using anon CVS, Marc's advice works fine: password a works for me and I can authenticate now. Philip. ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
