Dave Blasby <[EMAIL PROTECTED]> writes:
> So far, it doesnt work. Only one of my GiST support functions is called
> (the compress function), after that I get the error message:
> # create index qq on tp3 using gist (the_geom gist_geometry_ops) with
> (islossy);
> ERROR: index_formtuple: data ta
Hi,
I think I've come across a bug in plpgsql. It happens in the following
situation:
I have 2 tables, one with a foreign key to the other.
Inside a plpgsql function, I do:
update row in table2
delete that row in table2
delete the referenced row in table1
And I get a foreign key constrain
I'm trying to get my geometric type to spatially index. I tried RTrees,
but they dont like objects that are bigger than 8k.
I'm now trying to get a GiST index to index based on the bounding box
thats contained inside the geometry. So the index is on a GEOMETRY
type, but the index is only acting
At 01:51 25/05/01 +0500, Hannu Krosing wrote:
>
>How does it do MVCC with an overwriting storage manager ?
>
I don't know about Oracle, but Dec/RDB also does overwriting and MVCC. It
does this by taking a snapshot of pages that are participating in both RW
and RO transactions (De/RDB has the opti
> > > >Oracle has MVCC?
> > >
> > > With restrictions, yes.
> >
> > What restrictions? Rollback segments size?
> > Non-overwriting smgr can eat all disk space...
>
> Is'nt the same true for an overwriting smgr ? ;)
Removing dead records from rollback segments should
be faster than from datafile
On Thu, May 24, 2001 at 10:30:01AM -0400, Bruce Momjian wrote:
> > The HPUX man page for mmap documents its failure return value as "-1",
> > so I hacked around this with
> >
> > #ifndef MAP_FAILED
> > #define MAP_FAILED ((void *) (-1))
> > #endif
> >
> > whereupon it built and passed the simple
Chris Bowlby <[EMAIL PROTECTED]> writes:
> The configure script errors out looking
> for _eprintf(), which apparently is a now deprecated GCC
> attempt at a compatibility layer. This tells me I really
> can't use the binary build made by the HP-UX porting archive
> folks.
FWIW, I've seen eprintf
This value can be dynamically changed by:
echo "new value here" > /proc/sys/kernel/shmmax
Glad I bought that expensive RedHat support contract!
-r
At 08:02 PM 5/24/01 +0200, Poul L. Christiansen wrote:
>I think you still need to set your shared memory size, because my Redhat
>7.1 gives me thi
I think you still need to set your shared memory size, because my Redhat
7.1 gives me this:
[root@localhost kernel]# cat /proc/sys/kernel/shmmax
33554432
[root@localhost kernel]# uname -a
Linux localhost.localdomain 2.4.2-2 #1 Sun Apr 8 20:41:30 EDT 2001 i686
unknown
I think shared memory is set
> > - A simple typo in psql can currently cause a forced
> > rollback of the entire TX. UNDO should avoid this.
>
> Yes, I forgot to mention this very big advantage, but undo is
> not the only possible way to implement savepoints. Solutions
> using CommandCounter have been discussed.
This would
This is my first post here. I hope that I got
everything right...
This has already been possible for 2.2.x Kernels.
Check out the Postgresql admin documentation at
http://www.fr.postgresql.org/devel-corner/docs/admin/kernel-resources.html#SYSVIPC
Or did I get something wrong.
By the way. Is th
> I think so too. I've never said that an overwriting smgr
> is easy and I don't love it particularily.
>
> What I'm objecting is to avoid UNDO without giving up
> an overwriting smgr. We shouldn't be noncommittal now.
Why not? We could decide to do overwriting smgr later
and implement UNDO then
>This is true. You can adjust the value in the /proc/sys/kernel/shmmax
>file. If you change the value it will be reset when you reboot, so you
>will need to write a start-up script to always change this value if you
>want it to be permanent.
>
>-r
>
>At 09:51 AM 5/24/01 -0700, you wrote:
>
>
Tom Lane wrote:
>"Oliver Elphick" <[EMAIL PROTECTED]> writes:
>> Notices are being timestamped in GMT in the syslog, instead of local
>> time like all other log entries. Here's a fragment from my syslog:
>
>Curious. I always assumed that syslog timestamps were supplied by the
>syslog
> If PostgreSQL wants to stay MVCC, then we should imho forget
> "overwriting smgr" very fast.
>
> Let me try to list the pros and cons that I can think of:
> Pro:
> no index modification if key stays same
> no search for free space for update (if tuple still
> fits into page)
In the past, I had to change the RedHat Linux kernel so that the
shared memory was set to something much higher than the default (which
I think was about 32 MBytes). It seems that this is no longer
necessary in RH 7.1 (kernel 2.4). Can someone confirm this?
-Tony
---(end
Sorry for delay ... just built using the .tar.gz file as below if someone
wants to check it to confirm ... for those with shell access on the
server, just ftp to it and login as yourself, and cd to
~pgsql/ftp/pub/source/v7.1.2 ...
if all looks well, I'll put out a more general announce later thi
> >> Impractical ? Oracle does it.
> >
> >Oracle has MVCC?
>
> With restrictions, yes.
What restrictions? Rollback segments size?
Non-overwriting smgr can eat all disk space...
> You didn't know that? Vadim did ...
Didn't I mention a few times that I was
inspired by Oracle? -:)
Vadim
--
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Tom Lane writes:
>>> * rename the internal representation: s = select, i = insert, u = update,
>>> d = delete, R = rules
>>
>> Since the internal representation is visible to users, I fear that a
>> wholesale renaming will break existing applications
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> This is a compilation of the BSD-licensed gettext tools from NetBSD plus
> some of my own code, put into a (hopefully) portable package, intended to
> be evaluated for possible use in PostgreSQL. Give it a try if you're
> interested.
On HPUX 10.20:
"Oliver Elphick" <[EMAIL PROTECTED]> writes:
> Notices are being timestamped in GMT in the syslog, instead of local
> time like all other log entries. Here's a fragment from my syslog:
Curious. I always assumed that syslog timestamps were supplied by the
syslog daemon, but to make this happen t
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> * Make DELETE distinct from UPDATE privilege
Okay.
> * rename the internal representation: s = select, i = insert, u = update,
> d = delete, R = rules
Since the internal representation is visible to users, I fear that a
wholesale renaming will br
Dave Blasby <[EMAIL PROTECTED]> writes:
> So far, so good, but when you try to create an rtree index, you get;
>> create index quick on test_geom using rtree (poly);
> ERROR: index_formtuple: data takes 20040 bytes, max is 8191
Yup. We don't yet have a solution that allows index entries to be m
I can't see any reason in the code why this should be happening.
--- Forwarded Message
Date:Thu, 24 May 2001 00:25:32 -0400
From:Marc Sherman <[EMAIL PROTECTED]>
To: Debian Bug Tracking System <[EMAIL PROTECTED]>
Subject: Bug#98565: postgresql logs notices with GMT timestamps in
24 matches
Mail list logo
