Re: [HACKERS] Proposal for Recover mode in pg_ctl (in 8.0)
I was thinking that even mildly experienced folks could benefit from a helpful sanity check. Typically the need to recover a system never comes at a good time, and features that help prevent silly mistakes are a great stress saver. As an aside, while testing recovery during pre beta, I think I probably "forgot" to put in a recovery.conf about 1 time in 10. Now I was using a small database cluster tar'ed up in /tmp, so no big deal, but if it had been a 100G beast that had to come off tape regards Mark Tom Lane wrote: I can't get very excited about this approach, because it only protects those people who (a) use pg_ctl to start the postmaster (not everyone) and (b) carefully follow the recovery directions (which the people you are worried about are very bad at, by hypothesis). ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Proposal for Recover mode in pg_ctl (in 8.0)
While this is nice, it will not help you if the restoration directory is different from your archive directory. That is : restore_command in recovery.conf fetches from somewhere other than where archive_command in postgresql.conf copied. I am not sure how likely this situation is, but setting up log shipping, or maybe recovering from disk failure *might* mean you need to bring the saved archive files "back from somewhere else". regards Mark Tom Lane wrote: Another and simpler way is to recommend that people use archive_command strings that won't overwrite an existing archive file. For instance instead of showing the example archive_command = 'cp %p /mnt/server/archivedir/%f' we could show archive_command = 'test ! -f /mnt/server/archivedir/%f && cp %p /mnt/server/archivedir/%f' ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] Increasing the length of pg_stat_activity.current_query...
Sean Chittenden <[EMAIL PROTECTED]> writes: > Having a 1K query isn't uncommon on some of the stuff I work on, an 8K > query... > that's a tad different and would stick out like a sore thumb. Just as a point of reference, I've been processing my logs to see how large my queries work out to. They seem to max out at just over 5k, (5330 bytes to be exact). This is excluding "CREATE FUNCTION" calls where the body of the function can of course be much larger but isn't interesting for stats. > Would you be open to increasing this further after the 8.0 release? I > haven't heard of anyone complaining about dropped/fragmented pgstat > messages. :) -sc >From my own experience I would suggest 8k. If it's good enough for NFS defaults it ought to be good enough for Postgres. Realistically, you shouldn't be expecting any real quantities of dropped packets on a local area network, so fragmented UDP packets aren't really a problem. Anyone running their stats collector over a long haul internet connection with dropped packets is probably doing something pretty unusual. I think historically implementations didn't handle fragmented UDP packets at all, or perhaps not over 32k. But any platform today ought to be happy with packets at least up to 32k and any modern platform quite a bit larger. -- greg ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] Proposal for Recover mode in pg_ctl (in 8.0)
I wrote: > A possibly more reliable interlock would involve having the postmaster > probe during normal startup to see if there is already an archived WAL > segment for what it thinks is the current segment. Another and simpler way is to recommend that people use archive_command strings that won't overwrite an existing archive file. For instance instead of showing the example archive_command = 'cp %p /mnt/server/archivedir/%f' we could show archive_command = 'test ! -f /mnt/server/archivedir/%f && cp %p /mnt/server/archivedir/%f' or on some machines archive_command = 'cp -i %p /mnt/server/archivedir/%f
Re: [HACKERS] Proposal for Recover mode in pg_ctl (in 8.0)
I like it - nice and simple, but targets a large (and likely) foot gun situation. regards Mark Simon Riggs wrote: If a further pg_ctl mode, recover, were implemented, this would allow a fail safe mode for recovery. e.g.pg_ctl -D datadir recover pg_ctl could then check for the existence of a recovery.conf file and return an error if none were found. This mode would not then need to be passed through to the postmaster as an option, which could accidentally be re-invoked later should a crash recovery occur (the main reason to avoid adding recovery.conf options to postgresql.conf in the first place). This mode would do nothing more than: - check for recovery.conf, if not found, return error - invoke a start normally, as if mode=start had been requested The doc for invoking recovery could then be changed to include this new mode, and the potential for error would be removed. This is a change requested for 8.0, to ensure that PITR doesn't fall into disrepute by novice users shooting themselves in the foot. It is a minor change, effecting only PITR, and only to the extent of a documentation change and a file existence check in pg_ctl. No server code would be changed. Alternative suggestions are welcome. Thoughts? ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Proposal for Recover mode in pg_ctl (in 8.0)
Simon Riggs <[EMAIL PROTECTED]> writes: > If a further pg_ctl mode, recover, were implemented, this would allow a > fail safe mode for recovery. > e.g. pg_ctl -D datadir recover > pg_ctl could then check for the existence of a recovery.conf file and > return an error if none were found. I can't get very excited about this approach, because it only protects those people who (a) use pg_ctl to start the postmaster (not everyone) and (b) carefully follow the recovery directions (which the people you are worried about are very bad at, by hypothesis). A possibly more reliable interlock would involve having the postmaster probe during normal startup to see if there is already an archived WAL segment for what it thinks is the current segment. However there are several issues here: one is that if you're doing partial-log-file shipping, that isn't necessarily an error condition; another is that we don't know how to do such a probe unless more information is added to postgresql.conf. We could imagine adding another shell command string (something like "test -f ..." perhaps) but if the user gets it wrong he may still be left with no protection. regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Increasing the length of pg_stat_activity.current_query...
Simon Riggs <[EMAIL PROTECTED]> writes: > Not having the whole query is painful. Raising it to 1K doesn't get > round the fact that it's the longer queries that tend to be the more > painful ones, and so they are the ones you want to trap in full and > EXPLAIN, so you can find out if they are *ever* coming back. ... so look in the postmaster log ... > I'd vote in favour of relaxing the limit entirely, as Sean suggests. The choice is not between "limit" and "no limit", it is between "limit" and "broken". regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] relative_path() seems overly complicated and buggy
Bruce Momjian <[EMAIL PROTECTED]> writes: > Bruce Momjian wrote: >> Tom Lane wrote: >>> What I'd like to do is simplify it to just check for exact equality >>> up through the last directory separator in bin_path. Any objections? >> >> If you can simplify it, feel free. I found that code much more complex >> than I liked but couldn't simplify it. Originally I thought that would >> be used in more generic places but that hasn't happened. > Let me try to clean it up first by using canonicalize_path() and > comparing the result. I already checked in the simplification. 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] Proposal for Recover mode in pg_ctl (in 8.0)
Joachim Wieland has diligently and sensibly pointed out a potential for user error with the current PITR implementation. This is not a bug *per se*, but is a design flaw that more than one person could fall into. It is a minor issue and not that likely, since the manual describes what to do...but I'm proposing a possible solution nonetheless, since this error is likely to occur whilst learning the PITR functionality and might potentially dissuade users from using the approach. Following restoration of a base backup, archive recovery is entered by placing a recovery.conf file in the data directory and then restarting the server using pg_ctl start. If the recovery.conf file is misnamed, e.g. Recovery.conf, or if it is misplaced, or simply absent, then the server start will not enter archive recovery, yet will start normally. The precise difference might well not be apparent. Subsequent server activity could potentially overwrite archived log files in a poorly managed archive. Both of those situations are likely to occur simultaneously with inexperienced users. The first fix to this is clearly to document the possibility and warn the user of this possibility - i.e. describe what NOT to do when invoking archive recovery. This will be submitted shortly. A further fix is to implement a fail safe mode for invoking recovery. Rather than making the recovery a normal server start, which then searches for recovery.conf, it would be better to indicate that the server start is expected to be a recovery and so the absence of a recovery.conf should be regarded as an error. If a further pg_ctl mode, recover, were implemented, this would allow a fail safe mode for recovery. e.g.pg_ctl -D datadir recover pg_ctl could then check for the existence of a recovery.conf file and return an error if none were found. This mode would not then need to be passed through to the postmaster as an option, which could accidentally be re-invoked later should a crash recovery occur (the main reason to avoid adding recovery.conf options to postgresql.conf in the first place). This mode would do nothing more than: - check for recovery.conf, if not found, return error - invoke a start normally, as if mode=start had been requested The doc for invoking recovery could then be changed to include this new mode, and the potential for error would be removed. This is a change requested for 8.0, to ensure that PITR doesn't fall into disrepute by novice users shooting themselves in the foot. It is a minor change, effecting only PITR, and only to the extent of a documentation change and a file existence check in pg_ctl. No server code would be changed. Alternative suggestions are welcome. Thoughts? -- Best Regards, Simon Riggs ---(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] relative_path() seems overly complicated and buggy
Bruce Momjian wrote: > Tom Lane wrote: > > There's at least one bug in path.c's relative_path(): it will think > > "/foo/a/b" is equal to "/foo/ab" because it skips directory separators > > independently in the two strings. The code is sufficiently complex that > > I have little faith in it not having any other bugs, either. > > > > I believe that it's unnecessary for relative_path to be so tense > > about trying to implement platform-weirdness-aware comparison of paths. > > It is not called on arbitrary paths, but only on the compiled-in > > paths that were generated by configure. Therefore it is reasonable > > to assume that the common prefix we are trying to identify is spelled > > exactly the same in both paths. > > > > What I'd like to do is simplify it to just check for exact equality > > up through the last directory separator in bin_path. Any objections? > > If you can simplify it, feel free. I found that code much more complex > than I liked but couldn't simplify it. Originally I thought that would > be used in more generic places but that hasn't happened. Let me try to clean it up first by using canonicalize_path() and comparing the result. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Increasing the length of
On Sat, 2004-11-06 at 19:44, Tom Lane wrote: > Sean Chittenden <[EMAIL PROTECTED]> writes: > > Is there any reason the length of > > pg_catalog.pg_stat_activity.current_query is capped at 255 characters? > > The reason for a limit is to avoid fragmentation of UDP messages. > I believe we've set it at 1K for 8.0, though, and if you are on > a platform with a higher message size limit you could raise it more. > Hopefully, that is an explanation and not a justification. Assuming there is no actual barrier to change on that point... Not having the whole query is painful. Raising it to 1K doesn't get round the fact that it's the longer queries that tend to be the more painful ones, and so they are the ones you want to trap in full and EXPLAIN, so you can find out if they are *ever* coming back. The assumption that we are also logging queries is less likely to be true. pg_stat_activity is a window into the dynamic activity of the server and is used for to-the-minute administration. The query volume may be too high to enable full query logging all of the time. If somebody is bothered by UDP fragmentation, then they should ask for only the first 255 chars, rather than doing a select * from pg_stat_activity. If its a backward compatibility issue, perhaps we can set up a view to fake it for those people. I'd vote in favour of relaxing the limit entirely, as Sean suggests. -- Best Regards, Simon Riggs ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] Increasing the length of pg_stat_activity.current_query...
Sean Chittenden <[EMAIL PROTECTED]> writes: > Would you be open to increasing this further after the 8.0 release? Nope. > I haven't heard of anyone complaining about dropped/fragmented pgstat > messages. :) -sc That's because we keep 'em small enough to not fragment. regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] relative_path() seems overly complicated and buggy
Tom Lane wrote: > There's at least one bug in path.c's relative_path(): it will think > "/foo/a/b" is equal to "/foo/ab" because it skips directory separators > independently in the two strings. The code is sufficiently complex that > I have little faith in it not having any other bugs, either. > > I believe that it's unnecessary for relative_path to be so tense > about trying to implement platform-weirdness-aware comparison of paths. > It is not called on arbitrary paths, but only on the compiled-in > paths that were generated by configure. Therefore it is reasonable > to assume that the common prefix we are trying to identify is spelled > exactly the same in both paths. > > What I'd like to do is simplify it to just check for exact equality > up through the last directory separator in bin_path. Any objections? If you can simplify it, feel free. I found that code much more complex than I liked but couldn't simplify it. Originally I thought that would be used in more generic places but that hasn't happened. -- 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 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Increasing the length of pg_stat_activity.current_query...
I'm confused... UDP as in the UDP/IP? RPC caps UDP messages at 8K and NFS over UDP often runs at 32K... where is UDP used in the backend? pgstat messages travel over UDP/IP. Over the loopback interface, right? Then why worry about fragmentation? This seems like premature optimization/prevention. A lost packet over lo0 is symptom of a bigger problem. The contents of pgstat messages are probably the least of an admins concerns if that's happening. Having a 1K query isn't uncommon on some of the stuff I work on, an 8K query... that's a tad different and would stick out like a sore thumb. Would you be open to increasing this further after the 8.0 release? I haven't heard of anyone complaining about dropped/fragmented pgstat messages. :) -sc -- Sean Chittenden ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Increasing the length of pg_stat_activity.current_query...
Sean Chittenden <[EMAIL PROTECTED]> writes: > I'm confused... UDP as in the UDP/IP? RPC caps UDP messages at 8K and > NFS over UDP often runs at 32K... where is UDP used in the backend? pgstat messages travel over UDP/IP. regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] cygwin build failure
Bruce Momjian <[EMAIL PROTECTED]> writes: > Andrew Dunstan wrote: >> /home/adunstan/pgbf/root/HEAD/pgsql.3200/src/port/pgstrcasecmp.c:119: multiple >> definition of `_pg_tolower' > The _pg_tolower problem started when I changed exec.c to use the more > standard pg_strcasecmp rather than stricmp. Since it's in an #ifdef WIN32 section, there's probably no harm in changing it back. Dunno about the optarg business; it sounds like a DLLIMPORT is needed someplace, but maybe that is a bug in the Cygwin headers rather than our bug? regards, tom lane ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
[HACKERS] relative_path() seems overly complicated and buggy
There's at least one bug in path.c's relative_path(): it will think "/foo/a/b" is equal to "/foo/ab" because it skips directory separators independently in the two strings. The code is sufficiently complex that I have little faith in it not having any other bugs, either. I believe that it's unnecessary for relative_path to be so tense about trying to implement platform-weirdness-aware comparison of paths. It is not called on arbitrary paths, but only on the compiled-in paths that were generated by configure. Therefore it is reasonable to assume that the common prefix we are trying to identify is spelled exactly the same in both paths. What I'd like to do is simplify it to just check for exact equality up through the last directory separator in bin_path. Any objections? regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Increasing the length of pg_stat_activity.current_query...
Is there any reason the length of pg_catalog.pg_stat_activity.current_query is capped at 255 characters? The reason for a limit is to avoid fragmentation of UDP messages. I believe we've set it at 1K for 8.0, though, and if you are on a platform with a higher message size limit you could raise it more. I'm confused... UDP as in the UDP/IP? RPC caps UDP messages at 8K and NFS over UDP often runs at 32K... where is UDP used in the backend? -sc -- Sean Chittenden ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Increasing the length of pg_stat_activity.current_query...
Sean Chittenden <[EMAIL PROTECTED]> writes: > Is there any reason the length of > pg_catalog.pg_stat_activity.current_query is capped at 255 characters? The reason for a limit is to avoid fragmentation of UDP messages. I believe we've set it at 1K for 8.0, though, and if you are on a platform with a higher message size limit you could raise it more. regards, tom lane ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] Using ALTER TABLESPACE in pg_dump
Philip Warner <[EMAIL PROTECTED]> writes: > Attached. It has some trivial-looking rejects on current CVS. Let me know > if you would prefer me to do the work, or want some testing done. It was > tested (in terms of output validity) with 8.0b1. Applied with minor cleanups. regards, tom lane ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] Documentation on PITR still scarce
On Sat, 2004-11-06 at 15:03, Joachim Wieland wrote: > Hi, > > On Sat, Nov 06, 2004 at 11:13:34AM +, Simon Riggs wrote: > > The timeline code only comes into effect when you request an archive > > recovery. If you do not, it has no way of knowing it "should have". > > Ok. However these details should be added to the docs as well. > At least a short warning should show up in 22.3.3 7. > I agree. I'm thinking of other solutions/options also. Please feel free to suggest one. > > > Once you have brought up a database in timeline N+1, you can't use it as > > the base to recover to a point in timeline N because the data file > > contents cannot be trusted to be identical to the way they were in > > timeline N. > > You mean "in timeline N ... to a point in timeline N+1", don't you? > Specifically not. The point is: you can't go back in time. Recovery is a rollforward operation, so you must start at an earlier point and rollforwards from there. -- Best Regards, Simon Riggs ---(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] Increasing the length of pg_stat_activity.current_query...
Sean Chittenden wrote: > Is there any reason the length of > pg_catalog.pg_stat_activity.current_query is capped at 255 characters? > Why can't it be a pointer to the currently running query? > > Seems silly to me and is a PITA to try and use as a debugging tool only > to find out that the query in question, has a logical break right at > character 255 so the query in pg_stat_query looks like it's the > complete query, but it's not (extra foo at the end of the query is > causing it to run dog slow, but it's difficult to see that without > going to the logs and digging through them to find the problem > statement). > > Anyway, is there any good reason for this or can this be increased > somehow? -sc I think it is limited because the queries are stored in shared memory, maybe. -- 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
Re: [HACKERS] cygwin build failure
Andrew Dunstan wrote: > As requested by Reini I set up a Cygwin buildfarm client, and immediately got this > build failure: > > > gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith -Wendif-labels > -fno-strict-aliasing -g pg_dump.o common.o pg_dump_sort.o pg_backup_archiver.o > pg_backup_db.o pg_backup_custom.o pg_backup_files.o pg_backup_null.o pg_backup_tar.o > dumputils.o ../../../src/backend/parser/keywords.o -L../../../src/interfaces/libpq > -lpq -L../../../src/port -L/usr/local/lib -lpgport -lcrypt -o pg_dump.exe > ../../../src/port/libpgport.a(pgstrcasecmp.o)(.text+0x1b0): In function `pg_tolower': > /home/adunstan/pgbf/root/HEAD/pgsql.3200/src/port/pgstrcasecmp.c:119: multiple > definition of `_pg_tolower' > ../../../src/interfaces/libpq/libpq.a(dshcs00145.o)(.text+0x0): first defined here > Info: resolving _optarg by linking to __imp__optarg (auto-import) > Info: resolving _optind by linking to __imp__optind (auto-import) > collect2: ld returned 1 exit status > make[3]: *** [pg_dump] Error 1 > > see http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=gibbon&dt=2004-11-06%2018:11:58 The _pg_tolower problem started when I changed exec.c to use the more standard pg_strcasecmp rather than stricmp. I am confused why this caused a problem however because libpgport has pg_tolower because it has pgstrcasecmp.c. Any ideas? -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
[HACKERS] Increasing the length of pg_stat_activity.current_query...
Is there any reason the length of pg_catalog.pg_stat_activity.current_query is capped at 255 characters? Why can't it be a pointer to the currently running query? Seems silly to me and is a PITA to try and use as a debugging tool only to find out that the query in question, has a logical break right at character 255 so the query in pg_stat_query looks like it's the complete query, but it's not (extra foo at the end of the query is causing it to run dog slow, but it's difficult to see that without going to the logs and digging through them to find the problem statement). Anyway, is there any good reason for this or can this be increased somehow? -sc -- Sean Chittenden ---(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] cygwin build failure
As requested by Reini I set up a Cygwin buildfarm client, and immediately got this build failure: gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith -Wendif-labels -fno-strict-aliasing -g pg_dump.o common.o pg_dump_sort.o pg_backup_archiver.o pg_backup_db.o pg_backup_custom.o pg_backup_files.o pg_backup_null.o pg_backup_tar.o dumputils.o ../../../src/backend/parser/keywords.o -L../../../src/interfaces/libpq -lpq -L../../../src/port -L/usr/local/lib -lpgport -lcrypt -o pg_dump.exe ../../../src/port/libpgport.a(pgstrcasecmp.o)(.text+0x1b0): In function `pg_tolower': /home/adunstan/pgbf/root/HEAD/pgsql.3200/src/port/pgstrcasecmp.c:119: multiple definition of `_pg_tolower' ../../../src/interfaces/libpq/libpq.a(dshcs00145.o)(.text+0x0): first defined here Info: resolving _optarg by linking to __imp__optarg (auto-import) Info: resolving _optind by linking to __imp__optind (auto-import) collect2: ld returned 1 exit status make[3]: *** [pg_dump] Error 1 see http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=gibbon&dt=2004-11-06%2018:11:58 (Is it possible to get rid of those Info lines?) cheers andrew ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] pg buildfarm status update
Andrew Dunstan schrieb: Could loris also be used to do the cygwin and MSVC builds? Cygwin is next on my list. The buildfarm client script does full server builds, so MSVC isn't on the radar right now. FYI the steps in the process are (more or less): configure make make check make contrib make install initdb startdb make installcheck make contrib install make contrib installcheck stopdb I don't intend to use the machine that is loris for long - it's too slow and memory bound. If anyone has a nice fast Windows machine with 1Gb+ of Ram that we could use for a buildfarm client (Windows Native and/or Cygwin) that would be awesome. Sorry, no. Is there no ISP around, which wants to save some money? :) Also, if anyone managed to port ccache to Windows that would be huge too. Using it on Unix has proved to be a major gain. ccache is available via cygwin at least. -- Reini Urban http://xarch.tu-graz.ac.at/home/rurban/ ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] pg buildfarm status update
Reini Urban wrote: Andrew Dunstan schrieb: The PG buildfarm has been operational for a little while now, thanks to Joshua and CommandPrompt for the server space. You can see the current status at: http://www.pgbuildfarm.org/cgi-bin/show_status.pl Today for the first time I got a Windows client working, and will be putting the code changes in CVS on pgfoundry soon. Then I will turn to improving the web interface, moving from the rather severely functional setup currently used. Could loris also be used to do the cygwin and MSVC builds? Cygwin is next on my list. The buildfarm client script does full server builds, so MSVC isn't on the radar right now. FYI the steps in the process are (more or less): configure make make check make contrib make install initdb startdb make installcheck make contrib install make contrib installcheck stopdb I don't intend to use the machine that is loris for long - it's too slow and memory bound. If anyone has a nice fast Windows machine with 1Gb+ of Ram that we could use for a buildfarm client (Windows Native and/or Cygwin) that would be awesome. Also, if anyone managed to port ccache to Windows that would be huge too. Using it on Unix has proved to be a major gain. cheers andrew ---(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] Release schedule plans
Simon Riggs <[EMAIL PROTECTED]> writes: >> Peter has is thinking of freezing error message strings next week so >> others can start on translations, and we should start collecting port >> reports after the next beta too. > Is there a doc freeze as well as the error message string freeze? No, we never freeze docs in advance of release. regards, tom lane ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] pg buildfarm status update
Andrew Dunstan schrieb: The PG buildfarm has been operational for a little while now, thanks to Joshua and CommandPrompt for the server space. You can see the current status at: http://www.pgbuildfarm.org/cgi-bin/show_status.pl Today for the first time I got a Windows client working, and will be putting the code changes in CVS on pgfoundry soon. Then I will turn to improving the web interface, moving from the rather severely functional setup currently used. Could loris also be used to do the cygwin and MSVC builds? -- Reini Urban http://xarch.tu-graz.ac.at/home/rurban/ ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
[HACKERS] pg buildfarm status update
The PG buildfarm has been operational for a little while now, thanks to Joshua and CommandPrompt for the server space. You can see the current status at: http://www.pgbuildfarm.org/cgi-bin/show_status.pl Today for the first time I got a Windows client working, and will be putting the code changes in CVS on pgfoundry soon. Then I will turn to improving the web interface, moving from the rather severely functional setup currently used. cheers andrew ---(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] Documentation on PITR still scarce
Hi, On Sat, Nov 06, 2004 at 11:13:34AM +, Simon Riggs wrote: > The timeline code only comes into effect when you request an archive > recovery. If you do not, it has no way of knowing it "should have". Ok. However these details should be added to the docs as well. At least a short warning should show up in 22.3.3 7. > Once you have brought up a database in timeline N+1, you can't use it as > the base to recover to a point in timeline N because the data file > contents cannot be trusted to be identical to the way they were in > timeline N. You mean "in timeline N ... to a point in timeline N+1", don't you? > Re-restoring the backup sounds like a thing that > needs-optimization, but it is required for transactional correctness. > [There is some slight area of improvement, but I don't wish to explain > this because it might lure people into error by mentioning it...the code > currently requires re-restoring] Ok. Thanks for all your explanations, Joachim ---(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] Concern about new PL/Perl
It seems that in the new PL/Perl, the result of the spi_exec_query
function changes in meaning depending on the command. For a SELECT,
the value of
$res->{rows}
is a reference to an array of the result rows.
For a different command
$res->{rows}
is a scalar containing the number of affected rows. I think this is a
poor design. Couldn't we have a different result field that always
contains the number of rows?
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
---(end of broadcast)---
TIP 8: explain analyze is your friend
Re: [HACKERS] Release schedule plans
On Sat, 2004-11-06 at 04:38, Bruce Momjian wrote: > In talking to people working on various items, I think we should plan > for a beta next week once we have completed all the major open 8.0 > items. Only the tablespace and win32 lost signals seem major. > > And, once the beta has been tested for a week, we should start thinking > about an 8.0 release candidates. > > Peter has is thinking of freezing error message strings next week so > others can start on translations, and we should start collecting port > reports after the next beta too. > Is there a doc freeze as well as the error message string freeze? Or did we already pass that? -- Best Regards, Simon Riggs ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Documentation on PITR still scarce
On Sat, 2004-11-06 at 00:54, Joachim Wieland wrote: > Hi, > > On Fri, Nov 05, 2004 at 10:26:55PM +, Simon Riggs wrote: > > That is exactly the situation Timelines are designed to avoid. This > > should not have happened. What leads you to think it has? My guess is > > that it has not. If it has, its a bug. > > Hmm. I did the following: > > - I recovered to one PIT. > - I verified that everything was fine. > - If I shut down postmaster now and try to recover to another PIT, > everything will work fine. (by re-restoring the original backup as you > pointed out) > > However if I: > > - Shut down postmaster and restart it in normal mode (without a new >recovery.conf) and then do some database operations, it seems to >overwrite a file from my archive: > Right. You have not done a correct archive recovery and so, yes, you will get that failure. The database can't know about your activities - you do, and you know they are wrong, so you should expect error. The timeline code only comes into effect when you request an archive recovery. If you do not, it has no way of knowing it "should have". This error is possible because of two things: i) when PostgreSQL starts up, the only things it knows about are in the files in the data directory... it has no other "memory" likes humans do...if you put an incorrect set of files there for it, then it will be...incorrect ii) PostgreSQL hands-off responsibility for management of the archive to you. Using a simple copy command is not the best way to protect your important data archives - its just an example for understanding and testing. It doesn't and can't know what you have done, so cannot itself avoid *requesting* the overwrite. You are the only one that determine that the *request* to archive would cause an error. I can see that this exposes a window for user error, and we should document this. The correct way to get around this potential error is to: i) follow the instructions ii) or, for safety, write a script that checks for the existence of the file in the archive before it does the copy. so then set archive_command = "copy2myarchive " where copy2myrchive does - checks for file existence in archive, abort if file exists - does the copy Timelines are brilliant, but they don't protect you from everything. > [...recovery...] > LOG: archive recovery complete > LOG: database system is ready > LOG: archived transaction log file "0002.history" > > Now we are at timeline 2 I guess. > > [...normal startup...] > LOG: checkpoint record is at 0/22701F8 > LOG: redo record is at 0/22701F8; undo record is at 0/0; shutdown TRUE > LOG: next transaction ID: 2595; next OID: 231915 > LOG: database system is ready > [...I do some database action...] > LOG: archived transaction log file "00010001" > LOG: archived transaction log file "00020002" > > > If I stop postmaster again, wipe out my data/ dir and re-restore the > original backup, I can't do any PITRs any more... If I re-install my archive > as well, it works again. > > > > > My question is: When I've restored up to the time t_0, how can I go on > > > to restore up to another point in time, later than t_0 but before the > > > end of my log files. > > > You need to re-restore the original backup. > > Ah. Ok. I had the impression that the timelines save me from re-restoring > the original files and that I could start off directly from there. Ok, > that's why it didn't work out that well ;-) > Once you have brought up a database in timeline N+1, you can't use it as the base to recover to a point in timeline N because the data file contents cannot be trusted to be identical to the way they were in timeline N. Re-restoring the backup sounds like a thing that needs-optimization, but it is required for transactional correctness. [There is some slight area of improvement, but I don't wish to explain this because it might lure people into error by mentioning it...the code currently requires re-restoring] -- Best Regards, Simon Riggs ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] [PATCHES] CVS should die
Andrew McMillan wrote: Switching to Arch is more work, but it also offers a lot more benefits - including the opportunity for individuals to maintain their own trees, and be able to work out which patchsets from someone else's tree have not been applied. If anything is going to become the open-source BitKeeper it will be this, I think. For those interested in SVN versus arch, I found the following from Tom Lord (the guy behind Arch) http://web.mit.edu/ghudson/thoughts/diagnosing and a reply from Greg Hudson (SVN developer) http://web.mit.edu/ghudson/thoughts/undiagnosing. Regards, Thomas Hallgren ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] [PATCHES] CVS should die
On Fri, 2004-11-05 at 15:37 -0500, Tom Lane wrote: > > One of the reasons I'm disinclined to move is that none of the proposed > alternatives seem especially, um, mature. AFAIK this project has never > had CVS lose any data in the eight years we've used it. I'd want a > comparable level of trust in any replacement SCM, and I haven't got it. A very sane reason. I've lost my share of stuff with SVN in trialling it, but we are switching our company over to Arch, which seems to offer significantly more benefits. From our trialling of it, I think it has a more robust and mature repository structure too. Watching the PostgreSQL team developing I would think that Arch would provide much better support for the developers than SVN would. Switching to Arch is more work, but it also offers a lot more benefits - including the opportunity for individuals to maintain their own trees, and be able to work out which patchsets from someone else's tree have not been applied. If anything is going to become the open-source BitKeeper it will be this, I think. Cheers, Andrew. - Andrew @ Catalyst .Net .NZ Ltd, PO Box 11-053, Manners St, Wellington WEB: http://catalyst.net.nz/PHYS: Level 2, 150-154 Willis St DDI: +64(4)803-2201 MOB: +64(272)DEBIAN OFFICE: +64(4)499-2267 Planning an election? Call us! - signature.asc Description: This is a digitally signed message part
[HACKERS] "unkown" columns
Hi Hackers, I have created a table with an unknown column in it. CREATE table test AS select 'a' as columna, 'b' as columnb; will create a table with columna and columnb as an unknown type. This in itself is not strictly a problem. However there are not functions in postgresql to convert unknown to another value. There are functions if you do explicit casts, but when extracting data from a table it is not possible. So this creates a problem where you cannot cast the value of the column to anything else. Attempting to change the column type on 8.0b4 or even trying to do select columna::text from test results in the following error. SQL error: ERROR: failed to find conversion function from "unknown" to text In statement: ALTER TABLE "test" ALTER COLUMN "columna" TYPE text I would have assumed there was an implicit cast to text for items in the format 'a', but it seems not. I have spoken to Gavin Sherry on IRC and he has made functions to allow casting from unknown to text in this situation, however he has not had an opportunity to send a mail to the list about this issue. So I am doing it. Neil Conway also made some comments about unknown being as issue that has a low priority, however I think we need to either be able to cast away from unknown, or at least error when attempting to create a table with an unknown column type. I get the same error on 7.4.5 and 8.0b4 Regards Russell Smith ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
