[HACKERS] they only drink coffee at dec
From src/backend/tcop/postgres.c: appendStringInfo(str, !\t%ld/%ld [%ld/%ld] filesystem blocks in/out\n, r.ru_inblock - Save_r.ru_inblock, /* they only drink coffee at dec */ r.ru_oublock - Save_r.ru_oublock, r.ru_inblock, r.ru_oublock); Been there as far back as CVS goes. Will I find other goodies by poking around? :-) -- Michael Fuhr http://www.fuhr.org/~mfuhr/ ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] read-only planner input
Tom Lane wrote: You could make a good case that we just ought to save query text and start from there in any replanning; it'd be the most compact representation, the easiest to copy around, and the least likely to break. What happens if (for example) DateStyle changes between the two parses? (not that I'm sure what the expected behaviour is in that case anyway..) -O ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
[HACKERS] Unstable timestamp binary representation?
Hi all, In the OLE DB code there is code for parsing timestamps received from the server. This code behaves erratically. Upon further examination, I found the following piece of code in Postgresql's timestamp2tm: #ifdef HAVE_INT64_TIMESTAMP dt -= CTimeZone * INT64CONST(100); #else dt -= CTimeZone; #endif In other words, it seems that I, as a client, needs to guess whether postgres was compiled with or without HAVE_INT64_TIMESTAMP. If it was, what I am getting is a big-endian int64. If it was not, this is a double that needs to be multiplied by 100. In my tests, Potgresql 8 running on Windows uses double, while Postgresql 7.4 running on Debian Linux SID uses int64. Is there any way I can remotely detect which is it? Reading from the actual code, it seems each instance of postgres just assumes that it was encoded in the same format as it was compiled with, not stopping to ask what the other side was compiled with. Is this a bug in postgres as well? Shachar -- Shachar Shemesh Lingnu Open Source Consulting ltd. Have you backed up today's work? http://www.lingnu.com/backup.html ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] read-only planner input
Oliver Jowett wrote: What happens if (for example) DateStyle changes between the two parses? From my original email: This is the common case of a more general problem: a query plan depends on various parts of the environment at plan-creation time. That environment includes the definitions of database objects, but also GUC variables (most importantly search_path, but also optimizer-tuning variables for example), the state of database statistics, and so on. I'll leave resolution of the more general problem to someone else -- I think if we can manage to invalidate plans automatically when dependent objects change, that's better than nothing. I'm don't think recreating the plan from the query string changes this fundamentally -- the interaction between (for example) GUC variables and prepared plans will likely not be well-defined (which will be no worse than it is today). (It might be plausible to work something out where a backend-local SET of some subset of the GUC variables flushes all the cached query plans, but I'm don't have any plans to look at it myself.) -Neil ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[HACKERS] Version 1.0.0.18 of OLE DB released
Hi all, Version 1.0.0.18 of OLE DB has just been uploaded to gborg. This is a major upgrade than the previous versions, with most types now handled (the #1 complaint about OLE DB thus far). As far as my understanding goes, this version solves almost all of the problems that surfaced with OLE DB in the near past. I strongly recommend upgrading, especially prior to filing any new bug reports. The new version can be obtained from http://gborg.postgresql.org/project/oledb/download/download.php. Shachar -- Shachar Shemesh Lingnu Open Source Consulting ltd. Have you backed up today's work? http://www.lingnu.com/backup.html ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] PHP stuff
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 We can't, because we can't revoke Berkeley's copyright. But in practice there's hardly any difference anyway. Just out of curiosity, are the docs covered by the Berkeley copyright? I know the code originally came from there, but did our current docs evolve from them, or were they created later on? - -- Greg Sabino Mullane [EMAIL PROTECTED] PGP Key: 0x14964AC8 200503171713 http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8 -BEGIN PGP SIGNATURE- iD8DBQFCOgExvJuQZxSWSsgRAgi0AKD5UUl3frO6uv4UBTGed/1OaZppqwCgiw12 pjxiwpS/2TNGBDRp3syigGQ= =cHI1 -END PGP SIGNATURE- ---(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] PHP stuff
Greg Sabino Mullane wrote: [ There is text before PGP section. ] -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 We can't, because we can't revoke Berkeley's copyright. But in practice there's hardly any difference anyway. Just out of curiosity, are the docs covered by the Berkeley copyright? I know the code originally came from there, but did our current docs evolve from them, or were they created later on? They evolved, so they are BSD copyrighted. -- Bruce Momjian| http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[HACKERS] QueryResults from Executor
i am trying to find that which file/function is actually printing the QueryResults from Executor..Please help Thanks Zahid __ Do you Yahoo!? Make Yahoo! your home page http://www.yahoo.com/r/hs ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] securing pg_proc
On Thu, 2005-03-17 at 13:36 -0500, Merlin Moncure wrote: However, I still maintain that views are the perfect security mechanism for system catalogs. Imagine that all the system catalogs were all views, and could be redefined or even dropped by the dba. They would present exactly the same stuff they do now, with rules presenting them just like the original table. Now, for extreme situations like that government server that requires catalog security, the dba can redefine the various rules for the catalog views and lock various things down, using whatever methodology he/she sees fit. This would not affect the internal workings of the server but would affect the client tools, which is really what I'm after. Configurable security? Sounds great to me. This is exactly how Teradata implements this; they even present you with a choice of views to load ontop of the catalog tables. Secure/Not. You choose. That would be just great. Now why wouldn't this work? ...but in this case: ( A possible variant: the function body stays in prosrc, but is encrypted.) That sounds OK for this situation. Doesn't it Merlin? Well, I think the idea has merit but there are complexities in the implementation. 1. when is the encryption key first introduced (create function?) or is it somehow supplied by the server? 2. is the encryption key stored? If so, where? 3. can the su decrypt functions without the key? (remembering he can just attach a debugger and grab the source at some point) 4. can the decryption be integrated with the user security model, so that decryption is tied to some other function? In short, how could this be made to work? :-). Merlin ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] they only drink coffee at dec
Michael Fuhr [EMAIL PROTECTED] writes: From src/backend/tcop/postgres.c: /* they only drink coffee at dec */ I never did figure out what that meant. Anyone know? Been there as far back as CVS goes. Will I find other goodies by poking around? :-) There's a few jokes ... not that many ... regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] read-only planner input
Neil Conway [EMAIL PROTECTED] writes: Oliver Jowett wrote: What happens if (for example) DateStyle changes between the two parses? I'm don't think recreating the plan from the query string changes this fundamentally -- the interaction between (for example) GUC variables and prepared plans will likely not be well-defined (which will be no worse than it is today). It is well defined, because we insist that the gram.y transformation not depend on any changeable state. So if we forced replan after a change of DateStyle, the right thing would happen with either plain text or raw parsetrees as the starting point. There is a separate issue here of course, which is whether it's really the right thing --- if the plan got through parsing the first time then it's pretty likely that it would fail under a different datestyle. But certainly we've seen requests for cached plans to respond to changes in search_path, and I doubt you can make a principled distinction between that and datestyle. From a practical point of view, I suspect the path of least resistance is to use plain text as the saved representation, because (a) it's smaller and (b) IIRC we don't currently have a complete set of copyfuncs for raw parsetree nodes. regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Unstable timestamp binary representation?
Shachar Shemesh [EMAIL PROTECTED] writes: In other words, it seems that I, as a client, needs to guess whether postgres was compiled with or without HAVE_INT64_TIMESTAMP. No, you need to inquire of the value of the integer_datetimes parameter. (At least as of 8.0, this is provided for free during connection startup, so you don't even need an extra network round trip to find it out.) Reading from the actual code, it seems each instance of postgres just assumes that it was encoded in the same format as it was compiled with, No, it checks. See pg_control. regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] QueryResults from Executor
Zahid Khan [EMAIL PROTECTED] writes: i am trying to find that which file/function is actually printing the QueryResults from Executor..Please help printtup() in access/common/printtup.c regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Query crashes/hangs server
Tatsuo Ishii [EMAIL PROTECTED] writes: It seems your patches do not fix the case when the table is a temporary table... Ah, should've thought to try that case too. Thanks, Tatsuo. regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] WIN1252 patch broke my database
Am Donnerstag, 17. März 2005 19:23 schrieb Tom Lane: It doesn't eliminate the need for initdb, because pg_conversion contains instances of the client-only encoding numbers. I think that clients know the client-only encoding numbers too, so I'm not sure we aren't stuck with a compatibility issue. I think the problem case was old pg_dump versions saving the encoding number rather than name. I don't recall any problems with renumbering the client encodings. I believe that we in fact did that in 8.0. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] WIN1252 patch broke my database
Peter Eisentraut [EMAIL PROTECTED] writes: Am Donnerstag, 17. März 2005 19:23 schrieb Tom Lane: It doesn't eliminate the need for initdb, because pg_conversion contains instances of the client-only encoding numbers. I think that clients know the client-only encoding numbers too, so I'm not sure we aren't stuck with a compatibility issue. I think the problem case was old pg_dump versions saving the encoding number rather than name. I don't recall any problems with renumbering the client encodings. I believe that we in fact did that in 8.0. As long as client code only uses the names, I suppose we are OK. I'm a bit worried about that assumption though, since it's not like the numbers aren't exposed to view in pg_database and pg_conversion ... regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] they only drink coffee at dec
Tom Lane wrote: Michael Fuhr [EMAIL PROTECTED] writes: From src/backend/tcop/postgres.c: /* they only drink coffee at dec */ I never did figure out what that meant. Anyone know? Been there as far back as CVS goes. Will I find other goodies by poking around? :-) There's a few jokes ... not that many ... And, of course, my favorite, which is now gone because we fixed it (*snif*): _bt_getstackbuf: my bits moved right off the end of the world! -- Bruce Momjian| http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 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] they only drink coffee at dec
On Fri, 18 Mar 2005, Tom Lane wrote: Michael Fuhr [EMAIL PROTECTED] writes: From src/backend/tcop/postgres.c: /* they only drink coffee at dec */ I never did figure out what that meant. Anyone know? Been there as far back as CVS goes. Will I find other goodies by poking around? :-) There's a few jokes ... not that many ... Be almost cute to add a section to the web site that links to cvsweb to point out these ... making sure to link to the oldest version in cvs that contains it ... Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ---(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] they only drink coffee at dec
From src/backend/tcop/postgres.c: /* they only drink coffee at dec */ Tcop might be pronounced tea-cop IOW, 'We are the tea police. In order to be sure what it means, I think you would have to ask the original author of the quote. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Marc G. Fournier Sent: Friday, March 18, 2005 7:57 AM To: Tom Lane Cc: Michael Fuhr; [EMAIL PROTECTED]; pgsql-hackers@postgresql.org Subject: Re: [HACKERS] they only drink coffee at dec On Fri, 18 Mar 2005, Tom Lane wrote: Michael Fuhr [EMAIL PROTECTED] writes: From src/backend/tcop/postgres.c: /* they only drink coffee at dec */ I never did figure out what that meant. Anyone know? Been there as far back as CVS goes. Will I find other goodies by poking around? :-) There's a few jokes ... not that many ... Be almost cute to add a section to the web site that links to cvsweb to point out these ... making sure to link to the oldest version in cvs that contains it ... Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ---(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 ---(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] Unstable timestamp binary representation?
Tom Lane wrote: Shachar Shemesh [EMAIL PROTECTED] writes: In other words, it seems that I, as a client, needs to guess whether postgres was compiled with or without HAVE_INT64_TIMESTAMP. No, you need to inquire of the value of the integer_datetimes parameter. (At least as of 8.0, this is provided for free during connection startup, so you don't even need an extra network round trip to find it out.) Hmm. So I need to call |PQparameterStatus with |integer_datetimes. If I get TRUE, treat as integer, if I get FALSE, treat as double. What happens if I get NULL? The docs seem to suggest that this is what will happen for 7.4 back end, and the FALSE is the default. My experience shows, however, that at least 7.4 for Debian Sid should be true. No, it checks. See pg_control. Not what I have seen from the code, but I will take your word for it. regards, tom lane Shachar -- Shachar Shemesh Lingnu Open Source Consulting ltd. Have you backed up today's work? http://www.lingnu.com/backup.html ---(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: [pgsql-www] [HACKERS] they only drink coffee at dec
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Marc G. Fournier Sent: 18 March 2005 15:57 To: Tom Lane Cc: Michael Fuhr; [EMAIL PROTECTED]; pgsql-hackers@postgresql.org Subject: Re: [pgsql-www] [HACKERS] they only drink coffee at dec Be almost cute to add a section to the web site that links to cvsweb to point out these ... making sure to link to the oldest version in cvs that contains it ... Maybe - anyone know of any more, or anything else of historical interest that could go on such a page? /D ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[HACKERS] rewriter in updateable views
Hi,
Bernd and myself are working in updateable views, one thing we find is
that when we have something like:
create table foo (
col1 serial,
col2 text default 'default'
);
create view vfoo as select * from foo;
then we create the appropiate rules for allow INSERT /UPDATE /DELETE on the view
but if we do INSERT INTO vfoo(col2) values ('some_string) the rewriter
cann resolv the value for col1. the reason is that views does not
inherit the defaults of the parent table. That is the reason you add
the ALTER TABLE ALTER COLUMN ADD/DROP DEFAULT for views.
Ok, this is a problem for us, so we want to improve the rewriter to
see the default in the base table an add it as appropiate.
Can you comment on this? Are there any issues here we have not seen
yet? performance? possible?
regards,
Jaime Casanova
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
Re: [HACKERS] read-only planner input
Tom Lane wrote: It is well defined, because we insist that the gram.y transformation not depend on any changeable state. That's my point -- whether we begin from the query string or the raw parsetree shouldn't make a difference. By not well-defined, I meant that if the user is changing GUC variables on the fly, they can't rely on their prepared query being planned under any particular datestyle (or search path, etc.), since they can't really predict when replanning will take place (e.g. an sinval overflow could occur spontaneously and cause all cached plans to be invalidated). This is similar to how search_path and pl/pgsql works right now -- we'll use the search_path in effect when the query is planned, which may or may not be what the user would expect. -Neil ---(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] corrupted tuple (header?), pg_filedump output
I've brought this back on-list, probably best that way..? Eric Parusel wrote: Tom Lane wrote: What it kinda looks like from here is that you suffered a page tear: the itemid pointers at the front of the page may be self-consistent, but they don't quite match the state of the rest of the page. For instance the claimed item-2 header is obviously bogus but it looks like there is a valid header starting a few bytes after where the itemid points. I suspect that the itemid pointers are one generation earlier or later than the remainder of the page. Since disks typically write in 512-byte sectors and there is nothing else in the first 512 bytes except the itemids, we could imagine that that sector got written and then the rest of the page did not. Postgres is supposed to protect against this sort of thing in case of a system crash, but I wouldn't want to swear that the protections are completely bulletproof. Have you had any power failures or system crashes lately? What sort of hardware and OS is this on? Hmm... Here is some system information: Dell PE1750, 2GB ECC ram, 2x73GB 10K scsi attached to Perc4/di (raid-on-motherboard, LSI megaraid chipset, battery-backed cache, write-back cache enabled), firmware/drivers is up to date as of a month ago. The OS is RHEL3, kept up to date with the newest kernel for it. PgSQL 8.0.1 installed from RPMs on postgresql.org, it had 8.0.0 installed from DGPG RPMs initially until 8.0.1 came out. No power failures or crashes since it's been up... It's been up and running with moderate to heavy load for about 2 months now. I don't think there have been any pgsql backend (if that's the word for them) processes crashing or anything of that sort... Pretty heavy write load on the box, it will be getting a 14 disk raid10 array plugged into it soon to speed things up. I can't remember and I couldn't find it, but is there a consistency checking tool (pg_fsck or something?) for pgsql? Or I suppose a dump of the whole database (which I do nightly) ensures all the data is readable... If there's anything else I can do to help figure this out, let me know.. Thanks, Eric How would I go about double checking I don't have this problem on other pages? As above, a successful db dump would verify everything's fine? I suppose a dump and reload after that point would verify that my indexes and anything else in base/ is fine? How would I figure out where and how much to overwrite with dd if I was to clear this page? Or how would I set the invalid item's itemid to empty? Obviously, stuff like this tends not to be in the documentation :D Thanks for the help, Eric ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] read-only planner input
Neil Conway [EMAIL PROTECTED] writes: ... By not well-defined, I meant that if the user is changing GUC variables on the fly, they can't rely on their prepared query being planned under any particular datestyle (or search path, etc.), since they can't really predict when replanning will take place (e.g. an sinval overflow could occur spontaneously and cause all cached plans to be invalidated). This is similar to how search_path and pl/pgsql works right now -- we'll use the search_path in effect when the query is planned, which may or may not be what the user would expect. As soon as we have the replanning mechanism, I think that there will be considerable pressure to use it to ensure that search_path changes and so on *do* behave consistently. The question here is what does consistently mean. My first thought is that the best idea in most scenarios would be to associate a search_path value with each function, rather than allowing the meaning of queries within each function to vary depending on the caller's search_path. We have seen one or two examples where the user would rather have the other behavior --- but they are surely a small minority. I'm not sure though that I care to extend that thought to each individual GUC variable ... even though it's surely true that changes in e.g. datestyle could break a particular function. The contrary argument is that GUC variables are useful just because they represent a single place to set some behavior, and having to fix the values associated with N different functions would be a nightmare outweighing the benefits of stable values for individual functions. Any thoughts on how this stuff ought to behave? regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] rewriter in updateable views
Jaime Casanova [EMAIL PROTECTED] writes:
... but if we do INSERT INTO vfoo(col2) values ('some_string) the rewriter
cann resolv the value for col1. the reason is that views does not
inherit the defaults of the parent table. That is the reason you add
the ALTER TABLE ALTER COLUMN ADD/DROP DEFAULT for views.
Ok, this is a problem for us, so we want to improve the rewriter to
see the default in the base table an add it as appropiate.
Why do you not define the problem as when we decide a view is
updateable and create the needed rules for it, also create default
values for it by copying up from the base tables?
regards, tom lane
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
Re: [HACKERS] rewriter in updateable views
On Fri, 18 Mar 2005 23:31:26 -0500, Tom Lane [EMAIL PROTECTED] wrote:
Jaime Casanova [EMAIL PROTECTED] writes:
... but if we do INSERT INTO vfoo(col2) values ('some_string) the
rewriter
cann resolv the value for col1. the reason is that views does not
inherit the defaults of the parent table. That is the reason you add
the ALTER TABLE ALTER COLUMN ADD/DROP DEFAULT for views.
Ok, this is a problem for us, so we want to improve the rewriter to
see the default in the base table an add it as appropiate.
Why do you not define the problem as when we decide a view is
updateable and create the needed rules for it, also create default
values for it by copying up from the base tables?
regards, tom lane
Well, that was our first thought. but what if the default value is
changed in the base table? then we have a problem, can we found in
what views we have to alter the default value in order to keep
consistency.
regards,
Jaime Casanova
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
