On 12/9/18 8:03 AM, Mike Lissner wrote: > > The above seems to be the crux of the problem, how did NULL get into > the > column data? > > > I agree. My queries are generated by Django (so I never write SQL > myself), but: > > - the column has always been NOT NULL for its entire lifetime
The lifetime being since the migration did this?:
ALTER TABLE "search_docketentry" ADD COLUMN "recap_sequence_number" varchar(50) DEFAULT '' NOT NULL; ALTER TABLE "search_docketentry" ALTER COLUMN "recap_sequence_number" DROP DEFAULT;
"Lifetime" meaning that there was never a time when this column allowed nulls.
Also does the column recap_sequence_number appear in any other tables. Just wondering if the error was on another table?
Good idea, but no. This column only exists in one table.
> - we don't send *any* SQL commands to the replica yet, so that's not a > factor (for now it's just a live backup) > - the publisher now has a NOT NULL constraint on that column. I never > had to clear out null values to put it in place. I assume that if that
This part confuses me. You seem to imply that the column existed before the migration and you just added a NOT NULL constraint. The migration shows the column being created with a NOT NULL constraint.
Sorry, what I mean is that if *somehow* the master had null values in that column at some point, which I don't know how would even be possible because it only came into existence with the command above — if somehow that happened, I'd know, because I wouldn't have been able to add a NULL constraint without first fixing the data in that column, which I never did.
My contention is that for all these reasons, there should *never* have been a null value in that column on master.
> column ever had a null value and I tried to run a DDL to add a null > constraint, the DDL would have failed, right? > > Something feels wrong here, the more I think about it.
