Re: [HACKERS] pg_config
Tom Lane wrote: I doubt it. People can always just read the file to see what settings are in it, and it's not like nonexperts are going to have a variety of different configurations that we're gonna have to ask them about. (Even in the Unix world, pg_config is not really needed when most people are installing one of a small number of RPM-type packages...) The point of pg_config is not primarily to debug the installation layout for us. pg_config is used in configure scripts to find PostgreSQL libraries and header files. I don't know if Windows users have a similar need. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] localhost redux
I don't know if the problem is isolated to just me, but I wanted to suggest that we use a parameter for that, which can be configured in the postgresql.conf, with a default value if it's not set, set to localhost. I think you should first trace down what the problem really is --- is your system just misconfigured or is there some fundamental issue that we really ought to answer to? The trouble on AIX is, that getaddrinfo only does a nameservice lookup, no /etc/hosts. So if your nameservice does not have localhost ... Same for `hostname`, if nameservice does not resolve `hostname` ... Andreas ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Point in Time Recovery
Hang on, are you supposed to MOVE or COPY away WAL segments? Copy. pg will delete them once they are archived. Copy. pg will recycle them once they are archived. Andreas ---(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] PITR COPY Failure (was Point in Time Recovery)
On Tue, 2004-07-20 at 05:14, Tom Lane wrote: Mark Kirkwood [EMAIL PROTECTED] writes: I have been doing some re-testing with CVS HEAD from about 1 hour ago using the simplified example posted previously. It is quite interesting: The problem seems to be that the computation of checkPoint.redo at xlog.c lines 4162-4169 (all line numbers are per CVS tip) is not allowing for the possibility that XLogInsert will decide it doesn't want to split the checkpoint record across XLOG files, and will then insert a WASTED_SPACE record to avoid that (see comment and following code at lines 758-795). This wouldn't really matter except that there is a safety crosscheck at line 4268 that tries to detect unexpected insertions of other records during a shutdown checkpoint. I think the code in CreateCheckPoint was correct when it was written, because we only recently changed XLogInsert to not split records across files. But it's got a boundary-case bug now, which your test scenario is able to exercise by making the recovery run try to write a shutdown checkpoint exactly at the end of a WAL file segment. Thanks for locating that, I was suspicious of that piece of code, but it would have taken me longer than this to locate it exactly. It was clear (to me) that it had to be of this nature, since I've done a fair amount of recovery testing and not hit anything like that. The quick and dirty solution would be to dike out the safety check at 4268ff. I don't much care for that, but am too tired right now to work out a better answer. I'm not real sure whether it's better to adjust the computation of checkPoint.redo or to smarten the safety check ... but one or the other needs to allow for file-end padding, or maybe we could hack some update of the state in WasteXLInsertBuffer(). (But at some point you have to say this is more trouble than it's worth, so maybe we'll end up taking out the safety check.) I'll take a look In any case this isn't a fundamental bug, just an insufficiently smart safety check. But thanks for finding it! As is, the code has a nonzero probability of failure in the field :-( and I don't know how we'd have tracked it down without a reproducible test case. All code has a non-zero probability of failure in the field, its just they don't tell you that usually. The main thing here is that we write everything we need to write to the logs in the first place. If that is true, then the code can always be adjusted or the logs dumped and re-spliced to recover data. Definitely: Thanks Mark! Reproducibility is key. Best regards, Simon Riggs ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] PITR COPY Failure (was Point in Time Recovery)
Great that it's not fundamental - and hopefully with this discovery, the probability you mentioned is being squashed towards zero a bit more :-) Don't let this early bug detract from what is really a superb piece of work! regards Mark Tom Lane wrote: In any case this isn't a fundamental bug, just an insufficiently smart safety check. But thanks for finding it! As is, the code has a nonzero probability of failure in the field :-( and I don't know how we'd have tracked it down without a reproducible test case. ---(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] localhost redux
Gavin M. Roy wrote: I have no problem resolving localhost anywhere else on the box, do you have any suggestions on finding out if it's a misconfiguration? Gavin Are you the users on IRC yesterday night ? He had the same problem, however he/she had the GUC variable stats_start_collector equal to on in the configuration file but was shown as off with a SHOW stats_start_collector inside a psql section. That GUC variable is resetted to off is the collector doesn't start ? Regards Gaetano Mendola ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] pg_dump bug fixing
In article [EMAIL PROTECTED], Rod Taylor [EMAIL PROTECTED] writes: On Mon, 2004-07-19 at 12:36, Josh Berkus wrote: Rod, I think what we want is a clean template without all of the extras that template1 has. We have this, it's called Template0. Doesn't work for me. I remove a number of things that are included by default in template0, but yes, it's close. I think pg_dump should do a kind of diff between template1 and the database in question and include the necessary statements in the dump to allow pg_restore to replay the diff after it has created the database from template1. ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] pg_config
Peter Eisentraut said: Tom Lane wrote: I doubt it. People can always just read the file to see what settings are in it, and it's not like nonexperts are going to have a variety of different configurations that we're gonna have to ask them about. (Even in the Unix world, pg_config is not really needed when most people are installing one of a small number of RPM-type packages...) ISTM that if it's not useful we should rip it out and if it is then we should make it portable. The point of pg_config is not primarily to debug the installation layout for us. pg_config is used in configure scripts to find PostgreSQL libraries and header files. To that extent is it not broken by relocated installations that we have now made some provision for? I don't know if Windows users have a similar need. I don't see why not. cheers andrew ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] PITR COPY Failure (was Point in Time Recovery)
On Tue, 2004-07-20 at 05:14, Tom Lane wrote: Mark Kirkwood [EMAIL PROTECTED] writes: I have been doing some re-testing with CVS HEAD from about 1 hour ago using the simplified example posted previously. It is quite interesting: The problem seems to be that the computation of checkPoint.redo at xlog.c lines 4162-4169 (all line numbers are per CVS tip) is not allowing for the possibility that XLogInsert will decide it doesn't want to split the checkpoint record across XLOG files, and will then insert a WASTED_SPACE record to avoid that (see comment and following code at lines 758-795). This wouldn't really matter except that there is a safety crosscheck at line 4268 that tries to detect unexpected insertions of other records during a shutdown checkpoint. I think the code in CreateCheckPoint was correct when it was written, because we only recently changed XLogInsert to not split records across files. But it's got a boundary-case bug now, which your test scenario is able to exercise by making the recovery run try to write a shutdown checkpoint exactly at the end of a WAL file segment. The quick and dirty solution would be to dike out the safety check at 4268ff. Well, taking out the safety check isn't the answer. The check produces the last error message concurrent transaction..., but it isn't the cause of the mismatch in the first place. If you take out that check, we still fail because the wasted space at the end is causing a record with zero length error. I'm not real sure whether it's better to adjust the computation of checkPoint.redo or to smarten the safety check ... but one or the other needs to allow for file-end padding, or maybe we could hack some update of the state in WasteXLInsertBuffer(). (But at some point you have to say this is more trouble than it's worth, so maybe we'll end up taking out the safety check.) ...I'm looking at other options now. Best Regards, Simon Riggs ---(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] localhost redux
Zeugswetter Andreas SB SD [EMAIL PROTECTED] writes: I think you should first trace down what the problem really is --- is your system just misconfigured or is there some fundamental issue that we really ought to answer to? The trouble on AIX is, that getaddrinfo only does a nameservice lookup, no /etc/hosts. Wouldn't that break many other programs besides Postgres? But in any case if your nameserver doesn't resolve localhost, I'd say you'd better fix your nameserver. See eg, http://www.faqs.org/rfcs/rfc2606.html The .localhost TLD has traditionally been statically defined in host DNS implementations as having an A record pointing to the loop back IP address and is reserved for such use. Any other use would conflict with widely deployed code which assumes this use. regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] PITR COPY Failure (was Point in Time Recovery)
Simon Riggs [EMAIL PROTECTED] writes: The quick and dirty solution would be to dike out the safety check at 4268ff. If you take out that check, we still fail because the wasted space at the end is causing a record with zero length error. Ugh. I'm beginning to think we ought to revert the patch that added the don't-split-across-files logic to XLogInsert; that seems to have broken more assumptions than I realized. That was added here: 2004-02-11 17:55 tgl * src/: backend/access/transam/xact.c, backend/access/transam/xlog.c, backend/access/transam/xlogutils.c, backend/storage/smgr/md.c, backend/storage/smgr/smgr.c, bin/pg_controldata/pg_controldata.c, bin/pg_resetxlog/pg_resetxlog.c, include/access/xact.h, include/access/xlog.h, include/access/xlogutils.h, include/pg_config_manual.h, include/catalog/pg_control.h, include/storage/smgr.h: Commit the reasonably uncontroversial parts of J.R. Nield's PITR patch, to wit: Add a header record to each WAL segment file so that it can be reliably identified. Avoid splitting WAL records across segment files (this is not strictly necessary, but makes it simpler to incorporate the header records). Make WAL entries for file creation, deletion, and truncation (as foreseen but never implemented by Vadim). Also, add support for making XLOG_SEG_SIZE configurable at compile time, similarly to BLCKSZ. Fix a couple bugs I introduced in WAL replay during recent smgr API changes. initdb is forced due to changes in pg_control contents. There are other ways to do this, for example we could treat the WAL page headers as variable-size, and stick the file labeling info into the first page's header instead of making it be a separate record. The separate-record way makes it easier to incorporate future additions to the file labeling info, but I don't really think it's critical to allow for that. regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] PITR COPY Failure (was Point in Time Recovery)
On Tue, 2004-07-20 at 13:51, Tom Lane wrote: Simon Riggs [EMAIL PROTECTED] writes: The quick and dirty solution would be to dike out the safety check at 4268ff. If you take out that check, we still fail because the wasted space at the end is causing a record with zero length error. Ugh. I'm beginning to think we ought to revert the patch that added the don't-split-across-files logic to XLogInsert; that seems to have broken more assumptions than I realized. That was added here: 2004-02-11 17:55 tgl * src/: backend/access/transam/xact.c, backend/access/transam/xlog.c, backend/access/transam/xlogutils.c, backend/storage/smgr/md.c, backend/storage/smgr/smgr.c, bin/pg_controldata/pg_controldata.c, bin/pg_resetxlog/pg_resetxlog.c, include/access/xact.h, include/access/xlog.h, include/access/xlogutils.h, include/pg_config_manual.h, include/catalog/pg_control.h, include/storage/smgr.h: Commit the reasonably uncontroversial parts of J.R. Nield's PITR patch, to wit: Add a header record to each WAL segment file so that it can be reliably identified. Avoid splitting WAL records across segment files (this is not strictly necessary, but makes it simpler to incorporate the header records). Make WAL entries for file creation, deletion, and truncation (as foreseen but never implemented by Vadim). Also, add support for making XLOG_SEG_SIZE configurable at compile time, similarly to BLCKSZ. Fix a couple bugs I introduced in WAL replay during recent smgr API changes. initdb is forced due to changes in pg_control contents. There are other ways to do this, for example we could treat the WAL page headers as variable-size, and stick the file labeling info into the first page's header instead of making it be a separate record. The separate-record way makes it easier to incorporate future additions to the file labeling info, but I don't really think it's critical to allow for that. I think I've fixed it now...but wait 20 The problem was that a zero length XLOG_WASTED_SPACE record just fell out of ReadRecord when it shouldn't have. By giving it a helping hand it makes it through with pointers correctly set, and everything else was already thought of in the earlier patch, so xlog_redo etc happens. I'll update again in a few minutesno point us both looking at this. Best regards, Simon Riggs ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] localhost redux
Tom Lane wrote: Zeugswetter Andreas SB SD [EMAIL PROTECTED] writes: I think you should first trace down what the problem really is --- is your system just misconfigured or is there some fundamental issue that we really ought to answer to? The trouble on AIX is, that getaddrinfo only does a nameservice lookup, no /etc/hosts. Wouldn't that break many other programs besides Postgres? Maybe not many use getaddrinfo() But in any case if your nameserver doesn't resolve localhost, I'd say you'd better fix your nameserver. See eg, http://www.faqs.org/rfcs/rfc2606.html The .localhost TLD has traditionally been statically defined in host DNS implementations as having an A record pointing to the loop back IP address and is reserved for such use. Any other use would conflict with widely deployed code which assumes this use. If localhost isn't being resolved correctly are you seeing error messages like this on the server log (from pqcomm.c)? could not translate host name \%s\, service \%s\ to address: %s Of course, using -i or -h * on the postmaster would inhibit that, but you would expect it in the default setup if localhost resolution fails. cheers andrew ---(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] PITR COPY Failure (was Point in Time Recovery)
Simon Riggs [EMAIL PROTECTED] writes: On Tue, 2004-07-20 at 13:51, Tom Lane wrote: Ugh. I'm beginning to think we ought to revert the patch that added the don't-split-across-files logic to XLogInsert; that seems to have broken more assumptions than I realized. The problem was that a zero length XLOG_WASTED_SPACE record just fell out of ReadRecord when it shouldn't have. By giving it a helping hand it makes it through with pointers correctly set, and everything else was already thought of in the earlier patch, so xlog_redo etc happens. Yeah, but the WASTED_SPACE/FILE_HEADER stuff is already pretty ugly, and adding two more warts to the code to support it is sticking in my craw. I'm thinking it would be cleaner to treat the extra labeling information as an extension of the WAL page header. regards, tom lane ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] PITR COPY Failure (was Point in Time Recovery)
On Tue, 2004-07-20 at 15:00, Tom Lane wrote: Simon Riggs [EMAIL PROTECTED] writes: On Tue, 2004-07-20 at 13:51, Tom Lane wrote: Ugh. I'm beginning to think we ought to revert the patch that added the don't-split-across-files logic to XLogInsert; that seems to have broken more assumptions than I realized. The problem was that a zero length XLOG_WASTED_SPACE record just fell out of ReadRecord when it shouldn't have. By giving it a helping hand it makes it through with pointers correctly set, and everything else was already thought of in the earlier patch, so xlog_redo etc happens. Yeah, but the WASTED_SPACE/FILE_HEADER stuff is already pretty ugly, and adding two more warts to the code to support it is sticking in my craw. I'm thinking it would be cleaner to treat the extra labeling information as an extension of the WAL page header. Sounds like a better solution than scrabbling around at the end of file with too many edge cases to test properly ...over to you then... Best Regards, Simon Riggs ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] PITR COPY Failure (was Point in Time Recovery)
On Tue, 2004-07-20 at 14:11, Simon Riggs wrote: On Tue, 2004-07-20 at 13:51, Tom Lane wrote: Simon Riggs [EMAIL PROTECTED] writes: The quick and dirty solution would be to dike out the safety check at 4268ff. If you take out that check, we still fail because the wasted space at the end is causing a record with zero length error. Ugh. I'm beginning to think we ought to revert the patch that added the don't-split-across-files logic to XLogInsert; that seems to have broken more assumptions than I realized. That was added here: 2004-02-11 17:55 tgl * src/: backend/access/transam/xact.c, backend/access/transam/xlog.c, backend/access/transam/xlogutils.c, backend/storage/smgr/md.c, backend/storage/smgr/smgr.c, bin/pg_controldata/pg_controldata.c, bin/pg_resetxlog/pg_resetxlog.c, include/access/xact.h, include/access/xlog.h, include/access/xlogutils.h, include/pg_config_manual.h, include/catalog/pg_control.h, include/storage/smgr.h: Commit the reasonably uncontroversial parts of J.R. Nield's PITR patch, to wit: Add a header record to each WAL segment file so that it can be reliably identified. Avoid splitting WAL records across segment files (this is not strictly necessary, but makes it simpler to incorporate the header records). Make WAL entries for file creation, deletion, and truncation (as foreseen but never implemented by Vadim). Also, add support for making XLOG_SEG_SIZE configurable at compile time, similarly to BLCKSZ. Fix a couple bugs I introduced in WAL replay during recent smgr API changes. initdb is forced due to changes in pg_control contents. There are other ways to do this, for example we could treat the WAL page headers as variable-size, and stick the file labeling info into the first page's header instead of making it be a separate record. The separate-record way makes it easier to incorporate future additions to the file labeling info, but I don't really think it's critical to allow for that. I think I've fixed it now...but wait 20 The problem was that a zero length XLOG_WASTED_SPACE record just fell out of ReadRecord when it shouldn't have. By giving it a helping hand it makes it through with pointers correctly set, and everything else was already thought of in the earlier patch, so xlog_redo etc happens. I'll update again in a few minutesno point us both looking at this. This was a very confusing test...Here's what I think happened: Mark discovered a numerological coincidence that meant that the XLOG_WASTED_SPACE record was zero length at the end of EACH file he was writing to, as long as there was just that one writer. So no matter how many records were inserted, each xlog file had a zero length XLOG_WASTED_SPACE record at its end. ReadRecord failed on seeing a zero length record, i.e. when it got to the FIRST of the XLOG_WASTED_SPACE records. Thats why the test fails no matter how many records you give it, as long as it was more than enough to write into a second xlog segment file. By telling ReadRecord that XLOG_WASTED_SPACE records of zero length are in fact *OK*, it continues happily. (Thats just a partial fix, see later) The test works, but gives what looks like strange results: the test blows away the data directory completely, so the then-current xlog dies too. That contained the commit for the large COPY, so even though the recovery now works, the table has zero rows in it. (When things die you're still likely to lose *some* data). Anyway, so then we put the concurrent transaction test back in and the test passes because we have now set the pointers correctly. After all that, I think the wasted space idea is still sensible. You musn't have a continuation record across files, otherwise we'll end up with half a commit one-day, which would break ACID. I'm happy that we have the explicit test in XLogInsert for zero-length records. Somebody will one-day write a resource manager with zero length records when they didn't mean to and we need to catch that at write time, not at recovery time like Mark has done. The WasteXLInsertBuffer was the only part of the code that *can* write a zero-length record, so we will *not* see another recurrence of this situation --at recovery time--. Though further concerns along this theme are: - what happens when the space at the end of a file is so small we can't even write a zero-length XLOG_WASTED_SPACE record? Hopefully, you're gonna say damn your eyes...couldnt you see that, its already there. - if the space at the end of a file was just zeros, then the concurrent transaction test would still failwe probably need to enhance this to treat a few zeros at end of file AS IF it was an XLOG_WASTED_SPACE record an continue. (That scenario would happen if we were doing a recovery that included a local un-archived xlog that was very close to being full - probably
Re: [HACKERS] pg_config
Andrew Dunstan wrote: Peter Eisentraut said: Tom Lane wrote: I doubt it. People can always just read the file to see what settings are in it, and it's not like nonexperts are going to have a variety of different configurations that we're gonna have to ask them about. (Even in the Unix world, pg_config is not really needed when most people are installing one of a small number of RPM-type packages...) ISTM that if it's not useful we should rip it out and if it is then we should make it portable. Agreed. Right now we have a shell script in the Win32 binary directory that doesn't work for them. The point of pg_config is not primarily to debug the installation layout for us. pg_config is used in configure scripts to find PostgreSQL libraries and header files. To that extent is it not broken by relocated installations that we have now made some provision for? Good question. -- 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])
Re: [HACKERS] localhost redux
If localhost isn't being resolved correctly are you seeing error messages like this on the server log (from pqcomm.c)? could not translate host name \%s\, service \%s\ to address: %s After poking around, I found the following: The Windows pdc (==name server :-( ) does really not resolve localhost (this might be common for Windows nameservers). I do not have a services entry for 5432, and don't have a dns record for this RS6000. LOG: could not translate service 5432 to address: Host not found WARNING: could not create listen socket for * LOG: could not bind socket for statistics collector: Can't assign requested address Setting to a port, that is listed in /etc/services does not change anything (except the port of course). I do not have those problems on a machine where dns lists the machine and localhost. This machine has a long obsolete oslevel 4.3.2, so am not sure it is worth pursuing the issue. I only wanted to state, that it does not work here under certain cirumstances eighter. Andreas ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] localhost redux
Yeah, I was talking about it on freenode yesterday. If the stats collector doesn't start, the internal variable is set to off. Gavin Gaetano Mendola wrote: Gavin M. Roy wrote: I have no problem resolving localhost anywhere else on the box, do you have any suggestions on finding out if it's a misconfiguration? Gavin Are you the users on IRC yesterday night ? He had the same problem, however he/she had the GUC variable stats_start_collector equal to on in the configuration file but was shown as off with a SHOW stats_start_collector inside a psql section. That GUC variable is resetted to off is the collector doesn't start ? Regards Gaetano Mendola ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] localhost redux
On Tue, Jul 20, 2004 at 08:32:00AM -0400, Tom Lane wrote:
Zeugswetter Andreas SB SD [EMAIL PROTECTED] writes:
I think you should first trace down what the problem really is --- is
your system just misconfigured or is there some fundamental issue that
we really ought to answer to?
The trouble on AIX is, that getaddrinfo only does a nameservice lookup,
no /etc/hosts.
Wouldn't that break many other programs besides Postgres? But in any
case if your nameserver doesn't resolve localhost, I'd say you'd better
fix your nameserver. See eg, http://www.faqs.org/rfcs/rfc2606.html
The .localhost TLD has traditionally been statically defined in
host DNS implementations as having an A record pointing to the
loop back IP address and is reserved for such use. Any other use
would conflict with widely deployed code which assumes this use.
There is no requirement for a recursive resolver (local nameserver) to
have localhost hardwired to return 127.0.0.1. It's not even clearly a
good idea in all cases. If, though, the resolver returns anything for
localhost it must be 127.0.0.1 (or, presumably, ::127.0.0.1).
While many recursive resolvers do have localhost hardwired (to avoid
this sort of issue) relying on it may be overly brave.
It would be nice if the OP could check their recursive resolver to see
what it is returning for a query for localhost ('dig @nameserver localhost',
where nameserver is the nameserver listed in /etc/resolv.conf), just to
check whether the DNS vs non-DNS localhost thing is an issue at all. Also
whether they have /etc/netsvc.conf (IIRC) configured to use /etc/hosts
or not.
getaddrinfo() has had strange and unusual bugs on some older versions of
AIX, anyway, so it may not be a DNS issue at all.
Cheers,
Steve
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] pg_config
Andrew Dunstan wrote: To that extent is it not broken by relocated installations that we have now made some provision for? Well, then it should be fixed to take relocated installations into account. Relocatable installations are by nature a pretty broken feature. When you use pg_config to locate, say, libpq, then compile your third-party package, and then move libpq somewhere else, nothing can save you (except moving libpq back). At least on Unix, relocatable installations are a walking cane when you need parallel installations for upgrades, but they'll never work reliably in general. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(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] pg_dump bug fixing
KL, CREATE DATABASE phppgadmin WITH TEMPLATE = template0 OWNER = chriskl ENCODING = 'LATIN1'; CREATE DATABASE usa WITH TEMPLATE = template0 OWNER = usadmin ENCODING = 'LATIN1'; Ok, so that would come under the heading of already fixed. Great. -- Josh Berkus Aglio Database Solutions San Francisco ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Why we really need timelines *now* in PITR
Tom Lane [EMAIL PROTECTED] writes: Anybody see any holes in this design? God help the DBA who deletes a history file with needed information. Or edits it inappropriately. Why can't every log file contain a header that says which timeline it's part of and which timeline the preceding log file was part of? That would avoid having a file outside PGDATA and would mean the backups would always contain enough information to be self-sufficient. Then if you want to restore from a cold backup and apply PITR up to segment 0020 in timeline X. You read the header of X.0020, find out it followed X.0019 and so on. If X.0010 branched from Y.0009 you'll find out and be able to continue threading back until you find a segment that matches the current segment in the cold backup. The only problem I see is that if your backups are stored on tape it might be awkward to have to read the headers of all log segments in reverse order to backtrack to the right place to start. -- greg ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Why we really need timelines *now* in PITR
On Tue, 2004-07-20 at 00:58, Tom Lane wrote: Simon Riggs [EMAIL PROTECTED] writes: where the default is notarget and if you specify a target, the default target_in_timeline is latest. I think actually the default target has to be the timeline ID found in pg_control -- otherwise you get weird behavior in the plain crash recovery, non-PITR case. Yes, I was talking about recovery.conf only So, overall there would be 5 recovery modes with 4 levels of default: Summarised in the table, also showing what set of actions/parameters we need to specify to invoke that mode... SPECIFIED ITEMs MODErecovery.conf rec_target* target_in_timeline crash recovery - up to 7.4-no--no--no archive recovery - current end---yes-no--no - current target (*)yes-yes-no current timeline - other target (*)--yes-either--yes, = 'latest' latest timeline - other target (*)--yes-either--yes, = 'value' other timeline (*) these operations cause a new timeline to be created More verbosely (not numbered because they're not a sequence or progression) - if no recovery.conf is present we do crash recovery to end of logs on pg_control timeline (i.e. current) - if recovery.conf is present and we do not specify a target we do archive recovery to end of logs on pg_control timeline (i.e. current) - if recovery.conf is present and we specify a target, but no timeline, then we do archive recovery on the pg_control timeline only, and assume that the target was supposed to be on this, even if we don't find it - if recovery.conf is present and we specify a timeline of literally 'latest' (without having to know what that is) - then we search archive for the latest history file, then we do archive recovery from the pg_control timeline to the latest timeline as specified in the latest history file. If we specify a target, then this is searched for on whatever timeline we're on as we rollforward. - if recovery.conf is present and we specify a timeline - then we search archive for that history file, then we do archive recovery from the pg_control timeline to the specified timeline as shown in that history file. If we specify a target, then this is searched for on whatever timeline we're on as we rollforward. I don't like the name target_in_timeline, Agreed, but I don't have a better name offhand for it. The point I was making is that we seem to be using target to mean a point-in-time stopping target. But you might be interested in going to the end of timeline N and so there's not a target in that sense. That's why I was wanting to avoid using the term target for the desired timeline. But maybe there's not a better word. how about? end_at_timeline which is more neutral towards the idea of whether a target has been specified or not... Another thing I note is that archive_status .ready messages are written for all restored xlog files (rather than .done messages). That seems to cause the archive to be completely overwritten when recovery is complete. Is that part of the plan for timelines also. Not sure I understand that... Best Regards, Simon Riggs ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Cannot initdb in cvs tip
Seems it might be time to address this and get it fixed. Win32 doesn't clean up the directory structure under /data and leave /data unchanged, and there is no way to do this with a system() command on Win32. I resisted adding a C version of rmtree during Win32 development because I was concerned about disturbing the Unix behavior, but at this point I think we should just move ahead and add a /port function for this and remove the system() backend and initdb calls to 'rm' for directories. --- Andrew Dunstan wrote: John Hansen said: On Sun, 2004-06-20 at 08:04, Dave Page wrote: although it says it's clearing the contents of the directory, in actual fact it leaves the directory structure in place, thus a subsequent initdb will not run without a manual clearup. Hm. The rmtree() function in initdb.c is responsible for this, and I see it has WIN32-specific behavior, which is evidently wrong. Can you recommend a fix? The current solution does an rmdir /q /s $PGDATA if the datadir was created, and del /q /s $PGDATA if the directory already existed. The second case will not work, as del will not remove directories. AFAICS, there is no easy way to do this using system() as rmdir won't accept wildcards, so we can't do del $PGDATA/* rmdir $PGDATA/*. It seems to me that the simple answer is to put Andrew's recursive unlink code back in (as he suggested), which Bruce removed as rm etc. were being used in commands/dbcommands.c (which should work fine under Windows). Patch below you could of course rmdir /s /q $PGDATA mkdir $PGDATA if the purpose is to leave the directory intact if it already existed prior to install. No we can't. This was discussed months ago, IIRC. The user might very well not have the privileges necessary to delete the directory, and might not have the privileges to recreate it if they do. The direct recursive delete is not a lot of code, and I must confess I *hate* having C programs calling system() for such tasks. One of my goals in rewriting initdb in C was to avoid any calls at all to any external program other than postgres itself. cheers andrew ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go 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])
[HACKERS] check point segments leakage ?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi all, today I add 4 new columns to a table with 4E+06 rows, I also update to an initial value these new columns. The new columns are 3 INTEGER one of type DOUBLE. The table have also 5 indexes. Immediately after the operation my partition data had an usage increment of 1.2GB. I did a reindex and a vacuum full on that table and 600MB were freed. Now I have an increment of only 600 MB. I use a checkpoint_segments = 16 but in my pg_xlog I have 35 files. Why 35 files ? Where are lost my 600MB ? Also the load increased from 1 to 5 !! Any ideas ? I'm attaching boot graphs ( HD space usage and load ). Regards Gaetano Mendola -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFA/Ydh7UpzwH2SGd4RAuhKAKCTftBGjBLSfR+OTy5vHlYpL46TXQCfc65/ VfepMM87dQKvg3rswhGUNL8= =HWHy -END PGP SIGNATURE- inline: load.pnginline: space_usage.png ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] How to display privileges in psql
Added to TODO: * Allow psql to display permission information using \df+ and \l+ --- Christopher Kings-Lynne wrote: Maybe other people want to comment on this issue. So far, \z and \dp have shown privileges of tables. Now \dn+ and \db+ show the privileges of schemas and tablespaces. Should we, for consistency, move the table privilege display to \dt+, or should we move the schema and tablespace display to, say \zn and \zb? Or maybe this is not an issue at all. I don't know :( psql is starting to struggle to show all information! And what about \df+ and \l+ ? They both need privilege display as well. Chris ---(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 8: explain analyze is your friend
Re: [HACKERS] Point in Time Recovery
Simon Riggs wrote: On Sat, 2004-07-17 at 00:57, Bruce Momjian wrote: OK, I think I have some solid ideas and reasons for them. Sorry for taking so long to reply... First, I think we need server-side functions to call when we start/stop the backup. The advantage of these server-side functions is that they will do the required work of recording the pg_control values and creating needed files with little chance for user error. It also allows us to change the internal operations in later releases without requiring admins to change their procedures. We are even able to adjust the internal operation in minor releases without forcing a new procedure on users. Yes, I think we should go down this route. there's a but and that is we don't absolutely need it for correctnessand so I must decline adding it to THIS release. I don't imagine I'll stop be associated with this code for a while yet Can we recommend that users should expect to have to call a start and end backup routine in later releases? Don't expect you'll agree to that.. I guess my big question is that if we don't do this for 7.5 how will people doing restores know if the xid they specify is valid for the backup they used. If we recover to most recent time, is there any check that will tell them their backup is invalid because there are no archive records that span the time of their backup? -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] How to display privileges in psql
Bruce Momjian wrote: Added to TODO: * Allow psql to display permission information using \df+ and \l+ What about, develop a consistent way to display privilege information for all objects in psql? -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] How to display privileges in psql
On Tue, Jul 20, 2004 at 11:41:14PM +0200, Peter Eisentraut wrote: Bruce Momjian wrote: Added to TODO: * Allow psql to display permission information using \df+ and \l+ What about, develop a consistent way to display privilege information for all objects in psql? Excellent idea. :) Is this worth breaking backward compatibility for? IMHO, yes, but others may have good reasons--critical-path psql scripts, e.g.--for not doing it. BTW, while I working out an example for CREATE DOMAIN (http://fetter.org/sgml/sql-createdomain.html), I found that \dD and \dD+ appear to do the exact same thing. I was hoping that \dD+ would show all CONSTRAINTs. Cheers, D -- David Fetter [EMAIL PROTECTED] http://fetter.org/ phone: +1 510 893 6100 mobile: +1 415 235 3778 Remember to vote! ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
[HACKERS] V3 protocol + DECLARE problems
(cc: -hackers as I think this has been raised there before)
It's going to be fun using anything more than very basic cursors via the
V3 protocol in the JDBC driver. DECLARE does not work with parameters
passed via a Parse/Bind combination -- which is how we currently always
pass parameters when talking V3. I'm reluctant to have two
implementations of the parameter logic for V3 (one that does direct
substitution, one that uses Bind) since that's extra unnecessary code
and a recipe for inconsistent behaviour.
Logs follow; basically this is issuing a Parse/Bind/Execute for a
parameterized DECLARE, which blows up with no value found for parameter
1 despite there definitely being one there. (also, that error appears
on Execute, not Parse/Bind).
Any chance of getting this fixed for 7.5? Alternatively, if we can get
WITH HOLD / SCROLL behaviour in portals created by Execute (probably
means a protocol change) that works too. I don't have a runnable 7.5 on
hand to test against so it's possible this has already been fixed.
-O
Trying to establish a protocol version 3 connection to localhost:5432
FE= StartupPacket(user=oliver, database=test, client_encoding=UNICODE, DateStyle=ISO)
=BE AuthenticationOk
=BE ParameterStatus(client_encoding = UNICODE)
=BE ParameterStatus(DateStyle = ISO, DMY)
=BE ParameterStatus(is_superuser = off)
=BE ParameterStatus(server_version = 7.4.1)
=BE ParameterStatus(session_authorization = oliver)
=BE BackendKeyData(pid=676,ckey=704988999)
=BE ReadyForQuery(I)
compatible = 7.5
loglevel = 0
prepare threshold = 0
getConnection returning driver[className=org.postgresql.Driver,[EMAIL PROTECTED]
simple execute, [EMAIL PROTECTED], maxRows=0, fetchSize=0, flags=21
FE= Parse(stmt=null,query=DECLARE c CURSOR WITH HOLD FOR SELECT typname,oid from pg_type WHERE typname LIKE $1,oids={25})
FE= Bind(stmt=null,portal=null,$1=%)
FE= Describe(portal=null)
FE= Execute(portal=null,limit=1)
FE= Sync
=BE ParseComplete [null]
=BE BindComplete [null]
=BE NoData
=BE CommandStatus(DECLARE CURSOR)
=BE ErrorMessage(ERROR: no value found for parameter 1
Location: File: execQual.c, Routine: ExecEvalParam, Line: 518
ServerSQLState: 42704)
java.sql.SQLException: ERROR: no value found for parameter 1
Location: File: execQual.c, Routine: ExecEvalParam, Line: 518
ServerSQLState: 42704
at org.postgresql.core.v3.QueryExecutorImpl.receiveErrorResponse(QueryExecutorImpl.java:1130)
at org.postgresql.core.v3.QueryExecutorImpl.processResults(QueryExecutorImpl.java:933)
at org.postgresql.core.v3.QueryExecutorImpl.execute(QueryExecutorImpl.java:139)
at org.postgresql.jdbc2.AbstractJdbc2Statement.execute(AbstractJdbc2Statement.java:343)
at org.postgresql.jdbc2.AbstractJdbc2Statement.executeWithFlags(AbstractJdbc2Statement.java:291)
at org.postgresql.jdbc2.AbstractJdbc2Statement.executeUpdate(AbstractJdbc2Statement.java:246)
at TestDeclare.main(TestDeclare.java:11)
SQLException: SQLState(42704)
=BE NoticeResponse(WARNING: AbortTransaction and not in in-progress state
Location: File: xact.c, Routine: AbortTransaction, Line: 1034
ServerSQLState: 01000)
SQLWarning:
=BE ReadyForQuery(I)
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] How to display privileges in psql
Peter Eisentraut wrote: Bruce Momjian wrote: Added to TODO: * Allow psql to display permission information using \df+ and \l+ What about, develop a consistent way to display privilege information for all objects in psql? OK, item wording updated. -- 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 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] check point segments leakage ?
Hello, Perhaps you have an open transaction that isn't closing and thus the pg_xlog continues to grow? Sincerely, Joshua D. Drake Gaetano Mendola wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi all, today I add 4 new columns to a table with 4E+06 rows, I also update to an initial value these new columns. The new columns are 3 INTEGER one of type DOUBLE. The table have also 5 indexes. Immediately after the operation my partition data had an usage increment of 1.2GB. I did a reindex and a vacuum full on that table and 600MB were freed. Now I have an increment of only 600 MB. I use a checkpoint_segments = 16 but in my pg_xlog I have 35 files. Why 35 files ? Where are lost my 600MB ? Also the load increased from 1 to 5 !! Any ideas ? I'm attaching boot graphs ( HD space usage and load ). Regards Gaetano Mendola -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFA/Ydh7UpzwH2SGd4RAuhKAKCTftBGjBLSfR+OTy5vHlYpL46TXQCfc65/ VfepMM87dQKvg3rswhGUNL8= =HWHy -END PGP SIGNATURE- ---(end of broadcast)--- TIP 8: explain analyze is your friend -- Command Prompt, Inc., home of Mammoth PostgreSQL - S/ODBC and S/JDBC Postgresql support, programming shared hosting and dedicated hosting. +1-503-667-4564 - [EMAIL PROTECTED] - http://www.commandprompt.com Mammoth PostgreSQL Replicator. Integrated Replication for PostgreSQL begin:vcard fn:Joshua D. Drake n:Drake;Joshua D. org:Command Prompt, Inc. adr:;;PO Box 215;Cascade Locks;Oregon;97014;USA email;internet:[EMAIL PROTECTED] title:Consultant tel;work:503-667-4564 tel;fax:503-210-0034 note:Command Prompt, Inc. is the largest and oldest US based commercial PostgreSQL support provider. We provide the only commercially viable integrated PostgreSQL replication solution, but also custom programming, and support. We authored the book Practical PostgreSQL, the procedural language plPHP, and adding trigger capability to plPerl. x-mozilla-html:FALSE url:http://www.commandprompt.com/ version:2.1 end:vcard ---(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] unused variable
OK, it turns out myXID is only used by Assert tests, and most developers
compile with Asserts. I have fixed this by defining the variable only
when asserts are enabled.
Patch attached and applied.
---
Gaetano Mendola wrote:
[ PGP not available, raw data follows ]
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi all,
I'm compiling the last postgres CVS version and I get:
vacuum.c: In function `repair_frag':
vacuum.c:1528: warning: unused variable `myXID'
Regards
Gaetano Mendola
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.4 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFA+bCj7UpzwH2SGd4RAtyKAJsH6V22SijBN3VD/HJ/sWoLO8Ta7wCcD1wt
U2VsEehBuK64q4/kjsHA4g4=
=TsL8
-END PGP SIGNATURE-
---(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
[ End of raw data]
--
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
Index: src/backend/commands/vacuum.c
===
RCS file: /cvsroot/pgsql-server/src/backend/commands/vacuum.c,v
retrieving revision 1.282
diff -c -c -r1.282 vacuum.c
*** src/backend/commands/vacuum.c 1 Jul 2004 00:50:11 - 1.282
--- src/backend/commands/vacuum.c 20 Jul 2004 22:43:52 -
***
*** 1525,1531
--- 1525,1533
VacPageList vacuum_pages, VacPageList fraged_pages,
int nindexes, Relation *Irel)
{
+ #ifdefUSE_ASSERT_CHECKING
TransactionId myXID = GetCurrentTransactionId();
+ #endif
Buffer dst_buffer = InvalidBuffer;
BlockNumber nblocks,
blkno;
---(end of broadcast)---
TIP 8: explain analyze is your friend
Re: [HACKERS] check point segments leakage ?
Bruce said the other day open transactions can't cause this problem. I wonder what all can? On Tue, 2004-07-20 at 16:32, Joshua D. Drake wrote: Hello, Perhaps you have an open transaction that isn't closing and thus the pg_xlog continues to grow? Sincerely, Joshua D. Drake Gaetano Mendola wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi all, today I add 4 new columns to a table with 4E+06 rows, I also update to an initial value these new columns. The new columns are 3 INTEGER one of type DOUBLE. The table have also 5 indexes. Immediately after the operation my partition data had an usage increment of 1.2GB. I did a reindex and a vacuum full on that table and 600MB were freed. Now I have an increment of only 600 MB. I use a checkpoint_segments = 16 but in my pg_xlog I have 35 files. Why 35 files ? Where are lost my 600MB ? Also the load increased from 1 to 5 !! Any ideas ? I'm attaching boot graphs ( HD space usage and load ). Regards Gaetano Mendola -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFA/Ydh7UpzwH2SGd4RAuhKAKCTftBGjBLSfR+OTy5vHlYpL46TXQCfc65/ VfepMM87dQKvg3rswhGUNL8= =HWHy -END PGP SIGNATURE- ---(end of broadcast)--- TIP 8: explain analyze is your friend ---(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] check point segments leakage ?
Joshua D. Drake wrote: Hello, Perhaps you have an open transaction that isn't closing and thus the pg_xlog continues to grow? Sincerely, Joshua D. Drake I was thinking about it but unfortunately there is no transaction open. On my development database, were I simulate the same operation that I did in production I have the same situation: 34 files and same configuration, right now there are 5 connection and no one of them have a transaction opened: template1=# select * from pg_locks ; relation | database | transaction | pid | mode | granted --+--+-+---+-+- 16759 |1 | | 15910 | AccessShareLock | t | | 7714652 | 15910 | ExclusiveLock | t Regards Gaetano Mendola ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] check point segments leakage ?
Scott Marlowe wrote: I use a checkpoint_segments = 16 but in my pg_xlog I have 35 files. Why 35 files ? You have 35 because the max files in pg_xlog is 2*checkpoint_segments +1 or something like that. This is documented in the SGML. -- 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 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] check point segments leakage ?
Gaetano Mendola wrote: Bruce Momjian wrote: Scott Marlowe wrote: I use a checkpoint_segments = 16 but in my pg_xlog I have 35 files. Why 35 files ? You have 35 because the max files in pg_xlog is 2*checkpoint_segments +1 or something like that. This is documented in the SGML. Ok, that explain why. And they will remain there also if not needed ? Yes, it keeps them around so it doesn't need to recreate them. Another weird behaviour is that during the day the storage space usage increase gruadualy. Since today as the graph show the space usage is constant, it's like if some space was pre-allocated and now is used, see same yesterday period between 18:00 and 24:00. Toughts ? My guess is that you need a certain amount of free space in the tables to operate properly. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] PITR COPY Failure (was Point in Time Recovery)
FYI - I can confirm that the patch fixes main issue. Simon Riggs wrote: This was a very confusing test...Here's what I think happened: . The included patch doesn't attempt to address those issues, yet. Best regards, Simon Riggs ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] PITR COPY Failure (was Point in Time Recovery)
This is presumably a standard feature of any PITR design - if the failure event destroys the current transaction log, then you can only recover transactions that committed in the last *archived* log. regards Mark Simon Riggs wrote: The test works, but gives what looks like strange results: the test blows away the data directory completely, so the then-current xlog dies too. That contained the commit for the large COPY, so even though the recovery now works, the table has zero rows in it. (When things die you're still likely to lose *some* data). ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
[HACKERS] no instruction after install
Hi all, why after compiling and install postgresql CVS tip there is no information on how to run it ? Also the file INSTALL is not there anymore. Do I miss something in these days ? Regards Gaetano Mendola ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
[HACKERS] NT and aborted transaction
Hi all, still experimenting NT: kalman=# begin; BEGIN kalman=# select * from a; ERROR: relation a does not exist kalman=# begin; BEGIN kalman=# select * from test; ERROR: current transaction is aborted, commands ignored until end of transaction block I think the second begin shall fail instead of open an already invalid transaction. Regards Gaetano Mendola ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
[HACKERS] NT + deadlock intended behaviour ?
Hi all, I'm doing some experiments with NT, I din't expect this behaviuor: create table test ( a integer ); insert into test values (3); insert into test values (4); insert into test values (5); insert into test values (6); SESSION 1;SESSION 2; begin;begin; update test set a = 300 where a = 3; update test set a = 40 where a = 4; begin; update test set a = 400 where a = 4; BLOCKED update test set a = 30 where a = 3; DEAD LOCK DETECTED commit; UNBLOCKED-- !?!?! here I'm able to do another commit why SESSION 1 was unblocked ? If I repeat again but I do an abort: SESSION 1;SESSION 2; begin;begin; update test set a = 300 where a = 3; update test set a = 40 where a = 4; begin; update test set a = 400 where a = 4; BLOCKED update test set a = 30 where a = 3; DEAD LOCK DETECTED abort; STILL BLOCKED Why that commit unblock the SESSION 1? Regards Gaetano Mendola ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
[HACKERS] unused variable
Hi all, I'm compiling the last postgres CVS version and I get: vacuum.c: In function `repair_frag': vacuum.c:1528: warning: unused variable `myXID' Regards Gaetano Mendola ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
