[HACKERS] PostgreSQL port from DBExperts anybody using it ?
Hi, I was wondering if anybody here has any feedback on the windows version of PostgreSQL from DBExperts. Stability Speed Support Anything else I should know. Thanks -- Patrick McLaughlin Les Logiciels S.I.G.M. Inc. Programmeur analyste ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [Monotone-devel] Re: [HACKERS] SCMS question
On Thu, Feb 22, 2007 at 03:13:49PM +0100, Markus Schiltknecht wrote: > one sparc (osol). So far all gcc compiled, AFAIK. I think, that buildbot was gcc on solaris9/sparc. I care for support of monotone built with sunpro on solaris10 (and opensolaris) on x86 and sparc (but no buildbot for those). there was once some work on msvc support, but I have no idea what happened to that. patrick georgi ---(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] recover without $PGDATA/global
here's a resume of what i am doing. note that i don't have the global direcotry of $PGDATA. first of all reinstall a new hard-drive and installed the same version of postgresql (8.0.4) with the same configuration. now doing a initdb somewhere on the new hd. then createdb the same database (with the same name) so now i have a working structure (with a global dir) now with oid2name i can find what is what in my $PGDATA/base so now it's time to put my $BACKUP/$PGDATA/base in the new $PGDATA/base but renaming my back-up with the new oid (only the first folder not sub-dir.) - i don't replace template0, template1 now a cp -R $BACKUP/$PGDATA/pg_xlog $PGDATA/ now a cp -R $BACKUP/$PGDATA/pg_clog $PGDATA/ now i have to use pg_resetxlog to fit my needs. this is what i'm not sure, i have 0001000E and 0001000F in pg_xlog. what should i use as arguments to pg_resetxlog -o -x -l. after finding the good arguments, i will be able to start postmaster and see my tables, cause right now it's always no realtions founds no matter my test with pg_resetxlog? also is it true that i will need to change also the oid of each files in $PGDATA/base/mydboid/* - this is impossible since i don't know the structure of my table before the hd crashed. yes and sorry for cross-posting to general... regards, pat ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] PostgreSQL for VAX on NetBSD/OpenBSD
On Sun, Jun 29, 2014 at 3:12 PM, Dave McGuire wrote: > On 06/29/2014 03:10 PM, Patrick Finnegan wrote: > > And it also runs on the 11/780 which can have multiple CPUs... but I've > > never seen support for using more than one CPU (and the NetBSD page > > still says "NetBSD/vax can only make use of one CPU on multi-CPU > > machines"). If that has changed, I'd love to hear about it. Support > > for my VAX 6000 would also be nice... > > It changed well over a decade ago, if memory serves. The specific > work was done on a VAX-8300 or -8350. I'm pretty sure the 11/780's > specific flavor of SMP is not supported. (though I do have a pair of > 11/785s here...wanna come hack? ;)) > If it works, someone should update the documentation. :) Which flavor of 11/78x MP? The official DEC kind (which is really just two computers with a block of shared memory) or the Purdue kind (which isn't quite SMP, but actually shares the system bus)? Pat
Re: [HACKERS] PostgreSQL for VAX on NetBSD/OpenBSD
On Sun, Jun 29, 2014 at 3:01 PM, Dave McGuire wrote: > On 06/29/2014 02:58 PM, Patrick Finnegan wrote: > > Last I checked, NetBSD doesn't support any sort of multiprocessor VAX. > > Multiprocessor VAXes exist, but you're stuck with either Ultrix or VMS > > on them. > > Hi Pat, it's good to see your name in my inbox. > Hi! :) > > NetBSD ran on multiprocessor BI-bus VAXen many, many years ago. Is > that support broken? > And it also runs on the 11/780 which can have multiple CPUs... but I've never seen support for using more than one CPU (and the NetBSD page still says "NetBSD/vax can only make use of one CPU on multi-CPU machines"). If that has changed, I'd love to hear about it. Support for my VAX 6000 would also be nice... . Pat
Re: [HACKERS] PostgreSQL for VAX on NetBSD/OpenBSD
Last I checked, NetBSD doesn't support any sort of multiprocessor VAX. Multiprocessor VAXes exist, but you're stuck with either Ultrix or VMS on them. Pat On Sun, Jun 29, 2014 at 2:06 PM, Tom Lane wrote: > Dave McGuire writes: > > On 06/29/2014 10:54 AM, Andres Freund wrote: > >> Maybe I'm just not playful enough, but keeping a platform alive so we > >> can run postgres in simulator seems a bit, well, pointless. > > > On the "in a simulator" matter: It's important to keep in mind that > > there are more VAXen out there than just simulated ones. I'm offering > > up a simulated one here because I can spin it up in a dedicated VM on a > > VMware host that's already running and I already have power budget for. > > I could just as easily run it on real hardware...there are, at last > > count, close to forty real-iron VAXen here, but only a few of those are > > running 24/7. I'd happily bring up another one to do Postgres builds > > and testing, if someone will send me the bucks to pay for the additional > > power and cooling. (that is a real offer) > > Well, the issue from our point of view is that a lot of what we care about > testing is extremely low-level hardware behavior, like whether spinlocks > work as expected across processors. It's not clear that a simulator would > provide a sufficiently accurate emulation. > > OTOH, the really nasty issues like cache coherency rules don't arise in > single-processor systems. So unless you have a multiprocessor VAX > available to spin up, a simulator may tell us as much as we'd learn > anyway. > > (If you have got one, maybe some cash could be found --- we do have > project funds available, and I think they'd be well spent on testing > purposes. I don't make those decisions though.) > > regards, tom lane > >
[HACKERS] Static Code Analysis Exploits.
Hi, We use Postgres in our product and we have a client that requires a static code analysis scan to detect vulnerabilities. They are concerned because the tool (Veracode) found several flaws in Postgres and they believe there might be a security risk. I'm sure there are lots of companies that use Postgres that have security policies like theirs in place, so I'm hoping someone has the experience to know that these are false positives or that they are not a security risk for some reason. Below is a description of the vulnerability and the location in the source code. Version 9.3.2.1 was scanned. Please let me know if there is a better place to ask this kind of question. Thanks, Patrick Stack-based Buffer Overflow (CWE ID 121)(13 flaws): There is a potential buffer overflow with these functions. If an attacker can control the data written into the buffer, the overflow may result in execution of arbitrary code. btree_gist.dll .../btree_gist/btree_utils_num.c 115 btree_gist.dll .../btree_gist/btree_utils_num.c 123 pgcrypto.dll .../contrib/pgcrypto/crypt-md5.c 103 libpq.dll .../interfaces/libpq/fe-connect.c 3185 libpq.dll .../interfaces/libpq/fe-connect.c 3220 clusterdb.exe .../interfaces/libpq/fe-connect.c 3243 libpq.dll .../libpq/fe-protocol3.c 1661 libecpg_compat.dll .../ecpg/compatlib/informix.c 978 pgcrypto.dll .../contrib/pgcrypto/mbuf.c 112 pgcrypto.dll .../contrib/pgcrypto/mbuf.c 290 pgcrypto.dll .../contrib/pgcrypto/mbuf.c 306 pgcrypto.dll .../contrib/pgcrypto/mbuf.c 330 libpq.dll .../interfaces/libpq/pqexpbuffer.c 369 Use of Inherently Dangerous Function (CWE ID 242)(1 flaw): These functions are inherently unsafe because they does not perform bounds checking on the size of their input. An attacker can send overly long input and overflow the destination buffer, potentially resulting in execution of arbitrary code. pg_isolation_regress.exe .../src/test/regress/pg_regress.c 2307 Integer Overflow or Wraparound (CWE ID 190)(1 flaw): An integer overflow condition exists when an integer that has not been properly sanity checked is used in the determination of an offset or size for memory allocation, copying, concatenation, or similarly. If the integer in question is incremented past the maximum possible value, it may wrap to become a very small, negative number, therefore providing an unintended value. This occurs most commonly in arithmetic operations or loop iterations. Integer overflows can often result in buffer overflows or data corruption, both of which may be potentially exploited to execute arbitrary code. dict_snowball.dll .../libstemmer/utilities.c 371 Process Control (CWE ID 114)(4 flaws) A function call could result in a process control attack. An argument to a process control function is either derived from an untrusted source or is hard-coded, both of which may allow an attacker to execute malicious code under certain conditions. If an attacker is allowed to specify all or part of the filename, it may be possible to load arbitrary libraries. If the location is hard-coded and an attacker is able to place a malicious copy of the library higher in the search order than the file the application intends to load, then the application will load the malicious version. psql.exe .../src/bin/psql/print.c 752 psql.exe .../src/bin/psql/print.c 791 psql.exe .../src/bin/psql/print.c 2209 psql.exe .../src/bin/psql/print.c 2500 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Static Code Analysis Exploits.
On 03/07/2014 07:19 PM, Tom Lane wrote: Patrick Curran writes: We use Postgres in our product and we have a client that requires a static code analysis scan to detect vulnerabilities. They are concerned because the tool (Veracode) found several flaws in Postgres and they believe there might be a security risk. I'm sure there are lots of companies that use Postgres that have security policies like theirs in place, so I'm hoping someone has the experience to know that these are false positives or that they are not a security risk for some reason. Below is a description of the vulnerability and the location in the source code. Version 9.3.2.1 was scanned. Please let me know if there is a better place to ask this kind of question. TBH, I don't think anyone's going to bother with going through this list in this form. Line numbers in something that's not an official community release are not very helpful, and the descriptions are far too vague for someone looking at the list to be sure exactly what their tool is on about. I took one example at random: Stack-based Buffer Overflow (CWE ID 121)(13 flaws): There is a potential buffer overflow with these functions. If an attacker can control the data written into the buffer, the overflow may result in execution of arbitrary code. libpq.dll .../interfaces/libpq/pqexpbuffer.c 369 This seems to be complaining about the memcpy in appendBinaryPQExpBuffer. Well, I don't see anything unsafe about it: the preceding call to enlargePQExpBuffer should have made sure that the target buffer is big enough. And the reference to stack-based buffer overflow is completely nonsensical, because no PQExpBuffer keeps its buffer on the stack. It's conceivable that their tool has spotted some unsafe pattern in some call site, but this report is unhelpful about identifying what that would be. I did look at a few of the other items, and none of the ones I looked at were any more clear. FWIW, we do have access to Coverity scans of the Postgres sources, and we do make efforts to fix things Coverity complains about. But we're unlikely to take reports like this one seriously: there's simply not enough information to know what the tool is unhappy about, nor any clear reason to believe that it's spotted something that both human readers and Coverity have missed. Sorry if that's not the answer you wanted; but a more positive response is going to require a substantially greater amount of work on your end. In particular, given the very substantial amounts of work that have already gone into hardening the Postgres code, I think the burden of proof is on you or your client to show that these are issues, not on us to disprove claims that are too vague to be disproven. regards, tom lane I understand. It makes perfect sense. Thanks for your response. It's actually been quite helpful. Thanks again, Patrick -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Select For Update and Left Outer Join
[I previously posted this to pgsql-sql, but received no response as of yet... it's more of a development team oriented message in any case.] In ORMs like NHibernate, there are a few strategies for mapping inheritance to SQL. One of these is "Joined Subclass," which allows for the elimination of duplicate data and clean separation of class contents. With a class hierarchy such as this: Pet Dog : Pet Cat : Pet The query to get all the pets is as follows: select * from Pet left join Dog on Dog.Id = Pet.Id left join Cat on Cat.Id = Pet.Id Now suppose you want to lock to ensure that your Cat is not updated concurrently. You add FOR UPDATE, but then PostgreSQL gets upset and complains that locking on the nullable side of an outer join is not allowed. >From our data model, we know that for every single Pet, there can never be a Dog or Cat that spontaneously appears, so locking in this case is totally safe. Unfortunately, PostgreSQL doesn't seem to provide any mechanism to lock just the rows involved in this query. Any advice? I'd be happy if such a thing was implemented in the engine, as it's supported by other databases without trouble. As another note, I'm one of the NHibernate developers and I'm working to get all the NHibernate tests working with PostgreSQL. The two significant cases I've had to avoid testing are the "FOR UPDATE" mentioned above and null characters in UTF strings. Storing a UTF "char" which defaults to zero doesn't work on PostgreSQL because it's apparently still using zero-terminated string functions. :( Aside from those two things, it looks like PostgreSQL is going to be passing all the tests soon, so that's good news. :) Patrick Earl -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Select For Update and Left Outer Join
On Sun, May 1, 2011 at 4:05 PM, Tom Lane wrote: > Patrick Earl writes: >> The query to get all the pets is as follows: > >> select * from Pet >> left join Dog on Dog.Id = Pet.Id >> left join Cat on Cat.Id = Pet.Id > >> Now suppose you want to lock to ensure that your Cat is not updated >> concurrently. You add FOR UPDATE, but then PostgreSQL gets upset and >> complains that locking on the nullable side of an outer join is not >> allowed. > > Quite. What would it mean to lock the absence of a row? > >> From our data model, we know that for every single Pet, there can >> never be a Dog or Cat that spontaneously appears, so locking in this >> case is totally safe. > > You might know that, but you didn't explain how you know that or how > the database could be expected to know it. > > regards, tom lane > I would argue that SELECT FOR UPDATE never locks on the absence of a row. For example, if I do: SELECT * FROM Table WHERE Column = 10 The existing rows are locked, but somebody could come along and add another unlocked row with Column = 10. Whether I'm specifying a secondary set of records (via a criteria involving a join) or a primary set of records (via a regular where criteria), FOR UPDATE always allows new rows to appear. The fact that new rows are not locked is common and expected. Whether they appear in the result set due to the join or due to the where clause seems unimportant to me. Patrick Earl -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Select For Update and Left Outer Join
On Sun, May 1, 2011 at 9:00 PM, Tom Lane wrote: > Addition of new rows certainly isn't supposed to be prevented by a > SELECT FOR UPDATE, but that's not the problem here. What I *do* expect > a SELECT FOR UPDATE to promise is that the rows it did return can't > change or be deleted by someone else for the life of my transaction. > This is not possible to promise for null-extended rows unless you > somehow lock out addition of a matching row on the inside of the join. > Without that, a row that looked like when you > selected it might suddenly start looking like > due to someone else's modification. And after that, since you still > haven't got a lock on the cat row, the cat fields could keep on > changing. > > I'm prepared to believe that there are some applications where that > can't happen due to other interlocking, or doesn't matter to the > application, but SELECT FOR UPDATE really can't assume that. I think > what you're proposing is to fundamentally break the semantics of SELECT > FOR UPDATE for the sake of convenience. While I don't have access to the SQL standard to check if the semantics are documented, the semantics don't seem clear cut. The question is whether the thing that you've promised won't change is the result row of the query or the source rows that built the result. I would like to know how other databases handle this, but I do know that it works on MSSQL. Perhaps it's using something like the source row locking semantics I mentioned. > You didn't explain exactly why your application doesn't care about this, > but I wonder whether it's because you know that a lock on the parent > "pet" row is sufficient due to application coding rules. If so, you > could just tell SELECT FOR UPDATE to only lock the "pet" rows, and be > happy: > > select * from pet left join cat ... for update of pet; If I select a collection that contains both dogs and cats, run a polymorphic operation that affects dogs and cats differently, then save my results back, I would need locks on all rows, not just the pet information. When "parts" of a "row" are stored in different tables, the results from both tables need to be locked. I see a couple possible workarounds, neither of which are particularly appealing: * Run many queries, being careful to ensure the appropriate rows from each table are locked. * Lock all related tables. Perhaps the syntax could be extended to indicate to the database that it's safe to lock on just the selected rows. select * from pet left join cat ... for update of pet, cat; On a conceptual level, I still tend to think of select for update as "locking the data returned by the query." If no data is returned by the query, I don't get a lock on that non-data. Is this an area that is covered by the standard? Thanks for your thoughts on this Tom. Your time is much appreciated. Patrick Earl -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] FW: VACUUM FULL Error
Hi there Any suggestion how to get around this issue I am having with vacuum command I’m running on 8.1 version of prostgre SQL. The VACUUM FULL command seems to get stuck on vacuuming "pg_catalog.pg_largeobject" (last message for Verbose) Now attempting below - but not hopeful that it will complete successfully. > VACUUM VERBOSE pg_catalog.pg_largeobject; With initial Message INFO: vacuuming "pg_catalog.pg_largeobject" How long should I wait for this to complete – if it ever does? It has currently been running for over 30 minutes. Refer to the forwarded message below for additional information. My fallback is that an archive of the existing DB (almost 2 TBytes) has been made and verified (via VEEAM Clone process). It contains all of the historical records the need to be retained in a read-only DB. The only option I seem to have is to drop the DB and start with a blank canvas. Not an option I want to take as I am not postgre SQL expect. Help!!! From: Hayes, Patrick Sent: 29 December 2016 10:53 To: 'pgadmin-supp...@postgresql.org' Subject: VACUUM FULL Error Hi pgAdmin support, Recently truncated tables in Postgre SQL DB and now unable to free up disk space on server with the VACUUM FULL command. The DB is 1.91TBytes in size. Server is running Win 2008 R2 Standard Operating System. Postgre SQL is version 8.1 Error message reads as follows: ERROR: out of memory DETAIL: Failed on request of size 134217728. Adding memory to server does not seem to make any difference. Re-starting the server makes no difference. The VACUUM command always ends in the same record 134217728. Is there any way to selectively VACUUM tables – divide and conquer approach. Thank you in advance for any support you can provide Patrick Hayes [cid:image001.jpg@01D261C1.B01E8BE0]
Re: [HACKERS] VACUUM FULL Error
Hi there Can this be forwarded to someone who can assist with this query? Thank you, Patrick Hayes From: Hayes, Patrick Sent: 29 December 2016 12:26 To: 'pgsql-hackers@postgresql.org' Subject: FW: VACUUM FULL Error Hi there Any suggestion how to get around this issue I am having with vacuum command I’m running on 8.1 version of prostgre SQL. The VACUUM FULL command seems to get stuck on vacuuming "pg_catalog.pg_largeobject" (last message for Verbose) Now attempting below - but not hopeful that it will complete successfully. > VACUUM VERBOSE pg_catalog.pg_largeobject; With initial Message INFO: vacuuming "pg_catalog.pg_largeobject" How long should I wait for this to complete – if it ever does? It has currently been running for over 30 minutes. Refer to the forwarded message below for additional information. My fallback is that an archive of the existing DB (almost 2 TBytes) has been made and verified (via VEEAM Clone process). It contains all of the historical records the need to be retained in a read-only DB. The only option I seem to have is to drop the DB and start with a blank canvas. Not an option I want to take as I am not postgre SQL expect. Help!!! From: Hayes, Patrick Sent: 29 December 2016 10:53 To: 'pgadmin-supp...@postgresql.org' mailto:pgadmin-supp...@postgresql.org>> Subject: VACUUM FULL Error Hi pgAdmin support, Recently truncated tables in Postgre SQL DB and now unable to free up disk space on server with the VACUUM FULL command. The DB is 1.91TBytes in size. Server is running Win 2008 R2 Standard Operating System. Postgre SQL is version 8.1 Error message reads as follows: ERROR: out of memory DETAIL: Failed on request of size 134217728. Adding memory to server does not seem to make any difference. Re-starting the server makes no difference. The VACUUM command always ends in the same record 134217728. Is there any way to selectively VACUUM tables – divide and conquer approach. Thank you in advance for any support you can provide Patrick Hayes [cid:image001.jpg@01D261CF.0E36C280]
Re: [HACKERS] Select For Update and Left Outer Join
Okay, I finally had time to install a bunch of databases and see what the "industry" thinks. I tested the four seemingly most pertinent databases. The ability to "select for update" with a left outer join is present on these databases: * Oracle * SQL Server (not the same syntax, but does support the functionality) * MySQL It is not present in DB2, though I didn't check if it offered workarounds. Oracle and SQL Server did not limit the creation of the row that would fill the empty join. The ability to lock on outer joins is quite useful. I've even been contacted to ask if I was aware of any progress in this area. So, given that the majority of the important databases support it, I would propose that it would be a reasonable addition to PostgreSQL. It seems there is a difference of opinion about the locking model, but it seems that there are two possibilities: 1. Disallow it, hoping to save a naive user from an error. 2. Allow it, providing a significant piece of functionality. I would argue that the ability to perform a significant function such as this outweighs the needs of the naive user to be informed of his potential errors. Thanks for your consideration in this matter. Patrick Earl -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Full GUID support
I'd have to agree on the importance of UUID support. It's pretty much essential for any sort of disconnected sync model. We use UUIDs (generated with the "guid.comb" technique) for our surrogate keys in around 50 apps, and it has served us well. We have also been seriously missing the 64-bit generator functionality. I've been watching the threads for half a year to see when it will pop up again. It's been a long wait. Regarding UUID generation, IMHO, the random approach is the "standard" at this point. That'd be v4 in the oisp library. It would be handy to be able to generate these without having to load in special extensions. It's not the biggest deal though since we can run initialization code to get the database set up... just more effort. Patrick Earl On Mon, Jul 11, 2011 at 11:19 AM, Joshua D. Drake wrote: > Uh UUID/GUID is used pervasively throughout enterprise apps, especially > Java apps. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] write past chunk end in ExprContext / to_char
With today's CVS code (originally noticed with 8.2beta3), on a PC where INT_MAX=0x7FFF=2147483647 postgres=# select version(); version - PostgreSQL 8.3devel on i386-unknown-netbsdelf4.99.20, compiled by GCC gcc (GCC) 4.1.2 20070110 prerelease (NetBSD nb1 20070603) (1 row) postgres=# select to_char(2147483647,'999,999,999'); to_char -- ###,###,### (1 row) postgres=# select to_char(2147483648,'999,999,999'); WARNING: detected write past chunk end in ExprContext 0x845509c WARNING: detected write past chunk end in ExprContext 0x845509c to_char -- ###,###,### (1 row) postgres=# select to_char(2147483648,'99,999,999'); to_char - ##,###,### (1 row) postgres=# select to_char(2147483648,'9,999,999,999'); to_char 2,147,483,648 (1 row) postgres=# select to_char(1234567890123,'999,999,999,999'); WARNING: detected write past chunk end in ExprContext 0x845509c WARNING: detected write past chunk end in ExprContext 0x845509c to_char -- ###,###,###,### (1 row) postgres=# select to_char(1234567890123,'99,999,999,999'); to_char - ##,###,###,### (1 row) So strangely, to get the worrying WARNING, I seem to need >INT_MAX with a format string with 1 less positions than necessary - no wonder I seemed to only see it randomly... Thoughts? Cheers, Patrick ---(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] autoconf
I know that it doesn't matter as configure is in CVS, so there is no need for mere mortals to regenerate it, but why is RCS file: /projects/cvsroot/pgsql/configure.in,v revision 1.538 date: 2007/11/26 12:31:07; author: petere; state: Exp; lines: +2 -2 Require a specific Autoconf version, instead of a lower bound only. a good idea? Cheers, Patrick ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Password policy
On Wednesday 16 January 2008 08:32, Andrew Dunstan wrote: > ( Slightly OT - chkpass uses crypt(). Maybe that should be upgraded to > use md5 or some more modern hashing function. ) Some versions of crypt() will generate md5 hashes if you start the salt with $1$$. I know this to work on FreeBSD, NetBSD, and Fedora core, and I believe it also works on other Linux distributions and Solaris. I have a patch to chkpass.c which will do this based on a custom GUC. The nice thing about this is that it continues to work with mod_auth_pgsql. I did have to change the on-disk representation to fit in the extra data. D'Arcy, if you're interested I'll send you a patch. -- Patrick TJ McPhee <[EMAIL PROTECTED]> ---(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] quoting bug?
Given the following trivial trigger example: -- create language plpgsql; create table foo (a integer, b text, c timestamp); create function foo_insert() returns trigger as $$ begin raise notice '%', new; return null; end; $$ language plpgsql; create trigger foo_ins before insert on foo for each row execute procedure foo_insert(); insert into foo values (1, 'two', current_timestamp); I am surprised to see NOTICE: (1,two,"Sat 09 Feb 16:47:44.514503 2008") INSERT 0 0 I would have expected NOTICE: (1,'two','Sat 09 Feb 16:47:44.514503 2008') INSERT 0 0 i.e., a row whose columns look as though they went through quote_literal rather than through quote_ident. This is with yesterday's 8.3.0 (Feb 8 17:24 GMT) Thoughts? Cheers, Patrick ---(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] quoting bug?
On Sat, Feb 09, 2008 at 12:29:10PM -0500, Tom Lane wrote: > Patrick Welche <[EMAIL PROTECTED]> writes: > > I am surprised to see > > > NOTICE: (1,two,"Sat 09 Feb 16:47:44.514503 2008") > > This is the expected formatting for a composite type. Read > http://www.postgresql.org/docs/8.3/static/rowtypes.html#AEN6266 Thank you - sorry for noise. Patrick ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] Documentation on page files
Martijn, It may be useful to look at the pg_filedump utility located at http://sources.redhat.com/rhdb/tools.html This utility dumps out information at the page level and is commented to help the user understand the format/content of PostgreSQL heap/index/control files. Cheers, Patrick - Patrick Macdonald Red Hat Database Tom Lane wrote: > > Martijn van Oosterhout <[EMAIL PROTECTED]> writes: > > Chapter 7 of the Developers guide in about the Page Format on disk and it's > > a little out of date not to mention somewhat incomplete. > > Indeed, this seems to have very little relation to reality :-(. > I didn't even realize that we had such a description in the SGML docs. > It's obviously not been updated for many years. I'm not sure if the > "continuation" mechanism it describes ever existed at all, but it sure > hasn't been there since the code left Berkeley. > > > 1. Is there documentation elsewhere (other than the source)? > > Not that I can think of. The most accurate information seems to be in > src/include/storage/bufpage.h; AFAICT all the comments in that file are > up-to-date. In addition to this it'd be worth pulling out some > description of the "special space" structures used by the various index > access methods. > > > 2. If not, would patches be accepted to correct the situation? > > Go for it. > > regards, tom lane > > ---(end of broadcast)--- > TIP 5: Have you checked our extensive FAQ? > > http://www.postgresql.org/users-lounge/docs/faq.html ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] PostgreSQL mission statement?
On Thu, May 02, 2002 at 01:14:34PM -0300, Marc G. Fournier wrote: > On 2 May 2002, Hannu Krosing wrote: ... > > BTW, I think PostgreSQL does _not_ need any mission statement. > > Nope, it doesn't ... never did before, don't know why it does suddenly ... > do any other open source projects have one? Its kinda fun to see what ppl > banter around, but I can't see it being useful to adopt any single one, > considering I can't see *everyone* agreeing with it ... Quick - get out the Dilbert! Patick ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Issues Outstanding for Point In Time Recovery (PITR)
J.R., Nice first draft and a good read. Was going to comment in-line but thought this method would be easier to follow. The comments/suggestions below assume that PIT recovery is being performed at the cluster level with a data backup image created by a tar-like utility. As noted, one of the main problems is knowing where to begin in the log. This can be handled by having backup processing update the control file with the first lsn and log file required. At the time of the backup, this information is or can be made available. The control file can be the last file added to the tar and can contain information spanning the entire backup process. For data consistency, since the backup is being performed on an active cluster, we have to make sure to mark the end of the backup. On restore, to make the cluster consistent, you have to force the user to perform forward recovery passed the point of the backup completion marker in the (archived) log. This can be handled using a backup end log record. The backup end log record would have to contain an identifier unique to this backup. If a user requests to stop PIT recovery before this log record is encountered, consistency is not guaranteed. PIT should either disallow the action or warn of possible / impending doom. The necessary logging for rtee (and others) insertions/deletions can be added to the base code. Not much of a worry but I would expect to encounter other missing log items during testing. The idea of using the last lsn on the page to detect a partial write is used by other dbms systems. You already have that information available so there is no overhead in computing it. Nothing wrong with CRC though. As for the DB_SHUTDOWNED state, this could be handled by having the backup processing update the control file field to DB_PIT_REQUIRED (or some such identifier). After a restore, users would be blocked from connecting to the cluster's databases until a forward recovery passed the backup end log record has completed successfully. At the end of normal crash recovery, the user has to go digging to identify in-flight transactions still in the system and abort them manually. It would be nice if PIT recovery automatically aborted all in-flight transactions at the end. As PostgreSQL heads towards forward recovery functionality, it may be wise to add headers to the log files. As the logs from any cluster are identically named, the header would allow unique identification of the file and contents (cluster name, unique log id, id of the prior log file for chaining purposes, lsn ranges, etc). Most helpful. Just a few notes from the administrative side. PIT recovery should probably offer the user the following actions: . forward recover to end of logs [and stop] Process log files located in the current directory until you read through the last one. Allow the user the option to stop or not, just in case the logs are archived. Send back the timestamp of the last encountered commit log record and the series of log files scanned. . forward recover to PIT [and stop] Similar to that described above but use the commit timestamps to gauge PIT progress. . forward recover query Send back the log series covered and the last commit timestamp encountered. . forward recover stop Stop the current forward recovery session. Undo all in-flight transactions and bring the databases down in a consistent state. No other external user actions should be required. Looking forward to reading draft 2. Cheers, Patrick -- Patrick Macdonald Red Hat Canada "J. R. Nield" wrote: > > Hello: > > I've got the logging system to the point where I can take a shutdown > consistent copy of a system, and play forward through multiple > checkpoints. It seems to handle CREATE TABLE/DROP TABLE/TRUNCATE > properly, and things are moving forward well. Recovery to an arbitrary > point-in-time should be just as easy, but will need some administrative > interface for it. > > At this point, some input would be useful on how I should handle things. > > The most important questions that need answering are in sections 2 & 5, > since they impact the most other parts of the system. They will also > require good documentation for sysadmins. > > Issues Outstanding for Point In Time Recovery (PITR) > > $Date: 2002/07/04 14:23:37 $ > > $Revision: 1.4 $ > > J.R. Nield > > (Enc: ISO 8859-15 Latin-9) > > §0 - Introduction > > This file is where I'm keeping track of all the issues I run into while > trying to get PITR to work properly. Hopefully it will evolve into a > description of how PITR actually works once it is implemented. > > I will also try to add feedback as it comes in. > > The big items so-far are: > §1 - Logging Relation file creation, trun
Re: [HACKERS] Issues Outstanding for Point In Time Recovery (PITR)
Zeugswetter Andreas SB SD wrote: > > > As noted, one of the main problems is knowing where to begin > > in the log. This can be handled by having backup processing > > update the control file with the first lsn and log file > > required. At the time of the backup, this information is or > > can be made available. The control file can be the last file > > added to the tar and can contain information spanning the entire > > backup process. > > lsn and logfile number (of latest checkpoints) is already in the control > file, thus you need control file at start of backup. (To reduce the number > of logs needed for restore of an online backup you could force a checkpoint > before starting file backup) Maybe I should have been more clear. The control file snapshot must be taken at backup start (as you mention) but can be stored in cache. The fields can then be modified as we see fit. At the end of backup, we can write this to a temp file and add it to the tar. Therefore, as mentioned, the snapshot spans the entire backup process. > You will also need lsn and logfile number after file backup, to know how much > log needs to at least be replayed to regain a consistent state. This is a nicety but not a necessity. If you have a backup end log record, you just have to enforce that the PIT recovery encounters that particular log record on forward recovery. Once encountered, you know that you at passed the point of back up end. Cheers, Patrick ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Open 7.3 issues
On Thu, Aug 15, 2002 at 12:09:00AM -0400, Neil Conway wrote: > Bruce Momjian <[EMAIL PROTECTED]> writes: ... > > integrate or remove new libpqxx > > integrate or add to gborg Pg:DBD > > > > Seems like gborg is the place for these. > > Yes, but I'd also like to see libpq++, perl5, and possibly some other > interfaces re-packaged separately. I think everyone agrees on the > direction here, it just needs someone (Marc?) to do the work. Would the method of use be - checkout postgresql - cd pgsql/src/interfaces - checkout libpq++ from gborg - cd ../.. - configure --with-CXX or would libpq++ become more removed.. (configure options to libpq++ to point to the rest or pgsql?) Cheers, Patrick (prefer former) ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
[HACKERS] mac typo prob?
I just cut and pasted someone's mac address: patrimoine=# update ethernet set mac='00-00-39-AB-92-FO' where id=623; UPDATE 1 patrimoine=# select mac from ethernet where id=623; mac --- 00:00:39:ab:92:0f (1 row) Note the typo "O" instead of "0". I can see how that happened - should it be "notify"ed against? (pre-25 Sept code, 7.3b1) Cheers, Patrick ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] RC1?
On Thu, Nov 14, 2002 at 06:13:56PM +, Patrick Welche wrote: > On Wed, Nov 13, 2002 at 07:53:00PM +0100, Peter Eisentraut wrote: > > Tom Lane writes: > > > > > We can't just wait around indefinitely for port reports that may or may > > > not ever appear. In any case, most of the "<7.3" entries in the list > > > seem to be various flavors of *BSD; I think it's unlikely we broke > > > those ... > > > > Note that we have *zero* reports for any flavor of NetBSD and OpenBSD. > > That is highly suspicious, and I would not venture a guess about how > > likely it is they're broken. PostgreSQL 7.3b1 on i386-unknown-netbsdelf1.6H, compiled by GCC 2.95.3 PostgreSQL 7.4devel on i386-unknown-netbsdelf1.6K, compiled by GCC 2.95.3 I in fact get geometry.out rather than geometry-positive-zeros.out, but I think you get the former when you use libm387.so.0 instead of libm.so.0 which isn't exactly the general case for NetBSD, though I have only one NetBSD/i386 box which can't make use of libm387 (it's a 486SX25) The 7.4devel was with source from Nov 9 12:27 GMT, so I think rather close to 7.3, and again with source from just now. Cheers, Patrick ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
[HACKERS] Debian build prob
Believe it or not, I'm trying to compile today's cvs pgsql on a Debian 2.2.19 system. Compilation dies while compiling pg_dump with ../../../src/interfaces/libpq/libpq.so: undefined reference to `atexit' In the mail archives there is a mention of upgrading libc to libc6-dev_2.2.5-3_i386.deb. As far as I can tell, that should read libc6_2.2.5-3_i386.deb, and again AFAICT this system already has libc6_2.2.5-6_i386.deb on it. I can see atexit is undefined in libpq, and it is defined in /usr/lib/libc.a. For some reason /lib/libc*.so are stripped, so it is hard to tell, but I assume it must be the same as for /usr/lib/libc.a. Have any of you managed to compile postgresql on an oldstable Debian system? Cheers, Patrick ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] RC1?
On Wed, Nov 13, 2002 at 07:53:00PM +0100, Peter Eisentraut wrote: > Tom Lane writes: > > > We can't just wait around indefinitely for port reports that may or may > > not ever appear. In any case, most of the "<7.3" entries in the list > > seem to be various flavors of *BSD; I think it's unlikely we broke > > those ... > > Note that we have *zero* reports for any flavor of NetBSD and OpenBSD. > That is highly suspicious, and I would not venture a guess about how > likely it is they're broken. Does all OK on this count? PostgreSQL 7.3b1 on i386-unknown-netbsdelf1.6H, compiled by GCC 2.95.3 (I'm trying to build bison at the mo to have a go with whatever is in cvs tip at the moment.) Cheers, Patrick ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Debian build prob
On Thu, Nov 14, 2002 at 08:55:22PM +, Patrick Welche wrote: > Believe it or not, I'm trying to compile today's cvs pgsql on a > Debian 2.2.19 system. Compilation dies while compiling pg_dump with > > ../../../src/interfaces/libpq/libpq.so: undefined reference to `atexit' > > In the mail archives there is a mention of upgrading libc to > libc6-dev_2.2.5-3_i386.deb. As far as I can tell, that should read > libc6_2.2.5-3_i386.deb, and again AFAICT this system already has > libc6_2.2.5-6_i386.deb on it. I can see atexit is undefined in libpq, and it > is defined in /usr/lib/libc.a. For some reason /lib/libc*.so are stripped, > so it is hard to tell, but I assume it must be the same as for > /usr/lib/libc.a. > > Have any of you managed to compile postgresql on an oldstable Debian system? Adam Buraczewski tells me its a linux i386 gcc<=2.95.3 problem. Upgrading gcc to gcc version 2.95.4 20011002 (Debian prerelease) yielded a working postgresql! PostgreSQL 7.4devel on i686-pc-linux-gnu, compiled by GCC 2.95.4 Cheers, Patrick ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] RC1?
On Thu, Nov 14, 2002 at 09:06:01AM -0500, Tom Lane wrote: > "Magnus Naeslund(f)" <[EMAIL PROTECTED]> writes: > > OK OK, before anyone rubs my nose in it, i see the fork() failures :) > > > I'll see what's causing the fork() problems... > > Too low processes-per-user limit, likely. Success for PostgreSQL 7.4devel on acorn32-unknown-netbsd1.6K, compiled by GCC 2.95.3 In other words NetBSD/acorn32-1.6K. The fork() problem for me was not enough memory, but checking with --schedule=./serial_schedule made it pass all the tests, except geometry, which leads me to change my mind and suggest: Index: resultmap === RCS file: /projects/cvsroot/pgsql-server/src/test/regress/resultmap,v retrieving revision 1.59 diff -u -r1.59 resultmap --- resultmap 2002/11/12 20:02:32 1.59 +++ resultmap 2002/11/19 15:20:19 @@ -18,7 +18,6 @@ geometry/alpha.*-freebsd4.[0-5]=geometry-positive-zeros geometry/i.86-.*-openbsd=geometry-positive-zeros geometry/sparc-.*-openbsd=geometry-positive-zeros -geometry/.*-netbsd=geometry-positive-zeros geometry/hppa.*-hpux9=geometry-positive-zeros geometry/hppa.*-hpux10=geometry-positive-zeros geometry/.*-irix6=geometry-positive-zeros as this acorn32 is running on a StrongARM processor, so has nothing to do with libm387. Maybe get rid of the geometry-positive-zeros and see if someone complains and tells me otherwise? Cheers, Patrick ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] RC1?
On Tue, Nov 19, 2002 at 10:53:59AM -0500, Tom Lane wrote: > Patrick Welche <[EMAIL PROTECTED]> writes: > > [remove this:] > > -geometry/.*-netbsd=geometry-positive-zeros > > > as this acorn32 is running on a StrongARM processor, so has nothing to do > > with libm387. Maybe get rid of the geometry-positive-zeros and see if > > someone complains and tells me otherwise? > > Presumably that was put in because it was correct on i86. How do you > feel about changing that entry to > > geometry/i.86-.*-netbsd=geometry-positive-zeros > > rather than deleting it? I was under the impression until now that it was geometry.out for i86 using the libm387 math library, and geometry-positive-zeros for everyone else, but this acorn32 box is also giving geometry.out, so I must be wrong, in fact I've just tried not using libm387 on an i386, and it gives geometry.out too, so we might as well delete it... BTW cluster.out wants changing now that the ALL in CLUSTER ALL is no longer allowed.. Cheers, Patrick ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] RC1?
On Tue, Nov 19, 2002 at 06:22:08PM +0100, Peter Eisentraut wrote: > He was testing 7.4devel. That's not the right one. What's the difference? (Do I really want to wait another day while this ancient box compiles it given that the chances of it working under 7.4devel and not under 7.3rcN are smaller than the chances of it working under 7.3rcN and not under 7.4devel, no?) Patrick ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [PORTS] Geometry test on NetBSD (was Re: [HACKERS] RC1?)
On Wed, Nov 20, 2002 at 06:48:15PM +0100, Peter Eisentraut wrote: > Tom Lane writes: > > > AFAIK, all modern hardware claims compliance to the IEEE floating-point > > arithmetic standard, so failure to print minus zero as minus zero is > > very likely to be a software issue not hardware. That suggests strongly > > that the issue is netbsd version (specifically libc version) and not the > > hardware platform. > > I could confirm my initial suspicion: it's a *printf() library issue. The > FreeBSD CVS log tells the tale: > > http://www.de.freebsd.org/cgi/cvsweb.cgi/src/lib/libc/stdio/vfprintf.c > > The next FreeBSD subrelease (4.8?) should have this fixed. OpenBSD is not > fixed. NetBSD and Darwin seem to have temporarily hidden their cvsweb in > shame, but I would assume it's the same issue. Not sure what HP-UX is > doing about it. Right, the equivalent for NetBSD vfprintf.c is: revision 1.40 date: 2001/11/28 11:58:22; author: kleink; state: Exp; lines: +4 -4 Since we're returned the sign of a floating-point number by __dtoa(), use that to decide whether to include a minus sign in the result. Fixes printing -0.0, and thus PR lib/3137. NetBSD 1.5 has revision 1.32, NetBSD 1.6 has revision 1.42 Well spotted, Patrick ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [PORTS] Geometry test on NetBSD (was Re: [HACKERS] RC1?)
On Wed, Nov 20, 2002 at 01:21:47PM -0500, Tom Lane wrote: > Patrick Welche <[EMAIL PROTECTED]> writes: ... > > NetBSD 1.5 has revision 1.32, NetBSD 1.6 has revision 1.42 > > Ah-hah, so it is a version issue --- we could make the resultmap line > something like > geometry/.*-netbsd1.[0-5]=geometry-positive-zeros > > Would you confirm what config.guess prints on your box --- in > particular, is there a dot in the version number? Yes: NetBSD/i386-1.6H i386-unknown-netbsdelf1.6H (checked 7.3rc1) NetBSD/acorn32-1.6K arm-unknown-netbsdelf1.6K (still building 7.3rc1) (several NetBSDs probably come up with arm-unknown..) Cheers, Patrick ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [PORTS] Geometry test on NetBSD (was Re: [HACKERS] RC1?)
On Wed, Nov 20, 2002 at 01:51:28PM -0500, Tom Lane wrote: > Patrick Welche <[EMAIL PROTECTED]> writes: > > On Wed, Nov 20, 2002 at 01:21:47PM -0500, Tom Lane wrote: > >> Ah-hah, so it is a version issue --- we could make the resultmap line > >> something like > >> geometry/.*-netbsd1.[0-5]=geometry-positive-zeros > > > NetBSD/i386-1.6H i386-unknown-netbsdelf1.6H (checked 7.3rc1) > > NetBSD/acorn32-1.6K arm-unknown-netbsdelf1.6K (still building 7.3rc1) > > Hm, is that "elf" always there? I'm a little uncomfortable with making > the pattern be > geometry/.*-netbsd.*1.[0-5]=geometry-positive-zeros > as this seems way too lax ... "elf" won't always be there - that acorn32 is a case in point: it became elf for 1.6. acorn26 has always been elf. I can't remember when i386 became elf.. (In fact the old config.guess that comes with NeTraMet44b8 says i386-unknown-netbsd1.6K - so maybe the config.guess cvs log may shed some light) Just realised: the answers I gave above were with the config.guess from automake 1.7a! % uname -srmp NetBSD 1.6K acorn32 arm % postgresql-7.3rc1/config/config.guess acorn32-unknown-netbsd1.6K % automake/lib/config.guess arm-unknown-netbsdelf1.6K Confusing.. Patrick ---(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] RC1?
On Wed, Nov 20, 2002 at 09:33:41AM -0500, Bruce Momjian wrote: > Patrick Welche wrote: > > On Tue, Nov 19, 2002 at 06:22:08PM +0100, Peter Eisentraut wrote: > > > He was testing 7.4devel. That's not the right one. > > > > What's the difference? (Do I really want to wait another day while this > > ancient box compiles it given that the chances of it working under > > 7.4devel and not under 7.3rcN are smaller than the chances of it > > working under 7.3rcN and not under 7.4devel, no?) > > Uh, you are right, but we have made a _few_ 7.4 changes so I do think we > need a 7.3-specific test. OK - did 7.3rc1 successfully on NetBSD-1.6K/acorn32 and NetBSD-16H/i386 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] RC1?
On Wed, Nov 20, 2002 at 09:33:41AM -0500, Bruce Momjian wrote: > Patrick Welche wrote: > > On Tue, Nov 19, 2002 at 06:22:08PM +0100, Peter Eisentraut wrote: > > > He was testing 7.4devel. That's not the right one. > > > > What's the difference? (Do I really want to wait another day while this > > ancient box compiles it given that the chances of it working under > > 7.4devel and not under 7.3rcN are smaller than the chances of it > > working under 7.3rcN and not under 7.4devel, no?) > > Uh, you are right, but we have made a _few_ 7.4 changes so I do think we > need a 7.3-specific test. And yes, you are right, I've just spotted a little change: 7.3b1 dump imported into 7.4devel database needs "value" quoted in CREATE TABLE amount ( id serial NOT NULL, value integer ); so "value"'s keyword status must have changed.. Cheers, Patrick ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
[HACKERS] postgres core dump
Just tried a make runcheck with source from Dec 4 15:13 GMT, and:
Core was generated by `postgres'.
Program terminated with signal 11, Segmentation fault.
#0 ExecGetTupType (node=0x8453978) at execProcnode.c:744
744 slot =
hashjoinstate->jstate.cs_ResultTupleSlot;
(gdb) bt
#0 ExecGetTupType (node=0x8453978) at execProcnode.c:744
#1 0x80e6f6e in InitPlan (operation=CMD_INSERT, parseTree=0x837bb68,
plan=0x8453978, estate=0x8453bc0) at execMain.c:585
#2 0x80e69a0 in ExecutorStart (queryDesc=0x8453b94, estate=0x8453bc0)
at execMain.c:124
#3 0x81404bc in ProcessQuery (parsetree=0x837bb68, plan=0x8453978,
dest=Debug, completionTag=0xbfbfb1a4 "Ô±¿¿|à\023\bP³\"\b\n")
at pquery.c:214
#4 0x813e6b1 in pg_exec_query_string (query_string=0x837b01c, dest=Debug,
parse_context=0x8367444) at postgres.c:838
#5 0x813f991 in PostgresMain (argc=9, argv=0x8266000,
username=0x8268120 "prlw1") at postgres.c:2016
#6 0x80fb21f in main (argc=9, argv=0xbfbfb310) at main.c:234
#7 0x8069e84 in ___start ()
I think it had just got to the initdb..
(gdb) print *node
$1 = {type = T_HashJoin, startup_cost = 2.9253,
total_cost = 50.047, plan_rows = 370, plan_width = 172,
state = 0x8453bc0, instrument = 0x0, targetlist = 0x8453a4c, qual = 0x0,
lefttree = 0x8452874, righttree = 0x84538ec, extParam = 0x0, locParam = 0x0,
chgParam = 0x0, initPlan = 0x0, subPlan = 0x0, nParamExec = 0}
(gdb) print *node->hashjoinstate
There is no member named hashjoinstate.
??
Cheers,
Patrick
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
[HACKERS] postgres core dump PS
(gdb) print *((HashJoin *) node)->hashjoinstate
$4 = {jstate = {type = T_HashJoinState, cs_OuterTupleSlot = 0x0,
cs_ResultTupleSlot = 0x84527cc, cs_ExprContext = 0x8453e60,
cs_ProjInfo = 0x84546e0, cs_TupFromTlist = 0 '\000'}, hj_HashTable = 0x0,
hj_CurBucketNo = 0, hj_CurTuple = 0x0, hj_OuterHashKeys = 0x8454728,
hj_InnerHashKeys = 0x84538d0, hj_OuterTupleSlot = 0x84527e0,
hj_HashTupleSlot = 0x8452790, hj_NullInnerTupleSlot = 0x0,
hj_NeedNewOuter = 1 '\001', hj_MatchedOuter = 0 '\000',
hj_hashdone = 0 '\000'}
of course.. but still, why the segfault?
Patrick
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
[HACKERS] postgres core FALSE ALARM
I must have had an old object file in the build tree... It's all happy now. Sorry for the noise, Patrick (geometry fails just because of the ordering of the rows in "twenty") ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[HACKERS] 24:00:00 ?
transatlantic=# select '23:59:59.72'::time(0) without time zone; time -- 24:00:00 (1 row) So dumping a table with times derived from the timestamp then fails on the reload with: psql:transatlantic.dat:43681: ERROR: copy: line 5818, Bad time external representation '24:00:00' psql:transatlantic.dat:43681: lost synchronization with server, resetting connection timeslice | timestamp(6) without time zone | timesliced | date | timeslicet | time(0) without time zone | (timesliced and timesllicet are for M$ Access' benefit and just contain the date and time parts of timeslice as per above) So, that's what happened, but what can one do? 24:00:00 seems like a sensible rounding for 23:59:59.72, and it is also true that 24:00:00 isn't really a valid time (or could it in strange days with an extra second?), so both sides seem to be right, it's just the overall effect which seems bad. (sed s/24:00:00/23:59:59/g fixed the 5.6Gb data file..) Cheers, Patrick ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
[HACKERS] possible libpq++ prob
I have a program which worked merrily under 1.3b1, but with 1.4devel I get the first query working (so connection OK), and the second query, which may well be wrong, getting me: DEBUG: reaping dead processes DEBUG: child process (pid 13025) was terminated by signal 11 LOG: server process (pid 13025) was terminated by signal 11 LOG: terminating any other active server processes DEBUG: CleanupProc: sending SIGQUIT to process 13022 WARNING: Message from PostgreSQL backend: The Postmaster has informed me that some other backend died abnormally and possibly corrupted shared memory. I have rolled back the current transaction and am going to terminate your database system connection and exit. Please reconnect to the database system and repeat your query. DEBUG: reaping dead processes DEBUG: child process (pid 13022) exited with exit code 1 LOG: all server processes terminated; reinitializing shared memory and semaphores Should I be able to cause this with a duff query? I'm now digging myself in further by trying to recompile the program which uses libpq++ - I don't think libpq++ works terribly well anymore but unfortunately I have to leave now before figuring out what pg_config.h includes may be needed to define eg DLLIMPORT etc. More later no doubt... Cheers, Patrick ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
[HACKERS] SIGSEGV
Using cvs source of Dec 4 15:13:
test=# \d amount
Table "public.amount"
Column | Type | Modifiers
+-+
id | integer | not null default nextval('public.amount_id_seq'::text)
value | integer |
test=# select "value" from amount;
value
---
(0 rows)
test=# select value from amount;
server closed the connection unexpectedly
This probably means the server terminated abnormally
before or while processing the request.
The connection to the server was lost. Attempting reset: Failed.
!#
Not very graceful... (and this is different to the geqo prob I saw with my
libpq++ program, cured with geqo=false (Thanks Tom!))
Program received signal SIGSEGV, Segmentation fault.
transformTargetEntry (pstate=0x82e235c, node=0x82e21fc, expr=0x0, colname=0x0,
resjunk=0 '\000') at parse_target.c:61
61 if (IsA(expr, RangeVar))
(gdb) bt
#0 transformTargetEntry (pstate=0x82e235c, node=0x82e21fc, expr=0x0,
colname=0x0, resjunk=0 '\000') at parse_target.c:61
#1 0x80c2af0 in transformTargetList (pstate=0x82e235c, targetlist=0x82e2234)
at parse_target.c:192
#2 0x80a9c00 in transformSelectStmt (pstate=0x82e235c, stmt=0x82e22b4)
at analyze.c:1654
#3 0x80a7feb in transformStmt (pstate=0x82e235c, parseTree=0x82e22b4,
extras_before=0xbfbfa9b0, extras_after=0xbfbfa9b4) at analyze.c:308
#4 0x80a7bd0 in parse_analyze (parseTree=0x82e22b4, parentParseState=0x0)
at analyze.c:147
#5 0x813e1c0 in pg_analyze_and_rewrite (parsetree=0x82e22b4) at postgres.c:408
#6 0x813e4a3 in pg_exec_query_string (query_string=0x82e201c, dest=Remote,
parse_context=0x828c8ac) at postgres.c:696
#7 0x813f935 in PostgresMain (argc=5, argv=0xbfbfaca8,
username=0x826a925 "prlw1") at postgres.c:2016
#8 0x8124332 in DoBackend (port=0x826a800) at postmaster.c:2293
#9 0x8123c25 in BackendStartup (port=0x826a800) at postmaster.c:1915
#10 0x8122e0b in ServerLoop () at postmaster.c:1002
#11 0x8122972 in PostmasterMain (argc=3, argv=0x8266030) at postmaster.c:781
#12 0x80fb135 in main (argc=3, argv=0xbfbfb4b4) at main.c:209
#13 0x8069e84 in ___start ()
Cheers,
Patrick
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Big 7.4 items
Bruce Momjian wrote: > > I wanted to outline some of the big items we are looking at for 7.4: > > [snip] > > Point-In-Time Recovery (PITR) > > J. R. Nield did a PITR patch late in 7.3 development, and Patrick > MacDonald from Red Hat is working on merging it into CVS and > adding any missing pieces. Patrick, do you have an ETA on that? Neil Conway and I will be working on this starting the beginning of January. By the middle of January, we hope to have a handle on an ETA. Cheers, Patrick -- Patrick Macdonald Red Hat Database Development ---(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] FW: Duplicate oids!
Tom Lane wrote: > > Alvaro Herrera <[EMAIL PROTECTED]> writes: > > On Fri, Dec 13, 2002 at 09:43:19AM -0500, Tom Lane wrote: > >> Actually, if you don't mind grabbing a copy of pg_filedump --- see > >> http://sources.redhat.com/rhdb/tools.html > > > Has this been updated for 7.3? Last time I looked it only did 7.2, and > > the site shows an old date. If it hasn't, are there plans to update it > > sometime soon? It would be very useful to me right now... > > AFAIK it has not been updated yet. Patrick, do you have any near-term > plans to do so? If not, perhaps Alvaro would like to do the legwork ;-) Yes, it's on my list of things to do. Look for an updated version by middle of the week (once all the RHDB 2.1 work is finished). > I believe it should be possible to make a single version of pg_filedump > that understands both the 7.2 and 7.3 page layouts (the version field in > the page header would work for telling what you're looking at) Correct. The tool will be updated to understand the different page layouts/formats. Two tools would be a pain... Cheers, Patrick -- Patrick Macdonald Red Hat Database Development ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Big 7.4 items
Bruce Momjian wrote: > > Patrick Macdonald wrote: > > Bruce Momjian wrote: > > > > > > I wanted to outline some of the big items we are looking at for 7.4: > > > > > > [snip] > > > > > > Point-In-Time Recovery (PITR) > > > > > > J. R. Nield did a PITR patch late in 7.3 development, and Patrick > > > MacDonald from Red Hat is working on merging it into CVS and > > > adding any missing pieces. Patrick, do you have an ETA on that? > > > > Neil Conway and I will be working on this starting the beginning > > of January. By the middle of January, we hope to have a handle on > > an ETA. > > Ewe, that is later than I was hoping. I have put J.R's PITR patch up > at: > > ftp://candle.pha.pa.us/pub/postgresql/PITR_20020822_02.gz > > (I have tried to contact J.R. several times over the past few months, > with no reply.) > > J.R felt it was ready to go. I would like to have an evaluation of the > patch to know what it does and what is missing. I would like that > sooner rather than later because: > > o I want to avoid too much code drift > o I don't want to find there are major pieces missing and to >not have enough time to implement them in 7.4 > o It is a big feature so I would like sufficient testing before beta > > OK, I just talked to Patrick on the phone, and he says Neil Conway is > working on merging the code into 7.3, and adding missing pieces like > logging table creation. So, it seems PITR is moving forward. Well, sort of. I stated that Neil was already working on merging the patch into the CVS tip. I also mentioned that there are missing pieces but have no idea if Neil is currently working on them. Cheers, Patrick -- Patrick Macdonald Red Hat Database Development ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] FW: Duplicate oids!
Patrick Macdonald wrote: > > Tom Lane wrote: > > > > Alvaro Herrera <[EMAIL PROTECTED]> writes: > > > On Fri, Dec 13, 2002 at 09:43:19AM -0500, Tom Lane wrote: > > >> Actually, if you don't mind grabbing a copy of pg_filedump --- see > > >> http://sources.redhat.com/rhdb/tools.html > > > > > Has this been updated for 7.3? Last time I looked it only did 7.2, and > > > the site shows an old date. If it hasn't, are there plans to update it > > > sometime soon? It would be very useful to me right now... > > > > AFAIK it has not been updated yet. Patrick, do you have any near-term > > plans to do so? If not, perhaps Alvaro would like to do the legwork ;-) > > Yes, it's on my list of things to do. Look for an updated version > by middle of the week (once all the RHDB 2.1 work is finished). I've updated the pg_filedump utility for PostgreSQL 7.3. The new version, 1.1, requires a PostgreSQL 7.3 source tree to build and can be used against RHDB 2.x/1.x and PostgreSQL 7.3/7.2/7.1 installations. All questions and comments about the tool should be directed to [EMAIL PROTECTED], not this list. The pg_filedump utility can be found at the Red Hat Database Project site (http://sources.redhat.com/rhdb). Cheers, Patrick ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: Changing the default configuration (was Re: [pgsql-advocacy] [HACKERS] PostgreSQL Benchmarks)
On Tue, Feb 11, 2003 at 11:20:14AM -0500, Tom Lane wrote: ... > We could retarget to try to stay under SHMMAX=4M, which I think is > the next boundary that's significant in terms of real-world platforms > (isn't that the default SHMMAX on some BSDen?). ... Assuming 1 page = 4k, and number of pages is correct in GENERIC kernel configs, SHMMAX=4M for NetBSD (8M for i386, x86_64) Cheers, Patrick ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] psql and readline
On Thu, Feb 13, 2003 at 10:25:52AM -0500, Tom Lane wrote: > Patrick Welche <[EMAIL PROTECTED]> writes: > > The sad thing is that my readline wrapper for libedit doesn't wrap > > replace_history_entry, > > Well, is that a bug in your wrapper? Or must we add a configure test > for the presence of replace_history_entry()? Good question. Easiest for now for me would be add a configure test. Long term libedit needs tweeking... In fact for now, I just comment out the call the replace_history_entry, as I am more than happy with the rest of the readline behaviour (as implemented in libedit). Patrick ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Incremental backup
Bruce Momjian wrote: > > Patrick Macdonald wrote: > > > Yeah, it's a different method of producing a similar outcome. However, many > > companies do not want to be concerned with the management (and space) > > of archived logs. Incremental backup allows them the option of performing > > a full backup and then only backing up the modifications on a regular basis. > > When it's time to restore, they'll restore the full backup and then the > > proper sequence of incremental backups. > > Wow, I never even thought that was possible. Do other db's support that > feature? I know Oracle and DB2 have incremental backup in their arsenal (and iirc, SQL Server has something called "differential backup"). Whatever the name, it's a win at the enterprise level. Cheers, Patrick ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Incremental backup
Bruce Momjian wrote: > > Someone at Red Hat is working on point-in-time recovery, also known as > incremental backups. PITR and incremental backup are different beasts. PITR deals with a backup + logs. Incremental backup deals with a full backup + X smaller/incremental backups. So... it doesn't look like anyone is working on incremental backup at the moment. Cheers, Patrick > It will be in 7.4. > > --- > > Martin Marques wrote: > > How's this issue going on the 7.4 development tree? > > I saw it on the TODO list, but didn't find much on the archives of this > > mailing list. > > > > -- > > Porqu? usar una base de datos relacional cualquiera, > > si pod?s usar PostgreSQL? > > - > > Mart?n Marqu?s |[EMAIL PROTECTED] > > Programador, Administrador, DBA | Centro de Telematica > >Universidad Nacional > > del Litoral > > - > > > > > > ---(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 4: Don't 'kill -9' the postmaster ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] psql and readline
The sad thing is that my readline wrapper for libedit doesn't wrap replace_history_entry, so I could use readline up until now, the tests for readline succeed as the functions tested for exist, but command.o: In function `do_edit': /usr/src/local/pgsql/src/bin/psql/command.c:1652: undefined reference to `replace_history_entry' ho hum.. Patrick On Wed, Feb 12, 2003 at 11:08:16PM -0500, Bruce Momjian wrote: > > Patch applied. Thanks. > > --- > > > Ross J. Reedstrom wrote: > > On Fri, Jan 10, 2003 at 11:02:55PM +0100, Peter Eisentraut wrote: > > > Ross J. Reedstrom writes: > > > > > > > I already posted a one-line patch to implement this, but it doesn't > > > > seem to hve come through to the list. Here it is inline, instead of as > > > > an attachment: > > > > > > We need this to work without readline as well. (Of course there won't be > > > any history, but it needs to compile.) > > > > Even after slogging my way through the nesting #ifdefs for readline > > and win32, I forgot! Let's make that a three line patch, then. > > > > > > Index: src/bin/psql/command.c > > === > > RCS file: /projects/cvsroot/pgsql-server/src/bin/psql/command.c,v > > retrieving revision 1.84 > > diff -u -r1.84 command.c > > --- src/bin/psql/command.c 2002/10/23 19:23:56 1.84 > > +++ src/bin/psql/command.c 2003/01/10 22:06:07 > > @@ -1639,6 +1639,9 @@ > > error = true; > > } > > > > +#ifdef USE_READLINE > > + replace_history_entry(where_history(),query_buf->data,NULL); > > +#endif > > fclose(stream); > > } > > > > Ross > > > > ---(end of broadcast)--- > > TIP 2: you can get off all lists at once with the unregister command > > (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED]) > > > > -- > 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 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Call for platforms
Did we decide that "most NetBSD/i386 users have fpus" in which case Marko's patch should be applied? Cheers, Patrick (just checked, it isn't in today's cvs) On Thu, Mar 22, 2001 at 10:27:44PM +0200, Marko Kreen wrote: > On Thu, Mar 22, 2001 at 07:58:04PM +, Patrick Welche wrote: > > On Fri, Mar 23, 2001 at 06:25:50AM +1100, Giles Lean wrote: > > > > > > > PS: AFAIK geometry-positive-zeros-bsd works for all NetBSD platforms - the > > > > above difference is only for i386 + fpu. > > > > > > It doesn't on NetBSD-1.5/alpha -- there geometry-positive-zeros is > > > correct. > > > > Sorry, that should have read: > > > > AFAIK geometry-positive-zeros works for all NetBSD platforms - the > > above difference is only for i386 + fpu. > > Seems that following patch is needed. Now It Works For Me (tm). > Giles, does the regress test now succed for you? > > -- > marko > > > Index: src/test/regress/resultmap > === > RCS file: /home/projects/pgsql/cvsroot/pgsql/src/test/regress/resultmap,v > retrieving revision 1.45 > diff -u -r1.45 resultmap > --- src/test/regress/resultmap2001/03/22 15:13:18 1.45 > +++ src/test/regress/resultmap2001/03/22 17:29:49 > @@ -17,6 +17,7 @@ > geometry/.*-openbsd=geometry-positive-zeros-bsd > geometry/.*-irix6=geometry-irix > geometry/.*-netbsd=geometry-positive-zeros > +geometry/i.86-.*-netbsdelf1.5=geometry-positive-zeros-bsd > geometry/.*-sysv5uw7.*:cc=geometry-uw7-cc > geometry/.*-sysv5uw7.*:gcc=geometry-uw7-gcc > geometry/alpha.*-dec-osf=geometry-alpha-precision > > ---(end of broadcast)--- > TIP 4: Don't 'kill -9' the postmaster ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
[HACKERS] Re: Call for platforms
On Fri, Apr 13, 2001 at 01:25:45PM +, Thomas Lockhart wrote: > > Did we decide that "most NetBSD/i386 users have fpus" in which case Marko's > > patch should be applied? > > I'm unclear on what y'all mean by "i386 + fpu", especially since NetBSD > seems to insist on calling every Intel processor a "i386". History ;-) > In this case, > are you suggesting that this patch covers all NetBSD installations on > every Intel processor from i386 + fpu forward to i486, i586, etc etc? Yes! It's simply, if the peecee type thing has a fpu (as in the sysctl machdep.fpu_present returns 1), then libm387.so is used, and you get differences in the (from memory 44th insignificant figure?) otherwise it just uses libm.so and you get what is currently correct in resultmap. Cheers, Patrick ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Re: Call for platforms
On Mon, Apr 09, 2001 at 11:41:55AM -0700, Henry B. Hotz wrote: > At 1:50 AM -0400 4/6/01, Tom Lane wrote: ... > >What version of libreadline do you have installed, and how does it > >declare completion_matches()? > > I have whatever is standard on NetBSD 1.5. I noticed that configure > found a readline.h include file, but NetBSD doesn't integrate the > current GNU implementation. I did not do a test of psql to see if > the feature worked. > > I'm sure you could "fix" this problem if you installed GNU readline > and referenced it in the build. Since Solaris had even worse issues > with needing GNU support utilities installed this didn't seem like a > big deal to me. OTOH it could confuse a new user. Odd: I am using the standard NetBSD readline found in -ledit and it is fine.. Can it be a -1.5 vs -current difference? I have just stumbled across something which is broken though: NetBSD-1.5S/arm32: % ldd `which psql` /usr/local/pgsql/bin/psql: -lpq.2 => /usr/local/pgsql/lib/libpq.so.2.1 (0x2003b000) -lz.0 => /usr/lib/libz.so.0.2 (0x20048000) -lcrypt.0 => /usr/lib/libcrypt.so.0.0 (0x20056000) -lresolv.1 => /usr/lib/libresolv.so.1.0 (0x2005c000) -lm.0 => /usr/lib/libm.so.0.1 (0x20065000) -lutil.5 => /usr/lib/libutil.so.5.5 (0x2008b000) -ledit.2 => /usr/lib/libedit.so.2.5 (0x20096000) -lc.12 => /usr/lib/libc.so.12.74 (0x200ae000) NetBSD-1.5U/i386: % ldd `which psql` /usr/local/pgsql/bin/psql: -lcrypt.0 => /usr/lib/libcrypt.so.0 -lresolv.1 => /usr/lib/libresolv.so.1 -lpq.2 => /usr/local/pgsql/lib/libpq.so.2 -lz.0 => /usr/lib/libz.so.0 -lm.0 => /usr/lib/libm387.so.0 -lm.0 => /usr/lib/libm.so.0 -lutil.5 => /usr/lib/libutil.so.5 -ledit.2 => /usr/lib/libedit.so.2 -ltermcap.0 => /usr/lib/libtermcap.so.0 -lc.12 => /usr/lib/libc.so.12 -ltermcap is missing from arm32 - it's necessary if libedit is going to find _tgetent.. Investigating now.. Cheers, Patrick ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[HACKERS] shared library strangeness?
I just upgraded PostgreSQL from 21 March CVS (rc1?) to May 19 16:21 GMT CVS. I found that all my cgi/fcg scripts which use libpq++ stopped working in the vague sense of apache mentioning an internal server error. Relinking them cured the problem (had to do this in haste => unfortunately no more information) -rwxr-xr-x 1 postgres postgres 154795 Mar 21 21:28 libpq++.so.3.1 -rwxr-xr-x 1 postgres postgres 155212 May 21 14:48 libpq++.so.3.2 is the change. The programs using libpq only (not lipq++ as well) worked as before. I am sorry, I don't have an error message to say how it is broken, but I do have a slight feeling that maybe the major shared library number could have been bumped up... Ah... A clue! Undefined PLT symbol "ConnectionBad__12PgConnection" (reloc type = 7, symnum = 132) quartz% nm -g libpq++.so.3.1 | grep ConnectionBad 25e8 T ConnectionBad__12PgConnection quartz% !:s/1/2/ nm -g libpq++.so.3.2 | grep ConnectionBad 24fc T ConnectionBad__C12PgConnection RCS file: /home/projects/pgsql/cvsroot/pgsql/src/interfaces/libpq++/pgconnection.h,v retrieving revision 1.10 retrieving revision 1.11 diff -u -r1.10 -r1.11 --- pgconnection.h 2001/02/10 02:31:30 1.10 +++ pgconnection.h 2001/05/09 17:29:10 1.11 - int ConnectionBad(); ... + bool ConnectionBad() const; So I would suggest that the major number be bumped, leaving a small window since 9 May with a problem.. Cheers, Patrick ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] 7.2 items
On Sat, May 12, 2001 at 08:00:42PM -0400, Tom Lane wrote: > Peter Eisentraut <[EMAIL PROTECTED]> writes: > > * Translation: If we want to use gettext I can get started. I don't > > think I'm interested in using any other interface. > > I have no objection to the gettext API, but I was and still am concerned > about depending on GNU gettext's code, because of license conflicts. > There is a BSD-license gettext clone project, but it doesn't look to be > very far along. What's missing with it? (eg managed to force gmake's configure to use it rather than its own, and didn't have to fiddle anything for it to just work) % ldd `which gmake` /usr/local/bin/gmake: -lutil.5 => /usr/lib/libutil.so.5 -lkvm.5 => /usr/lib/libkvm.so.5 -lintl.0 => /usr/lib/libintl.so.0<< BSD license lib -lc.12 => /usr/lib/libc.so.12 % env LANGUAGE=fr gmake gmake: *** Pas de cibles spécifiées et aucun makefile n'a été trouvé. Arrêt. Cheers, Patrick ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] 7.2 items
On Mon, May 14, 2001 at 09:36:56PM +0200, Peter Eisentraut wrote: > Patrick Welche writes: > > > > I have no objection to the gettext API, but I was and still am concerned > > > about depending on GNU gettext's code, because of license conflicts. > > > There is a BSD-license gettext clone project, but it doesn't look to be > > > very far along. > > > > What's missing with it? > > * portability > > At first glance, uses strlcat and strlcpy. Didn't look further. As I said, I didn't change anything within the GNU make source to get it to work. grep strlcat on GNU make, which you must have in order to build postgresql, returns nothing, however grep gettext does. I chose gmake as an example which is probably written with portability in mind. > * dedication to portability > > Only plans to support *BSD. What does this imply? HISTORY The functions are implemented by Citrus project, based on the documenta- tions for GNU gettext. > * source code availability > > Didn't find anything outside NetBSD CVS and the CVS rep where they got it > from. >From libintl.h /*- * Copyright (c) 2000 Citrus Project, * All rights reserved. * * Redistribution and use in source and binary forms, with or without * modification, are permitted provided that the following conditions * are met: * 1. Redistributions of source code must retain the above copyright *notice, this list of conditions and the following disclaimer. * 2. Redistributions in binary form must reproduce the above copyright *notice, this list of conditions and the following disclaimer in the *documentation and/or other materials provided with the distribution. * * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF * SUCH DAMAGE. */ which I think counts as a postgresql compatible license? Is that what you meant? > * documentation > > Related to above. The HISTORY bit was quoted from the gettext man page.. What more documentation is required? AFAIK it's meant to be a direct replacement.. > * English support forum > > Only Japanese mailing list available. Yes, I wondered about that to.. Luckily PostgreSQL is international! Cheers, Patrick ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] cvs snapshot compile problems
On Sat, May 19, 2001 at 08:03:50PM -0400, bpalmer wrote: > On OBSD from cvs source, clean checkout: > > gcc -O2 -pipe -Wall -Wmissing-prototypes -Wmissing-declarations > -I../../../../src/include -DLIBDIR=\"/usr/local/pgsql/lib\ > " -DDLSUFFIX=\".so\" -c -o dfmgr.o dfmgr.c > dfmgr.c: In function `load_external_function': > dfmgr.c:118: `RTLD_GLOBAL' undeclared (first use in this function) > dfmgr.c:118: (Each undeclared identifier is reported only once > dfmgr.c:118: for each function it appears in.) > gmake[4]: *** [dfmgr.o] Error 1 > gmake[4]: Leaving directory > `/home/bpalmer/APPS/pgsql/src/backend/utils/fmgr' > > > ?? RTLD_GLOBAL problems? Not a solution, but a few data points: I had a successful build from cvs of May 19 16:21 GMT under NetBSD/i386, and for me RTLD_GLOBAL is defined in /usr/include/dlfcn.h ie., system header file, not postgresql. Hope that helps, Patrick ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] iconv?
On Thu, Jul 12, 2001 at 12:04:25PM +0900, Tatsuo Ishii wrote: > > Has it ever been considered to (optionally) use the iconv interface for > > character set conversion instead of rolling our own? It seems to be a lot > > more flexible, has pluggable conversion modules (depending on the > > implementation), supports more character sets. It seems to be available > > on quite a few systems, too. > > I have not checked iconv seriously since it's not very portable among > our supported platforms. Just FYI, in the mutt readme: - Mutt needs an implementation of the iconv API for character set conversions. A free one can be found under the following URL: http://clisp.cons.org/~haible/packages-libiconv.html Cheers, Patrick ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Idea: recycle WAL segments, don't delete/recreate 'em
Hmmm... my prior appends to this newsgroup are stalled. Hopefully, they'll be available soon. Tom Lane wrote: > > What you may really be saying is that the existing scheme for management > of log segments is inappropriate for PIT usage; if so feel free to > propose a better one. But I don't see how recycling of no-longer-wanted > segments can break anything. Yes, but in a very roundabout way (or so it seems). The main point that I was trying to illustrate was that if a database supports point-in-time recovery, recycling of the only available log segments is a bad thing. And, yes, in practice if you have point-in-time recovery enabled you better archive your logs with your backup to ensure that you can roll forward as expected. A possible solution (as I mentioned before)) is to have 2 methods of logging available: circular and forward-recoverable. When a database is created, the creator selects which type of logging to perform. The log segments are exactly the same, only the recycling method is different. Hmmm... the more I look at this, the more interested I become. Cheers, Patrick ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Idea: recycle WAL segments, don't delete/recreate 'em
Tom Lane wrote: > > Patrick Macdonald <[EMAIL PROTECTED]> writes: > > I understand your solution is for the existing architecture which does > > not support point-in-time recovery. If this item is picked up, your > > solution will become a stumbling block due the above mentioned log > > extent deletions. > > Hmm, I don't see why it's a stumbling block. There is a notion in the > present code that log segments might be moved someplace else for > archiving (rather than just be deleted), and I wasn't planning on > eliminating that option. I think however that a realistic archival > mechanism would not simply keep the log segments verbatim. It could > drop the page images, for a huge space savings, and perhaps also > eliminate records from aborted transactions. So in reality one could > still expect to recycle the log segments, just with a somewhat longer > cycle time --- ie, after the archiver is done copying a segment, then > you rename it into place as a forward file. Well, notion and actual practice can be mutually exclusive. Your initial message stated that you would like to rename the log segment. This insinuated that the log segment was not moved. Therefore, a straight rename would cause problems with the future point-in-time recovery item (ie. the only existing version of log segment N has been renamed to N+5). A backup of the database could not roll forward through this name change as stated. That was my objection. > In any case, a two-or-three-line change is hardly likely to create much > of an obstacle to PIT recovery, compared to some of the more fundamental > aspects of the existing WAL design (like its need to start from a > complete physical copy of the database files). So I'm not sure why > you're objecting on these grounds. Hmmm, stating that it is less of a problem than others doesn't make it the right thing to do. If the two or three lines you mention renames a segment I want to roll forward through, that's a problem. Yeah, I know it's not a problem now but it'll have to be changed when PIT comes into play. You didn't comment on the idea of two logging methods... circular and recoverable. Any thoughts? Cheers, Patrick ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Idea: recycle WAL segments, don't delete/recreate 'em
Tom, What you are describing is a pseudo circular log. Other database systems (such as DB2) support the concept of both circular and recoverable logs. Recoverable is named this way because recoverable logs can be used in point-in-time recovery. Both methods support crash recovery. In general, a user defines the number of log extents to be used in the log cycle. He/she also defines the number of secondary logs to use if by chance the circular log becomes full. If a secondary log extent is created, it is added to the cycle list. At a consistent shutdown, the secondary log extents are deleted. Since logs are deleted, any hope of point-in-time recovery is deleted with them. I understand your solution is for the existing architecture which does not support point-in-time recovery. If this item is picked up, your solution will become a stumbling block due the above mentioned log extent deletions. The other issues you list are of concern but are manageable with some coding. So, my question is, should PostgreSQL support both types of logging? There will be databases where you require the ability to perform point-in-time recovery. Conversely, there will be databases where an overwritten log extent (as you describe) is acceptable. I think it would be useful to be able to define which logging method you require for a database. This way, you incur the I/O hit only when forward recovery is a requirement. Thoughts/comments? Cheer, Patrick Tom Lane wrote: > > I have noticed that a large fraction of the I/O done by 7.1 is > associated with initializing new segments of the WAL log for use. > (We have to physically fill each segment with zeroes to ensure that > the system has actually allocated a whole 16MB to it; otherwise we > fall victim to the "hole-saving" allocation technique of most Unix > filesystems.) I just had an idea about how to avoid this cost: > why not recycle old log segments? At the point where the code > currently deletes a no-longer-needed segment, just rename it to > become the next created-in-advance segment. > > With this approach, shortly after installation the system would converge > to a steady state with a constant number of WAL segments (basically > CHECKPOINT_SEGMENTS + WAL_FILES + 1, maybe one or two more if load is > really high). So, in addition to eliminating initialization writes, > we would also reduce the metadata traffic (inode and indirect blocks) > to a very low level. That has to be good both for performance and for > improving the odds that the WAL files will survive a system crash. > > The sole disadvantage I can see to this approach is that a recycled > segment would not contain zeroes, but valid WAL records. We'd need > to take care that in a recovery situation, we not mistake old records > beyond the last one we actually wrote for new records we should redo. > While checking the xl_prev back-pointers in each record should be > sufficient to detect this, I'd feel more comfortable if we extended > the XLogPageHeader record to contain the file/segment number that it > belongs to. This'd cost an extra 8 bytes per 8K XLOG page, which seems > worth it to me. > > Another issue is whether the recycling logic should be "always recycle" > (hence number of extant WAL segments will never decrease), or should > it be more like "recycle if there are fewer than WAL_FILES advance > segments, else delete". If we were supporting WAL-based UNDO then I > think it'd have to be the latter, so that we could reduce the WAL usage > from a peak created by a long-running transaction. But with the present > logic that the WAL log is truncated after each checkpoint, I think it'd > be better just to never delete. Otherwise, the behavior is likely to > be that the system varies between N and N+1 extant segments due to > roundoff effects (ie, depending on just where you are in the current > segment when a checkpoint happens). That's exactly what we do not want. > > A possible answer is "recycle if there are fewer than WAL_FILES + SLOP > advance files, else delete", where SLOP is (say) about three or four > segments. That would avoid unwanted oscillations in the number of > extant files, while still allowing decrease from a peak for UNDO. > > Comments, better ideas? > > regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Idea: recycle WAL segments, don't delete/recreate 'em
Bruce Momjian wrote: > > > Hmmm... my prior appends to this newsgroup are stalled. Hopefully, > > they'll be available soon. > > > > Tom Lane wrote: > > > > > > What you may really be saying is that the existing scheme for management > > > of log segments is inappropriate for PIT usage; if so feel free to > > > propose a better one. But I don't see how recycling of no-longer-wanted > > > segments can break anything. > > > > Yes, but in a very roundabout way (or so it seems). The main point > > that I was trying to illustrate was that if a database supports > > point-in-time recovery, recycling of the only available log segments > > is a bad thing. And, yes, in practice if you have point-in-time > > recovery enabled you better archive your logs with your backup to > > ensure that you can roll forward as expected. > > I assume you are not going to do point-in-time recovery by keeping all > the WAL segments around on the same disk. Of course not. As mentioned, you'd probably archive them with your backup(s). > You have to copy them off > somewhere, right, and once you have copied them, why not reuse them? I'm not arguing that point. I stated "recycling of the only available log segments". Once the log segment is archived (copied) elsewhere you have two available images of the same segment. You can rename the local copy. > > A possible solution (as I mentioned before)) is to have 2 methods > > of logging available: circular and forward-recoverable. When a > > database is created, the creator selects which type of logging to > > perform. The log segments are exactly the same, only the recycling > > method is different. > > Will not fly. We need a solution that is flexible. Could you expand on that a little (ie. flexible in which way). Offering the user a choice of two is more flexible than offering no choice. > > Hmmm... the more I look at this, the more interested I become. > > My assumption is that once a log is full the point-in-time recovery > daemon will copy that off somewhere, either to a different disk, tape, > or over the network to another machine. Once it is done making a copy, > the WAL log can be recycled, right? Am I missing something here? Ok... I wasn't thinking of having a point-in-time daemon. Some other databases provide, for lack of a better term, user exits to allow user defined scripts or programs to be called to perform log segment archiving. This archiving is somewhat orthogonal to point-in-time recovery proper. Yep, once the archiving is complete, you can do whatever you want with the local log segment. Cheers, Patrick ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS]
On Thu, Jul 26, 2001 at 04:55:14PM +0700, Zudi Iswanto wrote: > I am developing application with c++ ... > /tmp/ccy63XDd.o(.text+0x70): undefined reference to `PQsetdbLogin' > /tmp/ccy63XDd.o(.text+0x91): undefined reference to `PQstatus' > /tmp/ccy63XDd.o(.text+0xc4): undefined reference to `PQerrorMessage' Did you link libpq as well as libpq++ ? ie something like -L/usr/local/lib/pgsql -Wl,-R/usr/local/lib/pgsql -lpq++ -lpq Cheers, Patrick ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Idea: recycle WAL segments, don't delete/recreate 'em
Bruce Momjian wrote: > > > > > Yes, but in a very roundabout way (or so it seems). The main point > > > > that I was trying to illustrate was that if a database supports > > > > point-in-time recovery, recycling of the only available log segments > > > > is a bad thing. And, yes, in practice if you have point-in-time > > > > recovery enabled you better archive your logs with your backup to > > > > ensure that you can roll forward as expected. > > > > > > I assume you are not going to do point-in-time recovery by keeping all > > > the WAL segments around on the same disk. > > > > Of course not. As mentioned, you'd probably archive them with your > > backup(s). > > You mean the nigthly backup? Why not do a pg_dump and be done with it. But the purpose of point-in-time recovery is to restore your backup and then use the WAL to bring the backed up image up to a more current version. > > > > A possible solution (as I mentioned before)) is to have 2 methods > > > > of logging available: circular and forward-recoverable. When a > > > > database is created, the creator selects which type of logging to > > > > perform. The log segments are exactly the same, only the recycling > > > > method is different. > > > > > > Will not fly. We need a solution that is flexible. > > > > Could you expand on that a little (ie. flexible in which way). > > Offering the user a choice of two is more flexible than offering no > > choice. > > We normally don't give users choices unless we can't come up with a > win-win solution to the problem. In this case, we could just query to > see if the WAL PIT archiver is running and handle tune reuse of log > segments on the fly. In fact, my guess is that the PIT archiver will > have to tell the system when it is done with WAL logs anyway. But this could be a win-win situation. If a user doesn't not care about point-in-time recovery, circular logs can be used. When a database is created, a configurable number of log segments are allocated. The database uses those logs in a cyclic manner. No new log segments need to be created under normal use. Automatic reuse. A database requiring point-in-time functionality will log very similar to the method in place today. New log segments will be created when needed. > > > > Hmmm... the more I look at this, the more interested I become. > > > > > > My assumption is that once a log is full the point-in-time recovery > > > daemon will copy that off somewhere, either to a different disk, tape, > > > or over the network to another machine. Once it is done making a copy, > > > the WAL log can be recycled, right? Am I missing something here? > > > > Ok... I wasn't thinking of having a point-in-time daemon. Some other > > databases provide, for lack of a better term, user exits to allow > > user defined scripts or programs to be called to perform log segment > > archiving. This archiving is somewhat orthogonal to point-in-time > > recovery proper. > > > > Yep, once the archiving is complete, you can do whatever you want > > with the local log segment. > > We will clearly need something to transfer these WAL logs somewhere > else, and it would be nice if it could be easily configured. I think a > PIT logger daemon is the only solution, especially since tape/network > transfer could take a long time. It would be forked by the postmaster > so would cover all users and databases. Actually, it would be better if the entire logger was split out into it's own process like the large commercial databases. Archiving the log segments would just be one of the many functions of the logger process. Just a thought. Cheers, Patrick ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
[HACKERS] backend hba.c prob
gcc -O2 -pipe -g -Wall -Wmissing-prototypes -Wmissing-declarations
-I../../../src/include -c -o hba.o hba.c
hba.c: In function `ident_unix':
hba.c:923: sizeof applied to an incomplete type
hba.c:960: dereferencing pointer to incomplete type
hba.c:965: dereferencing pointer to incomplete type
gmake: *** [hba.o] Error 1
Now, the problem is sizeof(Cred), typedef struct cmsgcred Cred, and I don't
have a cmsgcred anywhere! The closest is my sys/ucred.h which defines a
struct ucred {
u_short cr_ref; /* reference count */
uid_t cr_uid; /* effective user id */
gid_t cr_gid; /* effective group id */
short cr_ngroups; /* number of groups */
gid_t cr_groups[NGROUPS]; /* groups */
};
Thoughts?
Cheers,
Patrick
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://www.postgresql.org/search.mpl
Re: [HACKERS] backend hba.c prob
On Fri, Sep 07, 2001 at 10:14:27AM -0400, Tom Lane wrote: > Patrick Welche <[EMAIL PROTECTED]> writes: > > hba.c: In function `ident_unix': > > hba.c:923: sizeof applied to an incomplete type > > > Now, the problem is sizeof(Cred), typedef struct cmsgcred Cred, and I don't > > have a cmsgcred anywhere! > > That's new code and we expected some portability issues with it :-( > > What platform are you on exactly? NetBSD-1.5X/i386 Remeber me? :) > What changes are needed to make the > code work there, and how might we #ifdef or autoconfigure a test for it? I need to look at it some more for that.. Cheers, Patrick ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] backend hba.c prob
On Fri, Sep 07, 2001 at 04:05:58PM -0400, Bruce Momjian wrote: ... > OK, I have modified the CVS CREDS code to work on FreeBSD and BSD/OS, > and hopefully NetBSD. I talked to Jason at Linuxworld and I think this > code should work. Please test the CVS version and let me know. OpenBSD > doesn't support creds as far as I can tell. > > To test, define 'ident sameuser' for 'local' in pg_hba.conf and restart > postmaster. Then connect as local user. All tested OK under NetBSD :) Cheers, Patrick ---(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] factorial doc bug?
On Wed, Sep 12, 2001 at 02:45:10PM +0200, Peter Eisentraut wrote: > Thomas Lockhart writes: > > > Keep in mind that he is a mathematician, and I'll guess that he won't > > have much patience with folks who expect a result for a factorial of a > > fractional number ;) > > Real mathematicians will be perfectly happy with a factorial for a > fractional number, as long as it's properly and consistently defined. ;-) > > Seriously, there is a well-established definition of factorials of > non-integral real numbers, but the current behaviour is probably the most > intuitive for the vast majority of users. I would be happy with with exp(lgamma(x+1)) as a synonym for x! (So 4.3!=38.078 as far as I'm concerned :) ) Cheers, Patrick ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Major change to CVS effective immediately ...
On Wed, Sep 19, 2001 at 10:14:44AM -0400, Marc G. Fournier wrote: > > :pserver:[EMAIL PROTECTED]:/projects/cvsroot While trying a cvs update, I get ? ChangeLogs/libecpg.so.3.1.1 ? ChangeLogs/HTML ? ChangeLogs/GTAGS ? ChangeLogs/GPATH ? ChangeLogs/GRTAGS ? ChangeLogs/GSYMS ? ChangeLogs/libpqpp.h cannot create_adm_p /tmp/cvs-serv27285/ChangeLogs Cheers, Patrick ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Further CVS errors
On Fri, Sep 21, 2001 at 07:27:10PM +0200, Horák Daniel wrote: ... > but still I am getting > > > cannot create_adm_p /tmp/cvs-serv24877/ChangeLogs > > Permission denied Me Too! ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] anoncvs failure...
On Mon, Sep 24, 2001 at 10:22:28AM -0400, Marc G. Fournier wrote: > > okay, somehow you have two different CVSROOT's configured? > /home/projects/pgsql/cvsroot was the old server, /projects/cvsroot is the > new one Any hints? I had done a (csh) cd /usr/src/local/pgsql find . -name Root -print > allroots grep -v CVS allroots foreach i ( `cat allroots`) echo ":pserver:[EMAIL PROTECTED]:/projects/cvsroot" > $i end and CVSROOT is not set as an environment variable... Also odd that it appears there and there is no sign of "home" anywhere.. Cheers, Patrick ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] anoncvs failure...
On Mon, Sep 24, 2001 at 06:04:17PM +0100, Patrick Welche wrote: ... > and CVSROOT is not set as an environment variable... Also odd that it > appears there and there is no sign of "home" anywhere.. Got it: had /home/... in pgsql/src/backend/access/heap/CVS/Repository (!) All OK now.. Cheers, Patrick ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] anoncvs failure...
On Sat, Sep 22, 2001 at 08:15:11PM -0500, Dominic J. Eidson wrote: > On Sat, 22 Sep 2001, Marc G. Fournier wrote: > > > anoncvs: :pserer:[EMAIL PROTECTED]:/projects/cvsroot > > - passwd is blank, but postgresql should work just as well > > I can confirm that this works. Still no good for me: protocol error: directory '/home/projects/pgsql/cvsroot/pgsql/src/backend/access/heap' not within root '/projects/cvsroot' Checking: % pwd /usr/src/local/pgsql/src/backend/access/heap % cat CVS/Root :pserver:[EMAIL PROTECTED]:/projects/cvsroot ? Cheers, Patrick ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] failed runcheck
On Mon, Oct 23, 2000 at 10:26:39AM -0400, Tom Lane wrote: > > Could you dig into it a little further and try to determine where the > NULL is coming from? All clear now! (I did do another cvs update in the meantime, but either way, I can't now repeat the previously repeatable core dump) Cheers, Patrick
[HACKERS] Digest subscription
How do I change to digest? The instructions on the website are wrong. === Patrick Dunford, Christchurch, NZ - http://pdunford.godzone.net.nz/ Rejoice with those who rejoice; mourn with those who mourn. -- Romans 12:15 http://www.heartlight.org/cgi-shl/todaysverse.cgi?day=20001215 === Created by Mail2Sig - http://pdunford.godzone.net.nz/software/mail2sig/
[HACKERS] Connecting across internet
If I want to connect to a Postgresql server on the internet, how do I do it? What protocol do I use? How do I send commands? etc. === Patrick Dunford, Christchurch, NZ - http://pdunford.godzone.net.nz/ Therefore, since we are receiving a kingdom that cannot be shaken, let us be thankful, and so worship God acceptably with reverence and awe, for our "God is a consuming fire." -- Hebrews 12:28-29 http://www.heartlight.org/cgi-shl/todaysverse.cgi?day=20001228 === Created by Mail2Sig - http://pdunford.godzone.net.nz/software/mail2sig/
Re: [HACKERS] GNU readline and BSD license
On Sat, Dec 23, 2000 at 08:42:43AM -0800, Alfred Perlstein wrote: > > FreeBSD has a freely available library called 'libedit' that could > be shipped with postgresql, it's under the BSD license. > > If you have access to a FreeBSD box see the editline(3) manpage, > or go to: > >http://www.freebsd.org/cgi/man.cgi?query=editline&apropos=0&sektion=0&manpath=FreeBSD+4.2-RELEASE&format=html Good plan - AFAIK there isn't anything gnu readline can do that libedit can't.. Patrick
[HACKERS] Ignored PostgreSQL SET command
I have a line in a PHP script that looks like this: $set=pg_exec($dbconn, "SET DATESTYLE TO 'European'"); //Set date format Since my ISP updated their server, this appears to be ignored as pgsql always returns dates in ISO format. 1. What is the default format of dates returned that I can ALWAYS rely on? 2. Why is the command ignored? === Patrick Dunford, Christchurch, NZ - http://pdunford.godzone.net.nz/ There is no wisdom, no insight, no plan that can succeed against the LORD. -- Proverbs 21:30 http://www.heartlight.org/cgi-shl/todaysverse.cgi?day=20010101 === Created by Mail2Sig - http://pdunford.godzone.net.nz/software/mail2sig/
Re: [HACKERS] GNU readline and BSD license
On Sat, Dec 30, 2000 at 02:34:24AM +0100, Peter Eisentraut wrote: > > If libedit could be used as an alternative to readline depending on your > operating system setup then there's nothing wrong with that. NetBSD > already went the other way around and made libedit compatible with > readline. I had an attempt at fooling configure to look in libedit rather than readline, and all was OK except our libedit doesn't have "rl_special_prefixes" so tab-complete:105 is unhappy - I don't know what it is meant to do... Re licence business, one could argue hooks are there to use NetBSD libedit ;) Cheers, Patrick
Re: [HACKERS] GNU readline and BSD license
On Sun, Dec 31, 2000 at 01:06:40PM +0100, Peter Eisentraut wrote: > > I've removed the statement for now, since it was being used incorrectly > anyway, but for the future I suggest that NetBSD catch up, if it wants to > stay compatible. Thank you, and Jaromir tells me he'll commit a fix to NetBSD within days! Happy New Year, Patrick
[HACKERS] global/pg_database ?
Posting again as even though I receive mail from hackers I am apparently not a member (registered correctly as [EMAIL PROTECTED] - from will say [EMAIL PROTECTED] - setting reply-to to [EMAIL PROTECTED] used to get around it..) psql: FATAL 1: cannot open /usr/local/pgsql/data/global/pg_database: No such fi le or directory and it's true.. % ls /usr/local/pgsql/data/global 1260126112621264126917127 17130 pg_control source from Jan 3 15:59 GMT configure --enable-locale --enable-recode --enable-debug --enable-cassert --wit h-CXX all but geometry (rounding errors) pass gmake runcheck PGLIB=/usr/local/pgsql/lib PGDATA=/usr/local/pgsql/data PGDATESTYLE=European LC_ALL=en_GB.ISO8859-1 then did the initdb This database system will be initialized with username "postgres". This user will own all the data files and must also own the server process. Creating directory /usr/local/pgsql/data Creating directory /usr/local/pgsql/data/base Creating directory /usr/local/pgsql/data/global Creating directory /usr/local/pgsql/data/pg_xlog Creating template1 database in /usr/local/pgsql/data/base/1 DEBUG: starting up DEBUG: database system was shut down at 2001-01-03 18:51:59 DEBUG: CheckPoint record at (0, 8) DEBUG: Redo record at (0, 8); Undo record at (0, 8); Shutdown TRUE DEBUG: NextTransactionId: 514; NextOid: 16384 DEBUG: database system is in production state Creating global relations in /usr/local/pgsql/data/global DEBUG: starting up DEBUG: database system was shut down at 2001-01-03 18:52:03 DEBUG: CheckPoint record at (0, 108) DEBUG: Redo record at (0, 108); Undo record at (0, 0); Shutdown TRUE DEBUG: NextTransactionId: 514; NextOid: 17199 DEBUG: database system is in production state Initializing pg_shadow. Enabling unlimited row width for system tables. Creating system views. Loading pg_description. Setting lastsysoid. Vacuuming database. Copying template1 to template0. Success. You can now start the database server using: /usr/local/pgsql/bin/postmaster -D /usr/local/pgsql/data or /usr/local/pgsql/bin/pg_ctl -D /usr/local/pgsql/data start Any ideas? Cheers, Patrick
[HACKERS] initdb prob
Please ignore last 2 messages re psql: FATAL 1: cannot open /usr/local/pgsql/data/global/pg_database: No such file or directory - I had another old postmaster running... Cheers, Patrick
[HACKERS] initdb prob
psql: FATAL 1: cannot open /usr/local/pgsql/data/global/pg_database: No such file or directory and it's true.. % ls /usr/local/pgsql/data/global 1260126112621264126917127 17130 pg_control source from Jan 3 15:59 GMT configure --enable-locale --enable-recode --enable-debug --enable-cassert --with-CXX all but geometry (rounding errors) pass gmake runcheck PGLIB=/usr/local/pgsql/lib PGDATA=/usr/local/pgsql/data PGDATESTYLE=European LC_ALL=en_GB.ISO8859-1 then did the initdb This database system will be initialized with username "postgres". This user will own all the data files and must also own the server process. Creating directory /usr/local/pgsql/data Creating directory /usr/local/pgsql/data/base Creating directory /usr/local/pgsql/data/global Creating directory /usr/local/pgsql/data/pg_xlog Creating template1 database in /usr/local/pgsql/data/base/1 DEBUG: starting up DEBUG: database system was shut down at 2001-01-03 18:51:59 DEBUG: CheckPoint record at (0, 8) DEBUG: Redo record at (0, 8); Undo record at (0, 8); Shutdown TRUE DEBUG: NextTransactionId: 514; NextOid: 16384 DEBUG: database system is in production state Creating global relations in /usr/local/pgsql/data/global DEBUG: starting up DEBUG: database system was shut down at 2001-01-03 18:52:03 DEBUG: CheckPoint record at (0, 108) DEBUG: Redo record at (0, 108); Undo record at (0, 0); Shutdown TRUE DEBUG: NextTransactionId: 514; NextOid: 17199 DEBUG: database system is in production state Initializing pg_shadow. Enabling unlimited row width for system tables. Creating system views. Loading pg_description. Setting lastsysoid. Vacuuming database. Copying template1 to template0. Success. You can now start the database server using: /usr/local/pgsql/bin/postmaster -D /usr/local/pgsql/data or /usr/local/pgsql/bin/pg_ctl -D /usr/local/pgsql/data start Any ideas? Cheers, Patrick
[HACKERS] test/locale broken
Just tried it for the first time: % cd src/test/locale % gmake all gmake: Circular test-pgsql-locale <- all dependency dropped. cd: can't cd to pgsql-locale gmake: *** [test-pgsql-locale] Error 2 I think the next stage is gmake test-koi8.. Cheers, Patrick
Re: [HACKERS] Autoconf version discrepancies
On Mon, Oct 09, 2000 at 04:11:20PM -0300, The Hermit Hacker wrote: > On Sun, 8 Oct 2000, Tom Lane wrote: ... > > Also, we not long ago went through the exercise of making sure that all > > committers were standardized on the same version of Autoconf, ie, 2.13. > > Now it emerges that hub.org is running a NON STANDARD version of > > Autoconf: 2.13 + unspecified BSD-originated hacks. So the output is > > likely to change depending on who committed last and where they did it > > from. > ... > If using mktemp doesn't break any platform, this is a moot point ... if it > does, then I think it is something that *has* to be fix in the FreeBSD > port itself so that it doesn't make us look FreeBSD-centric in our > development efforts on any other package ... To flog an already dead horse (then again my posts get stalled, so 8 Oct mail isn't that late :-) (whatever happenend to pgsql-loophole) ) SECURITY CONSIDERATIONS The use of mktemp() should generally be avoided, as a hostile process can exploit a race condition in the time between the generation of a tempo- rary filename by mktemp() and the invoker's use of the temporary name. A link-time warning will be issued advising the use of mkstemp() or mkdtemp() instead. Cheers, Patrick
[HACKERS] charset.htm
>From http://www.postgresql.org/devel-corner/docs/admin/charset.htm Once you have chosen a set of localization rules this way you must keep them fixed for any particular database cluster. That means that the locales that were active when you ran initdb must be kept the same when you start the postmaster. Is that still true? I seem to remember something about the postmaster using whatever initdb set.. Cheers, Patrick
[HACKERS] FW: User management
> -Original Message- > From: Patrick Dunford [mailto:[EMAIL PROTECTED]] > Sent: Friday, 19 January 2001 15:19 > To: [EMAIL PROTECTED] > Subject: User management > > > What commands in SQL enable administrators to view user / group > information? > Are there special SQL commands? Or are there special system tables? > > ======= > Patrick Dunford, Christchurch, NZ - http://pdunford.godzone.net.nz/ > >Not only so, but we also rejoice in our sufferings, because we > know that suffering produces perseverance; perseverance, character; > and character, hope. > -- Romans 5:3-4 > http://www.heartlight.org/cgi-shl/todaysverse.cgi?day=20010118 > === > Created by Mail2Sig - http://pdunford.godzone.net.nz/software/mail2sig/ > >
Re: [HACKERS] Re: Getting configure to notice link-time vs run-time failures
On Fri, Jan 19, 2001 at 12:46:53AM +0100, Peter Eisentraut wrote: > Tom Lane writes: > > > Gene and I looked into this, and the cause of the misbehavior is this: > > gcc on this installation is set to search /usr/local/lib (along with the > > usual system library directories). libz.so and libreadline.so are > > indeed in /usr/local/lib, so configure's tests to see if they can be > > linked against will succeed. But he had LD_LIBRARY_PATH set to a list > > that did *not* include /usr/local/lib, so actually firing up the > > executable would fail. > > You get what you pay for. If you're running executables from configure > you're asking for it. > > This setup is a poor man's cross-compilation situation because the system > you're compiling on is not identically configured to the system you're > going to run on. (Strictly speaking, the behaviour of a test program > might even vary with different LD_LIBRARY_PATH settings.) > > So > > a) PostgreSQL does not support cross-compilation (yet). Too bad. > > b) We could get rid of all executition time checks in configure (to > remedy (a)). This is one of my plans for the future. > > c) You could move the execution time checks up before the suspicious > library checks, but I'm afraid that this will only cure a particular > symptom and might introduce other problems. > > I'd say, you're stuck. > > -- > Peter Eisentraut [EMAIL PROTECTED] http://yi.org/peter-e/ > Wouldn't a -Wl,-R/usr/local/lib have helped? Cheers, Patrick
Re: [HACKERS] Possible performance improvement: buffer replacement policy
On Fri, Jan 19, 2001 at 12:03:58PM -0500, Bruce Momjian wrote: > > Tom, did we ever test this? I think we did and found that it was the > same or worse, right? (Funnily enough, I just read that message:) To: Bruce Momjian <[EMAIL PROTECTED]> cc: [EMAIL PROTECTED] Subject: Re: [HACKERS] Possible performance improvement: buffer replacement policy In-reply-to: <[EMAIL PROTECTED]> References: <[EMAIL PROTECTED]> Comments: In-reply-to Bruce Momjian <[EMAIL PROTECTED]> message dated "Mon, 16 Oct 2000 11:41:41 -0400" Date: Mon, 16 Oct 2000 11:49:52 -0400 Message-ID: <[EMAIL PROTECTED]> From: Tom Lane <[EMAIL PROTECTED]> X-Mailing-List: [EMAIL PROTECTED] Precedence: bulk Sender: [EMAIL PROTECTED] Status: RO Content-Length: 947 Lines: 19 Bruce Momjian <[EMAIL PROTECTED]> writes: >> It looks like it wouldn't take too much work to replace shared buffers >> on the basis of LRU-2 instead of LRU, so I'm thinking about trying it. >> >> Has anyone looked into this area? Is there a better method to try? > Sounds like a perfect idea. Good luck. :-) Actually, the idea went down in flames :-(, but I neglected to report back to pghackers about it. I did do some code to manage buffers as LRU-2. I didn't have any good performance test cases to try it with, but Richard Brosnahan was kind enough to re-run the TPC tests previously published by Great Bridge with that code in place. Wasn't any faster, in fact possibly a little slower, likely due to the extra CPU time spent on buffer freelist management. It's possible that other scenarios might show a better result, but right now I feel pretty discouraged about the LRU-2 idea and am not pursuing it. regards, tom lane
Re: [HACKERS] test/locale broken
On Fri, Jan 19, 2001 at 08:52:13PM +0100, Peter Eisentraut wrote: > Patrick Welche writes: > > > Just tried it for the first time: > > % cd src/test/locale > > % gmake all > > gmake: Circular test-pgsql-locale <- all dependency dropped. > > cd: can't cd to pgsql-locale > > gmake: *** [test-pgsql-locale] Error 2 > > I think it should work now. Yes, Thanks! Patrick
Re: [HACKERS] C++ interface build on FreeBSD 4.2 broken?
On Sat, Jan 20, 2001 at 08:06:51PM -0500, Tom Lane wrote: > What I've done to solve the immediate C++ problem is to take the > declaration of sys_nerr out of c.h entirely, and put it into the > two C modules that actually need it. However, I'm still wondering > whether we should not drop the rangecheck on errno completely. Probably not useful, but in our , sys_nerr is defined #if !defined(_ANSI_SOURCE) && !defined(_POSIX_C_SOURCE) && \ !defined(_XOPEN_SOURCE) P
[HACKERS] Strange..
rfb=# insert into person (id,surname) values (2274,'Unknown!'); ERROR: Relation 'subject' does not exist Correct - where does subject come from?! rfb=# \d person Table "person" Attribute | Type | Modifier ---+---+-- id| bigint| surname | character(20) | firstname | character(30) | email | character(30) | phone | character(16) | rfbdate | date | Index: name_idx (in fact no 'suject' in any table anywhere) Am I going spare? Cheers, Patrick PostgreSQL 7.1beta3 on i386-unknown-netbsdelf1.5Q, compiled by GCC egcs-1.1.2
[HACKERS] Strange.. solved
By comparing backups, I found
CREATE CONSTRAINT TRIGGER "" AFTER INSERT OR UPDATE ON "person" NOT
DEFERRABLE INITIALLY IMMEDIATE FOR EACH ROW EXECUTE PROCEDURE "RI_FKey_check_ins"
('', 'person', 'subject', 'UNSPECIFIED', 'subjectid', 'id');
Don't know where that came from, but probably operator error.. There isn't
an easy way of scrubbing an unnamed trigger is there? (I dump/edit/reloaded)
Cheers,
Patrick
Re: AW: [HACKERS] like and optimization
On Mon, Jan 22, 2001 at 05:46:09PM -0500, Tom Lane wrote: ... > Are there any BSD-license locale and/or timezone libraries that we might > assimilate in this way? We could use an LGPL'd library if there is no > other alternative, but I'd just as soon not open up the license issue. The "Citrus Project" is coming up with with i18n for BSD. FYI Patrick
Re: AW: [HACKERS] like and optimization
On Mon, Jan 22, 2001 at 03:09:03PM -0800, Nathan Myers wrote: ... > Posix systems include a set of commands for dumping locales in a standard > format, and building from them. Instead of shipping locales and code to > operate on them, one might include a script to run these tools (where > they exist) to dump an existing locale, edit it a bit, and build a more > PG-friendly locale. Is there really a standard format for locales? Apparantly there are 3 different ways of doing LC_COLLATE ?! Cheers, Patrick
Re: [HACKERS] beta3 Solaris 7 (SPARC) port report [ Was: Looking for . . . ]
On Thu, Jan 25, 2001 at 10:13:29PM -0500, Tom Lane wrote: > Frank Joerdens <[EMAIL PROTECTED]> writes: > > I just did that and ran make check 4 times. 3 times went completely > > smoothly, once I had random fail. This is the same behaviour that I saw > > when running make installcheck (76 successful most of the time, > > sometimes you get 75 out of 76 with random being the one that fails). > > Er, you do realize that the random test is *supposed* to fail every so > often? (Else it'd not be random...) See the pages on interpreting > regression test results in the admin guide. > > What troubles me is the nonrepeatable failures you saw on other tests. > As Peter says, if "make installcheck" (serial tests) is perfectly solid > and "make check" (parallel tests) is not, that suggests some kind of > interprocess locking problem. But we haven't heard about any such issue > on Solaris. Or simply running out of processes - check maxproc? (Deleted beginning of this thread, so may have missed something) Cheers, Patrick
[HACKERS] ODBC driver issue in MS Access
I installed the ODBC driver for Postgre, and linked in a table which has a Serial field for the primary key. In MS Access, the type is shown as just "Number (long integer)". When I try to add new records to my database in Access, I don't put anything into the key field because the server is supposed to generate it automatically. But when my record is sent back to the server, it rejects it and Access displays "#Deleted" in all of the fields. Is this because Postgre can't fill in the key field and so rejects it as an integrity constraint violation? I don't get any errors from Access. Should my database create its own key values and store them itself? ======= Patrick Dunford, Christchurch, NZ - http://pdunford.godzone.net.nz/ In this way, love is made complete among us so that we will have confidence on the day of judgment, because in this world we are like him. -- 1 John 4:17 http://www.heartlight.org/cgi-shl/todaysverse.cgi?day=20010210 === Created by Mail2Sig - http://pdunford.godzone.net.nz/software/mail2sig/
