Re: [PATCHES] ADD/DROPS INHERIT (actually INHERIT / NO INHERIT)
Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: Tom Lane wrote: So this patch was by no stretch of the imagination ready to apply, but you did it anyway. Right. What is your next question? Perhaps why is the buildfarm failing would be appropriate. Yes, that is appropriate, though it seems Neil's cleanup of the patch has fixed it now. I see only a single stats failure and an initdb failure in the buildfarm, neither of which I assume are related to the patch. -- 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: [PATCHES] ADD/DROPS INHERIT (actually INHERIT / NO INHERIT)
On Sun, 2 Jul 2006, Tom Lane wrote: Nah, it was a false alarm: I was looking at the first post-patch report, http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=mongoosedt=2006-07-02%2003:30:01 but apparently mongoose had managed to pick up a partially-updated snapshot. The later reports (including mongoose's own next try an hour later) were all OK. As the keeper of mongoose, is there anything I should do to prevent it from picking up a partially-updated snapshot? Or is this just a race condition that's bound to happen now and then? ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [PATCHES] ADD/DROPS INHERIT (actually INHERIT / NO INHERIT)
Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: Tom Lane wrote: Perhaps why is the buildfarm failing would be appropriate. Yes, that is appropriate, though it seems Neil's cleanup of the patch has fixed it now. I see only a single stats failure and an initdb failure in the buildfarm, neither of which I assume are related to the patch. Nah, it was a false alarm: I was looking at the first post-patch report, http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=mongoosedt=2006-07-02%2003:30:01 but apparently mongoose had managed to pick up a partially-updated snapshot. The later reports (including mongoose's own next try an hour later) were all OK. Sorry for the noise. Thanks for keeping an eye on that buildfarm. I often forget to look myself. -- 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: [PATCHES] table/index fillfactor control, try 3
Bruce Momjian [EMAIL PROTECTED] wrote: Patch applied. Thanks. Thank you for applying, but sorry, my patch has some incompletions. 1. A debug code is left. Assert() and if-test are redundant. 2. Add a comment on the average FSM request size. Now, the size contains not only the size of tuples, but also freespace on pages. Especially, there may be a room to discuss on 2; it changed the meaning of 'average request size'. If it is enough only to add a comment, please apply the following fixes. diff -cpr pgsql-orig/src/backend/access/heap/hio.c pgsql/src/backend/access/heap/hio.c *** pgsql-orig/src/backend/access/heap/hio.cMon Jul 3 09:22:49 2006 --- pgsql/src/backend/access/heap/hio.c Mon Jul 3 10:22:40 2006 *** RelationGetBufferForTuple(Relation relat *** 108,115 otherBlock; boolneedLock; - if (relation-rd_options == NULL) - elog(ERROR, RelationGetBufferForTuple %s IS NULL, RelationGetRelationName(relation)); Assert(relation-rd_options != NULL); len = MAXALIGN(len);/* be conservative */ --- 108,113 diff -cpr pgsql-orig/src/backend/storage/freespace/freespace.c pgsql/src/backend/storage/freespace/freespace.c *** pgsql-orig/src/backend/storage/freespace/freespace.cMon Jul 3 09:22:50 2006 --- pgsql/src/backend/storage/freespace/freespace.c Mon Jul 3 10:30:26 2006 *** RecordAndGetPageWithFreeSpace(RelFileNod *** 341,346 --- 341,348 /* * GetAvgFSMRequestSize - get average FSM request size for a relation. * + * Retuened value is the average of item size plus freespace specified + * by fillfactor. * If the relation is not known to FSM, return a default value. */ Size Regards, --- ITAGAKI Takahiro NTT Open Source Software Center ---(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: [PATCHES] [HACKERS] PQescapeIdentifier
Hang on a second. Has someone considered the encoding issues this might suffer from, same as PQescapeString? I remember we discussed it briefly and I mentioned it's outta my league to prove one way or the other... Bruce Momjian wrote: Christopher Kings-Lynne wrote: TODO item done for 8.2: * Add PQescapeIdentifier() to libpq Someone probably needs to check this :) Updated patch applied. Thanks. Index: doc/src/sgml/libpq.sgml === RCS file: /cvsroot/pgsql/doc/src/sgml/libpq.sgml,v retrieving revision 1.211 diff -c -c -r1.211 libpq.sgml *** doc/src/sgml/libpq.sgml 23 May 2006 22:13:19 - 1.211 --- doc/src/sgml/libpq.sgml 26 Jun 2006 23:54:12 - *** *** 2279,2284 --- 2279,2347 /para /sect2 + sect2 id=libpq-exec-escape-identifier + titleEscaping Identifier for Inclusion in SQL Commands/title + +indexterm zone=libpq-exec-escape-identifierprimaryPQescapeIdentifier// +indexterm zone=libpq-exec-escape-identifierprimaryescaping strings// + + para + functionPQescapeIdentifier/function escapes a string for use + as an identifier name within an SQL command. For example; table names, + column names, view names and user names are all identifiers. + Double quotes () must be escaped to prevent them from being interpreted + specially by the SQL parser. functionPQescapeIdentifier/ performs this + operation. + /para + + tip + para + It is especially important to do proper escaping when handling strings that + were received from an untrustworthy source. Otherwise there is a security + risk: you are vulnerable to quoteSQL injection/ attacks wherein unwanted + SQL commands are fed to your database. + /para + /tip + + para + Note that it is still necessary to do escaping of identifiers when + using functions that support parameterized queries such as functionPQexecParams/ or + its sibling routines. Only literal values are automatically escaped + using these functions, not identifiers. + + synopsis + size_t PQescapeIdentifier (char *to, const char *from, size_t length); + /synopsis + /para + + para + The parameter parameterfrom/ points to the first character of the string + that is to be escaped, and the parameterlength/ parameter gives the + number of characters in this string. A terminating zero byte is not + required, and should not be counted in parameterlength/. (If + a terminating zero byte is found before parameterlength/ bytes are + processed, functionPQescapeIdentifier/ stops at the zero; the behavior + is thus rather like functionstrncpy/.) + parameterto/ shall point to a + buffer that is able to hold at least one more character than twice + the value of parameterlength/, otherwise the behavior is + undefined. A call to functionPQescapeIdentifier/ writes an escaped + version of the parameterfrom/ string to the parameterto/ + buffer, replacing special characters so that they cannot cause any + harm, and adding a terminating zero byte. The double quotes that + may surround productnamePostgreSQL/ identifiers are not + included in the result string; they should be provided in the SQL + command that the result is inserted into. + /para + para + functionPQescapeIdentifier/ returns the number of characters written + to parameterto/, not including the terminating zero byte. + /para + para + Behavior is undefined if the parameterto/ and parameterfrom/ + strings overlap. + /para + /sect2 sect2 id=libpq-exec-escape-bytea titleEscaping Binary Strings for Inclusion in SQL Commands/title Index: src/interfaces/libpq/exports.txt === RCS file: /cvsroot/pgsql/src/interfaces/libpq/exports.txt,v retrieving revision 1.11 diff -c -c -r1.11 exports.txt *** src/interfaces/libpq/exports.txt28 May 2006 22:42:05 - 1.11 --- src/interfaces/libpq/exports.txt26 Jun 2006 23:54:20 - *** *** 130,132 --- 130,134 PQencryptPassword 128 PQisthreadsafe129 enlargePQExpBuffer130 + PQescapeIdentifier131 + Index: src/interfaces/libpq/fe-exec.c === RCS file: /cvsroot/pgsql/src/interfaces/libpq/fe-exec.c,v retrieving revision 1.186 diff -c -c -r1.186 fe-exec.c *** src/interfaces/libpq/fe-exec.c 28 May 2006 21:13:54 - 1.186 --- src/interfaces/libpq/fe-exec.c 26 Jun 2006 23:54:21 - *** *** 2516,2521 --- 2516,2557 } /* + * Escaping arbitrary strings to get valid SQL identifier strings. + * + * Replaces with . + * + * length is the length of the source string. (Note: if a terminating NUL + * is encountered sooner, PQescapeIdentifier stops short of length; the behavior + * is thus rather like strncpy.) + * + * For safety the buffer at to must be at
Re: [PATCHES] Client build of MSVC6+ patch
I am thinking this patch needs to be applied, and the #ifdef test changed to WIN32 so both MinGW and MSVC use the changed structure ordering. Your patch has been added to the PostgreSQL unapplied patches list at: http://momjian.postgresql.org/cgi-bin/pgpatches It will be applied as soon as one of the PostgreSQL committers reviews and approves it. --- Hiroshi Saito wrote: Hi. Tom-san. Oops, I understood it. Thank you for suggestion. What condition is this? Regards, Hiroshi Saito From: Tom Lane Hiroshi Saito [EMAIL PROTECTED] writes: Why do we need to reorder the fields in the struct? Eh? Even my FreeBSD used well shows a structure object. The standard lists the fields in the other order: http://www.opengroup.org/onlinepubs/009695399/basedefs/netdb.h.html Even though the standard doesn't say that that has to be the physical order, every other platform besides Windows does it that way. The patch as given is unacceptable because it *will* break other platforms (mine for instance ;-)). If it has to be this way for Windows then we need some sort of platform-specific #ifdef. Considering that the code works as-is on several sorts of Windows builds, we probably need something even more specific than that, like #if MSVC-before-version-XX. regards, tom lane [ Attachment, skipping... ] ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings -- 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: [PATCHES] table/index fillfactor control, try 3
ITAGAKI Takahiro [EMAIL PROTECTED] writes: Thank you for applying, but sorry, my patch has some incompletions. I'm busy reviewing/reworking this patch, and will deal with these items. 2. Add a comment on the average FSM request size. Now, the size contains not only the size of tuples, but also freespace on pages. Yeah, I noticed this and thought it was probably a pretty bad idea: it plays hob with the notion of tracking a moving average of freespace requests. I'm not sure what else to do though. Do we want the FSM to explicitly account for fillfactor, and if so how exactly? There's certainly no point in returning a page that doesn't have space for the fillfactor padding. regards, tom lane ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [PATCHES] ADD/DROPS INHERIT (actually INHERIT / NO INHERIT)
Jeremy Drake [EMAIL PROTECTED] writes: On Sun, 2 Jul 2006, Tom Lane wrote: Nah, it was a false alarm: I was looking at the first post-patch report, http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=mongoosedt=2006-07-02%2003:30:01 but apparently mongoose had managed to pick up a partially-updated snapshot. The later reports (including mongoose's own next try an hour later) were all OK. As the keeper of mongoose, is there anything I should do to prevent it from picking up a partially-updated snapshot? Or is this just a race condition that's bound to happen now and then? Well, it's certainly not *your* problem to fix. I suspect that this risk is inherent in CVS --- although there might also be something involved about our primary-vs-mirror CVS setup. Does anyone know exactly how the mirroring is done and whether it makes any attempt to ensure a consistent copy? regards, tom lane ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
