Hi,
... if the kernel of the OS has Xen support, there will be no
performance penalty (only 2%-3%) (Para-virtualization). Otherwise, there
will be full-virtualization, and we should expect a performance loss
about 30% for each guest OS (like Windows).
I may be wrong but I thought that the gues
Hi,
"Sander Steffann" <[EMAIL PROTECTED]> writes:
What the datetime.c code is doing is trying to find the zoneabbrev
in a built-in timezone table, and then adding the two together.
This is simply wacko.
I think that if anyone has ever tried to use this notation they would
ha
Hi,
The POSIX timezone notation as understood by the zic code includes
the possibility of
zoneabbrev[+-]hh[:mm[:ss]]
but the meaning is that hh:mm:ss *is* the offset from GMT, and
zoneabbrev is being defined as the abbreviation for that offset.
What the datetime.c code is doing is trying to fi
Hi,
> If this were a bulletproof solution then I'd consider it anyway, but
> AFAICS it's got the very same vulnerabilities as the flag-file method,
> ie, if you RPM install or upgrade while your mountable data directory
> is offline, you can still get screwed.
Isn't the most bulletproof solution
Hi,
[ concerning handling a change in a single datatype's representation ]
1. Under old system, munge the system catalog to add code for new inet
type with new OID. Probably needs a shared lib (if you could create
type input/output function with pl/pgsql it would help here).
2. Execute ALTER
Hi,
Just MHO:
1) The added 128-bit type should take the form of:
c) UUID, with only encode/decode/indexable - generic except for the
name of the type, and the encoding format.
2) According to your answer in 1), the added 128-bit type should be:
a) In core first.
1c is what I wo
Hi,
Tom Lane writes:
Martijn van Oosterhout writes:
For simple systems then you could have a short pg_hba.conf to limit the
IP addresses users can connect on, and the DB stores what databases
they have access to...
Right, you'd still have a pg_hba.conf, but it would hopefully be short
and sw
Hi,
Martijn van Oosterhout writes:
You solve it by allowing other backends to lock and examine your
temporary tables. But AIUI temporary tables are not stored in shared
memory so how do you get a consistant view of it?
Not unsolvable, but very tricky.
Right, the problem isn't that "it can
You can have foreign keys between temp tables, just not between temp and
permanent tables. The latter case is either fairly silly, or
technically hard, depending on which direction you have in mind.
A temp table referencing a permanent table wouldn't be very silly IMHO...
Sander.
---
Hi,
> I modified the TODO. I think we only need an INT4. I realize INT8
> would be for IPV6 but I can't imagine a network that has more than INT4
> hosts (not part of the network address).
Actually "increment the host address" isn't a well-defined concept for
IPV6. The "host" part of the add
Hi,
What to people think about having an optional "maintenance window" so
that autovac only takes action during an approved time.
This sounds like a realy good idea to me!
Sander.
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
Hi,
> Not sure if I like the URLs, myself ... opinions?
All those links look messy IMHO. Maybe it's possible to give one link for
every directory instead one for every file?
Something like:
Log Message:
---
attempt at a multi file commit, to seee how it formats
Modified Files:
---
Hi,
> Inside the RH9.0 coesist the 7.4.0-0.3 and 7.4.0-0.5 versions
> looking on other RH directory version I found that actually
>
> 7.4.0-0.2
> 7.4.0-0.3
> 7.4.0-0.4
> 7.4.0-0.5
>
> are existing.
> Inside the SRPMS directory is present only the 7.4.0-0.2
> version!
This is because when I built
Hi,
> Alternative thought: just recommend that if possible, people
> take a filesystem dump of their old PGDATA directory after
> stopping the old postmaster. This would be sufficient for
> retreating to the prior version if needed. It might or might
> not be slower than copying all the file
Hi Tom,
> I am inclined to rename plpython to plpythonu, by analogy to pltclu.
> The advantage of doing so is that (a) the name change makes it somewhat
> more obvious that there's a fundamental behavioral change, and (b)
> assuming that the Python folk someday figure out a secure version of
> REx
Hi,
> On Thursday 29 May 2003 07:26, ow wrote:
> > RH7.3 is a supported distribution for at least 6 months.
>
> By Red Hat, but not necessarily by us.
> That being said:
>
> > Any plans to add
> > Postgres 7.3.3 RPMs for RH7.3?
>
> Yes. Please understand that I only have at my disposal machines r
Hi,
> Would it be cool to decide on the version numbering of our next release
> like this:
>
> + If it looks like we'll have Win32 and/or PITR recovery in time for
> the next release, we call it PostgreSQL 8.0
>
> + If not, we call it 7.4
Wouldn't a new FE/BE protocol be a better reason t
Hi all,
Yesterday I tried to help Lamar by building RedHat 6.2, 7.3 and 8.0 (with
default tcl) RPMS for the 7.3.1 release. Lamar was going to put them on
ftp.postgresql.org, but it seems that he is away for Christmas... Can
anybody else please put them on the ftp server? The RPMS are at
http://www
Hi,
> I am wondering if we could have a configure-time or install-time
> option to make pg_shadow (and pg_group I guess) be database-local
> instead of installation-wide. I am not sure about the implications
> of this --- in particular, is the notion of a database owner still
> meaningful? How
Hi
> And what's the problem with networkcard_products being a separate table
> that shares a key with the products table?
>
> CREATE TABLE products (product_id int, ...)
> CREATE TABLE networkcard_products_data (product_id int, ...)
> CREATE VIEW networkcard_products AS
> SELECT produ
Hi!
> I've always thought of our release numbering as having "themes". The 6.x
> series took Postgres from interesting but buggy to a solid system, with
> a clear path to additional capabilities. The 7.x series fleshes out SQL
> standards compliance and rationalizes the O-R features, as well as a
> What about a SET variable that controls the behaviour of
> SET variables :-)
Or two commands for the same thing:
- a SET command that behaves as it does now
- a TSET command that is transaction-aware
Ouch... :-)
Sander
---(end of broadcast)---
Hi,
> > > > Maybe to keep hostile users from filling up your disk?
>
> Actually, I was serious, not sarcastic, about that "maybe." Like
> Tom, I'm not entirely sure that it's necessary to add this complexity,
> because there are so many other ways to abuse the system.
I know... But we have to st
Hi,
> Curt Sampson <[EMAIL PROTECTED]> writes:
> > On Fri, 19 Apr 2002, Sander Steffann wrote:
> >> I can't think of a reason that [creation of] temp tables should
> >> be prevented.
>
> > Maybe to keep hostile users from filling up your disk?
&
Hi Tom,
> One of the things I'd like this mechanism to do is answer the request
> we've heard so often about preventing users from creating new tables.
> If the DBA revokes write access on the public namespace from a particular
> user, and doesn't create a personal schema for that user, then unde
25 matches
Mail list logo
