Bruce Momjian wrote:
>
> > I can even think of a situation, as unlikely as it can be, where this
> > could happen ... run out of inodes on the file system ... last inode used
> > by the table, no inode to stick the symlink onto ...
>
> If you run out of inodes, you are going to have much bigger
> > Yes, I like that idea, but the problem is that it is hard to update just
> > one table in the file.
>
> why not have just one ever-growing file that is only appended to and
> that has
> lines of form
>
> OID, type (DB/TABLE/INDEX/...), name, time
>
> so when you need tha actual info you g
On Sun, Apr 29, 2001 at 08:17:28PM -0700, Alfred Perlstein wrote:
> Sort of, if that flat file is in the form of:
> 123456;"tablename "
> 33;"another_table "
Or better yet, since the flat file is unlikely to be large, you could
just do this dance:
1) open file
> It might be worth making a simple utility (could be based on Bryan
> White's pg_check) to grovel through the raw pg_class bits and extract
> relfilenode info the hard way. You'd only need it in certain disaster
> scenarios, but when you did need it you'd need it bad.
>
> So far we have not see
Vince Vielhaber <[EMAIL PROTECTED]> writes:
>> Oh, you did a direct postgres backend connect. Yes, that will work
>> fine. Good idea if the postmaster is down. I originally thought you
>> meant reading the pg_class file raw. Of course, that would be really
>> hard because there is no way to kn
On Sun, 29 Apr 2001, Bruce Momjian wrote:
> > > I think parsing the file contents is too hard. The database would have
> > > to be running and I would use psql.
> >
> > I don't know, I recovered someone's database using a "raw" connection ...
> > wasn't that difficult once I figured out the form
* Tom Lane <[EMAIL PROTECTED]> [010429 23:12] wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > big problem is that there is no good way to make the symlinks reliable
> > because in a crash, the symlink could point to a table creation that got
> > rolled back or the renaming of a table that g
Bruce Momjian <[EMAIL PROTECTED]> writes:
> big problem is that there is no good way to make the symlinks reliable
> because in a crash, the symlink could point to a table creation that got
> rolled back or the renaming of a table that got rolled back.
Yes. Have you already forgotten the very lo
Here is what I suggested for oid2name to do with file names:
---
Just seems like a major pain; not worth the work.
If you do a ls and pipe it, here is what you would need to do:
- find out where $PWD is
- in that databas
If this isn't incorporated into a utility, it would certainly be prime
for inclusion for the yet-to-be-written chapter 11 of the PG Admin Manual
"Database Recovery."
Thanks for your responses, -Casey
The Hermit Hacker wrote:
> On Sun, 29 Apr 2001, Bruce Momjian wrote:
>
>
Yes, I like
> > I think parsing the file contents is too hard. The database would have
> > to be running and I would use psql.
>
> I don't know, I recovered someone's database using a "raw" connection ...
> wasn't that difficult once I figured out the format *shrug*
>
> the following gets the oid,relname's
> It certainly works quickly for smaller tables, however the 21.7 million
> record table I ran this on takes a touch longer as shown here:
>
> database=# explain select count(*) from table;
> NOTICE: QUERY PLAN:
>
> Aggregate (cost=478056.20..478056.20 rows=1 width=0)
>-> Seq Scan on tabl
- Original Message -
From: Alfred Perlstein <[EMAIL PROTECTED]>
To: Bruce Momjian <[EMAIL PROTECTED]>
Cc: The Hermit Hacker <[EMAIL PROTECTED]>; Casey Lyon <[EMAIL PROTECTED]>;
<[EMAIL PROTECTED]>
Sent: Sunday, April 29, 2001 11:17 PM
Subject: Re: [HACKE
On Sun, 29 Apr 2001, Bruce Momjian wrote:
> > > Yes, I like that idea, but the problem is that it is hard to update just
> > > one table in the file. You sort of have to update the entire file each
> > > time a table changes. That is why I liked symlinks because they are
> > > per-table, but yo
Bruce Momjian wrote:
> The problem here is that now we don't have commit status in the index
> rows, so they have to check the heap for every row. One idea is to
> update the index status on an index scan, and if we can do that, we can
> easily use the index. However, the table scan is pretty
I could even see a utility that does a dump of this info into a flat file,
entirely overwriting the file every time.
This would be quick to reference and usable in a meltdown scenario. Could
easily be incorporated into vacuum and other db maintenance cron scripts.
-Casey
Bruce Momjian wrote:
> > Yes, I like that idea, but the problem is that it is hard to update just
> > one table in the file. You sort of have to update the entire file each
> > time a table changes. That is why I liked symlinks because they are
> > per-table, but you are right that the symlink creation could fail
>
2 points:
- I thought that a big part of the reason we got rid of filenames was
so we would use arbitrary table / db names that were not restricted by
the file system / OS. Using links would then return this restriction.
- What is the format for the table? Could we write a tool that can
read t
> * Bruce Momjian <[EMAIL PROTECTED]> [010429 20:14] wrote:
>
> > Yes, I like that idea, but the problem is that it is hard to update just
> > one table in the file. You sort of have to update the entire file each
> > time a table changes. That is why I liked symlinks because they are
> > per-t
On Sun, 29 Apr 2001, Bruce Momjian wrote:
> > I can even think of a situation, as unlikely as it can be, where this
> > could happen ... run out of inodes on the file system ... last inode used
> > by the table, no inode to stick the symlink onto ...
>
>
> If you run out of inodes, you are going
* Bruce Momjian <[EMAIL PROTECTED]> [010429 20:14] wrote:
> Yes, I like that idea, but the problem is that it is hard to update just
> one table in the file. You sort of have to update the entire file each
> time a table changes. That is why I liked symlinks because they are
> per-table, but yo
> I can even think of a situation, as unlikely as it can be, where this
> could happen ... run out of inodes on the file system ... last inode used
> by the table, no inode to stick the symlink onto ...
If you run out of inodes, you are going to have much bigger problems
than symlinks. Sort fil
On Sun, 29 Apr 2001, Bruce Momjian wrote:
> > I don't know the answers to these questions, which is why I'm asking them
> > ... if this is something safe to do, and doesn't break us again, then
> > sounds like a good idea to me too ...
>
> I was suggesting the symlinks purely for admin convenienc
> On Sun, 29 Apr 2001, Bruce Momjian wrote:
>
> > >
> > > doesn't this defeat the reasons for going to numerics? is there a reason
> > > why its such a difficult thing to do a SELECT oid on pg_database and
> > > pg_class to get this information? that's what I've been doing when I need
> > > to
On Sun, 29 Apr 2001, Bruce Momjian wrote:
> >
> > doesn't this defeat the reasons for going to numerics? is there a reason
> > why its such a difficult thing to do a SELECT oid on pg_database and
> > pg_class to get this information? that's what I've been doing when I need
> > to know *shrug*
>
> >
> > doesn't this defeat the reasons for going to numerics? is there a reason
> > why its such a difficult thing to do a SELECT oid on pg_database and
> > pg_class to get this information? that's what I've been doing when I need
> > to know *shrug*
>
> Yes, but you can't do that if you can'
>
> doesn't this defeat the reasons for going to numerics? is there a reason
> why its such a difficult thing to do a SELECT oid on pg_database and
> pg_class to get this information? that's what I've been doing when I need
> to know *shrug*
Yes, but you can't do that if you can't start the da
doesn't this defeat the reasons for going to numerics? is there a reason
why its such a difficult thing to do a SELECT oid on pg_database and
pg_class to get this information? that's what I've been doing when I need
to know *shrug*
On Sun, 29 Apr 2001, Bruce Momjian wrote:
> > First off I jus
> First off I just wanted to give a big 'thank you' to all the
> developers and contributors who have made PostgreSQL what it is
> today. I haven't come across a single thing since my first
> experience with it a few years ago that hasn't been corrected,
> sped up, or otherwise postively enhanced!
First off I just wanted to give a big 'thank you' to all the developers and
contributors
who have made PostgreSQL what it is today. I haven't come across a single thing
since my first experience with it a few years ago that hasn't been corrected, sped
up, or otherwise postively enhanced!
In work
30 matches
Mail list logo
