[HACKERS] COPY commands could use an enhancement.
It would be very helpful if the COPY command could be expanded in order to provide positional parameters. I noticed that it didn't a while back and it can really hurt someone when they happen to try to use pg_dump to move data from one database to another database and they happened to create the feilds in the tables in different orders. Basically: COPY webmaster FROM stdin; could become: COPY webmaster FIELDS id, name, ssn FROM stdin; this way when sourcing it would know where to place the feilds. -- -Alfred Perlstein - [[EMAIL PROTECTED]] Daemon News Magazine in your snail-mail! http://magazine.daemonnews.org/ ---(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] Thanks, naming conventions, and count()
On Sun, 29 Apr 2001, Bruce Momjian wrote: I think parsing the file contents is too hard. The database would have to be running and I would use psql. I don't know, I recovered someone's database using a raw connection ... wasn't that difficult once I figured out the format *shrug* the following gets the oid,relname's for a database in the format: echo select oid,relname from pg_class | postgres -L -D /usr/local/pgsql/data eceb | egrep oid|relname then just parse the output using a simple perl script: 1: oid = 163338 (typeid = 26, len = 4, typmod = -1, byval = t) 2: relname = auth_info_uid_key (typeid = 19, len = 32, typmod = -1, byval = f) 1: oid = 163341 (typeid = 26, len = 4, typmod = -1, byval = t) 2: relname = auth_info_id(typeid = 19, len = 32, typmod = -1, byval = f) 1: oid = 56082 (typeid = 26, len = 4, typmod = -1, byval = t) 2: relname = auth_info (typeid = 19, len = 32, typmod = -1, byval = f) Oh, you did a direct postgres backend connect. Yes, that will work fine. Good idea if the postmaster is down. I originally thought you meant reading the pg_class file raw. Of course, that would be really hard because there is no way to know what numeric file is pg_class! But would it work on a crashed database that won't come up or doesn't the direct connect care about any other tables in this usage? Vince. -- == Vince Vielhaber -- KA8CSHemail: [EMAIL PROTECTED]http://www.pop4.net 56K Nationwide Dialup from $16.00/mo at Pop4 Networking Online Campground Directoryhttp://www.camping-usa.com Online Giftshop Superstorehttp://www.cloudninegifts.com == ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] Learning from other open source databases
Bruce Momjian [EMAIL PROTECTED] wrote: I can see Interbase, MySQL, and SAP DB as being three database that would be worth researching. I am willing to assist anyone who wants to give it a try. I have all the sources here myself. I even have old University Ingres, Mariposa, and Postgres 4.2. There's also the Shore data manager. While not a complete SQL database, I've wondered if it could actually be spliced into PostgreSQL, since the licenses appear compatible. http://www.cs.wisc.edu/shore/ Ken Hirsch ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
[HACKERS] Bug in ODBC driver
Guys, while analyzing some stuff I came across something that looks like a bug in the ODBC driver to me. I'm by far not the ODBC user I should be to fix it, so could someone else please take another look? The symptom is when the driver is in AUTOCOMMIT=OFF, closing the last used curser issues an END, thereby committing the transaction. It happens in odbc/qresult.c line 320 and the code looks pretty much like ignoring the autocommit flag. Jan -- #==# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #== [EMAIL PROTECTED] # _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
[HACKERS] Re: COPY commands could use an enhancement.
On Mon, 30 Apr 2001, Alfred Perlstein wrote: Basically: COPY webmaster FROM stdin; could become: COPY webmaster FIELDS id, name, ssn FROM stdin; We'd need some way of making field name dumping optional, because one of the nice things about not having the field names appear is that I can dump, change the field names, and re-slurp in the old dump. -- Joel Burton [EMAIL PROTECTED] Director of Information Systems, Support Center of Washington ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
[HACKERS] Re: v7.1.1 branched and released on Tuesday ...
Nothing serious, but I would like to apply a patch to allow IDENT strings (e.g. 'hour') to be accepted by the SQL92 EXTRACT() function. We accept those for date_part(), which is what EXTRACT() is translated to by the parser, and it seems to be a reasonable to the standard. But why does that need to go into 7.1.1? Does not need to. But it is non-invasive, extremely low risk, gets the behavior to match the docs, and gets it off my desk and into the main tree. - Thomas ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] SAPDB Open Souce
Horst Herb wrote: I downloaded it. The directories are two characters in length, the files are numbers, and it is a mixture of C++, Python, and Pascal. Need I say more. :-) 1.) What is wrong with a mixture of C++, Python and Pascal? Nothing IMHO. 2.) The directory structure is probably the consequence of the development tools (produced automatically). Such a structure can have advantages, too. 3.) I left Germany 6 years ago. I don't know what happened in the meantime, but at that time (and the past 10 years before that) virtually any major business and the majority of large hospitals were running on SAP. AFAIK, similar in other european countries. Complaints about the horrendous price structure (par with Oracle) - yes. Complaints about crappy user interfaces - yes. Complaints about arrogant support team - yes. But *no* complaints regarding data integrity, robustness, and almost no complaints regarding performance. Don't mix up SAP's application (R/3 today and R/2 before) with SAP DB. Most of the customers I've seen (and I've worked as an SAP R/3 base-consultant for the past 10 years) ran SAP R/3 on top of Oracle. So that's where the integrity and robustness came from. And I've got may complaints WRT performance - but fortunately our projects where usually located in the multi-$M range, so simply throwing bucks into iron worked. Jan -- #==# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #== [EMAIL PROTECTED] # _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com ---(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] Thanks, naming conventions, and count()
Vince Vielhaber [EMAIL PROTECTED] writes: Oh, you did a direct postgres backend connect. Yes, that will work fine. Good idea if the postmaster is down. I originally thought you meant reading the pg_class file raw. Of course, that would be really hard because there is no way to know what numeric file is pg_class! But would it work on a crashed database that won't come up No. It's not that hard to know which numeric file is pg_class --- that info has to be hard-wired in at some level. (The backends cannot learn pg_class's own relfilenode number by examining its pg_class entry...) It might be worth making a simple utility (could be based on Bryan White's pg_check) to grovel through the raw pg_class bits and extract relfilenode info the hard way. You'd only need it in certain disaster scenarios, but when you did need it you'd need it bad. So far we have not seen a report of a situation where this seemed to be useful, so I'm not that excited about having it... WAL dump and interrogation utilities are higher on my want list. regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Re: Any optimizations to the join code in 7.1?
Thomas Lockhart [EMAIL PROTECTED] writes: But it is possible, under many circumstances, for query optimization to be a benefit for a many-table query. The docs indicate that explicit join syntax bypasses that, even for inner joins, so you may find that this syntax is a net loss in performance depending on the query and your choice of table order. Presumably we will be interested in making these two forms of inner join equivalent in behavior in a future release. Tom, what are the impediments we might encounter in doing this? I don't think there are any real technical problems in the way; it's simply an implementation choice not to treat INNER JOIN the same as an implicit join list. I did it that way in 7.1 mainly as a flyer, to see how many people would think it's a feature vs. how many think it's a bug. The votes aren't all in yet, but here we have Mike apparently pretty pleased with it, while I recall at least one other person who was not happy with the 7.1 behavior. regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Thanks, naming conventions, and count()
It might be worth making a simple utility (could be based on Bryan White's pg_check) to grovel through the raw pg_class bits and extract relfilenode info the hard way. You'd only need it in certain disaster scenarios, but when you did need it you'd need it bad. So far we have not seen a report of a situation where this seemed to be useful, so I'm not that excited about having it... WAL dump and interrogation utilities are higher on my want list. OK, updated TODO item: * Add table name mapping for numeric file names I removed the symlink mention, and I agree it is low priority. No one is really asking for it. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
[HACKERS] Re: v7.1.1 branched and released on Tuesday ...
Thomas Lockhart writes: Nothing serious, but I would like to apply a patch to allow IDENT strings (e.g. 'hour') to be accepted by the SQL92 EXTRACT() function. We accept those for date_part(), which is what EXTRACT() is translated to by the parser, and it seems to be a reasonable to the standard. But why does that need to go into 7.1.1? Does not need to. But it is non-invasive, extremely low risk, gets the behavior to match the docs, and gets it off my desk and into the main tree. Hehe, match the docs? The docs used to be perfectly accurate until you changed them. -- Peter Eisentraut [EMAIL PROTECTED] http://funkturm.homeip.net/~peter ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] COPY commands could use an enhancement.
Alfred Perlstein [EMAIL PROTECTED] writes: It would be very helpful if the COPY command could be expanded in order to provide positional parameters. I think it's a bad idea to try to expand COPY into a full-tilt data import/conversion utility, which is the direction that this sort of suggestion is headed in. COPY is designed as a simple, fast, reliable, low-overhead data transfer mechanism for backup and restore. The more warts we add to it, the less well it will serve that purpose. Example: if we allow selective column import, what do we do with missing columns? Must COPY now be able to handle insertion of default-value expressions? I think it'd be better to put effort into an external data translation utility that can deal with column selection, data reformatting, CR/LF conversion, and all those other silly little issues that come up when you need to move data from one DBMS to another. Sure, we could make the backend do some of this stuff, but it'd be more maintainable as a separate program ... IMHO anyway. I think that pgaccess and pgadmin already have some capability in this line, BTW. regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Re: v7.1.1 branched and released on Tuesday ...
Thomas Lockhart [EMAIL PROTECTED] writes: Nothing serious, but I would like to apply a patch to allow IDENT strings (e.g. 'hour') to be accepted by the SQL92 EXTRACT() function. We accept those for date_part(), which is what EXTRACT() is translated to by the parser, and it seems to be a reasonable to the standard. But why does that need to go into 7.1.1? Does not need to. But it is non-invasive, extremely low risk, gets the behavior to match the docs, and gets it off my desk and into the main tree. If the current behavior does not match the docs then it qualifies as a bug fix ;-). I have no objections to this one. Thomas, what do you think of the persistent reports of date conversion problems at DST boundaries, eg, Ayal Leibowitz's report today in pgsql-bugs? I cannot reproduce any such problem --- and my local timezone database claims that MET DST transitions are the last week of March, never the first week of April, anyway. There's something funny going on there. regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] COPY commands could use an enhancement.
* Tom Lane [EMAIL PROTECTED] [010430 08:37] wrote: Alfred Perlstein [EMAIL PROTECTED] writes: It would be very helpful if the COPY command could be expanded in order to provide positional parameters. I think it's a bad idea to try to expand COPY into a full-tilt data import/conversion utility, which is the direction that this sort of suggestion is headed in. COPY is designed as a simple, fast, reliable, low-overhead data transfer mechanism for backup and restore. The more warts we add to it, the less well it will serve that purpose. Honestly it would be hard for COPY to be any more less serving of people's needs, it really makes sense for it to be able to parse positional paramters for both speed and correctness. Example: if we allow selective column import, what do we do with missing columns? What is already done, if you initiate a copy into a 5 column table using only 4 columns of copy data the fifth is left empty. Must COPY now be able to handle insertion of default-value expressions? No, copy should be what it is simple but at the same time useful enough for bulk transfer without painful contortions and fear of modifying tables. -- -Alfred Perlstein - [[EMAIL PROTECTED]] Represent yourself, show up at BABUG http://www.babug.org/ ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
Re: [HACKERS] COPY commands could use an enhancement.
Alfred Perlstein [EMAIL PROTECTED] writes: It would be very helpful if the COPY command could be expanded in order to provide positional parameters. I think it's a bad idea to try to expand COPY into a full-tilt data import/conversion utility, which is the direction that this sort of suggestion is headed in. COPY is designed as a simple, fast, reliable, low-overhead data transfer mechanism for backup and restore. The more warts we add to it, the less well it will serve that purpose. What is really cool is Informix's UNLOAD/LOAD commands. It combines COPY with SELECT/INSERT: UNLOAD TO '/tmp/x' SELECT * FROM tab and LOAD is similar: LOAD FROM '/tmp/x' INSERT INTO TAB This leverages SELECT and INSERT's column and WHERE capabilities to do almost anything you want with flat files. I think it is superior to our COPY. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026 ---(end of broadcast)--- TIP 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] COPY commands could use an enhancement.
Karen saw me importing data into a database using pgaccess. Again, this could be useful to someone that it is not a superuser. But only superusers can use pgaccess. What a shame :-( Fernando P.S.: pgaccess has a much more limited import facility - only text files and you can only change the delimiter. But it can be expanded. Tom Lane wrote: Alfred Perlstein [EMAIL PROTECTED] writes: It would be very helpful if the COPY command could be expanded in order to provide positional parameters. I think it's a bad idea to try to expand COPY into a full-tilt data import/conversion utility, which is the direction that this sort of suggestion is headed in. COPY is designed as a simple, fast, reliable, low-overhead data transfer mechanism for backup and restore. The more warts we add to it, the less well it will serve that purpose. Example: if we allow selective column import, what do we do with missing columns? Must COPY now be able to handle insertion of default-value expressions? I think it'd be better to put effort into an external data translation utility that can deal with column selection, data reformatting, CR/LF conversion, and all those other silly little issues that come up when you need to move data from one DBMS to another. Sure, we could make the backend do some of this stuff, but it'd be more maintainable as a separate program ... IMHO anyway. I think that pgaccess and pgadmin already have some capability in this line, BTW. regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED] -- Fernando Nasser Red Hat Canada Ltd. E-Mail: [EMAIL PROTECTED] 2323 Yonge Street, Suite #300 Toronto, Ontario M4P 2C9 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] pg_dump Backup on 7.0.3 - Sanity error?
Tom Lane wrote: Most likely, you removed the user that owned ro_ellipse. Create a user with the same usesysid shown as ro_ellipse's relowner, or else change the relowner field to point at an extant user. I believe 7.1's pg_dump copes with this sort of thing more gracefully... regards, tom lane Yes. I did delete that user. Thanks Tom. That makes sense. -Tony ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
Re: [HACKERS] Re: v7.1.1 branched and released on Tuesday ...
Thomas, what do you think of the persistent reports of date conversion problems at DST boundaries, eg, Ayal Leibowitz's report today in pgsql-bugs? I cannot reproduce any such problem --- and my local timezone database claims that MET DST transitions are the last week of March, never the first week of April, anyway. There's something funny going on there. Yes. I tried the example on 7.0.2 (and 7.1) and could not get it to misbehave. I was guessing that it involves string-date conversion, which may pass through timestamp to get there, but it looks like there is an explicit text-date conversion function so time zone should just never be involved. Really! - Thomas ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
[HACKERS] Re: v7.1.1 branched and released on Tuesday ...
Hehe, match the docs? The docs used to be perfectly accurate until you changed them. ;) ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] PQftype()
From: Tom Lane [EMAIL PROTECTED] Magnus Naeslund\(f\) [EMAIL PROTECTED] writes: Where do get a listing of what PQftype() can return to me? select oid, typname from pg_type regards, tom lane Does these change often? Or could i do like the ODBC driver, autogenerate a .h out of that table. Magnus -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Programmer/Networker [|] Magnus Naeslund PGP Key: http://www.genline.nu/mag_pgp.txt -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] PQftype()
From: Tom Lane [EMAIL PROTECTED] [snip] The system type OIDs are stable. User-defined types would probably have a new OID after a dump and reload. Or could i do like the ODBC driver, autogenerate a .h out of that table. I would not recommend relying on compiled-in OID knowledge for any types other than the system-defined datatypes. If you expect to have to deal with user-defined types, it's best to cache the results of pg_type lookups at the client end. You need not worry about OIDs changing during a single client connection. regards, tom lane Ok, then i can use static thing for my application (for now atleast). Thanks.. Magnus ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] PQftype()
Magnus Naeslund\(f\) [EMAIL PROTECTED] writes: Where do get a listing of what PQftype() can return to me? select oid, typname from pg_type Does these change often? The system type OIDs are stable. User-defined types would probably have a new OID after a dump and reload. Or could i do like the ODBC driver, autogenerate a .h out of that table. I would not recommend relying on compiled-in OID knowledge for any types other than the system-defined datatypes. If you expect to have to deal with user-defined types, it's best to cache the results of pg_type lookups at the client end. You need not worry about OIDs changing during a single client connection. regards, tom lane ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
[HACKERS] Re: COPY commands could use an enhancement.
On Mon, 30 Apr 2001, Tom Lane wrote: I think it'd be better to put effort into an external data translation utility that can deal with column selection, data reformatting, CR/LF conversion, and all those other silly little issues that come up when you need to move data from one DBMS to another. Sure, we could make the backend do some of this stuff, but it'd be more maintainable as a separate program ... IMHO anyway. I think that pgaccess and pgadmin already have some capability in this line, BTW. Real conversion should happen in userland. However, allowing people to COPY in a different order does prevent a userland tool from having to re-arrange a dump file. (Of course, really, with perl, re-ordering a dump file should take more than a few lines anyway.) Are there any generalized tools for re-ordering delimited columns, without having to use sed/perl/regexes, etc.? If people can point to some best practices/ideas, I'd be happy to turn them into a HOWTO. -- Joel Burton [EMAIL PROTECTED] Director of Information Systems, Support Center of Washington ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] v7.1.1 branched and released on Tuesday ...
The Hermit Hacker [EMAIL PROTECTED] writes: Does anyone have any outstanding fixes for v7.1.x that they want to see in *before* we do this release? Any points unresolved that anyone knows about that we need to look at? FWIW, I've finished committing all the bug fixes I have pending. There are several worrisome unresolved bug reports, but AFAIK none are for reproducible conditions, and I don't think we can make any more progress on them without more information. I doubt we should hold up the 7.1.1 release while waiting to see if we get any. We do have that not-quite-done QNX4 port patch in hand. Perhaps we should give Bernd another day to respond to the comments on that and squeeze it into 7.1.1. There will surely be a 7.1.2. I vote against waiting for it. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] v7.1.1 branched and released on Tuesday ...
Bruce Momjian [EMAIL PROTECTED] writes: We do have that not-quite-done QNX4 port patch in hand. Perhaps we should give Bernd another day to respond to the comments on that and squeeze it into 7.1.1. There will surely be a 7.1.2. I vote against waiting for it. Possibly, but one hopes 7.1.2 will be a few months away ... Given the triviality of the objections to Bernd's patch, I expect he can turn it around pretty quickly. I do not want to wait more than a day for it. regards, tom lane ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
[HACKERS] Re: date conversion (was Re: Re: v7.1.1 branched and released on Tuesday ...)
I dug through the conversions involved (basically date_in and date_out).
AFAICS the only place where timezone could possibly get involved is that
DecodeDateTime attempts to derive a timezone for the given date/time.
It does this by calling mktime() (line 878 in datetime.c in current
sources). If mktime() screws up and alters the tm-tm_mday field then
we'd see the reported behavior. I really don't see any other place that
it could be happening.
Yes. It is possible to call DecodeDateTime() so that it *never* tries to
derive a time zone (call with the last argument set to NULL), but that
also causes it to reject date/time strings which have an explicit time
zone. We certainly would want to accept something like
select date('1993-04-02 04:05:06 PST');
(even though for a date-only result it is overspecified), so calling
with NULL is not the right thing to do (I tried it, then realized the
bad effect).
A platform-specific bug in mktime would do nicely to explain why we
can't reproduce the problem, too ... OTOH, it's hard to believe such a
bug would have persisted across several RedHat releases, which seems to
be necessary to explain the reports.
It is also hard to see how such a bug would not be similarly manifested
in Mandrake, Debian, etc etc.
For this particular problem, I'd like to see the DateStyle setting,
the time zone setting, an example of the problem (does not require a
table, but just a date string conversion), and the output of zdump -v
for the timezone in question.
I'm not sure how to handle date/time bug reports which are not
reproducible on our machines. Certainly date/time issues are the most
problematic in terms of number of bug reports, but they are also
probably the most sensitive to machine configuration and user's
location, so all in all I think the types are doing very well. I don't
want to sound complacent, but it is probably sufficient to fix
reproducible problems to keep our date/time data types viable, and we
are doing far more than that over time :)
- Thomas
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://www.postgresql.org/search.mpl
Re: [HACKERS] COPY commands could use an enhancement.
Philip Warner [EMAIL PROTECTED] writes: Do you have a alternate suggestion as to how to solve the problems it has backing up the regression DB? One possibility is to fix ALTER TABLE ADD COLUMN to maintain the same column ordering in parents and children. COPY with specified columns may in fact be the best way to deal with that particular issue, if pg_dump is all we care about fixing. However there are a bunch of things that have a problem with it, not only pg_dump. See thread over in committers about functions and inheritance. regards, tom lane ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] v7.1.1 branched and released on Tuesday ...
On Mon, 30 Apr 2001, Tom Lane wrote: The Hermit Hacker [EMAIL PROTECTED] writes: Does anyone have any outstanding fixes for v7.1.x that they want to see in *before* we do this release? Any points unresolved that anyone knows about that we need to look at? FWIW, I've finished committing all the bug fixes I have pending. There are several worrisome unresolved bug reports, but AFAIK none are for reproducible conditions, and I don't think we can make any more progress on them without more information. I doubt we should hold up the 7.1.1 release while waiting to see if we get any. We do have that not-quite-done QNX4 port patch in hand. Perhaps we should give Bernd another day to respond to the comments on that and squeeze it into 7.1.1. How about I do another end of week release? Give Bernd until Friday to sort through the patch with everyone without it being rushed ... ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] 7.1 startup recovery failure
Vadim Mikheev wrote: There's a report of startup recovery failure in Japan. Redo done but ... Unfortunately I have no time today. Please ask to start up with wal_debug = 1... Isn't it very difficult for dbas to leave the corrupted database as it is ? ISTM we could hardly expect to get the log with wal_debug = 1 unless we automatically force the log in case of recovery failures. regards, Hiroshi Inoue ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
Re: [HACKERS] 7.1 startup recovery failure
Corrupted or not, after a crash take a snapshot of the data tree before firing it back up again. Doesn't take that much time (especially with a netapp filer) and it allows for a virtually unlimited number of attempts to solve the trouble or debug. -- Rod Taylor BarChord Entertainment Inc. - Original Message - From: "Hiroshi Inoue" [EMAIL PROTECTED] To: "Vadim Mikheev" [EMAIL PROTECTED] Cc: "pgsql-hackers" [EMAIL PROTECTED] Sent: Monday, April 30, 2001 11:02 PM Subject: Re: [HACKERS] 7.1 startup recovery failure Vadim Mikheev wrote: There's a report of startup recovery failure in Japan. Redo done but ... Unfortunately I have no time today. Please ask to start up with wal_debug = 1... Isn't it very difficult for dbas to leave the corrupted database as it is ? ISTM we could hardly expect to get the log with wal_debug = 1 unless we automatically force the log in case of recovery failures. regards, Hiroshi Inoue ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
