On 03/22/2016 01:10 PM, Rob Sargent wrote:
>
>
> On 03/22/2016 12:55 PM, Melvin Davidson wrote:
>> Your problem seems strange as it has never been previously reported
>> for anyone else that has _successfully_ set up partioning.
>> Perhaps is you provide just a little bit more detail we might be able
>> to help you.
>> Useful and needed information would be:
>> 1. Version of PostgreSQL
>> 2. Operating System
>> 3. Table structure for partitioned table
>> 4. Trigger function and trigger used for insert
>> 5. The actual insert statement.
>>
>> On Tue, Mar 22, 2016 at 2:40 PM, CS DBA <cs_dba(at)consistentstate(dot)com
>> <mailto:cs_dba(at)consistentstate(dot)com>> wrote:
>>
>> Hi All;
>>
>> we setup partitioning for a large table but had to back off
>> because the return status (i.e: "INSERT 0 1") returns "INSERT 0
>> 0" when inserting into the partitioned table which causes the ORM
>> tool to assume the insert inserted 0 rows. Is there a standard /
>> best practices work around for this?
>>
>> Thanks in advance
>>
>>
>>
>>
>> --
>> Sent via pgsql-general mailing list (pgsql-general(at)postgresql(dot)org)
>> To make changes to your subscription:
>> http://www.postgresql.org/mailpref/pgsql-general
>>
>>
>>
> And which ORM are you using.
>
> I take it the problem is that the ORM is saying "zero rows inserted"
> and that's um, er, upsetting the client ( which might decide to retry
> and then generates an error for non-unique key or some such noise)
>
> rjs
>
>>
>> --
>> *Melvin Davidson*
>> I reserve the right to fantasize. Whether or not you
>> wish to share my fantasy is entirely up to you.
>
I think they are using Ruby, turns out the application is checking this
and throwing an error (and rolling back) when it detects no rows inserted