[HACKERS] Input Function (domain_in) Call
Hi, I was using OidInputFunctionCall() to cast a basic type into a domain type. But when I saw /* * As above, for I/O functions identified by OID. These are only to be * used in seldom-executed code paths. They are not only slow but leak * memory. */ Datum OidInputFunctionCall(Oid functionId, char *str, Oid typioparam, int32 typmod) comment in backend/utils/fmgr/fmgr.c, I started to consider my decision. Is this the right way to use domain_in() function? Which way would you suggest? Or is there a totally different way to accomplish basic type to domain transition? Regards. ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Windows 2000 Support
Peter Eisentraut wrote: > Magnus Hagander wrote: > > Yeah, that's better wording. Or more correct I think "Windows 2000 > > SP4 or above". > > > > FWIW, MS has officially said at some point that they will not make > > SP5 for Windows 2000, but they've changed their minds before... > > Unless there actually is a version of that operating system that is not > labelled "Windows 2000 SP4" that is supported, this expression is > meaningless. > > Note that the list of "supported" platforms in the documentation does > not make any open interval claims (or any interval claims for that > matter). > > If you know that anything before Windows 2000 SP4 is unsupported, that > would be useful information, but not the other way around. I see who mentions of Win2000, one in the FAQ, another in the release notes. If people want the text changed, I want an example showing exactly what the new wording should be because you can't just add "and later" into the text we have now. -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] [PATCHES] selecting large result sets in psql using
David Fetter wrote: > On Fri, Aug 18, 2006 at 10:16:12AM -0400, Tom Lane wrote: > > Peter Eisentraut <[EMAIL PROTECTED]> writes: > > > A \set variable would make sense to me. > > > > So Peter and Bruce like a \set variable, Chris and I like a > > different command. Seems like a tie ... more votes out there > > anywhere? > > It seems to me that a \set variable lets people use minimal > intrusiveness on scripts, etc., as they'll just set it when they start > needing cursor-ized result sets and unset it when finished. True. They could even put it in .psqlrc if they want. Basically need a way to modify \g. Seems a \set is the way we have always done such modifications in the past. The big question is whether this is somehow different. Personally, I don't think so. -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] [PATCHES] Information_schema fixes for sequences and temporary tables
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 > I'd be interested to see you cite chapter and verse in the SQL spec > where it says that information_schema should hide temp tables of > other backends. That change seems pretty dubious to me. (More > likely, we should be adding tests on whether the caller has USAGE > privilege on the table's containing schema.) Fair point: what brought this about was someone wondering why a SELECT 1 FROM information_schema.tables WHERE table_name = 'mytemptable' returned true but a subsequent DROP TABLE mytemptable; failed. Another subtle difference between \d and i_s.tables I suppose. It all depends on how one interprets "accessible" here: Function: [of information_schema.tables] Identify the tables defined in this catalog that are accessible to a given user or role. While I might extend "accessible" to schemas outside of a user's search path, I'm not sure that should include the pg_temp_ ones. Seems confusing for the user to see other temp tables, even if the schema is returned, as one does not specify a schema when creating temp tables. +1 on the USAGE idea. > As for all that ESCAPE junk, consider using regexps instead; they > play nicer with underscores in patterns. Hmph. I was just copying the surrounding code, in the theory that it increases the chance of my patches being accepted. :) - -- Greg Sabino Mullane [EMAIL PROTECTED] End Point Corporation PGP Key: 0x14964AC8 200608182237 http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8 -BEGIN PGP SIGNATURE- iD8DBQFE5n7EvJuQZxSWSsgRAr9UAKDSXYExsVwsYazS1ygaOCmsudGVpwCeKPHj 1g/fpDkpDdfOr9eGQzr3M9U= =9QRx -END PGP SIGNATURE- ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: BugTracker (Was: Re: [HACKERS] 8.2 features status)
So, the question is whether any of our biggest bug-fixers would dig in their heels and scream "No!" if we gave BugZilla a try. Comments? I could have this setup this weekend should we vote YES :) Joshua D. Drake ---(end of broadcast)--- TIP 1: 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] [PATCHES] Information_schema fixes for sequences and temporary tables
Greg Sabino Mullane <[EMAIL PROTECTED]> writes: > More to come, but these two are probably worth backpatching. We can't really backpatch changes to information_schema, since we can't force initdb in back branches. I'd be interested to see you cite chapter and verse in the SQL spec where it says that information_schema should hide temp tables of other backends. That change seems pretty dubious to me. (More likely, we should be adding tests on whether the caller has USAGE privilege on the table's containing schema.) As for all that ESCAPE junk, consider using regexps instead; they play nicer with underscores in patterns. regards, tom lane ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] Windows 2000 Support
Magnus Hagander wrote: > Yeah, that's better wording. Or more correct I think "Windows 2000 > SP4 or above". > > FWIW, MS has officially said at some point that they will not make > SP5 for Windows 2000, but they've changed their minds before... Unless there actually is a version of that operating system that is not labelled "Windows 2000 SP4" that is supported, this expression is meaningless. Note that the list of "supported" platforms in the documentation does not make any open interval claims (or any interval claims for that matter). If you know that anything before Windows 2000 SP4 is unsupported, that would be useful information, but not the other way around. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] [PATCHES] plpython improvements
Tom Lane wrote: > Anyone in a position to review the pending plpython patch? > http://archives.postgresql.org/pgsql-patches/2006-08/msg00151.php > > After that little fiasco with plperl I'm disinclined to apply anything > without review by somebody who's pretty familiar with the PL in > question ... and Python's not my language. > > does it have docs? cheers andrew ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] [PATCHES] plpython improvements
On Fri, Aug 18, 2006 at 04:27:23PM -0400, Tom Lane wrote: > Anyone in a position to review the pending plpython patch? > http://archives.postgresql.org/pgsql-patches/2006-08/msg00151.php In several places the code does this: so = PyObject_Str(value); valuestr = PyString_AsString(so); We've previously learned that calling PyString_AsString() without checking the return value of PyObject_Str() can result in a segmentation fault. http://archives.postgresql.org/pgsql-committers/2005-07/msg00233.php I haven't examined the current patch closely enough to know whether PyObject_Str() can possibly return NULL, but several occurrences of the above code snippet caught my eye because we had dealt with it before. -- Michael Fuhr ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: BugTracker (Was: Re: [HACKERS] 8.2 features status)
All, I chatted some with some of the Debian folks who maintain Debbugs. They thought it would take a significant amount of work to adapt it to PostgreSQL, in addition to the obvious needs to improve the web interface. RT has some significant short comings for our project such as not having good support for tying bugs to versions etc. As people have pointed out, it's a "Request Tracker", not necessarily a Bug Tracker. On the other hand, a lot of my personal dislike of BugZilla seems to be based on being forced to use old versions. A lot of the stuff I hate about it has been fixed in the current version. So, the question is whether any of our biggest bug-fixers would dig in their heels and scream "No!" if we gave BugZilla a try. Comments? -- --Josh Josh Berkus PostgreSQL @ Sun San Francisco ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] [PATCHES] plpython improvements
Anyone in a position to review the pending plpython patch? http://archives.postgresql.org/pgsql-patches/2006-08/msg00151.php After that little fiasco with plperl I'm disinclined to apply anything without review by somebody who's pretty familiar with the PL in question ... and Python's not my language. regards, tom lane ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] pg_dump schema breakup
Andrew Dunstan <[EMAIL PROTECTED]> writes: > Well, the other issue is how many canned breakup schemes we are going to > support. If this particular one is of sufficiently general usefulness > then I have no objection. But when you can produce it trivially from the > output of "pg_dump -s", the need to hardcode it hardly seems pressing. FWIW, I am in favor of providing a way to break up the dump output like this, I was merely objecting to the vocabulary ;-). We have certainly seen tons of people burnt by the performance problems inherent in separate-data-and-schema restores, and splitting the dump into three parts instead of two seems like it would fix that. But I also like Alvaro's comment that this should be on the restore side not so much the dump side. If you do two or three successive pg_dump runs to make your dump then you run a nontrivial risk of not getting consistent dumps. My advice to people would be to do *one* full "pg_dump -Fc" and then extract three scripts out of that. The question then is whether it's worth providing the extraction functionality in a more canned, user-friendly form than "here, hack up the -L output with this perl script". I'd vote yes. regards, tom lane ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] pg_dump schema breakup
Alvaro Herrera wrote: Andrew Dunstan wrote: Joshua D. Drake wrote: I think what you may really be after is "the stuff that should be loaded before inserting data" and "the stuff that should be loaded after", but the above are poor names for these concepts. But it certainly would be nice to be able to dump all that "stuff":-) Yea, I've been told that this would not be a high demand feature. So do I have a second vote? ;-) The ability to have a dump that automatically separated the before-data and after-data objects is definitely useful. The amount of times I have had to dump the schema and data separately just so I can modify the schema before restore, or disable some function that is causing problems can not even be counted. We already have a highly selective and configurable restore mechanism, using the -L feature of pg_restore. Maybe there's a good special case for this particular split, but it is hardly undoable now. As for Naz' needs - I gave him a perl script I whipped up in few minutes to do the split he wanted - and I'm sure you could do the same in python ;-) Maybe what we need is a program to process the object list from pg_restore -L. Or a mode in pg_restore, "from this dump give me all the sutff to be loaded before inserting data", and the reverse. I mean, should the problem be attacked while dumping, or while restoring? Well, the other issue is how many canned breakup schemes we are going to support. If this particular one is of sufficiently general usefulness then I have no objection. But when you can produce it trivially from the output of "pg_dump -s", the need to hardcode it hardly seems pressing. cheers andrew ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] libpq Describe Extension [WAS: Bytea and perl]
Volkan YAZICI <[EMAIL PROTECTED]> writes: > I've prepared a new patch that adds below commands to the libpq: > /* Accessor functions for PGresParamDesc field of PGresult. */ > int PQnparams(const PGresult *res) > int PQparamType(const PGresult *res, int param_num) > /* Async functions. */ > int PQsendDescribePrepared(PGconn *conn, const char *stmt) > int PQsendDescribePortal(PGconn *conn, const char *portal) > /* Synchronous ones. */ > PGresult *PQdescribePrepared(PGconn *conn, const char *stmt) > PGresult *PQdescribePortal(PGconn *conn, const char *portal) Applied with some small revisions to make it fit in better with the existing libpq code (I don't think it desirable to have copied-and-pasted versions of PQsendQueryStart, for instance). I added some documentation also. regards, tom lane ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] pg_dump schema breakup
Andrew Dunstan wrote: > Joshua D. Drake wrote: > > > I think what you may really be after is "the stuff that should be > loaded > before inserting data" and "the stuff that should be loaded after", > but > the above are poor names for these concepts. > > >>> > >>>But it certainly would be nice to be able to dump all that "stuff":-) > >>Yea, I've been told that this would not be a high demand feature. So > >>do I have a second vote? ;-) > > > >The ability to have a dump that automatically separated the > >before-data and after-data objects is definitely > >useful. The amount of times I have had to dump the schema and data > >separately just so I can modify the > >schema before restore, or disable some function that is causing > >problems can not even be counted. > > > > We already have a highly selective and configurable restore mechanism, > using the -L feature of pg_restore. Maybe there's a good special case > for this particular split, but it is hardly undoable now. > > As for Naz' needs - I gave him a perl script I whipped up in few minutes > to do the split he wanted - and I'm sure you could do the same in python ;-) Maybe what we need is a program to process the object list from pg_restore -L. Or a mode in pg_restore, "from this dump give me all the sutff to be loaded before inserting data", and the reverse. I mean, should the problem be attacked while dumping, or while restoring? -- Alvaro Herrerahttp://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] pg_dump schema breakup
Andrew Dunstan wrote: We already have a highly selective and configurable restore mechanism, using the -L feature of pg_restore. Maybe there's a good special case for this particular split, but it is hardly undoable now. As for Naz' needs - I gave him a perl script I whipped up in few minutes to do the split he wanted - and I'm sure you could do the same in python ;-) cheers andrew And very appreciative I am too. While I concede it is doable now, and I could do this in Python as well, I do feel that a feature like this would have wider use than may be apparent on a first glance. Furthermore, I think that the simplicity of implementing it makes it really a question of "why not" rather than "why". - Naz ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Windows 2000 Support
-Original Message- From: Magnus Hagander [mailto:[EMAIL PROTECTED] Sent: Fri 8/18/2006 12:46 PM To: Dave Page; pgsql-hackers@postgresql.org Subject: RE: [HACKERS] Windows 2000 Support > (btw, clinically insane without patching it.. And obviously you didn't > patch yours? :-P) Yeah, well it's behind all manner of firewalls, doing nothing but buildfarm runs of which I ran the first before WSUS had installed all the pending updates :-p /D ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] pg_dump schema breakup
Joshua D. Drake wrote: I think what you may really be after is "the stuff that should be loaded before inserting data" and "the stuff that should be loaded after", but the above are poor names for these concepts. But it certainly would be nice to be able to dump all that "stuff":-) Yea, I've been told that this would not be a high demand feature. So do I have a second vote? ;-) The ability to have a dump that automatically separated the before-data and after-data objects is definitely useful. The amount of times I have had to dump the schema and data separately just so I can modify the schema before restore, or disable some function that is causing problems can not even be counted. We already have a highly selective and configurable restore mechanism, using the -L feature of pg_restore. Maybe there's a good special case for this particular split, but it is hardly undoable now. As for Naz' needs - I gave him a perl script I whipped up in few minutes to do the split he wanted - and I'm sure you could do the same in python ;-) cheers andrew ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] pg_dump schema breakup
I think what you may really be after is "the stuff that should be loaded before inserting data" and "the stuff that should be loaded after", but the above are poor names for these concepts. But it certainly would be nice to be able to dump all that "stuff":-) Yea, I've been told that this would not be a high demand feature. So do I have a second vote? ;-) The ability to have a dump that automatically separated the before-data and after-data objects is definitely useful. The amount of times I have had to dump the schema and data separately just so I can modify the schema before restore, or disable some function that is causing problems can not even be counted. Sincerely, Joshua D. Drake ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] pg_dump schema breakup
Andreas Joseph Krogh wrote: On Friday 18 August 2006 18:52, Tom Lane wrote: Naz Gassiep <[EMAIL PROTECTED]> writes: I propose that two more be added: --tables-only --constraints-only This doesn't seem well-defined at all. There are many objects in a database that are definitely neither tables nor constraints, and it's not very clear what things should be considered constraints either. I think what you may really be after is "the stuff that should be loaded before inserting data" and "the stuff that should be loaded after", but the above are poor names for these concepts. But it certainly would be nice to be able to dump all that "stuff":-) Yea, I've been told that this would not be a high demand feature. So do I have a second vote? ;-)
Re: [HACKERS] pg_dump schema breakup
On Friday 18 August 2006 18:52, Tom Lane wrote: > Naz Gassiep <[EMAIL PROTECTED]> writes: > > I propose that two more be added: > > --tables-only > > --constraints-only > > This doesn't seem well-defined at all. There are many objects in a > database that are definitely neither tables nor constraints, and it's > not very clear what things should be considered constraints either. > > I think what you may really be after is "the stuff that should be loaded > before inserting data" and "the stuff that should be loaded after", but > the above are poor names for these concepts. But it certainly would be nice to be able to dump all that "stuff":-) -- Andreas Joseph Krogh <[EMAIL PROTECTED]> Senior Software Developer / Manager gpg public_key: http://dev.officenet.no/~andreak/public_key.asc +-+ OfficeNet AS| The most difficult thing in the world is to | Karenslyst Allé 11 | know how to do a thing and to watch | PO. Box 529 Skøyen | somebody else doing it wrong, without | 0214 Oslo | comment.| NORWAY | | Mobile: +47 909 56 963 | | +-+ ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] [PATCHES] selecting large result sets in psql using
On Fri, Aug 18, 2006 at 10:16:12AM -0400, Tom Lane wrote: > Peter Eisentraut <[EMAIL PROTECTED]> writes: > > A \set variable would make sense to me. > > So Peter and Bruce like a \set variable, Chris and I like a > different command. Seems like a tie ... more votes out there > anywhere? It seems to me that a \set variable lets people use minimal intrusiveness on scripts, etc., as they'll just set it when they start needing cursor-ized result sets and unset it when finished. Just my $.02 :) Cheers, D -- David Fetter <[EMAIL PROTECTED]> http://fetter.org/ phone: +1 415 235 3778AIM: dfetter666 Skype: davidfetter Remember to vote! ---(end of broadcast)--- TIP 1: 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] Windows 2000 Support
> > I am worried that saying required means it only works for that > > version, while it might work for SP5 if that is ever released. > > > How about: > > Windows 2000 SP4 and above required. Yeah, that's better wording. Or more correct I think "Windows 2000 SP4 or above". FWIW, MS has officially said at some point that they will not make SP5 for Windows 2000, but they've changed their minds before... > I know it seems trivial, but the amount of people that run > windows I really don't want to spend a ton of time with > the question: I see that Sp4 is supported, what about SP3? :) Well, SP3 isn't supported ;-) //Magnus ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] pg_dump schema breakup
Tom Lane wrote: Naz Gassiep <[EMAIL PROTECTED]> writes: I propose that two more be added: --tables-only --constraints-only This doesn't seem well-defined at all. There are many objects in a database that are definitely neither tables nor constraints, and it's not very clear what things should be considered constraints either. I think what you may really be after is "the stuff that should be loaded before inserting data" and "the stuff that should be loaded after", but the above are poor names for these concepts. regards, tom lane And here I was thinking that I'd been clear :) But yes, you are right, what I want is "the stuff that gets loaded before data insertion" and "the stuff that goes after data insertion" Essentially, the CREATE TABLE statements are the first part as that is what is needed for data to be inserted. Everything else is the second part.
Re: [HACKERS] pg_dump schema breakup
Naz Gassiep <[EMAIL PROTECTED]> writes: > I propose that two more be added: > --tables-only > --constraints-only This doesn't seem well-defined at all. There are many objects in a database that are definitely neither tables nor constraints, and it's not very clear what things should be considered constraints either. I think what you may really be after is "the stuff that should be loaded before inserting data" and "the stuff that should be loaded after", but the above are poor names for these concepts. regards, tom lane ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
[HACKERS] pg_dump schema breakup
This is my first post to a PostgreSQL mailing list, so please forgive me if I have posted to the wrong place Currently pg_dump has flags for dumping only table definitions and/or data. These flags are respectively: --schema-only --data-only I propose that two more be added: --tables-only --constraints-only These would essentially break up the output of --schema-only into two sections. I.e., the output of --tables-only plus the output of --constraints-only would be identical to the output of --schema-only . There are a number of scenarios where this may be useful, I will describe the one that I would use it for. When making changes to my database schema I would like to take the schema from the newly modified database, and dump the data from the old database into it to ensure that the new schema is able to take the data that exists in the live database. If it isn't then I modify the new schema or the live dataset as appropriate, and try again. This requires the following steps: 1. Create temporary database and apply modified schema to it 2. Dump new database using --schema-only 3. Split new schema into table definitions and constraints 4. Apply new schema table definitions from step 34 to the testing database 5. Dump the existing database using --data-only 6. Apply the dataset from step 5 to the testing database 7. Apply new schema constraints from step 3 to the testing database All of these steps are easily scriptable except step 3, which means that making quick changes to the new schema and re-applying includes the tedious task of opening the 5,000 line schema file in a text editor and manually pasting the relevant sections into new files. Step 3 really does hold up the development process with regards to testing changes to the schema. Generalizing the nature of this task, the pg_dump features I propose would allow the easy scripting of dumping databases, making changes to the dumps and then re-applying them in a non paradox-inducing order. FWIW I thought this would be a very simple patch, and had a look at the code for pg_dump myself, despite the fact that I've not even written a Hello World in C as yet. That attempt failed miserably, so now I am reduced to selling the merits of this idea to real developers. Incidentally, --schema-only appears to break tables and constraints into two sections already, as evidenced by the fact that all tables are created first, and constraints afterwards. ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] find the template of a database in SQL
> When I have a table that I don't know if it inherits from template 1, > how can I find the 'super' ? I do not believe that tables have templates in 7.4 unless you specifically use a query like: create table foo as select * from bar; I think Walter wants to know if a given table was defined in the current database, or if it was created from the template database (template0 or template1) when the database was created. I don't think you can tell. When you create a new database from a template (typically template1), you're just making a copy of that template. It's not really inheritance (meaning that a change to the table definition in the template won't affect any databases "cloned" from that template). To find out where the table came from, you'd have to know which template your current database was cloned from and I don't think we store that info anywhere. -- Korry -- Korry Douglas [EMAIL PROTECTED] EnterpriseDB http://www.enterprisedb.com
Re: [HACKERS] find the template of a database in SQL
"Walter Cruz" <[EMAIL PROTECTED]> writes: > well, when I create a database, it inherits from template1 > When I have a table that I don't know if it inherits from template 1, > how can I find the 'super' ? There isn't any persistent "inheritance" relationship for databases. CREATE DATABASE just copies the source database at the instant of creation, and that's the end of it. regards, tom lane ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] find the template of a database in SQL
Walter Cruz wrote: well, when I create a database, it inherits from template1 When I have a table that I don't know if it inherits from template 1, how can I find the 'super' ? I do not believe that tables have templates in 7.4 unless you specifically use a query like: create table foo as select * from bar; Joshua D. Drake []'s - Walter On 8/18/06, Joshua D. Drake <[EMAIL PROTECTED]> wrote: Walter Cruz wrote: > Hi all.. > > There's some way to find the template of a database in SQL (using 7.4)? Find the template? Could you clarify your question? > > []'s > - Walter > > ---(end of broadcast)--- > TIP 1: if posting/reading through Usenet, please send an appropriate > subscribe-nomail command to [EMAIL PROTECTED] so that your > message can get through to the mailing list cleanly > ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] find the template of a database in SQL
well, when I create a database, it inherits from template1 When I have a table that I don't know if it inherits from template 1, how can I find the 'super' ? []'s - Walter On 8/18/06, Joshua D. Drake <[EMAIL PROTECTED]> wrote: Walter Cruz wrote: > Hi all.. > > There's some way to find the template of a database in SQL (using 7.4)? Find the template? Could you clarify your question? > > []'s > - Walter > > ---(end of broadcast)--- > TIP 1: if posting/reading through Usenet, please send an appropriate > subscribe-nomail command to [EMAIL PROTECTED] so that your > message can get through to the mailing list cleanly > ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] find the template of a database in SQL
Walter Cruz wrote: Hi all.. There's some way to find the template of a database in SQL (using 7.4)? Find the template? Could you clarify your question? []'s - Walter ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] Windows 2000 Support
I am worried that saying required means it only works for that version, while it might work for SP5 if that is ever released. How about: Windows 2000 SP4 and above required. I know it seems trivial, but the amount of people that run windows I really don't want to spend a ton of time with the question: I see that Sp4 is supported, what about SP3? :) It is bad enough we answer the question: So how does PostgreSQL compare with MySQL 5000 times every time we go to a show ;) Joshua D. Drake ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Windows 2000 Support
Joshua D. Drake wrote: > Bruce Momjian wrote: > > > > I have updated the 8.0 release notes to say Windows 2000SP4 supported. > > > > > Not to nitpick, but I think you should change supported to *required*. I am worried that saying required means it only works for that version, while it might work for SP5 if that is ever released. -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] Windows 2000 Support
Bruce Momjian wrote: I have updated the 8.0 release notes to say Windows 2000SP4 supported. Not to nitpick, but I think you should change supported to *required*. Sincerely, Joshua D. Drake ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Windows 2000 Support
Magnus Hagander wrote: > > Hi, > > > > I just finished setting up a new buildfarm member (Bandicoot) > > running Windows 2000 Pro. Aside from the fact that it now fails > > with the same cyptic pg_regress error as seen on Snake, it also > > became apparent that CVS HEAD won't run properly on an unpatched > > Windows 2000 (initdb - and probably pg_ctl - fails when trying to > > dynamically load advapi32.dll which is used to shed excess > > privileges). This was solved by the installation of service pack 4. > > Unfortunately I couldn't find a way to catch the error - it seems > > to kill the app and throw a messagebox with a cryptic message. > > > > Given that you have to be clinically insane to run Win2K without > > patching it to the hilt I'm not overly concerned by this (and will > > add appropriate checks to pgInstaller), but it's probably worth > > mentioning that our minimum supported platform is Windows 2000 Pro > > with Service Pack 4 from 8.2. > > Late into the game, yes, I definitely think this is a reasonable > requirement. (FWIW, that's the same requirements as MS put on SQL > Server) > > But yes, this should probably go in the release notes. I have updated the 8.0 release notes to say Windows 2000SP4 supported. -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 1: 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] find the template of a database in SQL
Hi all.. There's some way to find the template of a database in SQL (using 7.4)? []'s - Walter ---(end of broadcast)--- TIP 1: 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] installcheck-parallel
Andrew Dunstan wrote: > Andrew Dunstan wrote: > > > > I see that the installcheck-parallel was not added to the top level > > Makefile and Gnumakefile.in when it was added as a regression test > > target back in the 8.0 cycle. Is there any objection to my adding it > > now so that it is treated the same as the other regression test > > targets? If so, should I add it just to HEAD, or backpatch it to 8.0 > > and 8.1? (Reasoning: I got confused for a few seconds and thought > > maybe I had mistyped the target name, before I realised what was > > wrong, but others less familiar than I am with the testing structure > > might well get rather more confused.) > > > > I didn't get any response to this so I'm going to add this and back port > it, since the risk factor is pretty well zero, and I suspect it was just > an inadvertent omission a couple of years ago. Agreed. -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] "cache reference leak" and "problem in alloc set" warnings
Volkan YAZICI <[EMAIL PROTECTED]> writes: > Looks like my palloc() math was correct. Just I had missed special > handling of attnulls array passed to heap_formtuple(). It had should be > attnulls[i] = (isnull) ? 'n' : ' '; These days I'd use heap_form_tuple in new code --- then you can work with plain bool isnull flags instead of that weird 'n'/' ' convention. regards, tom lane ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] BF Failure on Bandicoot
>>> The procedure entry point ldap_start_tls_sA could not be located in the >>> dynamic link library wldap32.dll. >> >> I'd counsel just leaving --with-ldap off until Magnus gets back >> from vacation. We can always revert the patch later if he can't >> fix it. > > Looking at the MSDN documentation it seems this function only > exists on > Windows 2003 and Windows XP. Which is very interesting, because I have > it working on one of my 2000 boxes. But I guess I got it through some > patch or other. > > I'm going to have to redo it to dynamically load that > function and exit > with a proper error message if it's not found. Shouldn't be too hard, > I'll get to it as soon as I can get down for a coding session. On my Windows 2000 (5.00.2195) Service Pack 4, the LDAP library does not contain any ldap_start_tls* File version of WLDAP32.DLL is 5.0.2195.7017. Yours, Laurenz Albe ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] "cache reference leak" and "problem in alloc set" warnings
On Aug 17 10:38, Tom Lane wrote: > Volkan YAZICI <[EMAIL PROTECTED]> writes: > > I've still biten by a single "write past chunk" error while returning a > > record in PL/scheme: > > > WARNING: problem in alloc set ExprContext: detected write past chunk > > end in block 0x84a0598, chunk 0x84a0c84 > > The actual bug, almost certainly, is that you're miscomputing the space > needed for a variable-size palloc request. But tracking that down will > be hard until you find out which chunk it is. Looks like my palloc() math was correct. Just I had missed special handling of attnulls array passed to heap_formtuple(). It had should be attnulls[i] = (isnull) ? 'n' : ' '; > Do you have a sequence that will make the problem happen consistently at > the same address? If so, you can use a gdb watchpoint to find out where > the write-past-end is happening. Or use a conditional breakpoint in > AllocSetAlloc to try to identify where the chunk is handed out. Yeah! That's exactly it. After setting a "watchpoint *0x84a0c84", in the first "where" call, the erronous line is in front of me! > Another possibility is to set a breakpoint where the warning is emitted > and take a look at the contents of the chunk to see if you can identify > it; that wouldn't require knowing the target chunk address in advance. > > BTW, if I recall that code correctly, the "chunk address" in the message > is probably the address of the start of the overhead data for the chunk, > not the usable-space start address that is passed back by palloc. Thanks so much for your kindly help. These all mentioned methods are applicable in a whole software development area. Thanks again. Regards. ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] [PATCHES] selecting large result sets in psql using
Peter Eisentraut <[EMAIL PROTECTED]> writes: > A \set variable would make sense to me. So Peter and Bruce like a \set variable, Chris and I like a different command. Seems like a tie ... more votes out there anywhere? regards, tom lane ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] Autovacuum on by default?
Peter Eisentraut <[EMAIL PROTECTED]> writes: > Does anyone, for that matter, want to propose possible default parameters for > vacuum_delay? I haven't seen any sign that anyone's done any serious testing of delay parameters, so I don't think we have the data needed to select some defaults ... regards, tom lane ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Going for "all green" buildfarm results
Stefan Kaltenbrunner <[EMAIL PROTECTED]> writes: > Tom Lane wrote: >> Vacuum's always had a race condition: it makes a list of rel OIDs and >> then tries to vacuum each one. It narrows the window for failure by >> doing a SearchSysCacheExists test before relation_open, but there's >> still a window for failure. > hmm yeah - missed the VACUUM; part of the regression diff. > Still this means we will have to live with (rare) failures once in a > while during that test ? I thought of what seems a pretty simple solution for this: make VACUUM lock the relation before doing the SearchSysCacheExists, ie instead of the existing code if (!SearchSysCacheExists(RELOID, ObjectIdGetDatum(relid), 0, 0, 0)) // give up lmode = vacstmt->full ? AccessExclusiveLock : ShareUpdateExclusiveLock; onerel = relation_open(relid, lmode); do lmode = vacstmt->full ? AccessExclusiveLock : ShareUpdateExclusiveLock; LockRelationOid(relid, lmode); if (!SearchSysCacheExists(RELOID, ObjectIdGetDatum(relid), 0, 0, 0)) // give up onerel = relation_open(relid, NoLock); Once we're holding lock, we can be sure there's not a DROP TABLE in progress, so there's no race condition anymore. It's OK to take a lock on the OID of a relation that no longer exists, AFAICS; we'll just drop it again immediately (the "give up" path includes transaction exit, so there's not even any extra code needed). This wasn't possible before the recent adjustments to the relation locking protocol, but now it looks trivial ... am I missing anything? Perhaps it is worth folding this test into a "conditional_relation_open" function that returns NULL instead of failing if the rel no longer exists. I think there are potential uses in CLUSTER and perhaps REINDEX as well as VACUUM. regards, tom lane ---(end of broadcast)--- TIP 1: 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] Going for "all green" buildfarm results
stark wrote: Alvaro Herrera writes: Maybe we could write a suitable test case using Martijn's concurrent testing framework. The trick is to get process A to commit between the times that process B looks at the new and old versions of the pg_class row (and it has to happen to do so in that order ... although that's not a bad bet given the way btree handles equal keys). I think the reason we've not tracked this down before is that that's a pretty small window. You could force the problem by stopping process B with a debugger breakpoint and then letting A do its thing, but short of something like that you'll never reproduce it with high probability. Actually I was already looking into a related issue and have some work here that may help with this. I wanted to test the online index build and to do that I figured you needed to have regression tests like the ones we have now except with multiple database sessions. So I hacked psql to issue queries asynchronously and allow multiple database connections. That way you can switch connections while a blocked or slow transaction is still running and issue queries in other transactions. I thought it was a proof-of-concept kludge but actually it's worked out quite well. There were a few conceptual gotchas but I think I have a reasonable solution for each. [snip] Can you please put the patch up somewhere so people can see what's involved? thanks cheers andrew ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] Going for "all green" buildfarm results
On Fri, Aug 18, 2006 at 02:46:39PM +0200, Peter Eisentraut wrote: > Am Donnerstag, 17. August 2006 17:17 schrieb stark: > > Instead I just added a command to cause psql to wait for a time. > > Do we need the full multiple-connection handling command set, or would > asynchronous query support and a wait command be enough? I am interested in this too. For example the tool I posted a while ago supported only this. It controlled multiple connections and only supported sending async & wait. It is enough to support fairly deterministic scenarios, for example, testing if the locks block on eachother as documented. However, it works less well for non-deterministic testing. Yet, a test-suite has to be deterministic, right? From a client side, is there any testing method better than async and wait? I've wondered about a tool that attached to the backend with gdb and for testing killed the backend when it hit a particular function. By selecting different functions each time, once you'd covered a lot of functions and tested recovery, you could have a good idea if the recovery code works properly. Has anyone seens a tool like that? Have a nice day, -- Martijn van Oosterhout http://svana.org/kleptog/ > From each according to his ability. To each according to his ability to > litigate. signature.asc Description: Digital signature
Re: [HACKERS] installcheck-parallel
Andrew Dunstan wrote: I see that the installcheck-parallel was not added to the top level Makefile and Gnumakefile.in when it was added as a regression test target back in the 8.0 cycle. Is there any objection to my adding it now so that it is treated the same as the other regression test targets? If so, should I add it just to HEAD, or backpatch it to 8.0 and 8.1? (Reasoning: I got confused for a few seconds and thought maybe I had mistyped the target name, before I realised what was wrong, but others less familiar than I am with the testing structure might well get rather more confused.) I didn't get any response to this so I'm going to add this and back port it, since the risk factor is pretty well zero, and I suspect it was just an inadvertent omission a couple of years ago. cheers andrew ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] pg_terminate_backend
> > Though for the Windows case only, we could easily enough make it > > possible to run pg_ctl kill remotely, since we use a named pipe. > Does > > this seem like a good or bad idea? > > Seems like we'd be opening a can of security worms :-( Not really, standard windows ACL already applies to everything, so you need to be an admin on the machine to make it work. Anyhoo, I don't really see the gain in it, which also seems to be what others think, so let's just drop that idea. //Magnus ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Autovacuum on by default?
Peter Eisentraut wrote: Am Donnerstag, 17. August 2006 18:40 schrieb Josh Berkus: I'm in favor of this, but do we want to turn on vacuum_delay by default as well? People might complain that suddenly their vacuum runs take four times as long (or whatever). Of course, if we turn on autovacuum and advocate a more or less hands-off vacuum policy, they won't have to care either way. All of this would certainly be release-notes material. Does anyone, for that matter, want to propose possible default parameters for vacuum_delay? I said vacuum_delay but I should have been more specific, there are autovacuum GUC variables which is what we should be talking about. This way manually run, or nighly run by cron vacuums are still as fast as they ever were. ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] pg_terminate_backend
"Magnus Hagander" <[EMAIL PROTECTED]> writes: > Though for the Windows case only, we could easily enough make it > possible to run pg_ctl kill remotely, since we use a named pipe. Does > this seem like a good or bad idea? Seems like we'd be opening a can of security worms :-( regards, tom lane ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: BugTracker (Was: Re: [HACKERS] 8.2 features status)
Tom Lane wrote: Alvaro Herrera <[EMAIL PROTECTED]> writes: Have you tried to use debbugs? I agree with Greg Stark that it's a better fit for our current procedure, while enabling better traceability. The principal strike against debbugs seems to be that the source code is not readily available and/or isn't updated regularly. If we could get current sources we'd probably end up maintaining our own fork ... OTOH, given all the enthusiasm being expressed in this thread, somebody would volunteer to do that no? Other than that not-small problem, I agree that debbugs seems like an excellent fit to our existing habits. Well, the enthusiasm was for use, not for maintaining a fork :-) I had a brief look at the code (literally less than 5 minutes). The good news is that it is admirably small. A fork isn't a bad idea, though, especially as a pgfoundry project. I can think of several excellent candidates for such a project (no names, no pack drill) ;-) I should mention that it's a perl app. cheers andrew ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] BF Failure on Bandicoot
> Just guessing from the function name, but does this go away if you > don't configure --with-ldap? > > If so it's presumably a portability issue in this recent patch: > > 2006-03-06 12:41 momjian > > * configure, configure.in, src/backend/libpq/auth.c, > src/backend/libpq/hba.c, > src/backend/libpq/pg_hba.conf.sample, > src/include/pg_config.h.in, src/include/libpq/hba.h: This > patch > adds native LDAP auth, for those platforms that don't have > PAM > (such as Win32, but also unixen without PAM). On Unix, uses > OpenLDAP. On win32, uses the builin WinLDAP library. > > Magnus Hagander > > I'd counsel just leaving --with-ldap off until Magnus gets back > from vacation. We can always revert the patch later if he can't > fix it. > (There's some fairly ugly stuff going on at lines 69-89 of > backend/libpq/auth.c, which I bet is the root of the trouble, but > I'm not going to dig further --- I've wasted more than enough time > on Windows this week ;-)) Looking at the MSDN documentation it seems this function only exists on Windows 2003 and Windows XP. Which is very interesting, because I have it working on one of my 2000 boxes. But I guess I got it through some patch or other. I'm going to have to redo it to dynamically load that function and exit with a proper error message if it's not found. Shouldn't be too hard, I'll get to it as soon as I can get down for a coding session. The ugly stuff I assume is the stuff about the mingw broken headers? If so, no, not related in any way. //Magnus ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] Windows buildfarm support, or lack of it
> > I have spare licences for most versions of Windows as well, so if > Microsoft's virtual server product is not too expensive for us I > can probably add a few platform variations to that box. I'll look > into it. > > In fact MS released Virtual PC 2004 for free a couple days ago > (http://www.microsoft.com/windows/virtualpc/default.mspx) FWIW, Virtual Server 2005 R2 Enterprise Edition (how's that for a product name) is also a free download from MS (provided you have a license for the underlying OS, but since it runs only on Win2k3, what'd they expect..) //Magnus ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] [PATCHES] WIP archive_timeout patch
Simon Riggs <[EMAIL PROTECTED]> writes: > On Thu, 2006-08-17 at 19:11 -0400, Tom Lane wrote: >> I noticed a minor annoyance while testing: when the system is completely >> idle, you get a forced segment switch every checkpoint_timeout seconds, >> even though there is nothing useful to log. The checkpoint code is >> smart enough not to do a checkpoint if nothing has happened since the >> last one, and the xlog switch code is smart enough not to do a switch >> if nothing has happened since the last one ... but they aren't talking >> to each other and so each one's change looks like "something happened" >> to the other one. > I noticed that minor annoyance and understood that I had fixed it before > submitting. That was the reason for putting the code in bgwriter to > check whether the pointer had moved before attempting the switch... > perhaps that functionality has been removed? No, the original form of the patch was equally vulnerable. AFAICS the only way to prevent this would be for XLogRequestSwitch (or really XLogInsert, which does the heavy lifting for this) to suppress a switch if the current segment is empty *or* contains only a checkpoint WAL record. Basically it'd have to pretend the checkpoint record is not there. This is doable but seems a bit weird --- in particular, that would mean that pg_switch_xlog sometimes returns a pointer less than pg_current_xlog_location, which might confuse backup scripts. On the whole I'm leaning towards not changing it. As Florian mentioned, guaranteed segment-every-checkpoint isn't completely without its uses. And people who are looking for low WAL volume ought to be stretching out their checkpoint intervals anyway. regards, tom lane ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Going for "all green" buildfarm results
Am Donnerstag, 17. August 2006 17:17 schrieb stark: > Instead I just added a command to cause psql to wait for a time. Do we need the full multiple-connection handling command set, or would asynchronous query support and a wait command be enough? -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] [PATCHES] selecting large result sets in psql using
Am Donnerstag, 17. August 2006 20:05 schrieb Chris Mair: > \gc sounds like a good idea to me :) Strictly speaking, in the randomly defined grammer of psql, \gc is \g with an argument of 'c' (try it, it works). I'm not sure what use case you envision for this feature. Obviously, this is for queries with large result sets. I'd guess that people will not normally look at those result sets interactively. If the target audience is instead psql scripting, you don't really need the most convenient command possible. A \set variable would make sense to me. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Bug with initDB under windows 2003
> > Have you been able to determine *why* Microsoft made this > braindead > > decision? Or where it's documented? Their own knowledgebase is > filled > > with examples of using the device, so I imagine they'll have to > post a > > workaround somewhere... > > AFAIK, nobody has posted any links to information that shows that > Microsoft actually *did* change this. I've searched their KB some > (including the partner-only one for people with the paid > agreements, which contains information about bugs that they don't > want to be public), and find nothing about it. > > Unless you can reproduce this on a clean system, I'm definitely > inclined to say this is caused by some other piece of software on > the machine - firewall, antivirus, antispyware or virus/spyware > itself. Actually, I've been able to find some more information about this, which confirms that the problem is access rights on the NUL device, but it's *NOT* set by a MS security patch. I'd be interested in seeing the output from the command: Subinacl /service NULL On a system where this does not work. (If you get an empty update, make sure you have a version of subinacl that corresponds to your windows version) (There are known apps that mess this up, but my NDA prevents me from telling you which one(s)...) //Magnus ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Autovacuum on by default?
Am Donnerstag, 17. August 2006 18:40 schrieb Josh Berkus: > I'm in favor of this, but do we want to turn on vacuum_delay by default > as well? People might complain that suddenly their vacuum runs take four times as long (or whatever). Of course, if we turn on autovacuum and advocate a more or less hands-off vacuum policy, they won't have to care either way. All of this would certainly be release-notes material. Does anyone, for that matter, want to propose possible default parameters for vacuum_delay? -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] [PATCHES] pg_regress in C
> > Per discussion at the conference: > > In order to run the regression tests on Windows without msys, > > pg_regress needs to be reimplemnted in C. > > This has some minor portability issues (macros with ... aren't > portable, for instance) but I think it's something we need to do. > Barring objections I'm going to clean up and apply it. Thanks for this, including all the followup patches :-) //Magnus ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] Windows 2000 Support
> Hi, > > I just finished setting up a new buildfarm member (Bandicoot) > running Windows 2000 Pro. Aside from the fact that it now fails > with the same cyptic pg_regress error as seen on Snake, it also > became apparent that CVS HEAD won't run properly on an unpatched > Windows 2000 (initdb - and probably pg_ctl - fails when trying to > dynamically load advapi32.dll which is used to shed excess > privileges). This was solved by the installation of service pack 4. > Unfortunately I couldn't find a way to catch the error - it seems > to kill the app and throw a messagebox with a cryptic message. > > Given that you have to be clinically insane to run Win2K without > patching it to the hilt I'm not overly concerned by this (and will > add appropriate checks to pgInstaller), but it's probably worth > mentioning that our minimum supported platform is Windows 2000 Pro > with Service Pack 4 from 8.2. Late into the game, yes, I definitely think this is a reasonable requirement. (FWIW, that's the same requirements as MS put on SQL Server) But yes, this should probably go in the release notes. (btw, clinically insane without patching it.. And obviously you didn't patch yours? :-P) //Magnus ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Question on SIGFPE in Windows
> SIGFPE is a synchornous signal and Windows will raise it if proper > flag is set (check out the example program): > > http://msdn2.microsoft.com/en-us/library/kfy34skx.aspx > > But seems we didn't use the above method. Instead, we use the same > methodology as other asynchrounous signals. My question is: (1) can > windows really raise SIGFPE in our setting && (2) can we really > catch it in windows? (1) No, because we haven't enabled it. (2) No, not the way things are set up. But because of (1), that's not a problem. There should be a discussion in the archives during the 8.0 development cycle about this. //Magnus ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] pg_terminate_backend
Magnus Hagander wrote: Since I have a stuck backend without client again, I'll have to >> kill >> -SIGTERM a backend. Fortunately, I do have console access to >> that >> machine and it's not win32 but a decent OS. >>> You do know that on Windows you can use pg_ctl to send a pseudo >>> SIGTERM to a backend, don't you? >>> >> The main issue still is that console access id required, on any OS. >> > > Yeah. > Though for the Windows case only, we could easily enough make it > possible to run pg_ctl kill remotely, since we use a named pipe. Does > this seem like a good or bad idea? > Not too helpful. How to kill a win32 backend from a linux workstation? Additionally, NP requires an authenticated RPC connection. I you're not allowed to access the console, you probably haven't got sufficient access permissions to NP as well, or you'd need extra policy tweaking or so. Nightmarish, just to avoid the easy and intuitive way. Regards, Andreas ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] pg_terminate_backend
> >> Since I have a stuck backend without client again, I'll have to > kill > >> -SIGTERM a backend. Fortunately, I do have console access to > that > >> machine and it's not win32 but a decent OS. > >> > >> > > > > You do know that on Windows you can use pg_ctl to send a pseudo > > SIGTERM to a backend, don't you? > The main issue still is that console access id required, on any OS. Yeah. Though for the Windows case only, we could easily enough make it possible to run pg_ctl kill remotely, since we use a named pipe. Does this seem like a good or bad idea? //Magnus ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Bug with initDB under windows 2003
> > Hi James, > > > > I just wanted to inform you all that I solve the issue, it was > indeed the nul device as James and Martijn mention. > > I have change the source to redirect the output to a log file, to > which I gave permission to the "postgres" user. > > The file (currently) is created at the temp folder. > > This is critical bug due to the fact that on more and more > win2003 machines the postgres installation failed to initialize the > DB. > > To be honest, this is the kind of crap that bugs me about Windows. > It happens all the time that you want to dump the output of a > program to nowhere. And then they make it so only admins can use > it? Writing it to a file is a hack, you don't want the output, that > why you send it to the NUL device. > > Have you been able to determine *why* Microsoft made this braindead > decision? Or where it's documented? Their own knowledgebase is > filled with examples of using the device, so I imagine they'll have > to post a workaround somewhere... AFAIK, nobody has posted any links to information that shows that Microsoft actually *did* change this. I've searched their KB some (including the partner-only one for people with the paid agreements, which contains information about bugs that they don't want to be public), and find nothing about it. Unless you can reproduce this on a clean system, I'm definitely inclined to say this is caused by some other piece of software on the machine - firewall, antivirus, antispyware or virus/spyware itself. (To reiterate a point from many other discussions, when it comes to AV, FW, AS software, it's very often not enough to disable it. And there are cases when even an uninstall isn't enough, because the vendor believe they have the right to stick around and tell you now and then to get their new version etc.) //Magnus ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] Removing the performance gap caused by CHECKPOINT
Hannu Krosing <[EMAIL PROTECTED]> wrote: > On postgresql anniversary summit there was a presentation byt SRA people > about using background writer to do CHECKPOINTs which seemed very > effective for removing the performance gap caused by CHECKPOINT. > > Has any of it been submitted for 8.2 ? That's my, *NTT*'s presentation :D But sorry, there are my company-specific troubles to open the source :-( I missed 8.2 feature freeze, so gave up proposing it. Please wait for a moment, or invent more effective checkpoint methods! Regards, --- ITAGAKI Takahiro NTT Open Source Software Center ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Win32 max connections bug (causing crashes)
> > Maybe this article can help: > > > > Windows and the ClearCase process limit: Understanding the > desktop > > heap > > http://www- > 128.ibm.com/developerworks/rational/library/05/1220_marecha > > l/ > > > > i doubled all my heap settings and was able to roughly double the - > c > on pgbench from ~158 (stock) to ~330 (modified). so this is > definately the problem. If you try decreasing max_files_per_process to a significantly lower value (say, try 100 instead of 1000), does the number of processes you can run change noticeably? (I don't have a box around ATM that I can try to reproduce on. Will try to set up a VM for it soon.) //Magnus ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
[HACKERS] Sorry about the GIN docs :(
Hi guys, I've attached as much as I've done so far on the GIN docs. It's not a lot, but I'm afraid with the feature freeze in effect, I'm just not going to have the ability to get them done by the RC date. The main problem was I just strugged to fully understand it all :( Anyway, hopefully someone else can pick them up and finish them off for the release. Sorry about that, Chris gindocs.tar.gz Description: GNU Zip compressed data ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] Win32 max connections bug (causing crashes)
> Hello, > > I had a customer call in today they are running Win2003 with 22 gig > of ram (that may be a mistype on their end, it may be 32gigs of > ram). > > They cranked up their postgresql max_connections to 500. > > When PostgreSQL hits above 400, it dies and I don't mean a slow > crawl type death. A death where all connections close and the > database does a rollback and restart. > > I was able to reproduce with a simple pgbench on my own win32 > environment. > > I wasn't able to go above 300 with mine. > > Any thoughts? A followup question - does this happen both when the server is started as a service and when it's started manually? Any difference in when it dies? //Magnus ---(end of broadcast)--- TIP 1: 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] [PATCHES] WIP archive_timeout patch
> I noticed a minor annoyance while testing: when the system is > completely idle, you get a forced segment switch every > checkpoint_timeout seconds, even though there is nothing > useful to log. The checkpoint code is smart enough not to do > a checkpoint if nothing has happened since the last one, and > the xlog switch code is smart enough not to do a switch if > nothing has happened since the last one ... but they aren't > talking to each other and so each one's change looks like > "something happened" > to the other one. I'm not sure how much trouble it's worth > taking to prevent this scenario, though. If you can't afford > a WAL file switch every five minutes, you probably shouldn't > be using archive_timeout anyway ... Um, I would have thought practical timeouts would be rather more than 5 minutes than less. So this does seem like a problem to me :-( Andreas ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] [PATCHES] WIP archive_timeout patch
On Thu, 2006-08-17 at 19:11 -0400, Tom Lane wrote: > Simon Riggs <[EMAIL PROTECTED]> writes: > >> Revised patch enclosed, now believed to be production ready. This > >> implements regular log switching using the archive_timeout GUC. > > > Further patch enclosed implementing these changes plus the record type > > version of pg_xlogfile_name_offset() > > Applied with minor changes --- it seemed better to me to put tracking of > the last xlog switch time directly into xlog.c, instead of having the > bgwriter code try to determine whether a switch had happened recently. Code location: sure. > I noticed a minor annoyance while testing: when the system is completely > idle, you get a forced segment switch every checkpoint_timeout seconds, > even though there is nothing useful to log. The checkpoint code is > smart enough not to do a checkpoint if nothing has happened since the > last one, and the xlog switch code is smart enough not to do a switch > if nothing has happened since the last one ... but they aren't talking > to each other and so each one's change looks like "something happened" > to the other one. I'm not sure how much trouble it's worth taking to > prevent this scenario, though. If you can't afford a WAL file switch > every five minutes, you probably shouldn't be using archive_timeout > anyway ... I noticed that minor annoyance and understood that I had fixed it before submitting. That was the reason for putting the code in bgwriter to check whether the pointer had moved before attempting the switch... perhaps that functionality has been removed? -- Simon Riggs EnterpriseDB http://www.enterprisedb.com ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: BugTracker (Was: Re: [HACKERS] 8.2 features status)
On Thu, Aug 17, 2006 at 08:20:22PM -0400, Tom Lane wrote: > Alvaro Herrera <[EMAIL PROTECTED]> writes: > > Have you tried to use debbugs? I agree with Greg Stark that it's a > > better fit for our current procedure, while enabling better > > traceability. > > The principal strike against debbugs seems to be that the source code is > not readily available and/or isn't updated regularly. If we could get > current sources we'd probably end up maintaining our own fork ... OTOH, > given all the enthusiasm being expressed in this thread, somebody would > volunteer to do that no? Well, actually, you can get the currently running source whenever you like: http://bugs.debian.org/debbugs-source/ I got that from one of the bugs listed against debbugs: http://bugs.debian.org/222077 The problem is that there is no recently packaged version that one can just quickly install somewhere. > Other than that not-small problem, I agree that debbugs seems like an > excellent fit to our existing habits. Yeah, debbugs is a really good fit here, like for Debian, because of the overwhelming prevalence of email correspondence compared to any other kind of communication. If we all used forums ofcourse, debbugs would suck :) Have a nice day, -- Martijn van Oosterhout http://svana.org/kleptog/ > From each according to his ability. To each according to his ability to > litigate. signature.asc Description: Digital signature
Re: [HACKERS] Removing the performance gap caused by CHECKPOINT
Hannu Krosing wrote: > On postgresql anniversary summit there was a presentation byt SRA people > about using background writer to do CHECKPOINTs which seemed very > effective for removing the performance gap caused by CHECKPOINT. > > Has any of it been submitted for 8.2 ? No, I don't remember seeing a patch for it. -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
[HACKERS] Removing the performance gap caused by CHECKPOINT
On postgresql anniversary summit there was a presentation byt SRA people about using background writer to do CHECKPOINTs which seemed very effective for removing the performance gap caused by CHECKPOINT. Has any of it been submitted for 8.2 ? -- Hannu Krosing Database Architect Skype Technologies OÜ Akadeemia tee 21 F, Tallinn, 12618, Estonia Skype me: callto:hkrosing Get Skype for free: http://www.skype.com ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
