Re: [HACKERS] sparse (static analyzer) report
Mark Wong wrote:
Ah, so you beat me to it Neil. ;) Out of curiosity, how much worse
was it before you started fixing things?
As I recall, not too different than things are today -- sparse flagged a
bunch of stylistic issues that I fixed, like:
void some_func() { ... } = void some_func(void) { ... }
extern void some_func(void) { ... } = void some_func(void) { ... }
etc. But given that there are 3000 odd warnings (mostly bogus), I doubt
I made a significant dent on the total warning count.
Also, I don't recall sparse picking up any significant errors or
problems. As I said, I've been meaning to explore if that's all that
sparse can do -- I just looked at the lowest of the low-hanging fruit.
-Neil
---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] OS/2 port regression tests
Hi, Never mind about the permission denied errors I tracked it down to a bug in the LIBC port's handling of doing an unlink... So it would appear the port mostly works barring the problems with the LIBC implementation. Lorne -- --- [EMAIL PROTECTED] --- ---(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] Much Ado About COUNT(*)
On Thu, 13 Jan 2005 00:39:56 -0500, Tom Lane [EMAIL PROTECTED] wrote: A would-be deleter of a tuple would have to go and clear the known good bits on all the tuple's index entries before it could commit. This would bring the tuple back into the uncertain status condition where backends would have to visit the heap to find out what's up. Eventually the state would become certain again (either dead to everyone or live to everyone) and one or the other hint bit could be set again. Last time we discussed this, didn't we come to the conclusion, that resetting status bits is not a good idea because of possible race conditions? In a previous post you wrote: | I think we still have one free bit in index tuple headers... AFAICS we'd need two new bits: visible to all and maybe dead. Writing the three status bits in the order visible to all, maybe dead, known dead, a normal index tuple lifecycle would be 000 - 100 - 110 - 111 In states 000 and 110 the heap tuple has to be read to determine visibility. The transitions 000 - 100 and 110 - 111 happen as side effects of index scans. 100 - 110 has to be done by the deleting transaction. This is the operation where the additional run time cost lies. One weakness of this approach is that once the index tuple state is 110 but the deleting transaction is aborted there is no easy way to reset the maybe deleted bit. So we'd have to consult the heap for the rest of the tuple's lifetime. Servus Manfred ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] WAL logging of heap_mark4update
On Sat, 15 Jan 2005, Tom Lane wrote: Alvaro Herrera [EMAIL PROTECTED] writes: Hackers, In access/heap/heapam.c, in heap_mark4update(), there's a comment that states /* * XLOG stuff: no logging is required as long as we have no * savepoints. For savepoints private log could be used... */ Is this still true in light of 8.0's savepoints? It isn't. Since mark4update is simply establishing a lock, which isn't going to be held across a system crash anyway, I see no need to WAL-log it. (But hmmm ... to support 2PC we'd probably need to do so ...) Yes, for 2PC you need to keep all locks over system crash. In any case I'm contemplating changing exclusive row locks to use LockAcquire, and supporting shared row locks using the same mechanism. All this per previous discussion on -hackers. We could get rid of heap_mark4update if that's done, right? Right. The 2PC connection is another reason to do it that way --- 2PC would require some way to save locks anyhow, and it'd be nice if there were only one mechanism to deal with not two. AFAICS, heap_mark4update calls XactLockTableWait for the updating transaction, and XactLockTableWait uses LockAcquire to do the waiting. I must be missing something. Can someone briefly explain me what's special about this locking mechanism, please? How are you planning to change it? - Heikki ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] WAL logging of heap_mark4update
Heikki Linnakangas [EMAIL PROTECTED] writes: On Sat, 15 Jan 2005, Tom Lane wrote: Right. The 2PC connection is another reason to do it that way --- 2PC would require some way to save locks anyhow, and it'd be nice if there were only one mechanism to deal with not two. AFAICS, heap_mark4update calls XactLockTableWait for the updating transaction, and XactLockTableWait uses LockAcquire to do the waiting. Right, but the marking on the row is essential as well. If we lost that marker in a crash-and-restart after precommitting the transaction that has locked the row, then another transaction could come along and think that it can take ownership of the row, when in reality the precommitted transaction should still be considered to have a lock on the row. So it's not enough to remember only the XactLockTableWait lock. (BTW, I think that XactLockTableWait is *only* used for heap_mark4update, so we could get rid of that too, thereby saving one lock acquisition per transaction ...) regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Much Ado About COUNT(*)
Manfred Koizar [EMAIL PROTECTED] writes: On Thu, 13 Jan 2005 00:39:56 -0500, Tom Lane [EMAIL PROTECTED] wrote: A would-be deleter of a tuple would have to go and clear the known good bits on all the tuple's index entries before it could commit. This would bring the tuple back into the uncertain status condition where backends would have to visit the heap to find out what's up. Eventually the state would become certain again (either dead to everyone or live to everyone) and one or the other hint bit could be set again. Last time we discussed this, didn't we come to the conclusion, that resetting status bits is not a good idea because of possible race conditions? There's no race condition, since resetting the hint only forces other transactions to go back to the original data (the tuple header) to decide what to do. AFAICS the above is safe; I'm just pretty dubious about the cost. AFAICS we'd need two new bits: visible to all and maybe dead. No, you've got this wrong. The three possible states are known visible to all, known dead to all, and uncertain. If you see uncertain this means you have to go to the heap and compare the XIDs in the tuple header to your snapshot to decide if you can see the row or not. The index states are not the same as the known committed good or known committed dead hint bits in the tuple header --- those can be set as soon as the inserting/deleting transaction's outcome is known, but we can't move the index entry into the visible to all or dead to all states until that outcome is beyond the GlobalXmin event horizon. regards, tom lane ---(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] Much Ado About COUNT(*)
Tom Lane [EMAIL PROTECTED] writes: Manfred Koizar [EMAIL PROTECTED] writes: Last time we discussed this, didn't we come to the conclusion, that resetting status bits is not a good idea because of possible race conditions? There's no race condition, Actually, wait a minute --- you have a point. Consider a tuple whose inserting transaction (A) has just dropped below GlobalXmin. Transaction B is doing an index scan, so it's going to do something like * Visit index entry, observe that it is in uncertain state. * Visit heap tuple, observe that A has committed and is GlobalXmin, and there is no deleter. * Return to index entry and mark it visible to all. Now suppose transaction C decides to delete the tuple. It will * Insert itself as the XMAX of the heap tuple. * Visit index entry, set state to uncertain if not already that way. C could do this between steps 2 and 3 of B, in which case the index entry ends up improperly marked visible to all while in fact a deletion is pending. Ugh. We'd need some kind of interlock to prevent this from happening, and it's not clear what. Might be tricky to create such an interlock without introducing either deadlock or a big performance penalty. regards, tom lane ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] Much Ado About COUNT(*)
On Sun, 16 Jan 2005 20:49:45 +0100, Manfred Koizar wrote: On Thu, 13 Jan 2005 00:39:56 -0500, Tom Lane wrote: A would-be deleter of a tuple would have to go and clear the known good bits on all the tuple's index entries before it could commit. This would bring the tuple back into the uncertain status condition where backends would have to visit the heap to find out what's up. Eventually the state would become certain again (either dead to everyone or live to everyone) and one or the other hint bit could be set again. Last time we discussed this, didn't we come to the conclusion, that resetting status bits is not a good idea because of possible race conditions? http://archives.postgresql.org/pgsql-performance/2004-05/msg4.php In a previous post you wrote: | I think we still have one free bit in index tuple headers... AFAICS we'd need two new bits: visible to all and maybe dead. Writing the three status bits in the order visible to all, maybe dead, known dead, a normal index tuple lifecycle would be 000 - 100 - 110 - 111 In states 000 and 110 the heap tuple has to be read to determine visibility. The transitions 000 - 100 and 110 - 111 happen as side effects of index scans. 100 - 110 has to be done by the deleting transaction. This is the operation where the additional run time cost lies. One weakness of this approach is that once the index tuple state is 110 but the deleting transaction is aborted there is no easy way to reset the maybe deleted bit. So we'd have to consult the heap for the rest of the tuple's lifetime. How bad is that really with a typical workload? Jochem ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] Much Ado About COUNT(*)
On Sun, Jan 16, 2005 at 03:22:11PM -0500, Tom Lane wrote: Tom Lane [EMAIL PROTECTED] writes: Manfred Koizar [EMAIL PROTECTED] writes: Last time we discussed this, didn't we come to the conclusion, that resetting status bits is not a good idea because of possible race conditions? There's no race condition, Actually, wait a minute --- you have a point. Consider a tuple whose inserting transaction (A) has just dropped below GlobalXmin. Transaction B is doing an index scan, so it's going to do something like * Visit index entry, observe that it is in uncertain state. * Visit heap tuple, observe that A has committed and is GlobalXmin, and there is no deleter. * Return to index entry and mark it visible to all. Now suppose transaction C decides to delete the tuple. It will * Insert itself as the XMAX of the heap tuple. * Visit index entry, set state to uncertain if not already that way. C could do this between steps 2 and 3 of B, in which case the index entry ends up improperly marked visible to all while in fact a deletion is pending. Ugh. We'd need some kind of interlock to prevent this from happening, and it's not clear what. Might be tricky to create such an interlock without introducing either deadlock or a big performance penalty. Wouldn't the original proposal that had a state machine handle this? IIRC the original idea was: new tuple - known good - possibly dead - known dead In this case, you would have to visit the heap page when an entry is in the 'new tuple' or 'possibly dead' states. When it comes to transitions, you would enforce the transitions as shown, which would eliminate the race condition you thought of. Err, I guess maybe you have to allow going from possibly dead back to known good? But I think that would be the only 'backwards' transition. In the event of a rollback on an insert I think you'd want to go directly from new tuple to known dead, as well. -- Jim C. Nasby, Database Consultant [EMAIL PROTECTED] Give your computer some brain candy! www.distributed.net Team #1828 Windows: Where do you want to go today? Linux: Where do you want to go tomorrow? FreeBSD: Are you guys coming, or what? ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Much Ado About COUNT(*)
Jim C. Nasby [EMAIL PROTECTED] writes: Wouldn't the original proposal that had a state machine handle this? IIRC the original idea was: new tuple - known good - possibly dead - known dead Only if you disallow the transition from possibly dead back to known good, which strikes me as a rather large disadvantage. Failed UPDATEs aren't so uncommon that it's okay to have one permanently disable the optimization. regards, tom lane ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] Much Ado About COUNT(*)
On Sun, 16 Jan 2005 20:01:36 -0500, Tom Lane wrote: Jim C. Nasby writes: Wouldn't the original proposal that had a state machine handle this? IIRC the original idea was: new tuple - known good - possibly dead - known dead Only if you disallow the transition from possibly dead back to known good, which strikes me as a rather large disadvantage. Failed UPDATEs aren't so uncommon that it's okay to have one permanently disable the optimization. But how about allowing the transition from possibly dead to new tuple? What if a failed update restores the tuple to the new tuple state, and only after that it can be promoted to known good state? Jochem ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] Much Ado About COUNT(*)
On Sun, Jan 16, 2005 at 08:01:36PM -0500, Tom Lane wrote: Jim C. Nasby [EMAIL PROTECTED] writes: Wouldn't the original proposal that had a state machine handle this? IIRC the original idea was: new tuple - known good - possibly dead - known dead Only if you disallow the transition from possibly dead back to known good, which strikes me as a rather large disadvantage. Failed UPDATEs aren't so uncommon that it's okay to have one permanently disable the optimization. Actually, I guess I wasn't understanding the problem to begin with. You'd never go from new tuple to known good while the transaction that created the tuple was in-flight, right? If that's the case, I'm not sure where there's a race condition. You can't delete a tuple that hasn't been committed, right? -- Jim C. Nasby, Database Consultant [EMAIL PROTECTED] Give your computer some brain candy! www.distributed.net Team #1828 Windows: Where do you want to go today? Linux: Where do you want to go tomorrow? FreeBSD: Are you guys coming, or what? ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Much Ado About COUNT(*)
On Sun, Jan 16, 2005 at 07:28:07PM -0600, Jim C. Nasby wrote: On Sun, Jan 16, 2005 at 08:01:36PM -0500, Tom Lane wrote: Jim C. Nasby [EMAIL PROTECTED] writes: Wouldn't the original proposal that had a state machine handle this? IIRC the original idea was: new tuple - known good - possibly dead - known dead Only if you disallow the transition from possibly dead back to known good, which strikes me as a rather large disadvantage. Failed UPDATEs aren't so uncommon that it's okay to have one permanently disable the optimization. Actually, I guess I wasn't understanding the problem to begin with. You'd never go from new tuple to known good while the transaction that created the tuple was in-flight, right? If that's the case, I'm not sure where there's a race condition. You can't delete a tuple that hasn't been committed, right? Er, nevermind, I thought about it and realized the issue. What changes when a delete is done on a tuple? It seems that's the key... if a tuple has been marked as possibly being expired/deleted, don't allow it to go into known_good unless you can verify that the transaction that marked it as potentially deleted was rolled back. -- Jim C. Nasby, Database Consultant [EMAIL PROTECTED] Give your computer some brain candy! www.distributed.net Team #1828 Windows: Where do you want to go today? Linux: Where do you want to go tomorrow? FreeBSD: Are you guys coming, or what? ---(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] Much Ado About COUNT(*)
Jim C. Nasby [EMAIL PROTECTED] writes: Actually, I guess I wasn't understanding the problem to begin with. You'd never go from new tuple to known good while the transaction that created the tuple was in-flight, right? By definition, not. If that's the case, I'm not sure where there's a race condition. You can't delete a tuple that hasn't been committed, right? The originating transaction could itself delete the tuple, but no one else could see it yet to do that. This means that you'd have to allow a transition directly from new tuple to possibly dead. (In the absence of subtransactions this could be optimized into a transition directly to known dead, but now that we have subtransactions I don't think we can do that.) However, the race condition comes in when someone wants to delete the row at about the same time as someone else is trying to mark it known good, ie, sometime *after* the originating transaction committed. This is definitely a possible situation. regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] [PATCHES] Latest Turkish translation updates
Devrim GUNDUZ wrote: These are the latest updates: Installed. BTW... Peter, we see some errors on postgres-tr.po file, on nlsstatus page (http://developer.postgresql.org/~petere/nlsstatus/po-current/postgre s-tr.po.err) po/postgres-tr.po:9383: number of format specifiers in msgid and msgstr does not match We can't reproduce it with msgfmt -v. How do you get those errors? The scripts that produce these tables do not use the standard gettext tools; they use hand-crafted Perl scripts. In some cases, these catch more errors. In all cases that I have analyzed further, this was because %m was not identified as a format specifier by msgfmt. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] pgdump
On Fri, 2005-01-14 at 16:24 +0100, Andreas Joseph Krogh wrote: http://dev.officenet.no/~andreak/pg_dump.c.diff Looks good, except for some minor code cleanups and doc updates. Barring any objections, I'll clean it up and apply it once we branch 8.0. I suppose for consistency we ought to allow multiple schemas to be specified via the -n option? (Speaking of which, is the plan still to branch 8.0 very shortly after the 8.0.0 final release?) -Neil ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] pgdump
Neil Conway wrote: On Fri, 2005-01-14 at 16:24 +0100, Andreas Joseph Krogh wrote: http://dev.officenet.no/~andreak/pg_dump.c.diff Looks good, except for some minor code cleanups and doc updates. Barring any objections, I'll clean it up and apply it once we branch 8.0. I suppose for consistency we ought to allow multiple schemas to be specified via the -n option? I don't remember this patch. How is it related to the other pg_dump patches in the 8.1 pathces queue? (Speaking of which, is the plan still to branch 8.0 very shortly after the 8.0.0 final release?) I guess we could do that now actually. -- Bruce Momjian| http://candle.pha.pa.us pgman@candle.pha.pa.us | (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] pgdump
On Sun, 2005-01-16 at 23:42 -0500, Bruce Momjian wrote: I don't remember this patch. http://archives.postgresql.org/pgsql-patches/2004-07/msg00331.php How is it related to the other pg_dump patches in the 8.1 pathces queue? I missed the July '04 discussion about the other patches for improving -t behavior. AFAIK the patches are unrelated. Something like the design elaborated here: http://archives.postgresql.org/pgsql-patches/2004-07/msg00374.php looks good to me, and would be preferrable to Andreas' patch IMHO. Unless I'm missing something, I don't see a patch from David Skoll in that thread that actually implements the above behavior. I'd be happy to implement Tom's suggested design for 8.1 unless someone has already beaten me to it. -Neil ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[HACKERS] Time to branch for 8.1?
Is it time to branch for 8.1? We are packaging 8.0.0 on Monday. -- Bruce Momjian| http://candle.pha.pa.us pgman@candle.pha.pa.us | (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] Time to branch for 8.1?
Bruce Momjian pgman@candle.pha.pa.us writes: Is it time to branch for 8.1? We are packaging 8.0.0 on Monday. At this point I suppose we should make the branch immediately after tagging 8.0.0. We delayed it long enough that there's no point in an earlier branch. regards, tom lane ---(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] Time to branch for 8.1?
On Mon, 17 Jan 2005, Bruce Momjian wrote: Is it time to branch for 8.1? We are packaging 8.0.0 on Monday. this late, may as well do the branch as part of the tag itself ... Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] pgdump
Neil Conway [EMAIL PROTECTED] writes: Something like the design elaborated here: http://archives.postgresql.org/pgsql-patches/2004-07/msg00374.php looks good to me, and would be preferrable to Andreas' patch IMHO. Unless I'm missing something, I don't see a patch from David Skoll in that thread that actually implements the above behavior. I'd be happy to implement Tom's suggested design for 8.1 unless someone has already beaten me to it. A little further down-thread there was some discussion of also allowing wild cards in the individual switches, eg -t 's1.*' (This would differ from '-n s1' in that a -t switch would restrict the dump to tables only, whereas -n should take every sort of object in the selected schema.) I dismissed it at the time because we were too close to feature freeze, but the idea should be considered if you're going to do a new patch for 8.1. I think the issues would be * what are the wildcard rules exactly? * what about quoting/downcasing rules? Possibly it's sufficient to say just like the way \d works in psql, but we should look closely before leaping. We've been burnt before by choosing rules that turned out to be awkward to use on a shell command line because of interference from the shell's quoting and expansion behavior. regards, tom lane ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] pgdump
Neil Conway [EMAIL PROTECTED] writes: On Mon, 2005-01-17 at 00:24 -0500, Tom Lane wrote: A little further down-thread there was some discussion of also allowing wild cards in the individual switches, Is this actually useful behavior? Possibly not. It's been requested often enough, but multiple -t and -n switches might be sufficient. * what about quoting/downcasing rules? If we don't implement wildcards, I don't believe we will need to change the present behavior of the -n and -t switches WRT case conversion etc. I'm not sure you can ignore the issue completely. The proposal you're supporting included being able to pick out a specific table with -t s1.t1 and without any quoting rules it would then become impossible to deal with names containing dots. Are we willing to blow off that case? Or is it better to drop that part of the proposal? regards, tom lane ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] IBM releases 500 patents
On Tue, 2005-01-11 at 08:04 -0800, Darcy Buskermolen wrote: IBM has just announced they are waving all rights and providing access to 500 patents. In the list of 500 there are several that relate RDBMS and query optimizations, it may be worth a look. FYI, IBM has applied for a patent on ARC (AFAICS the patent application is still pending, although the USPTO site is a little hard to grok): http://appft1.uspto.gov/netacgi/nph-Parser?Sect1=PTO1Sect2=HITOFFd=PG01p=1u=%2Fnetahtml%2FPTO%2Fsrchnum.htmlr=1f=Gl=50s1=%2220040098541%22.PGNR.OS=DN/20040098541RS=DN/20040098541 -Neil ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] pgdump
On Mon, 2005-01-17 at 00:54 -0500, Tom Lane wrote: -t s1.t1 [...] without any quoting rules it would then become impossible to deal with names containing dots. Ah, yeah -- sorry, I was focusing on case conversion rather than quoting in general. Are we willing to blow off that case? Or is it better to drop that part of the proposal? I would be OK with just ignoring this case, but on reflection I would prefer removing the -t schema.table syntax. Removing the feature resolves the quoting issue and also simplifies pg_dump's behavior. We lose the ability to dump table t1 in schema s1 and table t2 in schema s2 in a single command, but (a) you can specify -t t1 -t t2 -n s1 -n s2, although this might also dump t1.s2 and/or t2.s1 (b) you can just run pg_dump twice, specifying the appropriate -t and -n options each time So the behavior would be that suggested earlier by David Skoll: pg_dump -t t1 -- Dump table t1 in any schema pg_dump -n s1 -- Dump all of schema s1 pg_dump -t t1 -n s1-- Dump t1 in s1 pg_dump -t t1 -t t2 -n s1 -- Dump s1.t1 and s1.t2 pg_dump -t t1 -t t2 -n s1 -n s2-- Dump s1.t1, s1.t2, s2.t1 and s2.t2 We'd only raise an error if we found no matching tables/schemas, as was hashed out in July. -Neil ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
[HACKERS] ARC patent
Neil Conway [EMAIL PROTECTED] writes: FYI, IBM has applied for a patent on ARC (AFAICS the patent application is still pending, although the USPTO site is a little hard to grok): http://appft1.uspto.gov/netacgi/nph-Parser?Sect1=PTO1Sect2=HITOFFd=PG01p=1u=%2Fnetahtml%2FPTO%2Fsrchnum.htmlr=1f=Gl=50s1=%2220040098541%22.PGNR.OS=DN/20040098541RS=DN/20040098541 Ugh. We could hope that the patent wouldn't be granted, but I think it unlikely, unless Jan is aware of prior art (like a publication predating the filing date). I fear we'll have to change or remove that code. regards, tom lane ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] pgdump
Neil Conway [EMAIL PROTECTED] writes: So the behavior would be that suggested earlier by David Skoll: pg_dump -t t1 -- Dump table t1 in any schema pg_dump -n s1 -- Dump all of schema s1 pg_dump -t t1 -n s1-- Dump t1 in s1 pg_dump -t t1 -t t2 -n s1 -- Dump s1.t1 and s1.t2 pg_dump -t t1 -t t2 -n s1 -n s2-- Dump s1.t1, s1.t2, s2.t1 and s2.t2 Well, that at least obeys the KISS principle ;-). Sure, let's try that and see if it satisfies people. Just to be clear: what I understand the logic to be is OR across multiple switches of the same type, but AND across switches of two types. regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] pgdump
On Mon, 2005-01-17 at 01:19 -0500, Tom Lane wrote: Just to be clear: what I understand the logic to be is OR across multiple switches of the same type, but AND across switches of two types. If I understand you correctly, you're suggesting that we should only report an error if none of the specified tables exist OR none of the specified schemas exist. I'm not sure I agree. Consider this command: pg_dump -t some_table -t non_existent_table Assuming some_table exists, we will now blithely ignore the nonexistent table. That is perfectly reasonable because of the cartesian explosion of possibilities that occurs when both -t and -n are specified, but in the absence of that it seems regrettable. The same applies to -n foo -n non_existent_schema, naturally. An easy fix would be to raise an error for each specified but nonexistent object, *except* if both -n and -t are specified, in which case we use your behavior (report an error if none of the specified tables are found OR none of the specified schemas are found). Perhaps better would be to require that each -t or -n switch results in a 'match' -- i.e. if you specify -t foo -n x -n y, we check that (a) schema x exists AND (b) schema y exists AND (c) table foo exists in (schema x OR schema y) This means we have tighter error checking, although I'm not sure how intuitive it is. -Neil ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] pgdump
Neil Conway [EMAIL PROTECTED] writes: On Mon, 2005-01-17 at 01:19 -0500, Tom Lane wrote: Just to be clear: what I understand the logic to be is OR across multiple switches of the same type, but AND across switches of two types. If I understand you correctly, you're suggesting that we should only report an error if none of the specified tables exist OR none of the specified schemas exist. No, I was only expressing an opinion about what should be dumped, not about what kind of diagnostic messages to issue. If you want to warn about switches that fail to match anything, go for it. (I vote for just a warning, though, not a hard error.) regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
