Re: [HACKERS] Problem on AIX with current
> Andreas, have you tried CVS tip lately on AIX? What's your results? All 77 ok, no hangs, with make check on single CPU AIX 4.3.2. Only problem on AIX is, that the argv[0] stuff does not work anymore (I think since we don't exec() anymore), which is rather annoying. Andreas ---(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] Problem on AIX with current
"Zeugswetter Andreas SB SD" <[EMAIL PROTECTED]> writes: > Only problem on AIX is, that the argv[0] stuff does not work anymore > (I think since we don't exec() anymore), which is rather annoying. Hmm, perhaps we are selecting the wrong PS_STRINGS method for AIX? Please look at src/backend/utils/misc/ps_status.c and see if one of the other methods will work on AIX. regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Problem on AIX with current
> > Only problem on AIX is, that the argv[0] stuff does not work anymore > > (I think since we don't exec() anymore), which is rather annoying. > > Hmm, perhaps we are selecting the wrong PS_STRINGS method for AIX? > Please look at src/backend/utils/misc/ps_status.c and see if one of > the other methods will work on AIX. Yes, I see. Quite silly that I did not look earlier. The compiler does not define _AIX4 or _AIX3, no idea who thought that. It only defines _AIX, _AIX32, _AIX41 and _AIX43. I am quite sure that all AIX Versions accept the CLOBBER method, thus I ask you to apply the following patch, to make it work. Andreas ps_status.patch ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] btree_gist regression test busted?
Appears to have been already applied. Thanks. > You are right. Please, apply attached patch or copy result/btree_gist.out > expected/btree_gist.out > > > Tom Lane wrote: > > > In current CVS I see a failure in the btree_gist regression test. > > It kinda looks like the test data was changed without updating the > > expected results, but would you verify this? > > > > regards, tom lane > > > > > > *** ./expected/btree_gist.out Wed Aug 22 14:27:54 2001 > > --- ./results/btree_gist.outTue Oct 2 18:48:34 2001 > > *** > > *** 17,23 > > select count(*) from tstmp where t < '2001-05-29 08:33:09+04'; > >count > > --- > > ! 7 > > (1 row) > > > > -- create idx > > --- 17,23 > > select count(*) from tstmp where t < '2001-05-29 08:33:09+04'; > >count > > --- > > ! 66 > > (1 row) > > > > -- create idx > > *** > > *** 34,39 > > select count(*) from tstmp where t < '2001-05-29 08:33:09+04'; > >count > > --- > > ! 7 > > (1 row) > > > > --- 34,39 > > select count(*) from tstmp where t < '2001-05-29 08:33:09+04'; > >count > > --- > > ! 66 > > (1 row) > > > > > > > > > > > -- > Teodor Sigaev > [EMAIL PROTECTED] > [ Attachment, skipping... ] > > ---(end of broadcast)--- > TIP 6: Have you searched our list archives? > > http://archives.postgresql.org -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Beta time
On Thu, 4 Oct 2001, Bruce Momjian wrote: > Can we set a date for beta? If we are at least a week away, we should > say that so people know they can keep working. If we say the 10th I won't have to change the developer's page :) Vince. -- == Vince Vielhaber -- KA8CSHemail: [EMAIL PROTECTED]http://www.pop4.net 56K Nationwide Dialup from $16.00/mo at Pop4 Networking Online Campground Directoryhttp://www.camping-usa.com Online Giftshop Superstorehttp://www.cloudninegifts.com == ---(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] patch contrib/intarray to current CVS
Patch applied. Thanks. > Please apply attached patch to current CVS > > Changes: > > October 1, 2001 > > 1. Implemented binary search in array > > Regards, > Oleg > _ > Oleg Bartunov, sci.researcher, hostmaster of AstroNet, > Sternberg Astronomical Institute, Moscow University (Russia) > Internet: [EMAIL PROTECTED], http://www.sai.msu.su/~megera/ > phone: +007(095)939-16-83, +007(095)939-23-83 Content-Description: [ Attachment, skipping... ] > > ---(end of broadcast)--- > TIP 6: Have you searched our list archives? > > http://archives.postgresql.org -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] cvs problem
On Thu, 4 Oct 2001, John Summerfield wrote: > On Tue, 2 Oct 2001, Lamar Owen wrote: > > > > On Monday 01 October 2001 07:33 pm, John Summerfield wrote: > > > It seems you don't have to be new here to be a bit peeved about things;-( > > [snip] > > > Time to get your act together fellas. > > > > This is open source John, not rocket science. (pun intended) > > > > Lighten up. The release will happen, regardless of minor server issues (that > > are being worked out right now, even as I write, by highly capable > > professionals, who, BTW, are doing this on a volunteer basis). > > Changing the CVS repository so it doesn't work the same way any more > isn't smart. Having wrong documentation isn't smart. Taking two weeks > and NOT fixing a simple problem isn't smart. Giving wrong advice isn't > smart. Test your advice - where possible I do. > > "Lighten up" isn't the right response. Examine your project. See what points > I make have merit. Welcome criticism. You don't have to like the message you know;-) Actually, I think "Lighten up" was a reasonable response, given the tone of the message this was in response to which appears to be what Lamar was responding to. Besides, there's a far cry from a message of constructive criticism and the message this was in response to. The point that the documentation and reality need to match up is a good one, but saying that "It's wrong because it's different from what worked before" isn't reasonable. Saying, "This change is unfortunate and did it really have to happen and why? And the documentation and the server realities really have to match up. Perhaps changing the page first with a note of both configurations with an estimated time change for the server would have been better/the right way to do this" is reasonable. ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] cvs problem
> Changing the CVS repository so it doesn't work the same way any > more isn't smart. Having wrong documentation isn't smart. Taking > two weeks and NOT fixing a simple problem isn't smart. Giving > wrong advice isn't smart. Test your advice - where possible I > do. I will consider this point valid. When we changed CVS download steps, we should have updated the CVS web page right away. I did update the SGML version, but for other reasons, the web version didn't update and that caused great confusion. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
[HACKERS] Patch for fixing a few memory leaks
Patch fix memory leaks in src/backend/utils/fmgr/dfmgr.c . This leaks is very significant with massive update/insert tables with gist indexes in one transaction or with following sequence of commands: 1. COPY in table large number of row 2. CREATE GiST index on table 3. VACUUM ANALYZE On third step postgres eats very big number of memory. This patch fix it. BTW Tom, I want to notice that initGISTstate is called for every inserting value (for each row). I think it's not good, because this function called 'fmgr_info' 7 times. 'fmgr_info' call a 'load_external_function' with execution of sequence search on library name. Any suggestion? -- Teodor Sigaev [EMAIL PROTECTED] patch_dfmgr.gz ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
[HACKERS] how to increase the back end process
hi By default the backend process for postgresql is 32. I increased the N and B value and got to 140. Iam not able to increase it any more. The present N value is 1024 and B value is 2048. Can anyone help me in this. cheers balsu Do You Yahoo!? Send a newsletter, share photos & files, conduct polls, organize chat events. Visit http://in.groups.yahoo.com ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Patch for fixing a few memory leaks
Teodor Sigaev <[EMAIL PROTECTED]> writes: > Patch fix memory leaks in src/backend/utils/fmgr/dfmgr.c . Applied, thanks. (Looks like the leaks were introduced fairly recently by the dynamic-search-path feature.) > Tom, I want to notice that initGISTstate is called for every inserting > value (for each row). I think it's not good, because this function > called 'fmgr_info' 7 times. 'fmgr_info' call a > 'load_external_function' with execution of sequence search on library > name. Any suggestion? fmgr_info shouldn't be all that expensive; I'm not really inclined to worry about it. Do you have evidence to the contrary? regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Unhappiness with forced precision conversion for timestamp
> The code asserts that SQL99 requires the default precision to be zero, > but I do not agree with that reading. What I find is in 6.1: > 30) If is not specified, then 0 (zero) is implicit. > If is not specified, then 6 is implicit. > so at the very least you'd need two different settings for TIME and > TIMESTAMP. But we don't enforce the spec's idea of default precision > for char, varchar, or numeric, so why start doing so with timestamp? Sure, I'd forgotten about the 6 vs 0 differences. Easy to put back in. One of course might wonder why the spec *makes* them different. "Why start doing so with timestamp?". SQL99 compliance for one thing ;) I'm not sure I'm comfortable with the spec behavior, but without a discussion I wasn't comfortable implementing it another way. > Essentially, what I want is for gram.y to set typmod to -1 when it > doesn't see a "(N)" decoration on TIME/TIMESTAMP. I think everything > works correctly after that. "... works correctly..." == "... works the way we'd like...". Right? This is the start of the discussion I suppose. And I *expected* a discussion like this, since SQL99 seems a bit ill-tempered on this precision business. We shouldn't settle on a solution with just two of us, and I guess I'd like to hear from folks who have applications (the larger the better) who would care about this. Even better if their app had been running on some *other* DBMS. Anyone? - Thomas ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Timestamp, fractional seconds problem
Thomas Lockhart <[EMAIL PROTECTED]> writes: > ... then trailing zeros are hacked out, > two digits at a time. I was wondering why it seemed to always want to produce an even number of fractional digits. Why are you doing it 2 at a time and not 1? I should think timestamp(1) would produce 1 fractional digit, not two digits of which the second is always 0 ... regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Timestamp, fractional seconds problem
> > ... then trailing zeros are hacked out, > > two digits at a time. > I was wondering why it seemed to always want to produce an even number > of fractional digits. Why are you doing it 2 at a time and not 1? > I should think timestamp(1) would produce 1 fractional digit, not > two digits of which the second is always 0 ... Hmm. Good point wrt timestamp(1). I hack out two digits at a time to get convergence on a behavior consistant with previous releases of having (at least) two digits of precision (not one or three). I was trying to minimize the impact of the other changes. Note that another "arbitrary difference" is that, by default, TIMESTAMP is actually TIMESTAMP WITH TIME ZONE. SQL99 specifies otherwise, but there would seem to be fewer porting and upgrade issues for 7.2 if we choose the current behavior. Not sure where pg_dump and other utilities gin up the SQL9x type names, but we should fix things during beta to be consistant. - Thomas ---(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] cvs problem
On Wednesday 03 October 2001 07:53 pm, John Summerfield wrote: > On Tue, 2 Oct 2001, Lamar Owen wrote: > > On Monday 01 October 2001 07:33 pm, John Summerfield wrote: > > > Time to get your act together fellas. > > This is open source John, not rocket science. (pun intended) > Hmm. Kids I was at school with were building rockets in their backyards. > OSS is similarly a backyard affair. Awhere's the difference;-) But that's a _hobby_, not 'rocket science' -- and the pun was that there _is_ a rocket scientist among us Lots of us here are doing this as a hobby. > > Lighten up. The release will happen, regardless of minor server issues > > (that are being worked out right now, even as I write, by highly capable > > professionals, who, BTW, are doing this on a volunteer basis). > I appreciate the volunteer point. However, a project in disarray is a > project in disarray whether volunteer or not. Two weeks of disarray versus 5 years of soloid performance. You'd think a couple of weeks of temporary pain wouldn't be a big deal. > PG isn't perfect - we all know that. Nor is the project administration. > When there's a problem identified, someone has to take responsibility for > fixing it, and someone has to ensure the person reporting the problem has a > way forward. And the problem is being addressed. Patience is a good watchword. > "Lighten up" isn't the right response. Examine your project. See what > points I make have merit. Welcome criticism. You don't have to like the > message you know;-) No, I don't have to like the message. But the message can be phrased in a more polite way, as has been pointed out. You were just being a little too _serious_ about it, that's all. Give it a week or two, and things will be OK. The issues are in Vince and Marc's very capable hands -- but, as Marc said, this stuff has lived in the same place for >5 years -- and lots of interdependencies had to be addressed. And they _are_being addressed. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Timestamp, fractional seconds problem
Thomas Lockhart <[EMAIL PROTECTED]> writes: > Not sure where pg_dump and other utilities gin up the SQL9x type names, > but we should fix things during beta to be consistant. I believe pg_dump and psql are already okay now that I fixed format_type. Not sure if there are dependencies in other utilities. regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] BUG: text(varchar) truncates at 31 bytes
Thomas Lockhart <[EMAIL PROTECTED]> writes: >> Sure, I said *after* we fail to find an exact match. But the "freebie" >> match is for a function name that matches a type name and is >> binary-compatible with the source type. That's not a weak constraint. >> ISTM that interpretation should take priority over interpretations that >> involve more than one level of transformation. > Ah, OK I think. If there is a counterexample, it is probably no less > obscure than this one. Done. Essentially, this amounts to interchanging steps 2 and 3 of the function call resolution rules described at http://www.ca.postgresql.org/users-lounge/docs/7.1/postgres/typeconv-func.html regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Plpython bug with int8 - Found, need advice
Bradley McLean <[EMAIL PROTECTED]> writes: > 1) All of the conversion functions that return NULL ( line 1463 as > an example, page up and down from there) will cause the backend to terminate > abnormally. I'm not sure if this is considered a correct behavior, > or if elog(ERROR, ...) is a better approach. Comments? Backend coredump is never a correct behavior. I'd recommend elog ... regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Problem on AIX with current
> > > Only problem on AIX is, that the argv[0] stuff does not work anymore > > > (I think since we don't exec() anymore), which is rather annoying. > > > > Hmm, perhaps we are selecting the wrong PS_STRINGS method for AIX? > > Please look at src/backend/utils/misc/ps_status.c and see if one of > > the other methods will work on AIX. > > Yes, I see. Quite silly that I did not look earlier. > The compiler does not define _AIX4 or _AIX3, no idea who thought that. > It only defines _AIX, _AIX32, _AIX41 and _AIX43. > > I am quite sure that all AIX Versions accept the CLOBBER method, > thus I ask you to apply the following patch, to make it work. CLOBBER does not work with AIX5L, nor CHANGE_ARGV. (SETPROCTITLE, PSTAT and PS_STRINGS can not be used since AIX5L does not have appropreate header files). -- Tatsuo Ishii ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
[HACKERS] typo in src/interfaces/ecpg/preproc/preproc.y
Hi,
In trying to solve a bug in 'ALTER TABLE tbl RENAME col1 TO col2',I
noticed (what must be) a typo in src/interfaces/ecpg/preproc/preproc.y
patch attached, tho it might be easier if you just look for this
line in the file:
opt_column: COLUMN { $$ = make_str("colmunn"); }
Back to that original bug...
'ALTER TABLE tbl RENAME col1 TO col2' does not update any indices that
reference the old column name. Any suggestions to get this worked out
would be appreciated :-) I'll have some time this weekend to dig into
this, and would /really/ to tackle this myself.
cheers.
Brent
--
"Develop your talent, man, and leave the world something. Records are
really gifts from people. To think that an artist would love you enough
to share his music with anyone is a beautiful thing." -- Duane Allman
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] cvs problem
On Thu, 4 Oct 2001, Stephan Szabo wrote: > of the message this was in response to which appears to be what Lamar was > responding to. Besides, there's a far cry from a message of constructive > criticism and the message this was in response to. The point that the > documentation and reality need to match up is a good one, but saying > that "It's wrong because it's different from what worked before" isn't > reasonable. Saying, "This change is unfortunate and did it really have > to happen and why? And the documentation and the server realities really > have to match up. Perhaps changing the page first with a note of both > configurations with an estimated time change for the server would have > been better/the right way to do this" is reasonable. > How many people use anonymouse CVS? Hundreds? Thousands? Tens of thousands? You must have been fixing a pretty serious problem to justify inconveniencing them all. And if it really is that serious, add a word of explanation (to forestall problem reports) and apology. That is the point of my complaint. If it was just me, I'd shrug my shoulders and (once I figured out how) get on with it. ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] cvs problem
On Thu, 4 Oct 2001, Lamar Owen wrote: > On Wednesday 03 October 2001 07:53 pm, John Summerfield wrote: > > On Tue, 2 Oct 2001, Lamar Owen wrote: > > > On Monday 01 October 2001 07:33 pm, John Summerfield wrote: > > > > Time to get your act together fellas. > > > > This is open source John, not rocket science. (pun intended) > > > Hmm. Kids I was at school with were building rockets in their backyards. > > OSS is similarly a backyard affair. Awhere's the difference;-) > > But that's a _hobby_, not 'rocket science' -- and the pun was that there _is_ > a rocket scientist among us Lots of us here are doing this as a hobby. Well, I don't know the backgrounds of the folk here, any more than you know mine;-) And as far as I can tell, most open-source workers can properly be described as hobbyists. I know some get paid for their efforts, but not a lot. > > > Lighten up. The release will happen, regardless of minor server issues > > > (that are being worked out right now, even as I write, by highly capable > > > professionals, who, BTW, are doing this on a volunteer basis). > > > I appreciate the volunteer point. However, a project in disarray is a > > project in disarray whether volunteer or not. Well, remember I only arrived here in the past two weeks. What I've seen has not been reassuring. > > Two weeks of disarray versus 5 years of soloid performance. You'd think a > couple of weeks of temporary pain wouldn't be a big deal. > > > PG isn't perfect - we all know that. Nor is the project administration. > > When there's a problem identified, someone has to take responsibility for > > fixing it, and someone has to ensure the person reporting the problem has a > > way forward. > > And the problem is being addressed. Patience is a good watchword. It's hard to believe there's a serious effort being made to fix a problem when all the effort I can see has no apparent relationship to the problem. > > "Lighten up" isn't the right response. Examine your project. See what > > points I make have merit. Welcome criticism. You don't have to like the > > message you know;-) > > No, I don't have to like the message. But the message can be phrased in a > more polite way, as has been pointed out. You were just being a little too > _serious_ about it, that's all. Give it a week or two, and things will be I don't think I was being rude. It's true I'm no diplomat. I've criticised actions (and, I think, with considerable justice), but I've not actually criticised people. We all make mistakes, we should all be ready for them to be pointed out. > OK. The issues are in Vince and Marc's very capable hands -- but, as Marc > said, this stuff has lived in the same place for >5 years -- and lots of > interdependencies had to be addressed. And they _are_being addressed. And my point is that something moved. Something that many people (I don't know how many, but thousands wouldn't surprise me) depended on. I have over thirty years' experience in computing, many of them supporting users. That experiece tells me that making a change that inconveniences users is a mistake. If the change really must be made, do it so as to reduce the inconvenience as far as possible. >From my other readinds I see that the PG team controls the entire disk layout. Given >that, I can see no reason that the CVS tree needed to be changed in the way it was. I still think it should be made to work the old way; both ways, now, as there are people who depend on both structures. ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] cvs problem
On Tue, 2 Oct 2001, Lamar Owen wrote: > On Monday 01 October 2001 07:33 pm, John Summerfield wrote: > > It seems you don't have to be new here to be a bit peeved about things;-( > [snip] > > Time to get your act together fellas. > > This is open source John, not rocket science. (pun intended) Hmm. Kids I was at school with were building rockets in their backyards. OSS is similarly a backyard affair. Awhere's the difference;-) > > Lighten up. The release will happen, regardless of minor server issues (that > are being worked out right now, even as I write, by highly capable > professionals, who, BTW, are doing this on a volunteer basis). I appreciate the volunteer point. However, a project in disarray is a project in disarray whether volunteer or not. And the discussion that followed my original report of the CVS problem looked to me more like finger-pointing than a real effort to locate and fix the problem, or to help me on my way. I know I'm not well-known here, but I've made my contributions in other arenas where I'm stronger. PG isn't perfect - we all know that. Nor is the project administration. When there's a problem identified, someone has to take responsibility for fixing it, and someone has to ensure the person reporting the problem has a way forward. Changing the CVS repository so it doesn't work the same way any more isn't smart. Having wrong documentation isn't smart. Taking two weeks and NOT fixing a simple problem isn't smart. Giving wrong advice isn't smart. Test your advice - where possible I do. "Lighten up" isn't the right response. Examine your project. See what points I make have merit. Welcome criticism. You don't have to like the message you know;-) ---(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] cvs problem
On Thu, 4 Oct 2001, John Summerfield wrote: > I know I'm not well-known here, but I've made my contributions in other arenas where >I'm stronger. > > PG isn't perfect - we all know that. Nor is the project administration. When there's >a problem identified, someone has to take responsibility for fixing it, and someone >has to ensure the person reporting the problem has a way forward. > > > Changing the CVS repository so it doesn't work the same way any more isn't smart. >Having wrong documentation isn't smart. Taking two weeks and NOT fixing a simple >problem isn't smart. Giving wrong advice isn't smart. Test your advice - where >possible I do. > > "Lighten up" isn't the right response. Examine your project. See what points > I make have merit. Welcome criticism. You don't have to like the message you know;-) Do you know why you're not well known? With the pissy attitude you're showing here more and more folks tend to just drop your email in the bit bucket - like this... *** PLONK *** Vince. -- == Vince Vielhaber -- KA8CSHemail: [EMAIL PROTECTED]http://www.pop4.net 56K Nationwide Dialup from $16.00/mo at Pop4 Networking Online Campground Directoryhttp://www.camping-usa.com Online Giftshop Superstorehttp://www.cloudninegifts.com == ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] [COMMITTERS] pgsql/src/backend parser/parse_coerce.c utils/ ...
Thomas Lockhart <[EMAIL PROTECTED]> writes: >> Make the world safe for atttypmod=0 ... this didn't use to mean anything, >> but timestamp now wants it to mean something. > What was the effect of this? coerce_type_typemod thought that typmod=0 meant it shouldn't perform any length coercion. But typmod=0 is now a valid value for timestamp ... regards, tom lane ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [HACKERS] Timestamp, fractional seconds problem
Laurette Cisneros wrote: > > Could I get some more specific information on how this is fixed. Keep in mind that >using tochar() is not an option for us in that we ned to use COPY to/from the client. I'm finishing up implementing SQL99-style precision features in timestamp et al, so there will no longer be an arbitrary rounding of time to 2 decimal places when values are output. There will of course be *other* issues for you to worry about, since the default precision specified by SQL99 is zero decimal places... - Thomas ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[HACKERS] Unhappiness with forced precision conversion for timestamp
It seems to me that when there is no explicit precision notation attached, a time/timestamp datatype should not force a precision of zero, but should accept whatever it's given. This is analogous to the way we do char, varchar, and numeric: there's no length limit if you don't specify one. For example, I think this result is quite unintuitive: regression=# select '2001-10-04 13:52:42.845985-04'::timestamp; timestamptz 2001-10-04 13:52:43-04 (1 row) Throwing away the clearly stated precision of the literal doesn't seem like the right behavior to me. The code asserts that SQL99 requires the default precision to be zero, but I do not agree with that reading. What I find is in 6.1: 30) If is not specified, then 0 (zero) is implicit. If is not specified, then 6 is implicit. so at the very least you'd need two different settings for TIME and TIMESTAMP. But we don't enforce the spec's idea of default precision for char, varchar, or numeric, so why start doing so with timestamp? Essentially, what I want is for gram.y to set typmod to -1 when it doesn't see a "(N)" decoration on TIME/TIMESTAMP. I think everything works correctly after that. regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Beta time
> On Thu, 4 Oct 2001, Bruce Momjian wrote: >> Can we set a date for beta? If we are at least a week away, we should >> say that so people know they can keep working. I do not think we should slip it yet again, and especially not tell people "hey, send in more features", because that will lead to further slip. How about this Monday (10/8)? regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] timestamp resolution?
Thomas Lockhart <[EMAIL PROTECTED]> writes: > I'm going through gram.y and fixing up the implementations of > CURRENT_TIMESTAMP et al. One point folks will run into is that > CURRENT_TIMESTAMP *should* return time to the second, not fractions > thereof, and CURRENT_TIMESTAMP(p) should be used to get something more > precise. Another issue I just noticed is that the result of > create table t1 (d timestamp(2) default current_timestamp); > gives me two decimal points of fractional seconds (after fixups for > Tatsuo's reported troubles) but I would think that it should round to > the second. Looks like we are "type folding" past the typmod attributes. No, it's just that CURRENT_TIMESTAMP doesn't presently reduce its precision, as you assert it should do. However, I see nothing in SQL99 6.19 that asserts anything about the precision of CURRENT_TIMESTAMP without a precision indicator. It just says 2) If specified, and respectively determine the precision of the time or timestamp value returned. which seems to leave it up to us to choose the behavior when no precision is specified. I'd prefer to see CURRENT_TIMESTAMP return as much precision as possible (see also previous message). BTW, CURRENT_TIME and CURRENT_TIMESTAMP should return TIMETZ and TIMESTAMPTZ respectively, but currently do not --- are you fixing that? regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Beta time
> > On Thu, 4 Oct 2001, Bruce Momjian wrote: > >> Can we set a date for beta? If we are at least a week away, we should > >> say that so people know they can keep working. > > I do not think we should slip it yet again, and especially not tell > people "hey, send in more features", because that will lead to further > slip. > > How about this Monday (10/8)? OK, can I get another vote for that date. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Problem on AIX with current
Your patch has been added to the PostgreSQL unapplied patches list at: http://candle.pha.pa.us/cgi-bin/pgpatches I will try to apply it within the next 48 hours. > > > > Only problem on AIX is, that the argv[0] stuff does not work anymore > > > (I think since we don't exec() anymore), which is rather annoying. > > > > Hmm, perhaps we are selecting the wrong PS_STRINGS method for AIX? > > Please look at src/backend/utils/misc/ps_status.c and see if one of > > the other methods will work on AIX. > > Yes, I see. Quite silly that I did not look earlier. > The compiler does not define _AIX4 or _AIX3, no idea who thought that. > It only defines _AIX, _AIX32, _AIX41 and _AIX43. > > I am quite sure that all AIX Versions accept the CLOBBER method, > thus I ask you to apply the following patch, to make it work. > > Andreas Content-Description: ps_status.patch [ Attachment, skipping... ] > > ---(end of broadcast)--- > TIP 4: Don't 'kill -9' the postmaster -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Timestamp, fractional seconds problem
Thomas, Can you explain more how this functionality has changed? I know that in the JDBC driver fractional seconds are assumed to be two decimal places. If this is no longer true, I need to understand the new symantics so that the JDBC parsing routines can be changed. Other interfaces may have similar issues. thanks, --Barry Thomas Lockhart wrote: >>Problem: the external representation of time and timestamp are >> less precise than the internal representation. >> > > Fixed (as of yesterday) in the upcoming release. > >- Thomas > > ---(end of broadcast)--- > TIP 2: you can get off all lists at once with the unregister command > (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED]) > > ---(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] Patch for fixing a few memory leaks
Patch applied. Thanks. > Patch fix memory leaks in src/backend/utils/fmgr/dfmgr.c . > This leaks is very significant with massive update/insert tables with gist > indexes in one transaction or with following sequence of commands: > 1. COPY in table large number of row > 2. CREATE GiST index on table > 3. VACUUM ANALYZE > On third step postgres eats very big number of memory. > This patch fix it. > > BTW > Tom, I want to notice that initGISTstate is called for every inserting value > (for each row). I think it's not good, because this function called 'fmgr_info' > 7 times. 'fmgr_info' call a 'load_external_function' with execution of sequence > search on library name. Any suggestion? > > -- > Teodor Sigaev > [EMAIL PROTECTED] > [ Attachment, skipping... ] > > ---(end of broadcast)--- > TIP 6: Have you searched our list archives? > > http://archives.postgresql.org -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026 ---(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] CVS changes
On Thu, 4 Oct 2001, John Summerfield wrote: > On Tue, 2 Oct 2001, Bruce Momjian wrote: > > > > > On Sun, 30 Sep 2001, Bruce Momjian wrote: > > > > > > > > > > > On Sun, 30 Sep 2001, Bruce Momjian wrote: > > Script attached. I could poll cvs more frequently but it seems rude to > > hit the cvs server more frequently than every 15 minutes. If people > > want it polled more frequently, and Marc doesn't mind, I can change the > > polling interval here. > > > > Also, I added something that will show the files modified in the current > > build. > > > I'm not vary familiar with the administration of CVS - if it has a means to > run a script when something's updated, maybe you could flag the need to rebuild > automatically. It has that ability, but only on the server itself ... bruce has taken it upon himself to do this on his own machine, while the base problem is worked on, which is moving everything over to the new server ... Its had its hiccups, but considering we really haven't moved anything anywhere in >5 years now, and considering we are not in beta yet, we've done a decent job of getting problems fixed as soon as they've been reported ... ---(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] Timestamp, fractional seconds problem
Thanks Thomas...at least there will be a way to specify more than 2. we are looking forward to this release... L. On Thu, 4 Oct 2001, Thomas Lockhart wrote: > Laurette Cisneros wrote: > > > > Could I get some more specific information on how this is fixed. Keep in mind >that using tochar() is not an option for us in that we ned to use COPY to/from the >client. > > I'm finishing up implementing SQL99-style precision features in > timestamp et al, so there will no longer be an arbitrary rounding of > time to 2 decimal places when values are output. There will of course be > *other* issues for you to worry about, since the default precision > specified by SQL99 is zero decimal places... > > - Thomas > -- Laurette Cisneros (510) 420-3137 NextBus Information Systems, Inc. www.nextbus.com Passenger Information Everywhere ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Timestamp, fractional seconds problem
> Can you explain more how this functionality has changed? I know that in > the JDBC driver fractional seconds are assumed to be two decimal places. > If this is no longer true, I need to understand the new symantics so > that the JDBC parsing routines can be changed. Other interfaces may > have similar issues. OK. (Remember that the new behaviors can be changed if this doesn't work for you). Formerly, all times had either zero or two fractional decimal places. Now, times are explicitly truncated to their defined precision at a few specific points in processing (e.g. when reading a literal constant or when storing into a column). At all other points in processing, the values are allowed to take on whatever fractional digits might have come from math operations or whatever. The output routines now write the maximum number of fractional digits reasonably present for a floating point number (10 for time, should be but isn't less for timestamp) and then trailing zeros are hacked out, two digits at a time. The regression tests produced basically the same results as always, once the time and timestamp columns were defined to be "time(2)" or "timestamp(2)". But there is definitely the possibility of more precision than before in the output string for time fields. - Thomas ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] timestamp resolution?
> No, it's just that CURRENT_TIMESTAMP doesn't presently reduce its > precision, as you assert it should do. However, I see nothing in SQL99 > 6.19 that asserts anything about the precision of CURRENT_TIMESTAMP > without a precision indicator. It just says > 2) If specified, and > respectively determine the precision of the time or timestamp > value returned. > which seems to leave it up to us to choose the behavior when no > precision is specified. I'd prefer to see CURRENT_TIMESTAMP return as > much precision as possible (see also previous message). Hmm. Somewhere else it *does* specify a precision of zero for TIME and TIMESTAMP; wonder why that rule wouldn't apply to CURRENT_TIME etc too? Not that lots of precision isn't good, but I'd like to be consistant. > BTW, CURRENT_TIME and CURRENT_TIMESTAMP should return TIMETZ and > TIMESTAMPTZ respectively, but currently do not --- are you fixing that? Yup. Though I'm not certain that it would effectively be any different. - Thomas ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Beta time
... > OK, can I get another vote for that date. What was wrong with the 10th? I'm going to be tied up for most of the time between now and Monday. - Thomas ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] timestamp resolution?
... > Hmm. Somewhere else it *does* specify a precision of zero for TIME and > TIMESTAMP; wonder why that rule wouldn't apply to CURRENT_TIME etc too? > Not that lots of precision isn't good, but I'd like to be consistant. Ah, I'd forgotten about the 6 vs 0 behaviors (but had them in the code just a couple of days ago ;) - Thomas ---(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] Timestamp, fractional seconds problem
This is very good news. Thanks to all for the response. L. On Thu, 4 Oct 2001, Karel Zak wrote: > On Wed, Oct 03, 2001 at 05:02:59PM -0700, Laurette Cisneros wrote: > > > A work around for display might be to use to_char(). > > In 7.2 is possible use millisecond / microsecond format: > > # select to_char(now()+'2s 324 ms'::interval, 'HH:MM:SS MS'); >to_char > -- > 10:10:59 324 > (1 row) > > # select to_char(now()+'2s 324 ms 10 microsecon'::interval, 'HH:MM:SS US'); > to_char > - > 10:10:03 324010 > (1 row) > > Karel > > -- Laurette Cisneros (510) 420-3137 NextBus Information Systems, Inc. www.nextbus.com Passenger Information Everywhere ---(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] Feature suggestion: Postgresql binding to one IP?
Hi Lincoln, Not sure why you would want to run multiple instances, since you can run multiple dbs if you want to maintain separate environments but if you really need to do this, the postmaster has some options which control ip/port binds: [pritchma@blade pritchma]$ /usr/local/pgsql/bin/postmaster --help /usr/local/pgsql/bin/postmaster is the PostgreSQL server. Usage: /usr/local/pgsql/bin/postmaster [options...] Options: -B NBUFFERS number of shared buffers (default 64) -c NAME=VALUE set run-time parameter -d 1-5 debugging level -D DATADIR database directory -F turn fsync off -h HOSTNAME host name or IP address to listen on -i enable TCP/IP connections -k DIRECTORYUnix-domain socket location -N MAX-CONNECT maximum number of allowed connections (1..1024, default 32) -o OPTIONS pass 'OPTIONS' to each backend server -p PORT port number to listen on (default 5432) -S silent mode (start in background without logging output) Developer options: -n do not reinitialize shared memory after abnormal exit -s send SIGSTOP to all backend servers if one dies I run postgres on a box with two interfaces, and I only want it to bind to a single one: # start postgres nohup > /dev/null su -c '/usr/local/pgsql/bin/postmaster -h 10.4.0.1 -i -D /usr/local/pgsql/data > /usr/local/pgsql/log/server.log 2>&1' postgres & Cheers, Mark Pritchard ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Timestamp, fractional seconds problem
Hi Thomas, Could I get some more specific information on how this is fixed. Keep in mind that using tochar() is not an option for us in that we ned to use COPY to/from the client. Thanks, L. On Thu, 4 Oct 2001, Thomas Lockhart wrote: > > Problem: the external representation of time and timestamp are > > less precise than the internal representation. > > Fixed (as of yesterday) in the upcoming release. > >- Thomas > -- Laurette Cisneros (510) 420-3137 NextBus Information Systems, Inc. www.nextbus.com Passenger Information Everywhere ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] cvs problem
... > I hope you're in better shape by beta time. Hi John. I would highly recommend taking a deep breath and coming back in a couple of weeks. Things should have settled down by then and we will have returned to your high standards of service and support. In the meantime, folks are busy getting us there... Regards. - Thomas ---(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] [COMMITTERS] pgsql/src/backend parser/parse_coerce.c utils/ ...
> src/backend/parser: parse_coerce.c > src/backend/utils/adt: format_type.c > Log message: > Make the world safe for atttypmod=0 ... this didn't use to mean anything, > but timestamp now wants it to mean something. What was the effect of this? - Thomas ---(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] timestamp resolution?
... > Ah, I've got it. Two problems: AdjustTimestampForTypmod is one brick > shy of a load, and the hardwired calls to timestamp_in and friends > weren't passing all the parameters they should. (Can anyone think of > a way for DirectFunctionCall to do any checking?) OK, I found the second item last night, but am not sure why AdjustTimestampForTypmod needs more fixes. I'm going through gram.y and fixing up the implementations of CURRENT_TIMESTAMP et al. One point folks will run into is that CURRENT_TIMESTAMP *should* return time to the second, not fractions thereof, and CURRENT_TIMESTAMP(p) should be used to get something more precise. Another issue I just noticed is that the result of create table t1 (d timestamp(2) default current_timestamp); gives me two decimal points of fractional seconds (after fixups for Tatsuo's reported troubles) but I would think that it should round to the second. Looks like we are "type folding" past the typmod attributes. Comments? - Thomas ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Timestamp, fractional seconds problem
On Wed, Oct 03, 2001 at 05:02:59PM -0700, Laurette Cisneros wrote: > A work around for display might be to use to_char(). In 7.2 is possible use millisecond / microsecond format: # select to_char(now()+'2s 324 ms'::interval, 'HH:MM:SS MS'); to_char -- 10:10:59 324 (1 row) # select to_char(now()+'2s 324 ms 10 microsecon'::interval, 'HH:MM:SS US'); to_char - 10:10:03 324010 (1 row) Karel -- Karel Zak <[EMAIL PROTECTED]> http://home.zf.jcu.cz/~zakkr/ C, PostgreSQL, PHP, WWW, http://docs.linux.cz, http://mape.jcu.cz ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Feature suggestion: Postgresql binding to one
At 11:16 PM 03-10-2001 -0400, Tom Lane wrote: >Lincoln Yeoh <[EMAIL PROTECTED]> writes: >> Is it possible for Postgresql to bind to one IP address? > >See 'virtual_host' GUC parameter. > > regards, tom lane Thanks! I'm using a redhat style postgresql init and somehow postgresql seems to ignore the postgresql.conf file. What's the postmaster.opts file for? Cheerio, Link. ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] BUG: text(varchar) truncates at 31 bytes
> Thomas Lockhart <[EMAIL PROTECTED]> writes: > >> Perhaps it'd be a better idea for the option of a freebie conversion > >> to be checked earlier, say immediately after we discover there is no > >> exact match for the function name and input type. Thomas, what do you > >> think? > > > We *really* need that catalog lookup first. Otherwise, we will never be > > able to override the hardcoded compatibility assumptions in that > > matching routine. > > Sure, I said *after* we fail to find an exact match. But the "freebie" > match is for a function name that matches a type name and is > binary-compatible with the source type. That's not a weak constraint. > ISTM that interpretation should take priority over interpretations that > involve more than one level of transformation. That sounds very reasonable to me. Andreas ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] CVS changes
On Tue, 2 Oct 2001, Bruce Momjian wrote: > > On Sun, 30 Sep 2001, Bruce Momjian wrote: > > > > > > > > On Sun, 30 Sep 2001, Bruce Momjian wrote: > Script attached. I could poll cvs more frequently but it seems rude to > hit the cvs server more frequently than every 15 minutes. If people > want it polled more frequently, and Marc doesn't mind, I can change the > polling interval here. > > Also, I added something that will show the files modified in the current > build. I'm not vary familiar with the administration of CVS - if it has a means to run a script when something's updated, maybe you could flag the need to rebuild automatically. ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
[HACKERS] Beta time
Can we set a date for beta? If we are at least a week away, we should say that so people know they can keep working. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Feature suggestion: Postgresql binding to one
Lincoln Yeoh <[EMAIL PROTECTED]> writes: > I'm using a redhat style postgresql init and somehow postgresql seems to > ignore the postgresql.conf file. That seems unlikely, assuming you are running a PG version recent enough to have a postgresql.conf file (ie 7.1 or better). What exactly are you putting into postgresql.conf? Also, take a look at the postmaster log to see if it's issuing any complaints. I believe a syntax error anywhere in the conf file will cause the whole file to be ignored ... > What's the postmaster.opts file for? It's to log the command-line options you gave to the postmaster. regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] What about CREATE OR REPLACE FUNCTION?
> > Did we come to any conclusion about whether to accept Gavin Sherry's > > CREATE OR REPLACE FUNCTION patch? > > http://fts.postgresql.org/db/mw/msg.html?mid=1035792 > > AFAIR, the score was that I liked it, Bruce didn't, and no one else > > had expressed an opinion. > >I withdraw my objection. When I read it, I thought we were going to >have CREATE FUNCTION and REPLACE FUNCTION. I later realized it is >literally CREATE OR REPLACE FUNCTION. Looks strange, but there is no >standard way to do this and we usually take the Oracle syntax when the >standard doesn't specify it. > >Bruce Momjian| http://candle.pha.pa.us >[EMAIL PROTECTED] | (610) 853-3000 >+ If your life is a hard drive, | 830 Blythe Avenue >+ Christ can be your backup.| Drexel Hill, Pennsylvania 19026 > >TIP 5: Have you checked our extensive FAQ? >http://www.postgresql.org/users-lounge/docs/faq.html Hello, Does CREATE OR REPLACE FUNCTION preserve function OID? What it the difference with CREATE OR ALTER FUNCTION? We would like to implement pseudo-editing of functions in pgAdmin II. Is there any solution which preserves function OID? Best regards, Jean-Michel POURE ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] What about CREATE OR REPLACE FUNCTION?
On Thu, 4 Oct 2001, Jean-Michel POURE wrote: > Hello, > > Does CREATE OR REPLACE FUNCTION preserve function OID? > What it the difference with CREATE OR ALTER FUNCTION? > > We would like to implement pseudo-editing of functions in pgAdmin II. > Is there any solution which preserves function OID? Yes. The idea was to preserve the OID. > > Best regards, > Jean-Michel POURE Gavin ---(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] What about CREATE OR REPLACE FUNCTION?
Jean-Michel POURE <[EMAIL PROTECTED]> writes: > Does CREATE OR REPLACE FUNCTION preserve function OID? Yes. That's the whole point ... > What it the difference with CREATE OR ALTER FUNCTION? The former exists (now), the latter doesn't exist. regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] timestamp resolution?
Thomas Lockhart <[EMAIL PROTECTED]> writes: > Even stranger, this only happens on the first call to CURRENT_TIMESTAMP > after starting a backend (example below), and stays that way if I just > do "select current_timestamp". Something must not be initialized quite > right, but I don't know what. Any guesses? Ah, I've got it. Two problems: AdjustTimestampForTypmod is one brick shy of a load, and the hardwired calls to timestamp_in and friends weren't passing all the parameters they should. (Can anyone think of a way for DirectFunctionCall to do any checking?) Patch will be committed in a moment... regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Patch for fixing a few memory leaks
Tom Lane writes: > Applied, thanks. (Looks like the leaks were introduced fairly > recently by the dynamic-search-path feature.) Is there some sort of a system behind which places are subject to leaks and which places are just too lazy to call pfree()? I know that index support procedures must not leak, hmm, I guess this would include the function manager... (If that was not the right explanation, stop reading here.) Why aren't index support procedures called with an appropriate memory context set up? Since the functions currently do all the cleaning themselves, couldn't it work like this: 1. set up memory context 2. call index procedure 3. clean out memory context (This could even be slightly more efficient.) Then again, I'm probably oversimplifying things... -- Peter Eisentraut [EMAIL PROTECTED] http://funkturm.homeip.net/~peter ---(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] Patch for fixing a few memory leaks
Peter Eisentraut <[EMAIL PROTECTED]> writes: > Is there some sort of a system behind which places are subject to leaks > and which places are just too lazy to call pfree()? > I know that index support procedures must not leak, hmm, I guess this > would include the function manager... Yeah, that's basically why there's a problem here --- if this weren't getting called from the index support area, I don't think the leak would matter. > Why aren't index support procedures called with an appropriate memory > context set up? I looked at recovering space after index operations but decided it would take more work than I could invest at the time. The trouble is that several of the index AMs allocate space that they expect to stick around across operations, so they'd have to be fixed to use a special context for such things. Eventually it'd be nice to fix it properly, ie, run index support routines with CurrentMemoryContext = a short-term context, just as you say. regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Problem on AIX with current
Patch rejected, please resubmit: CLOBBER does not work with AIX5L, nor CHANGE_ARGV. (SETPROCTITLE, PSTAT and PS_STRINGS can not be used since AIX5L does not have appropreate header files). -- Tatsuo Ishii > > > > Only problem on AIX is, that the argv[0] stuff does not work anymore > > > (I think since we don't exec() anymore), which is rather annoying. > > > > Hmm, perhaps we are selecting the wrong PS_STRINGS method for AIX? > > Please look at src/backend/utils/misc/ps_status.c and see if one of > > the other methods will work on AIX. > > Yes, I see. Quite silly that I did not look earlier. > The compiler does not define _AIX4 or _AIX3, no idea who thought that. > It only defines _AIX, _AIX32, _AIX41 and _AIX43. > > I am quite sure that all AIX Versions accept the CLOBBER method, > thus I ask you to apply the following patch, to make it work. > > Andreas Content-Description: ps_status.patch [ Attachment, skipping... ] > > ---(end of broadcast)--- > TIP 4: Don't 'kill -9' the postmaster -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026 ---(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] cvs problem
On Tue, 2 Oct 2001, Vince Vielhaber wrote: > On Tue, 2 Oct 2001, John Summerfield wrote: > > > On Mon, 1 Oct 2001, Tom Lane wrote: > > > > > > > Bruce Momjian <[EMAIL PROTECTED]> writes: > > > > The one thing I can't check is the anoncvs directory. Not sure if that > > > > is the same as the CVS directory. > > > > > > It is the anoncvs server that's broken. The committers don't seem to be > > > having any problem with accesses to the primary server. I suspect that > > > there's a umask or group-membership issue on the anoncvs machine only. > > > > > > It seems you don't have to be new here to be a bit peeved about things;-( > > > > > > I'm peeved because I found instructions on how to checkout with anonymous CVS and >did so a few times. > > > > I had a find old time finding and reporting problems (with the software). > > > > Then CVS stopped working because someone thought it a fine idea to reorganise the >directory structure, to change the CVSROOT. No matter the user who had the old one >stored on their computers. > > Gee, I didn't realize we were doing it just cuze "someone thought it a > fine idea" Then why didn't you put it back the way it had been when it worked? When someone does a cvs login, cvs records the value for CVSROOT. You made everyone's cvs login fail. I don't see the sense in that. And then you diddle round endlessly instead of telling me what I had to do to fix YOUR mistake. I hope you're in better shape by beta time. And instead of componding the problem with rudeness, listen to it. You don't have to like the message or the language, but there are reasons for both. ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
