[ https://forge.continuent.org/jira/browse/SEQUOIA-880?page=all ]
Mathieu Peltier reopened SEQUOIA-880:
-------------------------------------
Assign To: Emmanuel Cecchet (was: Mathieu Peltier)
Reopened to track fix with 2.10 branch
> 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: Emmanuel Cecchet
> 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
