[ https://forge.continuent.org/jira/browse/SEQUOIA-880?page=all ]
     
Mathieu Peltier closed SEQUOIA-880:
-----------------------------------


Tested

> PostgreSQL backupers should not consider text on stderr as an error
> -------------------------------------------------------------------
>
>          Key: SEQUOIA-880
>          URL: https://forge.continuent.org/jira/browse/SEQUOIA-880
>      Project: Sequoia
>         Type: Bug
>   Components: Backup System
>     Versions: Sequoia 2.10.3
>  Environment: Sequoia 2.10.3 with PostgreSQL 8.1
>     Reporter: Guillaume Smet
>     Assignee: Mathieu Peltier
>      Fix For: Sequoia 2.10.5, Sequoia 3.0 beta2

>
>
> Hi all,
> I'm back to work on Sequoia and I'm currently playing with Sequoia 2.10.3 
> (far better than the 2.9.1 version I was using a few months ago, nice work!). 
> A few of you may remember that I worked on a patch to PostgreSQL backupers a 
> few months ago and various other patches and bug reports.
> I was trying to initialize a cluster and the database used contains a few 
> schema mistakes e.g. for example, two fields referenced by a foreign key are 
> not of the same type. When using pg_restore, we have a few comments on stderr 
> explaining that it's not a good idea and it may be slow:
> pg_restore: WARNING:  foreign key constraint "cms_use_hom_fol_map_se_f_7arnr" 
> will require costly sequential scans
> DETAIL:  Key columns "section_id" and "section_id" are of different types: 
> numeric and integer.
> pg_restore: WARNING:  foreign key constraint "cms_use_hom_fol_map_us_f_g0a5f" 
> will require costly sequential scans
> DETAIL:  Key columns "user_id" and "user_id" are of different types: numeric 
> and integer.
> I agree having this sort of mistakes in the schema is not a good idea but 
> that's not the point here (it's not a schema I designed and I cannot change 
> it atm).
> The problem is that Sequoia PostgreSQL backupers consider that any line on 
> stderr results in the fact that the pg_restore command was not successful. 
> See line 335-336 of NativeExecCommand.java which are:
> // Return exitValue + size of errors (if all is well, should be 0)
> return process.exitValue() + stderr.size();
> As far as PostgreSQL is concerned, the exit code is sufficient and 
> stderr.size()>0 should not be considered as an error as it is also used to 
> provide advice to the users.
> AFAICS the code in NativeExecCommand.java is also used at least by MySQL 
> backupers so it should be checked also with MySQL.
> Regards,
> --
> Guillaume

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   https://forge.continuent.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


_______________________________________________
Sequoia mailing list
[email protected]
https://forge.continuent.org/mailman/listinfo/sequoia

Reply via email to