/home/projects/pgsql partition at hub.org is down to zero free space...
regards, tom lane
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHe
On Fri, 20 Jul 2001, Hiroshi Inoue wrote:
> Bill Studenmund wrote:
> >
> > "How does postgres know that the new table a is sufficiently like the old
> > table that it should be used?"
> >
> > By making the reattachment automatic, you are saying that once we make an
> > object of a given name an
Tom Lane wrote:
>
> Hiroshi Inoue <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >> Could you use CTID instead of OID?
>
> > I am using both.
> > TIDs for fast access and OIDs for identification.
> > Unfortunately TIDs are transient and they aren't
> > that reliable as for identification.
>
>
On Fri, Jul 20, 2001 at 08:45:05AM +0900, Hiroshi Inoue wrote:
>
> It doesn't seem preferable that the default(unadorned) DROP
> allows reattachement after the DROP. The default(unadorned) DROP
> should be the same as DROP RESTRICT(or CASCADE because the current
> behabior is halfway CASCADE?). H
Bill Studenmund wrote:
>
> On Thu, 19 Jul 2001, Hiroshi Inoue wrote:
>
> > > This step I disagree with. Well, I disagree with the automated aspect
> of
> > > the update. How does postgres know that the new table a is sufficiently
> > > like the old table that it should be used? A way the DBA coul
Mike Cianflone <[EMAIL PROTECTED]> writes:
> is it possible to completely turn off the revision tracking feature so that
> vacuum does not need to be run at all?
No.
Of course, if you never update or delete any rows, you don't need VACUUM
... but I suspect that's not what you had in mind.
On Thu, 19 Jul 2001, Hiroshi Inoue wrote:
> > This step I disagree with. Well, I disagree with the automated aspect
of
> > the update. How does postgres know that the new table a is sufficiently
> > like the old table that it should be used? A way the DBA could say, "yeah,
> > restablish that," w
Philip Warner <[EMAIL PROTECTED]> writes:
> At 00:00 19/07/01 -0400, Tom Lane wrote:
>> INSERT INTO foo ... RETURNING x,y,z,...
> That would have been me; at the time we also talked about
> UPDATE...RETURNING and Jan proposed allowing UPDATE...RETURNING
> {[Old.|New.]Attr,...}
Hm. I'm less exci
I need to programatically relax a constraint during db syncronization. I
tried setting tgenabled to false in the pg_trigger table, but it didn't seem
to make a difference.
Thx,
Howie
---(end of broadcast)---
TIP 5: Have you checked our extensi
I've followed the threads of needing to run vacuum nightly, and even
got an answer to a slow updating database regarding needing to vacuum. But I
haven't see the question asked:
is it possible to completely turn off the revision tracking feature so that
vacuum does not need to be run at a
You are right; I have forgotten to create a "trusted" language.
Mark
Tom Lane wrote:
>
> Mark Volpe <[EMAIL PROTECTED]> writes:
> > ERROR: Only users with Postgres superuser privilege are permitted to create a
> > function in the 'plpgsql' language.
>
> > D'oh! So, if this is the case, then t
Mark Volpe <[EMAIL PROTECTED]> writes:
> ERROR: Only users with Postgres superuser privilege are permitted to create a
> function in the 'plpgsql' language.
> D'oh! So, if this is the case, then the last patch should be fine after all.
No, evidently you broke something, or your plpgsql is insta
OK, I finally got around to adding the superuser check to my patch. So I try
to test it and...
ERROR: Only users with Postgres superuser privilege are permitted to create a
function in the 'plpgsql' language.
D'oh! So, if this is the case, then the last patch should be fine after all.
Mark
Pe
J-P wrote:
> > I need to create a new system table like pg_log to
> > implement a replication scheme. The big problem is
> how
> > I could get an OID for it, a unique OID that is
> > reserved for that table???
Hiroshi Inoue wrote:
>
>
> Do you need the following ?
>
> visco=# select oid from p
> Yes, nowhere near, and yes. Sequence objects require disk I/O to
> update; the OID counter essentially lives in shared memory, and can
> be bumped for the price of a spinlock access.
Sequences also cache values (32 afair) - ie one log record is required
for 32 nextval-s. Sequence' data file is
> "Michael" == Michael Widenius <[EMAIL PROTECTED]> writes:
Michael> Please note that we NEVER have asked NuSphere to sign
Michael> over copyright of Gemini to us. We do it only for the
Michael> core server, and this is actually not an uncommon thing
Michael> among open source
Hiroshi Inoue <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Could you use CTID instead of OID?
> I am using both.
> TIDs for fast access and OIDs for identification.
> Unfortunately TIDs are transient and they aren't
> that reliable as for identification.
Hmm ... within a transaction I think
At 12:37 18/07/01 -0400, Tom Lane wrote:
>Philip Warner <[EMAIL PROTECTED]> writes:
>> At 11:38 18/07/01 -0400, Tom Lane wrote:
>>> I'd just make the dependency be from view_a to a and keep things
>>> simple. What's so wrong with recompiling the view for *every* change
>>> of the underlying table
>>>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
19 matches
Mail list logo
