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
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
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 mo
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 tabl
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
Chr
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
> 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
> 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 a
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
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
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 --m
"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
mult
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 $(top_builddir)/src/Makef
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 VACUU
Michael Meskes <[EMAIL PROTECTED]> writes:
> So here's the question comojng out of this all, anyone out here with an
> idea why the timestamp "Wed Jul 12 17:34:29 2000" becomes "Wed Jul 12
> 4649:34:26.02 2000" when putting it into timestamp format and back
> out. The function is almost identic
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 i
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 wha
> 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
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:
>
> READO
19 matches
Mail list logo