[HACKERS] v7.0.3 *pre-release* ...
In order that we can get a few days of testing on these, make sure the
packaging is right and whatnot, we are holding off on a formal release
until early->mid next week ...
I've just put pre-release tar balls into:
ftp://ftp.postgresql.org/pub/source/v7.0.3
Please take a minute to download and test these out, so that when we
release, we don't get a bunch of "oops, you forgot this" messages :)
Thanks ...
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: [EMAIL PROTECTED] secondary: scrappy@{freebsd|postgresql}.org
[HACKERS] INTERVAL representation
I've been working on date/time issues over the last few weeks (at least one or two from reports on the list, others that I've stumbled across, and even one or two planned ones ;) Anyway, the INTERVAL type output representation has trouble with values such as '-1 month +2 hours' since it assumes that the *sign* of every field is the same (the current development tree may have other troubles with interpreting this too, but I'm fixing that). For years/months, that resolves as those values are stored, so, for example, '-1 year +1 month' becomes '-11 months' as it is stored, and '-1 day +2 hours -4 minutes' resolves similarly. But months and days/hours/minutes/seconds are stored separately, so could have different signs. Any suggestions for how to represent mixed-sign intervals? I'm inclined to move away from the "ago" convention for representing negative intervals, since "-1 month +2 hours ago" could be considered a little ambiguous. Should we move to signed-only representations? Or retain the "ago" convention, having it match the sign of the first printed field, with subsequent fields having negative signs if they are positive values? At the moment, mixed-sign intervals are stored correctly (so have the right results for math) but are *not* represented in the output correctly. Possibilities are: '1 month -2 days ago' is less than a month ago. '1 month -2 days +03:04' is three hours more than two days less than a month from now. '-1 month +2 days' is less than a month ago. Comments? - Thomas
Re: [HACKERS] Re: [COMMITTERS] pgsql/contrib/pg_dumpaccounts (Makefile README pg_dumpaccounts.sh)
Tom Lane wrote: > > Peter Eisentraut <[EMAIL PROTECTED]> writes: > > What part of "no new features in bug-fix releases" is giving people > > trouble? > > Interesting observation here: the key developers seem to be much more > exercised about this than the rest of the community. Counting core > members and Peter we have three "no" and one "yes", whereas as best > I recall the votes from the rest of pghackers are about 6 to 1 in > favor. > > Make of that what you will --- but I'm going to yield the point, > since the non-core sentiment seems to be very clear. ISTM that devlopers are correctly concerned about policy. And ISTM that users place a slightly higher premium on administrative ease than they do on consistency. Nothing really wrong with that either. My guess is that users would be very happy to yield on placing the script in /contrib if some alternate were proposed. I'd be just as happy if there were a link to the file on the download page. Or if it was placed in an "interim" directory or something like that. I just want it to be available. I would prefer if it could be done in a way that's consistent with the project policy, but that consistency is just slightly less important to me than short-term usability. -- Karl DeBisschop[EMAIL PROTECTED] Learning Network Reference http://www.infoplease.com Netsaint Plugin Developer [EMAIL PROTECTED]
Re: [HACKERS] problems with configure
Martin A. Marques writes: > checking types of arguments for accept()... configure: error: could not determine >argument types According to the documentation for Solaris 7 it should be 'accept(int, struct sockaddr *, socklen_t *)', which is the same on my system, so the problem is elsewhere. One possibility is that the earlier tests for sys/types.h or sys/socket.h failed. Could you check what the file config.log says? -- Peter Eisentraut [EMAIL PROTECTED] http://yi.org/peter-e/
Re: [HACKERS] Re: [COMMITTERS] pgsql/contrib/pg_dumpaccounts (MakefileREADME pg_dumpaccounts.sh)
> Peter Eisentraut <[EMAIL PROTECTED]> writes: > > What part of "no new features in bug-fix releases" is giving people > > trouble? > > Interesting observation here: the key developers seem to be much more > exercised about this than the rest of the community. Counting core > members and Peter we have three "no" and one "yes", whereas as best > I recall the votes from the rest of pghackers are about 6 to 1 in > favor. > > Make of that what you will --- but I'm going to yield the point, > since the non-core sentiment seems to be very clear. One final analysis of this. If Jan had come to the list and explained the problem, and suggested adding something to /contrib for 7.0.3, I think most people would have said OK. My guess is that many of the negative votes are based on the way this was handled. I know I think about how this was handled and get upset myself. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026
[HACKERS] Re: [INTERFACES] DBD::Pg installation seems to fail with 7.1 libs
> Thomas, you've been muttering about altering the type resolution rules > so that "unknown" will be treated as "text" when all else fails. Are > you planning to commit such a thing for 7.1? If not, I'll probably have > to hack up parse_coerce.c's select_common_type(), along the lines of I'm *finally* getting several patches together, to do the following things: o Fix the type resolution for unknown function arguments to fall back to "text" or a string type, if available. Previously discussed. o Implement an AT TIME ZONE clause, per SQL9x. Will handle an INTERVAL argument, per standard, and also accept a string containing a time zone spec, per existing PostgreSQL extension. Previously discussed. o Fix timestamp/interval math across daylight savings time boundaries. Previously discussed. o Allow interpretation of "hh:mm:ss" as INTERVAL input. I can't remember if I've mentioned this one before. o Fix output of INTERVAL when sign of year/month is different than sign of hour/min/sec. This is accompanied by changes in the "ISO" form of output to more closely resemble a "hh:mm:ss" format. I just noticed the problem today, so have not discussed it on list yet. o Add some JOIN regression tests. More should be and will be done, but I don't want to keep holding back patches on this. Per Tom Lane's request. The only one with some potential for user trouble is the INTERVAL format change. The old code was wrong, but the format itself has been changed to be a little more concise. - Thomas
Re: [HACKERS] Alternative database locations are broken
> >> I think that to handle locations we could symlink catalogs - ln -s > >> path_to_database_in_some_location .../base/DatabaseOid > > > But that's a kludge. We ought to discourage people from messing with the > > storage internals. > > It's not a kluge, it's a perfectly fine implementation. The only kluge > here is if people have to reach in and establish such symlinks by hand. > We want to set up a user interface that hides the implementation. Agreed. And I don't see problems with handling this at CREATE DATABASE time. Create database dir in specified location, create symlink from base dir and remember location name in pg_database.datpath. Vadim
Re: [HACKERS] Transaction ID wraparound: problem and proposed solution
> > So, we'll have to abort some long running transaction. > > Well, yes, some transaction that continues running while ~ 500 million > other transactions come and go might give us trouble. I wasn't really > planning to worry about that case ;-) Agreed, I just don't like to rely on assumptions -:) > > Required frequency of *successful* vacuum over *all* tables. > > We would have to remember something in pg_class/pg_database > > and somehow force vacuum over "too-long-unvacuumed-tables" > > *automatically*. > > I don't think this is a problem now; in practice you couldn't possibly > go for half a billion transactions without vacuuming, I'd think. Why not? And once again - assumptions are not good for transaction area. > If your plans to eliminate regular vacuuming become reality, then this > scheme might become less reliable, but at present I think there's plenty > of safety margin. > > > If undo would be implemented then we could delete pg_log between > > postmaster startups - startup counter is remembered in pages, so > > seeing old startup id in a page we would know that there are only > > long ago committed xactions (ie only visible changes) there > > and avoid xid comparison. But ... there will be no undo in 7.1. > > And I foresee problems with WAL based BAR implementation if we'll > > follow proposed solution: redo restores original xmin/xmax - how > > to "freeze" xids while restoring DB? > > So, we might eventually have a better answer from WAL, but not for 7.1. > I think my idea is reasonably non-invasive and could be removed without > much trouble once WAL offers a better way. I'd really like to have some > answer for 7.1, though. The sort of numbers John Scott was quoting to > me for Verizon's paging network throughput make it clear that we aren't > going to survive at that level with a limit of 4G transactions per > database reload. Having to vacuum everything on at least a > 1G-transaction cycle is salable, dump/initdb/reload is not ... Understandable. And probably we can get BAR too but require full backup every WRAPLIMIT/2 (or better /4) transactions. Vadim
Re: [HACKERS] Re: [COMMITTERS] pgsql/contrib/pg_dumpaccounts (MakefileREADME pg_dumpaccounts.sh)
On Fri, 3 Nov 2000, Bruce Momjian wrote: > I have talked to GB and they understand their error. Until the next time? This isn't the first time you've "talked to them" ...
Re: [HACKERS] Thoughts on 7.0.3 pg_dump addition
Bruce Momjian wrote: > Basically, it seems that while we will have missteps like this from time > to time, our ability to resolve them is unhampered. > Apologies to those who felt this week's discussion was too lengthy. > This is the only way we have to make fair, informed decisions that take > everyone's opinions into account. This discussion just reaffirms to me why the PostgreSQL project is one of, if not _the_, best run open source projects out there. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
[HACKERS] Thoughts on 7.0.3 pg_dump addition
As everyone knows, there was discussion this week about a new utility to be added to 7.0.3. The final decision was that the utility should go into /contrib, and that the utility will not be mentioned in the release notes. I think we can learn some things from this episode. Certainly, this had many missteps: Company requests new feature with no discussion Employed core member adds feature without discussion Feature is added to a subrelease, which usually has no new features Subrelease is already frozen Feature is so minor, it is not even on the TODO list Initially added as a new command that would disappear in 7.1, now in /contrib I realize there were extenuating circumstances that caused some of these missteps. The good news from all of this is how it was resolved. Each employed core member had a different opinion, showing we still do control our own opinions. I believe the final solution was optimal. Having gone through this, I am now slightly less concerned about whether the dynamics will change now that companies are involved with PostgreSQL. Seems like this was handled just like before. In fact, some employed core members even went beyond their normal inclinations to maintain fairness. We do have these goofy issues to resolve occasionally. The interesting thing to me is that this company-induced one was really no different than any of the past issues. We discussed it, and we resolved it. Basically, it seems that while we will have missteps like this from time to time, our ability to resolve them is unhampered. Apologies to those who felt this week's discussion was too lengthy. This is the only way we have to make fair, informed decisions that take everyone's opinions into account. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026
Re: [HACKERS] Summary: what to do about INET/CIDR
Peter Eisentraut <[EMAIL PROTECTED]> writes: > A separate function for formatting output seems necessary, but if we don't > reach an agreement though, it ought to work to cast CIDR to INET to get > all four octets, no? Uh, weren't you one of the people objecting to relying on cidr-to-inet casts to control formatting? > I think the typecast-to-text representation of CIDR should be visually the > same as the normal representation. Well, we need *some* way to extract a representation like "w.x.y.z/n". If you don't like text() as the name of that formatting function, suggest another name... regards, tom lane
Re: [HACKERS] regression failure...
* Tom Lane <[EMAIL PROTECTED]> [001104 18:40]: > Larry Rosenman <[EMAIL PROTECTED]> writes: > > Looks like someone changed an error message, but didn't upgrade the > > expected file... > > Yup. I just undid the error message change, because the new text did > not seem like an improvement... I agree. Thanks! LER > > regards, tom lane -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 (voice) Internet: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749
Re: [HACKERS] regression failure...
Larry Rosenman <[EMAIL PROTECTED]> writes: > Looks like someone changed an error message, but didn't upgrade the > expected file... Yup. I just undid the error message change, because the new text did not seem like an improvement... regards, tom lane
[HACKERS] regression failure...
Looks like someone changed an error message, but didn't upgrade the expected file... (Current sources/multibyte/UnixWare 7.1.1) *** ./expected/geometry.out Tue Sep 12 16:07:16 2000 --- ./results/geometry.out Sat Nov 4 15:55:05 2000 *** *** 127,133 | (-5,-12) | [(10,-10),(-3,-4)]| (-1.60487804878049,-4.64390243902439) | (10,10)| [(10,-10),(-3,-4)]| (2.39024390243902,-6.48780487804878) | (0,0) | [(-100,200),(30,-40)] | (0.0028402365895872,15.384614860264) ! | (-10,0)| [(-100,200),(30,-40)] | (-9.99715942258202,15.3864610140472) | (-3,4) | [(-100,200),(30,-40)] | (-2.99789812267519,15.3851688427303) | (5.1,34.5) | [(-100,200),(30,-40)] | (5.09647083221496,15.3836744976925) | (-5,-12) | [(-100,200),(30,-40)] | (-4.99494420845634,15.3855375281616) --- 127,133 | (-5,-12) | [(10,-10),(-3,-4)]| (-1.60487804878049,-4.64390243902439) | (10,10)| [(10,-10),(-3,-4)]| (2.39024390243902,-6.48780487804878) | (0,0) | [(-100,200),(30,-40)] | (0.0028402365895872,15.384614860264) ! | (-10,0)| [(-100,200),(30,-40)] | (-9.99715942258202,15.3864610140473) | (-3,4) | [(-100,200),(30,-40)] | (-2.99789812267519,15.3851688427303) | (5.1,34.5) | [(-100,200),(30,-40)] | (5.09647083221496,15.3836744976925) | (-5,-12) | [(-100,200),(30,-40)] | (-4.99494420845634,15.3855375281616) *** *** 150,160 six |box -+ | (2.12132034355964,2.12132034355964),(-2.12132034355964,-2.12132034355964) ! | (71.7106781186548,72.7106781186548),(-69.7106781186548,-68.7106781186548) ! | (4.53553390593274,6.53553390593274),(-2.53553390593274,-0.535533905932738) ! | (3.12132034355964,4.12132034355964),(-1.12132034355964,-0.121320343559643) | (107.071067811865,207.071067811865),(92.9289321881345,192.928932188135) ! | (170.710678118655,70.7106781186548),(29.2893218813452,-70.7106781186548) (6 rows) -- translation --- 150,160 six |box -+ | (2.12132034355964,2.12132034355964),(-2.12132034355964,-2.12132034355964) ! | (71.7106781186547,72.7106781186547),(-69.7106781186547,-68.7106781186547) ! | (4.53553390593274,6.53553390593274),(-2.53553390593274,-0.535533905932737) ! | (3.12132034355964,4.12132034355964),(-1.12132034355964,-0.121320343559642) | (107.071067811865,207.071067811865),(92.9289321881345,192.928932188135) ! | (170.710678118655,70.7106781186547),(29.2893218813453,-70.7106781186547) (6 rows) -- translation *** *** 443,454 FROM CIRCLE_TBL; six | polygon -+- ! | ((-3,0),(-2.59807621135076,1.500442),(-1.499116,2.59807621135842),(1.53102359078377e-11,3),(1.501768,2.59807621134311),(2.59807621136607,1.49779),(3,-3.06204718156754e-11),(2.59807621133545,-1.503094),(1.496464,-2.59807621137373),(-4.59307077235131e-11,-3),(-1.50442,-2.5980762113278),(-2.59807621138138,-1.495138)) ! | ((-99,2),(-85.6025403783588,52.01473),(-48.97054,88.602540378614),(1.051034,102),(51.05893,88.6025403781036),(87.6025403788692,51.92634),(101,1.897932),(87.6025403778485,-48.10313),(50.88214,-84.6025403791243),(0.8468976,-98),(-49.14732,-84.6025403775933),(-85.6025403793795,-47.83795)) | ((-4,3),(-3.33012701891794,5.500737),(-1.498527,7.3301270189307),(1.002552,8),(3.502946,7.33012701890518),(5.33012701894346,5.496317),(6,2.994897),(5.33012701889242,0.4948437),(3.494107,-1.33012701895622),(0.9923449,-2),(-1.500
Re: [HACKERS] problems with configure
"Martin A. Marques" <[EMAIL PROTECTED]> writes: > On Vie 03 Nov 2000 22:16, Tom Lane wrote: >> Hm, how do your system's include files declare accept()? > The config.log file starts given fails at this point: > configure:5475: conflicting types for `accept' > /usr/include/sys/socket.h:384: previous declaration of `accept' So how does /usr/include/sys/socket.h declare accept() ? regards, tom lane
[HACKERS] cvs problems solved
Remember the CVS problems I had grabbing the logs from just one branch
of cvs?
Well, it turns out it is a cvs bug. CVS is fine with showing logs from
just a branch iff the file existed when the branch was created. For
post-branch files like pgsql/GNUmakefile.in, you see all changes.
I received e-mails from the cvs 'log' maintainer, which are attached.
He explained the problem and gave me a workaround. He is going to try
and get the bug fixed.
I have modified pgcvslog to show the workaround, and have attached the
output. Seems cvs2cl works around this problem somehow.
---
>From [EMAIL PROTECTED] Fri Nov 3 15:07:53 2000
Received: from foghorn.airs.com (IDENT:[EMAIL PROTECTED] [63.201.54.26])
by candle.pha.pa.us (8.9.0/8.9.0) with SMTP id PAA24342
for <[EMAIL PROTECTED]>; Fri, 3 Nov 2000 15:07:51 -0500 (EST)
Received: (qmail 1388 invoked by uid 10); 3 Nov 2000 20:07:47 -
Received: (qmail 15262 invoked by uid 269); 3 Nov 2000 20:07:44 -
Message-ID: <[EMAIL PROTECTED]>
Date: 3 Nov 2000 12:07:44 -0800
From: Ian Lance Taylor <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
In-reply-to: <[EMAIL PROTECTED]> (message from Bruce
Momjian on Fri, 3 Nov 2000 10:11:37 -0500 (EST))
Subject: Re: [HACKERS] 7.0.3 branded
References: <[EMAIL PROTECTED]>
Status: ORr
From: Bruce Momjian <[EMAIL PROTECTED]>
Date: Fri, 3 Nov 2000 10:11:37 -0500 (EST)
> On a related note, what tag should I give to cvs to get code from the
> 7.0.3 branch? Is it REL7_0_PATCHES?
It is. I can grab the cvs using that tag, but can not grab log entries
using that tag. No one seems to know why it doesn't work.
What are you trying to do? In what way does it not work as you
expect?
I just tried to find a file which was changed on the REL7_0_PATCHES
branches, but I failed. I was probably doing something wrong.
(I used to be a CVS maintainer--technically, I suppose I still am--so
I know something about how CVS works.)
Ian
>From [EMAIL PROTECTED] Fri Nov 3 15:29:40 2000
Received: from foghorn.airs.com (IDENT:[EMAIL PROTECTED] [63.201.54.26])
by candle.pha.pa.us (8.9.0/8.9.0) with SMTP id PAA24969
for <[EMAIL PROTECTED]>; Fri, 3 Nov 2000 15:29:39 -0500 (EST)
Received: (qmail 1536 invoked by uid 10); 3 Nov 2000 20:29:40 -
Received: (qmail 15422 invoked by uid 269); 3 Nov 2000 20:29:32 -
Message-ID: <[EMAIL PROTECTED]>
Date: 3 Nov 2000 12:29:32 -0800
From: Ian Lance Taylor <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
CC: [EMAIL PROTECTED]
In-reply-to: <[EMAIL PROTECTED]> (message from Bruce
Momjian on Fri, 3 Nov 2000 15:11:00 -0500 (EST))
Subject: Re: [HACKERS] 7.0.3 branded
References: <[EMAIL PROTECTED]>
Status: ORr
From: Bruce Momjian <[EMAIL PROTECTED]>
Date: Fri, 3 Nov 2000 15:11:00 -0500 (EST)
cvs log -rREL7_0_PATCHES
I want just log entries that are part of the branch. I get all entries.
What I see when I try this is that for files which have the
REL7_0_PATCHES tag (i.e., files which are on the branch), I see only
log entries for the branch. For files which are do not have the
REL7_0_PATCHES tag (i.e., are not on the branch), I see all log
entries.
For example, in the top pgsql directory,
cvs log -rREL7_0_PATCHES HISTORY
gives me only log entries for the branch for the HISTORY file.
However,
cvs log -rREL7_0_PATCHES GNUmakefile.in
gives me all log entries. It also gives me this warning:
cvs server: warning: no revision `REL7_0_PATCHES' in
`/home/projects/pgsql/cvsroot/pgsql/GNUmakefile.in,v'
Is this also what you see?
The natural way to fix this ought to be
cvs co -rREL7_0_PATCHES pgsql
cvs log .
Unfortunately, I tried it, and cvs log, I believe erroneously, seems
to pick up all files in the directory, even if they have not been
checked out.
I can tell you a hideous kludge to avoid this, but I can't claim that
it is the way to operate. Check out the branch using the -r option as
above. Then do this:
find . -name CVS -type d -exec touch '{}/Entries.Static' \;
After that, in the same directory, do
cvs log -rREL7_0_PATCHES
I'd hate to have to explain why that works.
Which version of CVS are you running on the server? When I find some
time I'll see about fixing cvs log.
Ian
>From [EMAIL PROTECTED] Fri Nov 3 15:48:15 2000
Received: from foghorn.airs.com (IDENT:[EMAIL PROTECTED] [63.201.54.26])
by candle.pha.pa.us (8.9.0/8.9.0) with SMTP id PAA25678
for <[EMAIL PROTECTED]>; Fri, 3 Nov 2000 15:48:14 -0500 (EST)
Received: (qmail 1742 invoked by uid 10); 3 Nov 2000 20:48:15 -
Received: (qmail 15565 invoked by uid 269); 3 Nov 2000 20:48:07 -
Message-ID: <[EMAIL PROTECTED]>
Date: 3 Nov 2000 12:48:07 -0800
From: Ian Lance Taylor <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
In-reply-to: <[EMAIL PROTECTED]> (message from Bruce
Momjian on Fri, 3 Nov 2000 15:35:01 -0500 (EST))
Subject: Re: [HACKERS] 7.0.3
[HACKERS] DROP [PROCEDURAL] LANGUAGE
Seems we call the command create language and drop language, but the syntax requires CREATE PROCEDURAL LANGUAGE and DROP PROCEDURAL LANGUAGE. I am going to change the docs and grammar so PROCEDURAL is optional. Is this OK? -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026
Re: [HACKERS] problems with configure
On Vie 03 Nov 2000 22:16, Tom Lane wrote:
>
> Hm, how do your system's include files declare accept()?
>
> It would help to see the part of the config.log file that shows the
> errors configure gets while trying to find workable input types for
> accept().
The config.log file starts given fails at this point:
configure:5383: checking for struct sockaddr_un
configure:5398: gcc -c -g conftest.c 1>&5
configure:5422: checking for int timezone
configure:5434: gcc -o conftest -g conftest.c -lz -lgen -lnsl -lsocket
-ldl -lm -lreadline -ltermcap -lcurses 1>&5
configure:5454: checking types of arguments for accept()
configure:5481: gcc -c -g conftest.c 1>&5
configure:5475: conflicting types for `accept'
/usr/include/sys/socket.h:384: previous declaration of `accept'
configure: failed program was:
#line 5468 "configure"
#include "confdefs.h"
#ifdef HAVE_SYS_TYPES_H
#include
#endif
#ifdef HAVE_SYS_SOCKET_H
#include
#endif
extern accept (int, struct sockaddr *, int *);
int main() {
; return 0; }
I see there that the extern accept function is different from the one that
Peter Eisentraut wrote in his mail. Could there be somthing wrong in the cvs
code, or in one of the Solaris headers?
Saludos... :-)
--
"And I'm happy, because you make me feel good, about me." - Melvin Udall
-
Martín Marqués email: [EMAIL PROTECTED]
Santa Fe - Argentinahttp://math.unl.edu.ar/~martin/
Administrador de sistemas en math.unl.edu.ar
-
Re: [HACKERS] Transaction ID wraparound: problem and proposed solution
One idea I had from this is actually truncating pg_log at some point if we know all the tuples have the special committed xid. It would prevent the file from growing without bounds. Vadim, can you explain how WAL will make pg_log unnecessary someday? > We've expended a lot of worry and discussion in the past about what > happens if the OID generator wraps around. However, there is another > 4-byte counter in the system: the transaction ID (XID) generator. > While OID wraparound is survivable, if XIDs wrap around then we really > do have a Ragnarok scenario. The tuple validity checks do ordered > comparisons on XIDs, and will consider tuples with xmin > current xact > to be invalid. Result: after wraparound, your whole database would > instantly vanish from view. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026
Re: [HACKERS] CommandCounterIncrement
I have added this to the developers FAQ. However, the developers FAQ isn't accessible from the web site, and I have contacted Vince on this. --- 13) What is CommandCounterIncrement()? Normally, transactions can not see the rows they modify. This allows UPDATE foo SET x = x + 1 to work correctly. However, there are cases where a transactions needs to see rows affected in previous parts of the transaction. This is accomplished using a Command Counter. Incrementing the counter allows transactions to be broken into pieces so each piece can see rows modified by previous pieces. CommandCounterIncrement() increments the Command Counter, creating a new part of the transaction. --- > Denis Perchine <[EMAIL PROTECTED]> writes: > > Small technical question: what exactly CommandCounterIncrement do? > > It increments the command counter ;-) > > > And what exactly it should be used for? > > You need it if, within a chunk of backend code, you want subsequent > queries to see the results of earlier queries. Ordinarily a query > cannot see its own output --- else a command like > UPDATE foo SET x = x + 1 > for example, would be an infinite loop, since as it scans the table > it would find the tuples it inserted, update them, insert the updated > copies, ... > > Postgres' solution is that tuples inserted by the current transaction > AND current command ID are not visible. So, to make them visible > without starting a new transaction, increment the command counter. > > > I ask this question because I found out that when I run postgres with > > verbose=4 I see lot's of StartTransactionCommand & CommitTransactionCommand > > pair in the place where BLOB is written. And I have a feeling that something > > is wrong. Looks like explicitly commit all changes. That's really bad... > > These do not commit anything, assuming you are inside a transaction > block. Offhand I don't think they will amount to much more than a > CommandCounterIncrement() call in that case, but read xact.c if you want > to learn more. > > regards, tom lane > -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026
Re: [HACKERS] OSDN Database conference report (long)
Tom Lane wrote: > Thanks for doing it ;) I have some comments too ... > One of the > longest-running parts of the discussion had to do with giving good error > messages and how it is hard to get friendly messages when you rely on the > database to do error checking. I thought this pointed up the need we've > been aware of for awhile to overhaul our error reporting. One thing I have wished for a long time is _configurable_ error reporting, so that I could tell the backent to "set errorlevel to N" and not receive any errors below level N > Tim also had > a "wish list" for PG that included better admin tools, such as a way to > see exactly what queries are running; and a way to retrieve all the > database-generated items in a just-inserted row, not only the OID. > Both of these have also been on the radar screen for awhile. or at least allow something like "select * from table where LAST_INSERTED_BY_ME" to be fast (are we currently smaprt enoug to stop scam after finding an unique item, or is it so, that "select ... where oid=N" still does a full table scan, even thoug oid's are uniqe") > After a fine lunch (all the food was superb BTW; OSDN made an excellent > choice of hotel), we reconvened to hear David Axmark talk about the > history and philosophy of MySQL. The only thing that really surprised me > is that that project is quite young: it started in 1995. Given that Monty > seems to do the vast majority of the development work, there are not many > man-years in it, certainly far less than in Postgres. They've done well > to come as far as they have. IIRC they already had an ISAM library and mSQL as a sampole implementation. > To get back to the technical part of Ann's talk, the thing I came away > with is a realization that IB did a lot of things pretty similar to > Postgres. In particular, it sounds like they have a multi-versioning > model nearly identical to Postgres'. I thought that was common knowledge here ;) At least I mentioned it on this list several times in early days (maybe 95-96) and I'm pretty sure that also Vadim wrote something about their approah back then ? > They also have some ideas we might > be able to adopt --- for example, their indexes point only to the newest > version of a row, not all versions. I seems to be good as an idea, but woul make it somewhat harder to find tuples in transactions that are started earlyer than the newest tuple, specifically in cases where they have planned to find the tuple using the index. > It'd be worth our while to dig > through their code for ideas. However, Ann admitted that they are > woefully short on internals documentation, so extracting useful ideas > promises to be painful :-( Probably it would be easier to have someone spy on their mailing lists ;) > The final group-wide session featured Mike Olson of Sleepycat as speaker. > Most of you know that Mike was part of the Berkeley Postgres team years > ago (if you don't, try scanning our sources for the initials mao) so I > count him still a Postgres man, even though Sleepycat is currently in bed > with MySQL. Mike had some *extremely* interesting things to say about > the prospects for open-source databases making inroads against commercial > competition. He pointed out that the notion that we have any chance of > doing so is mostly founded on the success Linux has been having competing > with Windows --- but that success is founded on (a) a cost advantage, > (b) a reliability advantage, and (c) an advantage in the applications > space: Linux runs sendmail, bind, Apache, and all the other core Internet > server apps, whereas Windows doesn't run them especially well. Mike > pointed out that Oracle could *easily* afford to give away their software > for free and make all their money on support contracts (license fees are > already only 1/3rd of their revenue, so it wouldn't be that big a > switch). That implies that their software is _not_ easy to install/maintain. I have a frustrated friend who set up a linux box for a company to replace an win2000 server which did not work (sendmail, squid, firewall, dns, ...) and who was promised a support contract as well, but as things just work for more than ahalf a year without him, he did not get any contract. > That would make the cost advantage a harder sell. We could > still make a good case for open databases on total cost of ownership, > but a key ball to keep our eye on is the ease of installation and > administration of our servers. IMHO postgres is easy to install, not only from .rpm biut also using configure, make, make install > Much of the differential comes from the > fact that qualified Oracle DBAs are scarce and obscenely well-paid. > We have to be sure that Joe Average Unix Sysadmin can deal with our > servers without much trouble. As for point (b), the news is bad: > we are *not* up to Oracle standards on reliability. (Mike only said > that it's unproven that we are up to commercial standard
Re: [HACKERS] Alternative database locations are broken
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> But RelFileNode already claims to store the identity of the table space,
> being the database oid. This doesn't work because a location can contain
> more than one database. So effectively we'd need to redefine RelFileNode
> something like 'struct { locationid, dbid, relid }'.
No, I don't think so. The direction we want to head in is that RelFileNode
should identify a tablespace (physical storage location) and a table.
There isn't any need for a hardwired association between tablespaces and
databases, at least not at this level.
IIRC, the proposed design that Vadim was basing this on is that the
actual path to a particular file would be
$PGDATA/base/TABLESPACE/TABLE
or for a segmented relation
$PGDATA/base/TABLESPACE/TABLE.SEGMENT
where TABLESPACE, TABLE, and SEGMENT are all numeric strings --- the
first two come from RelFileNode and the last from the target block #.
In this design, the tablespace directories appearing under $PGDATA/base
can either be plain subdirectories, or symlinks to directories that live
elsewhere. The low-level file access code doesn't know or care which.
The questions you are asking seem to concern design of a user interface
that lets these directories or symlinks get set up via SQL commands
rather than direct manual intervention. I agree that's a good thing to
have, but it's completely separate from the low-level access code.
The current implementation has one physical-subdirectory tablespace per
database, but I don't see any reason that multiple databases couldn't
share a tablespace, or that tables in a database couldn't be scattered
across multiple tablespaces. We just need to design the commands that
let the dbadmin control this.
BTW, we could eliminate special-casing for the shared system relations
if we treat them as stored in another tablespace. For example, make
$PGDATA/base/0 be a symlink to ../global, or just move the stuff
currently in $PGDATA/global to a subdirectory of $PGDATA/base.
>> I think that to handle locations we could symlink catalogs - ln -s
>> path_to_database_in_some_location .../base/DatabaseOid
> But that's a kludge. We ought to discourage people from messing with the
> storage internals.
It's not a kluge, it's a perfectly fine implementation. The only kluge
here is if people have to reach in and establish such symlinks by hand.
We want to set up a user interface that hides the implementation.
regards, tom lane
Re: [HACKERS] status applications
[ Charset ISO-8859-1 unsupported, converting... ] > On Mi? 01 Nov 2000 20:57, Martin A. Marques wrote: > > Seeing that nobody responded to my questions, here I go. ;-) > > I think one of the poor partes about postgres is the administration tools. I > am not a PostgreSQL hacker (would like to be one) so I don know if there are > things like user threads, locks and all those stuff to check for with some > sort of administration tool. > > I am willing to help in the development of this tool, and I think it would be > very important for the PostgreSQL community, adn for PostgreSQL as a whole. > > Any comments? Bruce? Tom? Vadim? I want to write a tcl/tk utility that can monitor database connections and server status. I hope to start in in the next month or two. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026
