>>>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 o
(if I run 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
data dir, clog or xlog then what's 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?
> >
> >
007
1 ./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:
>
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
--
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 s
>>>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
>>>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
>>>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 PostgreS
>>>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 no
>>>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
>>>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
>>>Justin Clift said:
>
> > 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 likel
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 will
>>>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
>>>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 us
>>>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 sy
>>>"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
> >
>>>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
>>>[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 a
>>>"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
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
>>>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
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:
>
> http://www.linuxquestions.org/questions/showthread.php
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 f
>>>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,
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
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 at
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 times,
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:
>>>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.
Sorry for the incomplete r
>>>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:
cu
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 vac
>>>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
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
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 (
>>>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
37 matches
Mail list logo
