> The Upper- and the lower function don't convert the german umlauts (ü.ä.ö.) but
>leave them in their original condition
Gert (or anyone): what should the result be? I'm German-impaired, so
you'll need to be more specific. Did you compile with locale turned on?
Multi-byte character sets?? Which
Matthew <[EMAIL PROTECTED]> writes:
>> I think we have found a bug in postgresql 7.0.2.
Bug confirmed --- on a compilation with Asserts enabled, this sequence
causes an assert failure during update of pg_group_name_index in the
DROP USER command, in both 7.0.* and current sources. I ran out of
s
"John Huttley" <[EMAIL PROTECTED]> writes:
> Documentation on time constants and how to misuse them is weak...
You can say that again! Who's up for submitting documentation patches?
regards, tom lane
- Original Message -
From: Bruce Momjian <[EMAIL PROTECTED]>
To: Alex Pilosov <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Wednesday, 18 October 2000 16:21
Subject: Re: [HACKERS] time stops within transaction
> Wow, that is strange.
>
>
> > I just ran into a strangest thing: within
Alex Pilosov <[EMAIL PROTECTED]> writes:
> I just ran into a strangest thing: within transaction, select now() will
> always return time when transaction started.
That is what now() is defined to return: transaction start time.
Perhaps the documentation needs improvement...
Wow, that is strange.
> I just ran into a strangest thing: within transaction, select now() will
> always return time when transaction started. Same happens with select
> 'now'::timestamp.
>
> This is with 7.0. I have not tested it with CVS.
>
> I am not sure what causes this. I assume that re
Strangely, the same thing does not happen when I do timenow() instead of
time(). This is very counter-intuitive, if this is the way it is supposed
to work, at least docs should be saying that.
Also, I checked, and its probably not the fmgr cache, since now() is set
to be noncacheable...
-alex
I just ran into a strangest thing: within transaction, select now() will
always return time when transaction started. Same happens with select
'now'::timestamp.
This is with 7.0. I have not tested it with CVS.
I am not sure what causes this. I assume that result of now() is cached by
fmgr. Is th
> I think we have found a bug in postgresql 7.0.2. If I'm right then a fix
> for this should probably be added to 7.0.3 also. Anyway without further
> adieu:
>
> I have attached detail of my session at the end of this email, but the
> summary is as follows.
>
> If I run the following commands
On Tuesday 17 October 2000 16:33, Tom Lane wrote:
> Mark Hollomon <[EMAIL PROTECTED]> writes:
> > In tcop/ulitity.c we have the following code fragment:
> > case VIEW:
> > {
> > char *viewName = stmt->name;
> > char *ruleName;
> >
> > ruleName = MakeRetrieveViewRuleName(vie
Tatsuo Ishii <[EMAIL PROTECTED]> writes:
>> bpcharin() will most definitely NOT fix the problem, because it often
>> will not know the target column's typmod, if indeed there is an
>> identifiable target column at all.
> Can you give me any example for this case?
UPDATE foo SET bpcharcol = 'a':
> Tatsuo Ishii <[EMAIL PROTECTED]> writes:
> > I'm going to fix the problem by changing bpcharin() rather than
> > changing exprTypmod(). Surely we could fix the problem by changing
> > exprTypmod() for INSERT, however, we could not fix the similar problem
> > for COPY FROM in the same way. Chang
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> I don't know how it looks now, but the "DROP TABLE x, y, z" was pretty
> broken a while ago. For example, if there was some sort of dependency
> between the tables (foreign keys?) it would abort and leave an
> inconsistent state. I'm not very fond o
Mark Hollomon <[EMAIL PROTECTED]> writes:
> In tcop/ulitity.c we have the following code fragment:
> case VIEW:
> {
> char *viewName = stmt->name;
> char *ruleName;
> ruleName = MakeRetrieveViewRuleName(viewName);
> relationName = RewriteGetRuleEventRel(ruleNam
Mark Hollomon writes:
> Also
>
> "DROP TABLE x, y, z" is allowed, but
>
> "DROP VIEW x, y, z" is not.
>
> Any reason other than historical?
I don't know how it looks now, but the "DROP TABLE x, y, z" was pretty
broken a while ago. For example, if there was some sort of dependency
between the
In tcop/ulitity.c we have the following code fragment:
case VIEW:
{
char *viewName = stmt->name;
char *ruleName;
ruleName = MakeRetrieveViewRuleName(viewName);
relationName = RewriteGetRuleEventRel(ruleName);
This looks like an expensive no-op to me.
> I'm still nervous about how we're going to test the WAL code
> adequately for the lesser-used index types. Any ideas out there?
First, seems we'll have to follow to what you've proposed for
their redo/undo: log each *fact* of changing a page to know
was update op done entirely or not (rebuild
> > >It is not premature. We will need a WAL based restore for 7.1
> > >or we imho don't need to enable WAL for 7.1 at all.
> >
> > I missed your point here - why ?!
> > New backup/restore is not only result of WAL.
> > What about recovery & performance?
>
> Ok, recovery is only improved for ind
> > > First, since when are we in the business of hiding away documentation for
> > > a supported platform, and second, how does putting installation
> > > instructions into a file named "FAQ" make it less "obvious"?
> >
> > Help, I am losing here. Does anyone want to help me... :-)
>
> I'm ha
On Tue, 17 Oct 2000, Bruce Momjian wrote:
> > Bruce Momjian writes:
> >
> > > > Bruce Momjian - CVS writes:
> > > >
> > > > > FAQ_MSWIN is better than INSTALL_MSWIN
> > > >
> > > > No it's not... The file in question doesn't contain any questions or
> > > > answers, it contains installation i
Bruce Momjian <[EMAIL PROTECTED]> writes:
>> First, since when are we in the business of hiding away documentation for
>> a supported platform, and second, how does putting installation
>> instructions into a file named "FAQ" make it less "obvious"?
> Help, I am losing here. Does anyone want to
Jeff Hoffmann <[EMAIL PROTECTED]> writes:
> my question is whether i should change the function to use the new fmgr
> type of definition or if it's only for internal functions.
Up to you. If you need any of the new features (like clean handling
of NULLs) then convert. If you were happy with the
> Bruce Momjian writes:
>
> > > Bruce Momjian - CVS writes:
> > >
> > > > FAQ_MSWIN is better than INSTALL_MSWIN
> > >
> > > No it's not... The file in question doesn't contain any questions or
> > > answers, it contains installation instructions for Windows. Oh, and yes,
> > > Microsoft does
* Michael J Schout <[EMAIL PROTECTED]> [001017 08:50] wrote:
> Tom:
>
> I think I may have been seeing this problem as well. We were getting
> crashes very often with 7.0.2 during VACUUM's if activity was going
> on to our database during the vacuum (even though the activity was
> light). Our
Bruce Momjian writes:
> > Bruce Momjian - CVS writes:
> >
> > > FAQ_MSWIN is better than INSTALL_MSWIN
> >
> > No it's not... The file in question doesn't contain any questions or
> > answers, it contains installation instructions for Windows. Oh, and yes,
> > Microsoft does own the Windows n
i've started playing with the 7.1 snapshots to try out the toast
support. now it looks like i'm going to have to change a bunch of C
functions that i have that call internal postgres functions, which
didn't seem to be a problem (other than some extra typing) but my
question is whether i should ch
Michael J Schout <[EMAIL PROTECTED]> writes:
> I think I may have been seeing this problem as well. We were getting
> crashes very often with 7.0.2 during VACUUM's if activity was going
> on to our database during the vacuum (even though the activity was
> light). Our solution in the meantime w
Under current sources, it no longer crashes, it just elogs now
after Tom's changes. When I get more time I'd like to put in a
more complete solution (possibly moving to oids rather than names
in the argument list in the process). There are alot of other related
problems (rename column, check c
Tatsuo Ishii <[EMAIL PROTECTED]> writes:
> It seems some incompatible changes have been made between 7.0 and
> current. In 7.0, if a parameter is NULL OR a null string (""), then
> the value from an environment variable is applied. However in current
> ONLY NULL is considered. Is there any reason
Yep, that's the one. I was going to resend, but it had
disappeared from my sent mail for some reason.
On Tue, 17 Oct 2000, Bruce Momjian wrote:
> >
> > This effectively one line patch should fix the fact that
> > foreign key definitions in create table were erroring if
> > a primary key was
Tom:
I think I may have been seeing this problem as well. We were getting
crashes very often with 7.0.2 during VACUUM's if activity was going
on to our database during the vacuum (even though the activity was
light). Our solution in the meantime was to simply disable the
aplications during a v
Tatsuo Ishii writes:
> It seems some incompatible changes have been made between 7.0 and
> current. In 7.0, if a parameter is NULL OR a null string (""), then
> the value from an environment variable is applied. However in current
> ONLY NULL is considered. Is there any reason for this?
Yes, the
Tatsuo Ishii <[EMAIL PROTECTED]> writes:
> I'm going to fix the problem by changing bpcharin() rather than
> changing exprTypmod(). Surely we could fix the problem by changing
> exprTypmod() for INSERT, however, we could not fix the similar problem
> for COPY FROM in the same way. Changing bpchar
Bruce Momjian writes:
> Peter, comments?
It doesn't destroy all databases anymore, although I can't make any
statements about what it actually does do. I suppose it's still broken.
> > Richard Poole <[EMAIL PROTECTED]> writes:
> > > It seems that initdb starts a single-user backend but gives i
I don't know if this has been fixed or not, but alter table will not
adjust RI/FK triggers on the table.
I.E:
create table foo (a int4 primary key)
create table bar (b int4 references foo)
alter table foo rename to foo2
now, updates to foo will either crash or hang postgres.
What needs to be
> Bruce Momjian wrote:
> >
> > > > > I doubt everyone would like trading query speed for insert/update
> > > > > speed plus index size
> > > >
> > > > If he is scanning through the entire index, he could do a sequential
> > > > scan of the table, grab all the tid transaction status values, and us
On Monday 16 October 2000 20:56, Tom Lane wrote:
> Mark Hollomon <[EMAIL PROTECTED]> writes:
> I say let them drop it with either one.
> >>
> >> I kinda like the 'drop index with drop index', 'drop table with drop
> >> table' and 'drop view with drop view' groupings ... at least you are
> >>
Andrew McMillan <[EMAIL PROTECTED]> writes:
>
> I would _love_ to see full-text or keyword indexing natively in
> PostgreSQL.
>
I would rather love to see a great fulltext engine integrated with
PostgreSQL. It would be cool to be able to have ranked results and
different ways of searching the i
It seems some incompatible changes have been made between 7.0 and
current. In 7.0, if a parameter is NULL OR a null string (""), then
the value from an environment variable is applied. However in current
ONLY NULL is considered. Is there any reason for this?
--
Tatsuo Ishii
> It's just hardwired knowledge about that particular datatype. In the
> light of your comments, it seems clear that the code here is wrong
> for the MULTIBYTE case: instead of plain VARSIZE(), it should be
> returning the number of multibyte characters + 4 (or whatever
> atttypmod is defined to
> > > > those when viewing the index. No need to store/update the transaction
> > > > status in the index that way.
> > >
> > > Huh ? How ? It is how you do it now. Do you expect
> > > load several milion transaction statuses into memory,
> > > then scan index and lookup these values ?
> > > Miss
> > I doubt everyone would like trading query speed for insert/update
> > speed plus index size
>
> If he is scanning through the entire index, he could do a sequential
> scan of the table, grab all the tid transaction status values, and use
> those when viewing the index. No need to store/upda
Bruce Momjian wrote:
>
> > > > I doubt everyone would like trading query speed for insert/update
> > > > speed plus index size
> > >
> > > If he is scanning through the entire index, he could do a sequential
> > > scan of the table, grab all the tid transaction status values, and use
> > > those
> > > I doubt everyone would like trading query speed for insert/update
> > > speed plus index size
> >
> > If he is scanning through the entire index, he could do a sequential
> > scan of the table, grab all the tid transaction status values, and use
> > those when viewing the index. No need t
Hi guys,
Havin some trouble.
One of my databases appeared to be empty suddenly after having a large
amount of data in it. I contacted our server company and they gave me the
postgres dir.
I have put back the folder of the newsdatabase from the base dir into the
base dir of Postgres and rec
Bruce Momjian wrote:
> I can not apply this. Seems it has changed in the current tree. Here
> is the current plperl.c file.
>
It seems that the current file has been fixed. There's no more call to the
buggy variables in it. I don't know what you want me to do ?
Do you still have problem to com
> >It is not premature. We will need a WAL based restore for 7.1
> >or we imho don't need to enable WAL for 7.1 at all.
>
> I missed your point here - why ?!
> New backup/restore is not only result of WAL.
> What about recovery & performance?
Ok, recovery is only improved for indexes, no ?
Perf
Andrew McMillan wrote:
>
> Bruce Momjian wrote:
> >
> > See contrib/fulltextindex.
>
> An easy answer, but not a very good solution in the real world.
>
> contrib/fulltextindex requires you to jump through hoops in developing
> queries to retrieve your data. It's also very space-inefficient in
Alfred Perlstein wrote:
> Thank you, it's not a big problem that this doesn't happen, but it'd
> be nice to see it as an option when creating a table via inheritance.
>
> What about RULEs? I wouldn't really have a use for that but others
> might.
Actually it's a reasonably big deal. Apart from
Zeugswetter Andreas SB wrote:
> > This style of "DROP COLUMN" would change the attribute
> > numbers whose positons are after the dropped column.
> > Unfortunately we have no mechanism to invalidate/remove
> > objects(or prepared plans) which uses such attribute numbers.
> > And I've seen no pro
> Just a confirmation.
> Do you plan overwrite storage manager also in 7.2 ?
Yes if I'll get enough time.
Vadim
>> Just to clarify; I have no intention of doing anything nasty to pg_dump.
Oh, ok, it wasn't clear, sorry -:)
>>All I plan to do is rename the pg_restore to one of
>>pg_load/pg_import/pg_undump/pmud_gp, to make way for a WAL based
>>restore utility, although as Bruce suggests, this may be prema
Bruce Momjian wrote:
>
> See contrib/fulltextindex.
An easy answer, but not a very good solution in the real world.
contrib/fulltextindex requires you to jump through hoops in developing
queries to retrieve your data. It's also very space-inefficient in that
a table with a fulltextindex on a f
> >So, pg_dump should be preserved asis.
> >
>
> Just to clarify; I have no intention of doing anything nasty to pg_dump.
> All I plan to do is rename the pg_restore to one of
> pg_load/pg_import/pg_undump/pmud_gp, to make way for a WAL based restore
> utility, although as Bruce suggests, this m
> > > > Currently a view may be dropped with either 'DROP VIEW'
> > > > or 'DROP TABLE'. Should this be changed?
> > >
> > > I say let them drop it with either one.
> >
> > I kinda like the 'drop index with drop index', 'drop table with drop
> > table' and 'drop view with drop view' groupings
"Mikheev, Vadim" wrote:
> >> One of the purposes of WAL is immediate removing tuples
> >> inserted by aborted xactions. I want make VACUUM
> >> *optional* in future - space must be available for
> >> reusing without VACUUM. And this is first, very small,
> >> step in this direction.
> >
> >Why w
56 matches
Mail list logo
