I've been experimenting with Matthew T. O'Connor's pg_avd (auto vacuum
daemon), which is actually quite an interesting piece of software that
so far seems to function pretty well.
I've ported it to PG 7.2.4, which is the version I'm running on my
system, and experimenting with it has uncovered
I found it, well not really that is. It seems the problem is triggered
by some gcc optimization. I'm using gcc 3.2.3. If I specify -O2 it does
not work correctly, without optimization it does. Now the big question
is which optimization is causing trouble.
It certainly is not -ffast-math as I do
Kevin Brown [EMAIL PROTECTED] writes:
When a heavy INSERT or UPDATE load on a table is occurring (lots of
quick INSERTs or UPDATEs within a single transaction), a VACUUM
ANALYZE (or just straight VACUUM) has a really good chance (10% or so)
of causing either the INSERT/UPDATE or the VACUUM to
On Thu, Mar 27, 2003 at 09:07:48AM -0500, Tom Lane wrote:
FWIW, I get the correct answer in CVS tip on Red Hat Linux 8.0, which
is using gcc 3.2 (and -O2, per defaults in our makefiles):
Thanks Tom. I just wonder what's different in my makefile. It just does:
include
Jinqiang Han [EMAIL PROTECTED] writes:
hi,Bruce Momjian
I think you are wrong. multiple query in a string, such as SELECT;SELECT
will invoke pg_execute_query_string twice, It won't generate two parsetree.
Try it in something other than psql. psql splits such a string into
multiple
Michael Meskes [EMAIL PROTECTED] writes:
Tom, I take it you have released gcc 3.2 right? It seems my ione is
based on a CVS prerelease:
It's whatever came with RH 8.0 ...
$ gcc -v
Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/3.2/specs
Configured with: ../configure --prefix=/usr
Tom Lane writes:
Maybe I'm just a Luddite, but I've never understood what autoheader
buys us that's worth the trouble of conforming to its restrictions.
We wouldn't have to edit the config.h file by hand whenever some editing
of configure.in occurs. That's all, but I'm not aware of any real
Peter Eisentraut [EMAIL PROTECTED] writes:
Tom Lane writes:
Maybe I'm just a Luddite, but I've never understood what autoheader
buys us that's worth the trouble of conforming to its restrictions.
We wouldn't have to edit the config.h file by hand whenever some editing
of configure.in occurs.
Neil Conway [EMAIL PROTECTED] writes:
On Wed, 2003-03-26 at 20:42, Thomas T. Thai wrote:
ERROR: datumGetSize: Invalid typLen 0
Works for me:
Me too. Could be a 64-bit issue? Or a bug in the compiler Thomas is
using?
Please get a stack trace from the point of the error and post that.
Even dropping the table and all of its indexes and recreating it does
nothing to solve this problem, so I don't have any reason to suspect
corruption of the table itself. Corruption elsewhere is a
possibility, I suppose, but I haven't noticed any strangeness
elsewhere.
This sounds very
Tom Lane wrote:
Kevin Brown [EMAIL PROTECTED] writes:
When a heavy INSERT or UPDATE load on a table is occurring (lots of
quick INSERTs or UPDATEs within a single transaction), a VACUUM
ANALYZE (or just straight VACUUM) has a really good chance (10% or so)
of causing either the
I seem to be getting this:
gmake[3]: Entering directory `/home/chriskl/pgsql-temp/src/backend/parser'
bison -y -d gram.y
gram.y:4260.4-4307.10: type clash (`boolean' `keyword') on default action
gram.y:4307.11: parse error, unexpected :, expecting ; or |
gmake[3]: *** [parse.h] Error 1
Chris
Bruce Momjian wrote:
Peter Eisentraut wrote:
Bruce Momjian writes:
One idea is to require FOR UPDATE on the cursor --- while that prevents
other transactions from changing the cursor, it doesn't deal with the
current transaction modifying the table outside the
Hiroshi Inoue wrote:
Bruce Momjian wrote:
Peter Eisentraut wrote:
Bruce Momjian writes:
One idea is to require FOR UPDATE on the cursor --- while that prevents
other transactions from changing the cursor, it doesn't deal with the
current transaction modifying the table
Hiroshi Inoue,
But still can't explain this:
SENSITIVE = not READ_ONLY
It's in the ODBC Spec.
Bruce Momjian wrote:
Sorry, no idea. Peter's idea is that FOR UPDATE requires SENSITIVE, so
INSENSITIVE has to be READONLY because the update has to see
Bruce Momjian wrote:
Hiroshi Inoue wrote:
Bruce Momjian wrote:
Peter Eisentraut wrote:
Bruce Momjian writes:
I don't understand what you two are discussing.
What's is SENSITIVE, INSENSITIVE or ASESNSITIVE ?
In SQL99 standard, I see:
Bruce Momjian wrote:
Sorry, no idea. Peter's idea is that FOR UPDATE requires SENSITIVE, so
INSENSITIVE has to be READONLY because the update has to see other
changes to be accurate.
I think clearly SENSITIVE/READONLY should be possible, so:
AFAIK the except select won't see other inserts in uncommitted
transactions. If those transactions are committed you will end up with the
same problem. You can try it yourself, by manually doing two separate
transactions in psql.
Yeah, I see that now.
You either have to lock the whole
18 matches
Mail list logo
