> Neil Conway <[EMAIL PROTECTED]> writes:
> >> It's just
> >> for i in t1 t2 t3; do pg_dump -t$i mydb > $i.tbl; done
>
> > Although with a strategy like this, they're no guarantee that the
> > snapshot you get will be consistent. And if you're using refential
> > integrity it might not even restor
Hello.
What is the recommended method of disconnecting all users while a
database is vacuumed and backed up?
I have tried a stop/start cycle but this doesn't work. The only method
that I have found so far that does work is to kill -9 every postgresql
process but this sounds way too heavy hand
Limin Liu <[EMAIL PROTECTED]> writes:
> I just realized that INSERT allows us to have more syntax than the
> manual said. I wonder if we want to elimiate it or keep it with more
> documentation on the INSERT statment?
This will likely go away when we get around to upgrading INSERT to the
full SQ
"Steve Wolfe" <[EMAIL PROTECTED]> writes:
>The docs list EFFECTIVE_CACHE_SIZE as being a run-time parameter with
> the postmaster's assumptions about the kernel disk cache size. Is that
> something that is determined by querying the kernel, or by other means?
It's just a constant by default.
Neil Conway <[EMAIL PROTECTED]> writes:
>> It's just
>> for i in t1 t2 t3; do pg_dump -t$i mydb > $i.tbl; done
> Although with a strategy like this, they're no guarantee that the
> snapshot you get will be consistent. And if you're using refential
> integrity it might not even restore properly.
Hi all. Thanks for all the good advice on how to deal with the source and
the RPMs. The PostgreSQL RPM "god" has just spoken, so I think I'll be
waiting until Saturday to get the new RPMs. But I'll be saving the messages
for when the next version of PostgreSQL comes out and I can't wait for th
> > Let's compare removing the RPM's:
>
> rpm -e `rpm -qa |grep postgresql`
Nice. I like it.
> > #rpm --erase php-pgsql-3.0.15-2
>
> That's not what you're doing for your manual install...
>
> > rm -rf ~postgres/*
>
> So postgres doesn't install it's binaries in /usr/local/bin, libraries
> in
I was bitten by the same problem recently. It means that the owner of the
pgsql call handler no longer exists. To find out the id of the owner, do a
select like:
select * from pg_proc where proname like 'plpg%';
Then create a user having that id. You may need to edit pg_shadow to get
the desire
"Steve Wolfe" <[EMAIL PROTECTED]> writes:
> > Running rpm -ql on the RPMset is too much of a hassle, right? Removing
> > all traces of the RPMset is easier than removing all traces of a from-source
> > install.
>
>Really?
>
> Let's compare removing the RPM's:
rpm -e `rpm -qa |grep postgre
> On Thursday 31 May 2001 16:22, Steve Wolfe wrote:
> > something else fills up /var, PG isn't hosed. And if PG fills up it's
> > partition, other services aren't hosed.
>
> Make a partition mounted on /var/lib/pgsql. :-)
Touche!
> > Now, play some villanous music, and enter RedHat wearin
> > Unfortunately, I can't just "compile" since I need to be able to
replace my
> > current 7.0.3 installation, installed via RPMs. How do I go about this
so I
> > don't mess everything up (leftover files and such, in addition to the
> > mandatory pg_dump) ?
>
> Install the "compiled" version some
> > Now, play some villanous music, and enter RedHat wearing a black
cape,
> > with small, beedy eyes.
>
> I don't have a cape, but I do have a red hat. And blue eyes, normal
size.
I was going for the melodrama. : )
> > They insist that an OS should not touch /usr/local, and they're
> > ri
12 matches
Mail list logo
