今天忽然发现一个问题，某一个本人正在维护的管理后台，随手编辑了一条数据，结果sql就一直报错超过上限。
先按照常规思路，查看这条数据，是否有某个字段是字符串类型的数据，超出255的上限了，结果仔细查看了一下，最长的字符串才只有四十个汉字，远没有到上限呢。
接着就是挨个查看其它类型的数据，就忽然发现，有个时间，前端传过来的是活动结束时间是2070年，忽然反应过来，是不是时间的长度导致的。
一看数据库里，时间戳是int4类型32位的，而这种类型的数据上限是 ：2147483647 比这个数字大的话，就没法保存了。
另外再补充一下，int4的最低可以存储的值是 -21474836478 是个负数来着。
所以定位到数据库可以存的时间上限了（2038-01-19 11:14:07） 超过这个时间，数据库就没法存储了。
定位到问题就好解决了。假如数据库更换类型，代价不大，可以平滑的换过来，那直接加大时间戳的数据长度就行，类似于换成int8,64位的。
假如生产数据比较多，换类型代价比较大，没法平滑的切换过来，那就只能用双库写入的方法，运行一段时间后，再干掉老的int4那个的。
再补充一下双库写入的操作流程：
假设目前有个老表0，时间戳是int4类型的，现在继续加大时间上限。这个时候，新建一个表1，字段和老表0的一模一样，除了时间戳的长度换成int8,别的不能有任何区别。
然后把老表0的数据，完全导入到表1里边。同时程序里，需要修改逻辑，把写入的地方，逻辑改为，同时写入俩表。然后这样程序跑一段时间后，可以平滑切换了后，先把程序改成只往表1写入，然后再把老表0干掉。
需要注意的细节是，切换的时候，一定要选用户访问最低的时间段弄，尽量把损失降到最低。还有双库写入的时候，一定要注意 pgsql的递增序列，程序往新表1里写入的时候，要保证递增序列和老表0 的一致，不然俩表递增id出现错位，就很尴尬。