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 may be
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
Just a confirmation.
Do you plan overwrite storage manager also in 7.2 ?
Yes if I'll get enough time.
Vadim
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
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 that
a
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 ?
Performance
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
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
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
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 when viewing the
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 ?
Missed I something ?
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 mean
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
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
pretty sure you
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 when viewing
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
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 it 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 bpcharin()
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, there
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
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
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
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 was to
* 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 name.
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 help
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 having a hard
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 ?
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
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.
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
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 of
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
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'::char ||
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(viewName);
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 my
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
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
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 result
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...
- 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
"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
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
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
44 matches
Mail list logo
