Tom Lane said:
Daniel Kalchev [EMAIL PROTECTED] writes:
(found out 7.2.3 does not have pg_database)
You think not?
Not as a file similar to pg_control. pg_database is indeed table in the system
catalog.
By the way, I had to copy over the 'new' files from pg_clog and pg_xlog (t
the problem?
Daniel Kalchev wrote:
Hello,
Is there ANY chance to recover data from a database system that suffered d
isk
crash, and is not missing the data/global directory?
Version is 7.2.4. Database files seem to be intact as well as pg_clog and
pg_xlog
postmaster with -P I get not errors, but no tables as well).
By the way, I had to copy over the 'new' files from pg_clog and pg_xlog (this
is the second possible error) to get the postmaster running. Perhaps better
would be to use pg_resetxlog or similar?
Daniel
Tom Lane said:
Daniel Kalchev
Hello,
Is there ANY chance to recover data from a database system that suffered disk
crash, and is not missing the data/global directory?
Version is 7.2.4. Database files seem to be intact as well as pg_clog and
pg_xlog directories.
Thanks in advance for any ideas.
Daniel
./base/133512058/pgsql_tmp
11933861./base/133512058
13456555./base
98209 ./pg_xlog
41315 ./pg_clog
13596100.
My database should be with oid 77573557, template0 is apparently 16555
Let's see how all this works.
Daniel
Tom Lane said:
Daniel Kalchev [EMAIL
I know this is an attempt to save myself reading the mailing list, but still
the issue remains:
the psql from version 7.4 does not talk to a 7.2.4 database.
The CHANGELOG indicates, that both server and libraries keep compatibility
with versions after 6.3 - still there is no switch in psql to
Ryan Bradetich said:
the table would look like:
1 | Mon Feb 17 00:34:24 MST 2003 | p101 | user x has an invalid shell.
1 | Mon Feb 17 00:34:24 MST 2003 | p101 | user y has an invalid shell.
1 | Mon Feb 17 00:34:24 MST 2003 | p101 | user y has expired password.
2 | Mon Feb 17 00:34:24 MST
Jason Hihn said:
Pardon my ignorance, but there's no way to auto-tune? Ship it with a thread
that gathers statistics and periodically re-tunes the database parameters.
Of course, be able to turn it off. People that actually take the time to run
tune manually will turn it off as to not have
Josh Berkus said:
How about we take this discussion to the Performance List, where it belongs?
I believe the design and addition of code that collects and outputs the usage patterns
of the database (statistics) belongs here.
If we take the approach to providing information to tune PostgreSQL
Manfred Koizar said:
effective_cache_size = 2 (~ 160 MB) should be more adequate for a
256 MB machine than the extremely conservative default of 1000. I
admit that the effect of this change is hard to benchmark. A way too
low (or too high) setting may lead the planner to wrong
Tom,
Sound excellent. Index growth has been something that always bothered me (not
the disk space usage, but the slow searches).
I believe it's best to have pages marked dead at the time the last key
contained in the page is deleted (you didn't discuss how efficient this is),
because this
Justin Clift said:
snip
In theory, if we find recyclable page(s) at the physical end of the index,
we could truncate the file (ie, give the space back to the filesystem)
instead of reporting these pages to FSM. I am not sure if this is worth
doing --- in most cases it's likely that
Bruce Momjian said:
This brings up one item it would be nice to address at the same time.
It would be nice if VACUUM FULL would be able to compress the actual
index file and return unused space to the operating system. REINDEX
does this, but I was thinking of something a little
Bruce Momjian said:
I imagined they could run pgtune anytime after install to update those
performance parameters. It gives them a one-stop location to at least
do minimal tuning, and as their load changes, they can run it again.
True, but to make reasonably good choice, they will need
scott.marlowe said:
On 11 Feb 2003, Greg Copeland wrote:
Besides, I'm not sure that it makes sense to let other product needs
dictate the default configurations for this one. It would be one thing
if the vast majority of people only used PostgreSQL with Apache. I know
I'm using it
Vatamanescu Victor said:
I don't really much care what's the OS our product is running on. I care muc
h about our product's high availability, speed, scalability etc. In the la
st month I saw on this list a lot of opinions regarding the differences be
tween various operating
Vatamanescu Victor said:
Well, I havent seen much that unstable API. If you saw something unstable pl
ease provide me source code that proves Windows API is unstable. Don't tel
l me about some expert's oppinion: if you have a problem with Windows sh
ow it to me. We are not users
Bruce Momjian said:
[...]
For example, we can ask them how many rows and tables they will be
changing, on average, between VACUUM runs. That will allow us set the
FSM params. We can ask them about using 25% of their RAM for shared
buffers. If they have other major apps running on the
Hannu Krosing said:
Tom Lane kirjutas N, 23.01.2003 kell 02:04:
We already do cache column offsets when they are fixed. The code that's
the problem executes when there's a variable-width column in the table
--- which means that all columns to its right are not at fixed offsets,
and
[EMAIL PROTECTED] said:
I'd support making psql 7.3 and forward be aware of the backend they
are connecting to, and support them being able to work against all 7.3+
servers, but I still fail to see the pressing need for a backward-compatible
version when the correct one is always
D'Arcy J.M. Cain said:
On Thursday 16 January 2003 11:59, Adrian 'Dagurashibanipal' von Bidder wrot
e:
On Thu, 2003-01-16 at 17:42, D'Arcy J.M. Cain wrote:
We are also looking at hardware solutions, multi-CPU PCs with tons (24GB
)
of memory. I know that memory will improve
Neil Conway said:
On Fri, 2003-01-10 at 21:27, Christopher Kings-Lynne wrote:
So what actually is the point of OIDs then?
My understanding is that they're used to uniquely identify entries in
system catalogs. If there's a good reason to make use of OIDs on user
tables, I can't see
If ever this happens, same should be considered for tables created via the
SELECT INTO statement. These are in many cases 'temporary' in nature and do
not need OIDs (while making much use of the OIDs counter).
Daniel
---(end of broadcast)---
TIP
Registration is easy, and pretty much anonymous... worth to promote our
beloved database. :)
Happy New Year,
Daniel
Marc G. Fournier said:
Just got this in my mailbox:
2002 LinuxQuestions.org Members Choice Awards:
I have had similar troubles, related to oid overflow. I had to modify pg_dump
to properly cast queries that contain oids. This is against 7.1.3 source. The
patch was hacked quickly, in order to get a corrupted database reloaded, and
this while I was traveling in another country... so it is far
Peter Eisentraut said:
Daniel Kalchev writes:
One would normally expect, that when DROP USER someuser is issued, all
associated data structures will be readjusted, especially ownership and ac
cess
rights.
Perhaps, but the documentation states otherwise.
[...]
Any
I have encountered unexpected behavior of DROP USER in 7.2.1.
One would normally expect, that when DROP USER someuser is issued, all
associated data structures will be readjusted, especially ownership and access
rights.
This however does not happen.
After droping an user, that had ownership
o
I have a problem with an 7.1.3 database that has probably overflowed
the oid counter. The startup halts with these messages
DEBUG: database system was interrupted at 2002-06-24 21:19:43 EEST
DEBUG: CheckPoint record at (156, 1692817164)
DEBUG: Redo record at (156, 1692775580); Undo record
Hi,
I got an corrupted table,,, unfortunately with pretty important data :(
VACUUM tells me:
NOTICE: Rel relx: TID 2344/5704: OID IS INVALID. TUPGONE 1.
NOTICE: Rel relx: TID 2344/5736: OID IS INVALID. TUPGONE 1.
NOTICE: Rel relx: TID 2344/5768: OID IS INVALID. TUPGONE 1.
(this, many
I have hit another very annouing problem with the oids being larger than
max_int. When tables are created under such circumstances, pg_dump cannot dump
the database anymore. The error is
getTables(): SELECT (for PRIMARY KEY) failed on table config_2002_03_02.
Explanation from backend: ERROR:
Has anyone seen this:
ERROR: dtoi4: integer out of range
on 7.1.3
What worries me, is that at startup time, the log shows:
DEBUG: database system was shut down at 2002-04-02 23:16:52 EEST
DEBUG: CheckPoint record at (82, 1928435208)
DEBUG: Redo record at (82, 1928435208); Undo record at
An followup to my previous post.
It turned out to be an query containing oid = somenumber called from perl script. Is
it possible that the default type conversion functions do not work as expected?
Changing this to oid = oid(somenumber) worked as expected.
Daniel
Tom Lane said:
This is one of a whole raft of cases involving undesirable assignment
of types to numeric constants; see past complaints about int4 being used
where int2 or int8 was wanted, numeric vs float8 constants, etc etc.
We're still looking for a promotion rule that does what you
I found out, that there are some probably temporary relations in one of my
databases, with names (that show in vacuum verbose output) like
pg_temp.12720.0.
Are these the result of CREATE TEMP TABLE or simmilar and if so, can such
relations be safely dropped? Perhaps a good idea to add some
Tom Lane said:
Daniel Kalchev [EMAIL PROTECTED] writes:
So in essence this means that my best bet is to again dump/reload the
database...
Either that or fix your queries to cast the literals explicitly.
There is more to it:
customer=# select max(oid) from croute;
max
Bruce Momjian said:
[...]
No, we won't, because OID wrap is an issue already for any long-uptime
installation. (64-bit XIDs are not a real practical answer either,
btw.)
Have we had a wraparound yet?
Just for the record, I had an OID overflow on production database (most
36 matches
Mail list logo
