Hello -
I am observing odd behavior that I am wondering if anyone here may have an
idea of how better to debug. I am suspecting a bug in the pgsql code, but
would be happy to find it is my error.
My specific situation is that I am using version 8.1.4 on a FreeBSD 6.1
AMD-64 system. I have a
Marc Evans [EMAIL PROTECTED] writes:
... I have a table with about 15000 records in it, which I
would like to add a new column to. The alter command shows success.
However, testing inserts reveals that the data for the new column is never
stored.
What do you mean by that exactly? The
On Tue, 19 Sep 2006, Tom Lane wrote:
Marc Evans [EMAIL PROTECTED] writes:
... I have a table with about 15000 records in it, which I
would like to add a new column to. The alter command shows success.
However, testing inserts reveals that the data for the new column is never
stored.
What do
Marc Evans [EMAIL PROTECTED] writes:
On Tue, 19 Sep 2006, Tom Lane wrote:
What do you mean by that exactly? The example you showed seems to be
doing just what it's supposed to.
In the failure mode, the source_record column always has the value NULL,
regardless of any value specified in an
On Tue, 19 Sep 2006, Tom Lane wrote:
Marc Evans [EMAIL PROTECTED] writes:
On Tue, 19 Sep 2006, Tom Lane wrote:
What do you mean by that exactly? The example you showed seems to be
doing just what it's supposed to.
In the failure mode, the source_record column always has the value NULL,
Marc Evans [EMAIL PROTECTED] writes:
On Tue, 19 Sep 2006, Tom Lane wrote:
What insert command is being issued exactly, and from what source? I'm
speculating about issues like stale plans or metadata caches, but you're
not providing any information about where to look.
Sorry for being terse
On Tue, 19 Sep 2006, Tom Lane wrote:
Marc Evans [EMAIL PROTECTED] writes:
On Tue, 19 Sep 2006, Tom Lane wrote:
What insert command is being issued exactly, and from what source? I'm
speculating about issues like stale plans or metadata caches, but you're
not providing any information about
Marc Evans [EMAIL PROTECTED] writes:
On Tue, 19 Sep 2006, Tom Lane wrote:
Hmph. You got any ON INSERT triggers or rules on that table? I can't
think of anything else that would interfere with data getting stored.
No INSERT triggers. I do have a BEFORE DELETE trigger, and a pile of
FOREIGN
On Tue, 19 Sep 2006, Tom Lane wrote:
Marc Evans [EMAIL PROTECTED] writes:
On Tue, 19 Sep 2006, Tom Lane wrote:
Hmph. You got any ON INSERT triggers or rules on that table? I can't
think of anything else that would interfere with data getting stored.
No INSERT triggers. I do have a BEFORE
Marc Evans [EMAIL PROTECTED] writes:
Any suggested tricks for seeing additional debug information or even
roaming through gdb, to try to figure this out?
Is the problem reproducible enough that you can watch it under gdb?
In that case it shouldn't be that hard to narrow it down. I gathered
On Tue, 19 Sep 2006, Tom Lane wrote:
Marc Evans [EMAIL PROTECTED] writes:
Any suggested tricks for seeing additional debug information or even
roaming through gdb, to try to figure this out?
Is the problem reproducible enough that you can watch it under gdb?
In that case it shouldn't be
I wrote:
... I think maybe
something is applying an UPDATE to the row and losing the new value
at that point. Are any of the FKs non-default actions (ON ... SET NULL
or some such that would try to alter data instead of just erroring)?
I've been able to reproduce a problem that may or may not
12 matches
Mail list logo
