Mark Hollomon <[EMAIL PROTECTED]> writes:
> I think it would be better to move the test further down, to just before we
> actually try to do the update/insert. Maybe into the heap access routines as
> suggested by Andreas.
I'm worried about whether it'll be practical to generate a good error
me
Mark Hollomon <[EMAIL PROTECTED]> writes:
> plpgsql. plperl and pltcl all cache the result of a compile of prosrc.
plpgsql does, but I didn't think the other two do.
> I would like to propose that a new attribute be added to pg_proc
> 'proserial'. 'CREATE FUNCTION' will set proserial to 0. 'ALT
On Friday 01 December 2000 00:33, Tom Lane wrote:
> The rewriting is done, all right, but what's left afterward still has
> references to the view, because each rule is conditional. Essentially,
> the rewriter output looks like
>
> -- rule 1
> if (rule1 condition holds)
>
I am working on an implementation of 'ALTER FUNCTION' and have run into a
problem.
plpgsql. plperl and pltcl all cache the result of a compile of prosrc.
Which leads to things like:
mhh=# create function f() returns integer as 'begin return 42; end;' language
'plpgsql';
CREATE
mhh=# select f(
I am curious as to where the newest ODBC driver source is -- I retrieved
/src/interfaces/odbc from CVS, but it appeared to only be version
6.40.0009 and was lacking the Visual C++ workspace/project files that
were in the 6.50. release zip file on the FTP server.
Thanks
Michael Fork - CCNA
At 03:05 PM 12/1/00 -0800, Alfred Perlstein wrote:
>How about adding COPY XML?
>(kidding of course about the XML, but it would make postgresql more
>buzzword compliant :) )
Hey, we could add a parser and call the module MyXML ...
- Don Baccus, Portland OR <[EMAIL PROTECTED]>
Nature photos,
* Tom Lane <[EMAIL PROTECTED]> [001201 14:57] wrote:
> Alfred Perlstein <[EMAIL PROTECTED]> writes:
> > I would rip it out.
>
> I thought about that too, but was afraid to suggest it ;-)
I think you'd agree that you have more fun and important things to
do than to deal with this yucky interface.
> The existing COPY BINARY file format is entirely brain-dead
> anyway; for example, it wants the number of tuples to be stored
> at the front, which means we have to scan the whole relation an
> extra time to get that info. Its handling of nulls is bizarre, too.
> I'm thinking this might be a go
> Alfred Perlstein <[EMAIL PROTECTED]> writes:
> > I would rip it out.
>
> I thought about that too, but was afraid to suggest it ;-)
>
> How many people are actually using COPY BINARY?
It could be useful if only single scan would be required.
But I have no strong opinion about keeping it.
Vad
Alfred Perlstein <[EMAIL PROTECTED]> writes:
> I would rip it out.
I thought about that too, but was afraid to suggest it ;-)
How many people are actually using COPY BINARY?
regards, tom lane
* Tom Lane <[EMAIL PROTECTED]> [001201 14:42] wrote:
> I've just noticed that COPY BINARY is pretty thoroughly broken by TOAST,
> because what it does is to dump out verbatim the bytes making up each
> tuple of the relation. In the case of a moved-off value, you'll get
> the toast reference, whic
I've just noticed that COPY BINARY is pretty thoroughly broken by TOAST,
because what it does is to dump out verbatim the bytes making up each
tuple of the relation. In the case of a moved-off value, you'll get
the toast reference, which is not going to be too helpful for reloading
the table data
At 12:56 PM 12/1/00 -0800, Nathan Myers wrote:
>(Remember, we're talking about what you could do *now*, with 7.1.
>Presumably with 7.2 other options will open.)
Maybe *you* are :) Seriously, I'm thinking out loud about future
possibilities. Putting a lot of work into building up a temporary
so
On Fri, Dec 01, 2000 at 11:48:23AM -0800, Don Baccus wrote:
> At 11:09 AM 12/1/00 -0800, Nathan Myers wrote:
> >On Fri, Dec 01, 2000 at 10:01:15AM +0100, Zeugswetter Andreas SB wrote:
>
> >> If you need to restore from offsite backup you loose transactions
> >> unless you transfer the WAL synchro
On Fri, Dec 01, 2000 at 08:10:40AM -0800, Vadim Mikheev wrote:
>
> > ... a new backup utility
> > could be written to make a hot backup which could be restored and
> > then replayed using the current WAL format. It might be easier to
> > add another log which could be replayed against the exis
> Ok, this has peaked my interest in learning exactly what WAL
> is and what it does... I don't see any in-depth explanation
> of WAL on the postgresql.org site, can someone point me to
> some documentation? (if any exists, that is).
WAL (Write Ahead Log) is standard technique described in,
I th
At 11:09 AM 12/1/00 -0800, Nathan Myers wrote:
>On Fri, Dec 01, 2000 at 10:01:15AM +0100, Zeugswetter Andreas SB wrote:
>> If you need to restore from offsite backup you loose transactions
>> unless you transfer the WAL synchronously with every commit.
>Currently the only way to avoid losing th
On Fri, Dec 01, 2000 at 09:13:28PM +1100, Philip Warner wrote:
>
> You have raised some interesting issues regrading write-order etc. Can we
> assume that when fsync *returns*, all records are written - though not
> necessarily in the order that the IO's were executed?
Not with ordinary disks.
Ok, this has peaked my interest in learning exactly what WAL is and what it
does... I don't see any in-depth explanation of WAL on the postgresql.org
site, can someone point me to some documentation? (if any exists, that is).
Thanks!
-Mitch
- Original Message -
From: "Nathan Myers" <[EM
On Fri, Dec 01, 2000 at 10:01:15AM +0100, Zeugswetter Andreas SB wrote:
>
> > > > No, WAL does help, cause you can then pull in your last dump and recover
> > > > up to the moment that power cable was pulled out of the wall ...
> > >
> > > False, on so many counts I can't list them all.
> >
> >
At 11:02 AM 12/1/00 -0800, Nathan Myers wrote:
>On Fri, Dec 01, 2000 at 06:39:57AM -0800, Don Baccus wrote:
>>
>> Probably the best answer to the "what does WAL get us, if it doesn't
>> get us full recoverability" questions is to simply say "it's a
>> prerequisite to getting full recoverability,
On Fri, Dec 01, 2000 at 06:39:57AM -0800, Don Baccus wrote:
>
> Probably the best answer to the "what does WAL get us, if it doesn't
> get us full recoverability" questions is to simply say "it's a
> prerequisite to getting full recoverability, PG 7.1 sets the foundation
> and later work will g
> > > As for replaying logs against a restored snapshot dump... AIUI, a
> > > dump records tuples by OID, but the WAL refers to TIDs. Therefore,
> > > the WAL won't work as a re-do log to recover your transactions
> > > because the TIDs of the restored tables are all different.
> >
> > Tru
At 12:30 AM 12/1/00 -0800, Ian Lance Taylor wrote:
>For example, I would hope that EMC
>disk systems handle power loss gracefully.
They must, their marketing literature says so :)
> But if you buy ordinary
>off the shelf PC hardware, you really do need to arrange for a UPS,
>and some sort of au
At 11:06 PM 11/30/00 -0800, Vadim Mikheev wrote:
>> As for replaying logs against a restored snapshot dump... AIUI, a
>> dump records tuples by OID, but the WAL refers to TIDs. Therefore,
>> the WAL won't work as a re-do log to recover your transactions
>> because the TIDs of the restored tabl
At 12:55 AM 12/1/00 -0800, Nathan Myers wrote:
>Many people hope to run PostgreSQL 24x7x365. With vacuuming, you
>might just as well shut down afterward; but when that goes away
>(in 7.2?), when will you get the chance to take your backups?
>Clearly we need either another form of snapshot ba
Kevin O'Gorman wrote:
>
> mlw wrote:
> >
> > Kevin O'Gorman wrote:
> > >
> > > mlw wrote:
> > > > Many operating systems used a fixed memory block size allocation for
> > > > their disk cache. They do not allocate a new block for every disk
> > > > request, they maintain a pool of fixed sized buf
At 00:55 1/12/00 -0800, Nathan Myers wrote:
>On Thu, Nov 30, 2000 at 11:06:31PM -0800, Vadim Mikheev wrote:
>> > As for replaying logs against a restored snapshot dump... AIUI, a
>> > dump records tuples by OID, but the WAL refers to TIDs. Therefore,
>> > the WAL won't work as a re-do log to re
> If the system were capable of determining that either rule1 or rule2
> condition will always hold, perhaps it could deduce that the original
> query on the view will never be applied. However, I doubt that we
> really want to let loose an automated theorem prover on the results
> of every rewr
> > > No, WAL does help, cause you can then pull in your last dump and recover
> > > up to the moment that power cable was pulled out of the wall ...
> >
> > False, on so many counts I can't list them all.
>
> would love to hear them ... I'm always opening to having my
> misunderstandings corre
On Thu, Nov 30, 2000 at 11:06:31PM -0800, Vadim Mikheev wrote:
> > As for replaying logs against a restored snapshot dump... AIUI, a
> > dump records tuples by OID, but the WAL refers to TIDs. Therefore,
> > the WAL won't work as a re-do log to recover your transactions
> > because the TIDs of
Hello,
Please , excuse me for my bad english.
One question on bitmaps index. In them Commercial data bases (oracle DB2),
Let bitmap type index is supported.This index is used for fields of type sex or
Boolean generally, would be it(he)
supported in postgres??? If not is foreseen it???
Best re
Date: Fri, 1 Dec 2000 01:54:23 -0500 (EST)
From: Alex Pilosov <[EMAIL PROTECTED]>
On Thu, 30 Nov 2000, Nathan Myers wrote:
> After a power outage on an active database, you may have corruption
> at low levels of the system, and unless you have enormous redundancy
> (and actuall
On Fri, Dec 01, 2000 at 01:54:23AM -0500, Alex Pilosov wrote:
> On Thu, 30 Nov 2000, Nathan Myers wrote:
> > After a power outage on an active database, you may have corruption
> > at low levels of the system, and unless you have enormous redundancy
> > (and actually use it to verify everything) t
34 matches
Mail list logo
