Re: [HACKERS] Can we revisit the thought of PostgreSQL 7.2.4?
Bruce Momjian <[EMAIL PROTECTED]> writes: > Agreed. How do we get the patches in there, or are they there already? We patch ;-). I've been working on it the past few days. Not quite done, but close. 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] Can we revisit the thought of PostgreSQL 7.2.4?
Agreed. How do we get the patches in there, or are they there already? --- Tom Lane wrote: > Bruce Momjian <[EMAIL PROTECTED]> writes: > > So, do we have non-security fixes to warrant a 7.2.X? > > There's the order-of-operations-in-checkpoint problem, and there's > one variant of the "no one parent tuple was found" problem that > should have been patched in 7.2.3, but was overlooked. > > Also, the bogus-datetime-table-ordering bugs appear to exist in > 7.2 (cf. recent complaint about timezone ART not being recognized). > That ought to be back-patched, if we're going to make a 7.2.4, > though one could certainly say that that doesn't merit a release > by itself. > > I think there's enough to warrant a 7.2.4 ... > > regards, tom lane > -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] [PERFORM] Proposal: relaxing link between explicit JOINs and execution order
Josh Berkus <[EMAIL PROTECTED]> writes: > How about: > EXPLICIT_JOIN_MINIMUM > and > FROM_COLLAPSE_LIMIT I've implemented this using FROM_COLLAPSE_LIMIT and JOIN_COLLAPSE_LIMIT as the variable names. It'd be easy enough to change if someone comes up with better names. You can read updated documentation at http://developer.postgresql.org/docs/postgres/explicit-joins.html 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] Can we revisit the thought of PostgreSQL 7.2.4?
Bruce Momjian <[EMAIL PROTECTED]> writes: > So, do we have non-security fixes to warrant a 7.2.X? There's the order-of-operations-in-checkpoint problem, and there's one variant of the "no one parent tuple was found" problem that should have been patched in 7.2.3, but was overlooked. Also, the bogus-datetime-table-ordering bugs appear to exist in 7.2 (cf. recent complaint about timezone ART not being recognized). That ought to be back-patched, if we're going to make a 7.2.4, though one could certainly say that that doesn't merit a release by itself. I think there's enough to warrant a 7.2.4 ... regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] domain check constraint syntax problem for 7.4
On Sun, Jan 26, 2003 at 00:01:04 -0500, Rod Taylor <[EMAIL PROTECTED]> wrote: > They work the same as table constraints with in-line declaration (no > comma). OK. But the documentation implies there is a comma, so it should probably get chenged then. This is from the create domain documentation: CREATE DOMAIN domainname [AS] data_type [ DEFAULT default_expr ] [ constraint [, ... ] ] I would have expected the last line to be: [ constraint [ ... ] ] if there weren't supposed to be commas. Thanks for the help. ---(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] domain check constraint syntax problem for 7.4
They work the same as table constraints with in-line declaration (no comma). On Sun, 2003-01-26 at 00:09, Bruno Wolff III wrote: > I am trying to create a domain with more than one check constraint and > I am getting an error that I don't think is correct according to the > documentation. I am not sure if this is a limitation of a partially > implemented feature or a bug that has so far been overlooked. > > For example: > area=# create domain test6 as int constraint ack check(value<4); > CREATE DOMAIN > area=# create domain test7 as int constraint ack check(value<4), > area-# constraint ack1 check(value>0); > ERROR: parser: syntax error at or near "," at character 57 > area=# create domain test7 as int check(value<4), check(value>0); > ERROR: parser: syntax error at or near "," at character 42 > > ---(end of broadcast)--- > TIP 6: Have you searched our list archives? > > http://archives.postgresql.org -- Rod Taylor <[EMAIL PROTECTED]> PGP Key: http://www.rbt.ca/rbtpub.asc signature.asc Description: This is a digitally signed message part
[HACKERS] domain check constraint syntax problem for 7.4
I am trying to create a domain with more than one check constraint and I am getting an error that I don't think is correct according to the documentation. I am not sure if this is a limitation of a partially implemented feature or a bug that has so far been overlooked. For example: area=# create domain test6 as int constraint ack check(value<4); CREATE DOMAIN area=# create domain test7 as int constraint ack check(value<4), area-# constraint ack1 check(value>0); ERROR: parser: syntax error at or near "," at character 57 area=# create domain test7 as int check(value<4), check(value>0); ERROR: parser: syntax error at or near "," at character 42 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] [CYGWIN] Have a PG 7.3.1 Windows (cygwin) easy installer... now
mlw wrote: Sorry, I think there was a misunderstanding. What were you looking for? Sorry Mark, I just thought you were busy. Was wondering if you were going to make a project of it somewhere, so we can get things together and have a really decent release for Windows when 7.4 comes out. :) I used inno setup as well. If you want I can send my install script. That would be really cool. :) How did you handle the user and "Log on as a service" aspects of it? :) I thought I was being very forth coming. Yep, you 100% have a really good attitude, that's why I thought you were busy. :) I even help out on the Windows PG console window. Took a look at it, and the three buttons seem permanently greyed out in the download from the WinMaster project. Wasn't sure if it was a configuration issue on my part, or if the code hadn't been fleshed out yet. Interested in making a project on GBorg or something for the "complete Windows installer" as a place to work out of? :-) Regards and best wishes, Justin Clift -- "My grandfather once told me that there are two kinds of people: those who work and those who take the credit. He told me to try to be in the first group; there was less competition there." - Indira Gandhi ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] [CYGWIN] Have a PG 7.3.1 Windows (cygwin) easy installer... now
Sorry, I think there was a misunderstanding. What were you looking for? I used inno setup as well. If you want I can send my install script. I thought I was being very forth coming. I even help out on the Windows PG console window. Justin Clift wrote: Hi everyone, Mark (mlw) put together a PostgreSQL installer for Windows (cygwin version) a little while ago, but he hasn't been responding to requests for feedback regarding it (probably busy). As we're going to be releasing a native Windows version of PostgreSQL 7.4 in a few months, it seems appropriate that we practise first to get the hang of making packages on Windows, plus encourage anyone with graphical talent to make attractive icon's for menu options, etc. Anyway, spent the last two days making a brand new "PostgreSQL 7.3.1 Proof of Concept for Windows Alpha 1" easy-installer (11,161KB) using a product called Inno Setup (very nice) and have a pretty good result. It looks and feels *really* professional, and if people didn't know that it was using cygwin, they'd probably never guess. Am reckoning that the best thing to do for this is to create a project on GBorg of some name, upload it, and everyone who is interested can take it from there. Does that sound like the best approach, and does anyone have good suggestions for a project name? :-) Regards and best wishes, Justin Clift ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
[HACKERS] Have a PG 7.3.1 Windows (cygwin) easy installer... now what to dowith it?
Hi everyone, Mark (mlw) put together a PostgreSQL installer for Windows (cygwin version) a little while ago, but he hasn't been responding to requests for feedback regarding it (probably busy). As we're going to be releasing a native Windows version of PostgreSQL 7.4 in a few months, it seems appropriate that we practise first to get the hang of making packages on Windows, plus encourage anyone with graphical talent to make attractive icon's for menu options, etc. Anyway, spent the last two days making a brand new "PostgreSQL 7.3.1 Proof of Concept for Windows Alpha 1" easy-installer (11,161KB) using a product called Inno Setup (very nice) and have a pretty good result. It looks and feels *really* professional, and if people didn't know that it was using cygwin, they'd probably never guess. Am reckoning that the best thing to do for this is to create a project on GBorg of some name, upload it, and everyone who is interested can take it from there. Does that sound like the best approach, and does anyone have good suggestions for a project name? :-) Regards and best wishes, Justin Clift -- "My grandfather once told me that there are two kinds of people: those who work and those who take the credit. He told me to try to be in the first group; there was less competition there." - Indira Gandhi ---(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] Win32 port patches submitted
Tom Lane wrote: > Peter Eisentraut <[EMAIL PROTECTED]> writes: > > I don't see a strong reason not > > to stick with good old configure; make; make install. You're already > > requiring various Unix-like tools, so you might as well require the full > > shell environment. > > Indeed. I think the goal here is to have a port that *runs* in native > Windows; but I see no reason not to require Cygwin for *building* it. Agreed. I don't mind Cygwin if we don't have licensing problems with distributing a Win32 binary that used Cygwin to build. I do have a problem with MKS toolkit, which is a commerical purchase. I would like to avoid reliance on that, though Jan said he needed their bash. -- 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] Can we revisit the thought of PostgreSQL 7.2.4?
Lamar Owen wrote: > On Saturday 25 January 2003 21:06, Bruce Momjian wrote: > > Lamar Owen wrote: > > > On Saturday 25 January 2003 20:36, Bruce Momjian wrote: > > > > improve the capabilities of the database. For security issues, if we > > > > already have ten open doors in a house, does it help to lock two of > > > > them when the other eight are still open? > > > > Yes. It depends upon which street the door faces. See the MS SQL Server > > > Sapphire worm for reference. > > > Right. All our open doors are on the inside, so we aren't too bad. > > SQL injection exploits for various frontends are also an issue. > > I just have an issue with being able to crash the server with an SQL command. > We'll see how it pans out, I guess. > > Red Hat certainly thought it was worth spending some time on; reference their > back porting of the fixes to versions as old as 6.5.3. If we can get them all, it is a big win. If we can't, I don't think it is a win. -- 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] Can we revisit the thought of PostgreSQL 7.2.4?
On Saturday 25 January 2003 21:06, Bruce Momjian wrote: > Lamar Owen wrote: > > On Saturday 25 January 2003 20:36, Bruce Momjian wrote: > > > improve the capabilities of the database. For security issues, if we > > > already have ten open doors in a house, does it help to lock two of > > > them when the other eight are still open? > > Yes. It depends upon which street the door faces. See the MS SQL Server > > Sapphire worm for reference. > Right. All our open doors are on the inside, so we aren't too bad. SQL injection exploits for various frontends are also an issue. I just have an issue with being able to crash the server with an SQL command. We'll see how it pans out, I guess. Red Hat certainly thought it was worth spending some time on; reference their back porting of the fixes to versions as old as 6.5.3. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] default to WITHOUT OIDS? Possible related problem
Emmanuel Charpentier wrote: > Tom Lane wrote: > > Daniel Kalchev <[EMAIL PROTECTED]> writes: > > > >>If ever this happens, same should be considered for tables created via the > >>SELECT INTO statement. These are in many cases 'temporary' in nature and do > >>not need OIDs (while making much use of the OIDs counter). > > > > > > SELECT INTO does create tables without OIDs, as of 7.3. We've already > > had complaints about that ;-) > > I very recently updated one of my servers to 7.3.1. Various MS tools have > started to give me guff when trying to access views in databases on that > server through ODBC. Especially, MS Query (yes, I have some Excel users > needing that) started complaining that "this table has no OID", which > really means that the ODBC driver complaints that ... > > Is that a side effect of the above problem ? Yes. We think we may have a fix in 7.3.2. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] What goes into the security doc?
Robert Treat wrote: > I'm not sure how adequately these topics are covered elsewhere, but you > should probably provide at least a pointer if not improved information: > > * Should have a mention of the pgcrypto code in contrib. > > * Brain hiccup, but isn't there some type of "password" datatype It is in /contrib as chkpass: Chkpass is a password type that is automatically checked and converted upon entry. It is stored encrypted. To compare, simply compare agains a clear text password and the comparison function will encrypt it before comparing. It also returns an error if the code determines that the password is easily crackable. This is currently a stub that does nothing. I haven't worried about making this type indexable. I doubt that anyone would ever need to sort a file in order of encrypted password. If you precede the string with a colon, the encryption and checking are skipped so that you can enter existing passwords into the field. On output, a colon is prepended. This makes it possible to dump and reload passwords without re-encrypting them. If you want the password (encrypted) without the colon then use the raw() function. This allows you to use the type with things like Apache's Auth_PostgreSQL module. D'Arcy J.M. Cain [EMAIL PROTECTED] The document is a good idea, and the initdb -W item is good too! -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Can we revisit the thought of PostgreSQL 7.2.4?
Lamar Owen wrote: > On Saturday 25 January 2003 20:36, Bruce Momjian wrote: > > improve the capabilities of the database. For security issues, if we > > already have ten open doors in a house, does it help to lock two of them > > when the other eight are still open? > > Yes. It depends upon which street the door faces. See the MS SQL Server > Sapphire worm for reference. Right. All our open doors are on the inside, so we aren't too bad. -- 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] Can we revisit the thought of PostgreSQL 7.2.4?
On Saturday 25 January 2003 20:36, Bruce Momjian wrote: > improve the capabilities of the database. For security issues, if we > already have ten open doors in a house, does it help to lock two of them > when the other eight are still open? Yes. It depends upon which street the door faces. See the MS SQL Server Sapphire worm for reference. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11 ---(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] unquoted special constants
Looks like you got them all. I assume you got those from gram.y. --- Christopher Kings-Lynne wrote: > Hi, > > Is this the complete list of constants that must not be quoted? > > CURRENT_TIME > CURRENT_TIMESTAMP > CURRENT_DATE > LOCAL_TIME > LOCAL_TIMESTAMP > CURRENT_USER > SESSION_USER > USER > > Anything else? (Aside from functions?) > > 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 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] Survey results from the PostgreSQL portal page
Michael Meskes wrote: > On Sun, Jan 19, 2003 at 01:19:03PM -0500, Robert Treat wrote: > > pretty wide feature set (as good as any other open source rdbms afaik) > > plus it's open source, so if we don't have a feature that say oracle has, > > you can pay someone the $10,000+ the oracle license will cost to implement > > it. I've also not seen much FUD on the other issues either. If you can > > Unfortunately it doesn't always work this way. I knew one government > organization that decided to go for Oracle for 500K Euro instead of > adding the missing features (actually almost exclusively PITR). One of > the top arguments I heard was: "I don't believe that free software > community works. Once the developers get a social life or even kids, > they stop working on software." Of course I told him that I still do > work on free software despite having three sons on which he answered: > "Maybe, but I still don't believe it." > > Sad but true. One issue he is probably right about is that more burden is placed on the user for testing/support in open source than in closed source. Of course, open source is usually free, so you can afford to pay for those extras, but they do exist have have to be managed. I bet some companies just want to pay the bill and the yearly support and don't want to deal with the extra burden, even if it saves them money. -- 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] Can we revisit the thought of PostgreSQL 7.2.4?
Neil Conway wrote: > On Thu, 2003-01-16 at 22:47, Justin Clift wrote: > > Over the last few days we've had patches submitted for 7.2.3 that > > address a couple of things, both the WAL Recovery Bug that Tom has > > developed a patch for, and a couple of buffer overflows that have been > > widely reported. > > The buffer overflows, IMHO, are not sufficient reason to release an > update. As Tom pointed out, there are lots of other, unpatched overflows > in 7.2.3 (and the whole class of vulnerability requires SQL access to > begin with). > > As for the "WAL recovery bug", AFAIK no such bug has been reported "in > the last few days". Exactly what issue are you referring to? Let's look at the issue here --- I think security fixes are of a different class from corruption bugs or functionality bugs. For the latter, fixing those fixes actual problems in the server that actually improve the capabilities of the database. For security issues, if we already have ten open doors in a house, does it help to lock two of them when the other eight are still open? I don't see any improvement in the functionality of PostgreSQL in such a case, while feature/corruption fixes _do_ improve the backend code. I think we have to accept the statement that in 7.2.X malicious SQL queries can cause database failure, and fixing one or two of the ten known problems doesn't change that fact. I don't have a problem with releasing 7.2.4 and including all the fixes, including security fixes, but I don't see the security fixes _as_ _a_ _reason_ to release a 7.2.4. So, do we have non-security fixes to warrant a 7.2.X? -- 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] IPv6 patch
OK, at your suggestion, IPv6 addresses will appear in pg_hba.conf, even if we don't support IPv6. However, the server log messages stating an IPv6 socket was not made is only printed if the binary supports IPv6. The message seems to be a compromise between those who wanted a separate IPv6 GUC/flag and those who wanted it to silently fail on IPv6. --- Peter Eisentraut wrote: > Bruce Momjian writes: > > > OK, you mentioned you want to put IPv6 addresses in pg_hba.conf even if > > the OS doesn't support it. How do others feel about that. > > We do leave the "local" in there even if the OS doesn't support it. > > -- > Peter Eisentraut [EMAIL PROTECTED] > > > ---(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 Index: src/backend/Makefile === RCS file: /cvsroot/pgsql-server/src/backend/Makefile,v retrieving revision 1.92 diff -c -c -r1.92 Makefile *** src/backend/Makefile7 Jan 2003 15:12:17 - 1.92 --- src/backend/Makefile26 Jan 2003 01:17:32 - *** *** 132,145 endif endif $(MAKE) -C catalog install-data - ifdef HAVE_IPV6 $(INSTALL_DATA) $(srcdir)/libpq/pg_hba.conf.sample $(DESTDIR)$(datadir)/pg_hba.conf.sample - else - grep -v '^host.*::1.*:::::' \ - $(srcdir)/libpq/pg_hba.conf.sample \ - > $(srcdir)/libpq/pg_hba.conf.sample.no_ipv6 - $(INSTALL_DATA) $(srcdir)/libpq/pg_hba.conf.sample.no_ipv6 $(DESTDIR)$(datadir)/pg_hba.conf.sample - endif $(INSTALL_DATA) $(srcdir)/libpq/pg_service.conf.sample $(DESTDIR)$(datadir)/pg_service.conf.sample $(INSTALL_DATA) $(srcdir)/libpq/pg_ident.conf.sample $(DESTDIR)$(datadir)/pg_ident.conf.sample $(INSTALL_DATA) $(srcdir)/utils/misc/postgresql.conf.sample $(DESTDIR)$(datadir)/postgresql.conf.sample --- 132,138 *** *** 191,199 rm -f postgres$(X) $(POSTGRES_IMP) \ $(top_srcdir)/src/include/parser/parse.h \ $(top_builddir)/src/include/utils/fmgroids.h - ifndef HAVE_IPV6 - rm -f $(srcdir)/libpq/pg_hba.conf.sample.no_ipv6 - endif ifeq ($(PORTNAME), win) rm -f postgres.dll postgres.def libpostgres.a endif --- 184,189 ---(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] copying perms to another user
Added to TODO: * Add group object ownership, so groups can rename/drop/grant on objects, so we can implement roles --- Peter Eisentraut wrote: > Bruce Momjian writes: > > > I think the one missing item mentioned was for group ownership of an > > object. However, if we give group _permission_ to the object, I am not > > sure why ownership is an issue. Are there certain permission we can't > > give to the group? > > Privilege to rename or drop the object, and the right to grant privileges > in the first place. > > -- > Peter Eisentraut [EMAIL PROTECTED] > > > ---(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 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
[HACKERS] interactive docs error
Warning: pg_connect() unable to connect to PostgreSQL server: FATAL 1: Sorry, too many clients already in /usr/local/www/www.postgresql.org/idocs/opendb.php on line 3 Unable to access database -- Dave Cramer <[EMAIL PROTECTED]> Cramer Consulting ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] WAL replay logic (was Re: [PERFORM] Mount options for Ext3?)
Curt Sampson <[EMAIL PROTECTED]> writes: > On Sat, 25 Jan 2003, Tom Lane wrote: >> We'd have to take it on faith that we should replay the visible files >> in their name order. > Couldn't you could just put timestamp information at the beginning if > each file, Good thought --- there's already an xlp_pageaddr field on every page of WAL, and you could examine that to be sure it matches the file name. If not, the file csn be ignored. regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] WAL replay logic (was Re: [PERFORM] Mount options for Ext3?)
Tom Lane wrote: > Kevin Brown <[EMAIL PROTECTED]> writes: > > One question I have is: in the event of a crash, why not simply replay > > all the transactions found in the WAL? Is the startup time of the > > database that badly affected if pg_control is ignored? > > Interesting thought, indeed. Since we truncate the WAL after each > checkpoint, seems like this approach would no more than double the time > for restart. Hmm...truncating the WAL after each checkpoint minimizes the amount of disk space eaten by the WAL, but on the other hand keeping older segments around buys you some safety in the event that things get really hosed. But your later comments make it sound like the older WAL segments are kept around anyway, just rotated. > The win is it'd eliminate pg_control as a single point of > failure. It's always bothered me that we have to update pg_control on > every checkpoint --- it should be a write-pretty-darn-seldom file, > considering how critical it is. > > I think we'd have to make some changes in the code for deleting old > WAL segments --- right now it's not careful to delete them in order. > But surely that can be coped with. Even that might not be necessary. See below. > OTOH, this might just move the locus for fatal failures out of > pg_control and into the OS' algorithms for writing directory updates. > We would have no cross-check that the set of WAL file names visible in > pg_xlog is sensible or aligned with the true state of the datafile > area. Well, what we somehow need to guarantee is that there is always WAL data that is older than the newest consistent data in the datafile area, right? Meaning that if the datafile area gets scribbled on in an inconsistent manner, you always have WAL data to fill in the gaps. Right now we do that by using fsync() and sync(). But I think it would be highly desirable to be able to more or less guarantee database consistency even if fsync were turned off. The price for that might be too high, though. > We'd have to take it on faith that we should replay the visible files > in their name order. This might mean we'd have to abandon the current > hack of recycling xlog segments by renaming them --- which would be a > nontrivial performance hit. It's probably a bad idea for the replay to be based on the filenames. Instead, it should probably be based strictly on the contents of the xlog segment files. Seems to me the beginning of each segment file should have some kind of header information that makes it clear where in the scheme of things it belongs. Additionally, writing some sort of checksum, either at the beginning or the end, might not be a bad idea either (doesn't have to be a strict checksum, but it needs to be something that's reasonably likely to catch corruption within a segment). Do that, and you don't have to worry about renaming xlog segments at all: you simply move on to the next logical segment in the list (a replay just reads the header info for all the segments and orders the list as it sees fit, and discards all segments prior to any gap it finds. It may be that you simply have to bail out if you find a gap, though). As long as the xlog segment checksum information is consistent with the contents of the segment and as long as its transactions pick up where the previous segment's left off (assuming it's not the first segment, of course), you can safely replay the transactions it contains. I presume we're recycling xlog segments in order to avoid file creation and unlink overhead? Otherwise you can simply create new segments as needed and unlink old segments as policy dictates. > Comments anyone? > > > If there exists somewhere a reasonably succinct description of the > > reasoning behind the current transaction management scheme (including > > an analysis of the pros and cons), I'd love to read it and quit > > bugging you. :-) > > Not that I know of. Would you care to prepare such a writeup? There > is a lot of material in the source-code comments, but no coherent > presentation. Be happy to. Just point me to any non-obvious source files. Thus far on my plate: 1. PID file locking for postmaster startup (doesn't strictly need to be the PID file but it may as well be, since we're already messing with it anyway). I'm currently looking at how to do the autoconf tests, since I've never developed using autoconf before. 2. Documenting the transaction management scheme. I was initially interested in implementing the explicit JOIN reordering but based on your recent comments I think you have a much better handle on that than I. I'll be very interested to see what you do, to see if it's anything close to what I figure has to happen... -- Kevin Brown [EMAIL PROTECTED] ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/doc
Re: [HACKERS] WAL replay logic (was Re: [PERFORM] Mount options for Ext3?)
On Sat, 25 Jan 2003, Tom Lane wrote: > We'd have to take it on faith that we should replay the visible files > in their name order. Couldn't you could just put timestamp information at the beginning if each file, (or perhaps use that of the first transaction), and read the beginning of each file to find out what order to run them in. Perhaps you could even check the last transaction in each file as well to see if there are "holes" between the available logs. > This might mean we'd have to abandon the current > hack of recycling xlog segments by renaming them --- which would be a > nontrivial performance hit. Rename and write a "this is an empty logfile" record at the beginning? Though I don't see how you could do this in an atomic manner Maybe if you included the filename in the WAL file header, you'd see that if the name doesn't match the header, it's a recycled file (This response sent only to hackers.) cjs -- Curt Sampson <[EMAIL PROTECTED]> +81 90 7737 2974 http://www.netbsd.org Don't you know, in this new Dark Age, we're all light. --XTC ---(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
