Mailing List Archive

My update-davical-database is failing. At the beginning it says schema
version is 1.2.5 but when it tries to apply 1.2.6 patch, it says it is
not 1.2.5.

Debug below:

The database is version 8.1 currently at revision 1.2.5.
Looking at patches[0] (1.1.2.sql)
Patch 1.1.2.sql has already been applied.
Looking at patches[1] (1.1.3.sql)
Patch 1.1.3.sql has already been applied.
Looking at patches[2] (1.1.4.sql)
Patch 1.1.4.sql has already been applied.
Looking at patches[3] (1.1.5.sql)
Patch 1.1.5.sql has already been applied.
Looking at patches[4] (1.1.6.sql)
Patch 1.1.6.sql has already been applied.
Looking at patches[5] (1.1.7.sql)
Patch 1.1.7.sql has already been applied.
Looking at patches[6] (1.1.8.sql)
Patch 1.1.8.sql has already been applied.
Looking at patches[7] (1.1.9.sql)
Patch 1.1.9.sql has already been applied.
Looking at patches[8] (1.1.10.sql)
Patch 1.1.10.sql has already been applied.
Looking at patches[9] (1.1.11.sql)
Patch 1.1.11.sql has already been applied.
Looking at patches[10] (1.1.11a.sql)
Patch 1.1.11a.sql has already been applied.
Looking at patches[11] (1.1.12.sql)
Patch 1.1.12.sql has already been applied.
Looking at patches[12] (1.1.12a.sql)
Patch 1.1.12a.sql has already been applied.
Looking at patches[13] (1.2.1.sql)
Patch 1.2.1.sql has already been applied.
Looking at patches[14] (1.2.1a.sql)
Patch 1.2.1a.sql has already been applied.
Looking at patches[15] (1.2.1b.sql)
Patch 1.2.1b.sql has already been applied.
Looking at patches[16] (1.2.2.sql)
Patch 1.2.2.sql has already been applied.
Looking at patches[17] (1.2.3.sql)
Patch 1.2.3.sql has already been applied.
Looking at patches[18] (1.2.3a.sql)
Patch 1.2.3a.sql has already been applied.
Looking at patches[19] (1.2.4.sql)
Patch 1.2.4.sql has already been applied.
Looking at patches[20] (1.2.5.sql)
Patch 1.2.5.sql has already been applied.
Looking at patches[21] (1.2.6.sql)
Applying patch 1.2.6.sql ... Password for user postgres:
Failed to apply revision 1.2.6.sql to the database!
failed!
psql:./patches/1.2.6.sql:388: ERROR: Database has not been upgraded to 1.2.5
psql:./patches/1.2.6.sql:494: ERROR: current transaction is aborted,
commands ignored until end of transaction block
psql:./patches/1.2.6.sql:497: ERROR: current transaction is aborted,
commands ignored until end of transaction block
psql:./patches/1.2.6.sql:498: ERROR: current transaction is aborted,
commands ignored until end of transaction block
psql:./patches/1.2.6.sql:500: ERROR: current transaction is aborted,
commands ignored until end of transaction block
psql:./patches/1.2.6.sql:501: ERROR: current transaction is aborted,
commands ignored until end of transaction block
psql:./patches/1.2.6.sql:503: ERROR: current transaction is aborted,
commands ignored until end of transaction block
psql:./patches/1.2.6.sql:505: ERROR: current transaction is aborted,
commands ignored until end of transaction block
psql:./patches/1.2.6.sql:506: ERROR: current transaction is aborted,
commands ignored until end of transaction block
psql:./patches/1.2.6.sql:507: ERROR: current transaction is aborted,
commands ignored until end of transaction block
psql:./patches/1.2.6.sql:510: ERROR: current transaction is aborted,
commands ignored until end of transaction block
psql:./patches/1.2.6.sql:517: ERROR: current transaction is aborted,
commands ignored until end of transaction block
psql:./patches/1.2.6.sql:522: ERROR: current transaction is aborted,
commands ignored until end of transaction block
psql:./patches/1.2.6.sql:526: ERROR: current transaction is aborted,
commands ignored until end of transaction block
psql:./patches/1.2.6.sql:530: ERROR: current transaction is aborted,
commands ignored until end of transaction block
psql:./patches/1.2.6.sql:535: ERROR: current transaction is aborted,
commands ignored until end of transaction block
psql:./patches/1.2.6.sql:540: ERROR: current transaction is aborted,
commands ignored until end of transaction block
psql:./patches/1.2.6.sql:542: ERROR: current transaction is aborted,
commands ignored until end of transaction block
psql:./patches/1.2.6.sql:543: ERROR: current transaction is aborted,
commands ignored until end of transaction block
psql:./patches/1.2.6.sql:544: ERROR: current transaction is aborted,
commands ignored until end of transaction block
psql:./patches/1.2.6.sql:552: ERROR: current transaction is aborted,
commands ignored until end of transaction block
psql:./patches/1.2.6.sql:553: ERROR: current transaction is aborted,
commands ignored until end of transaction block
psql:./patches/1.2.6.sql:554: ERROR: current transaction is aborted,
commands ignored until end of transaction block
psql:./patches/1.2.6.sql:564: ERROR: current transaction is aborted,
commands ignored until end of transaction block
psql:./patches/1.2.6.sql:567: ERROR: current transaction is aborted,
commands ignored until end of transaction block
psql:./patches/1.2.6.sql:569: ERROR: current transaction is aborted,
commands ignored until end of transaction block
==> No further patches will be attempted!
No patches were applied.
Password for user postgres:
Supported locales updated.
Password for user postgres:
Updated view: dav_principal.sql applied.
Password for user postgres:
CalDAV functions updated.
Password for user postgres:
RRULE functions updated.
GRANT SELECT,INSERT,UPDATE,DELETE on collection to davical_app
GRANT SELECT,INSERT,UPDATE,DELETE on caldav_data to davical_app
GRANT SELECT,INSERT,UPDATE,DELETE on calendar_item to davical_app
GRANT SELECT,INSERT,UPDATE,DELETE on relationship to davical_app
GRANT SELECT,INSERT,UPDATE,DELETE on locks to davical_app
GRANT SELECT,INSERT,UPDATE,DELETE on property to davical_app
GRANT SELECT,INSERT,UPDATE,DELETE on freebusy_ticket to davical_app
GRANT SELECT,INSERT,UPDATE,DELETE on usr to davical_app
GRANT SELECT,INSERT,UPDATE,DELETE on usr_setting to davical_app
GRANT SELECT,INSERT,UPDATE,DELETE on roles to davical_app
GRANT SELECT,INSERT,UPDATE,DELETE on role_member to davical_app
GRANT SELECT,INSERT,UPDATE,DELETE on session to davical_app
GRANT SELECT,INSERT,UPDATE,DELETE on tmp_password to davical_app
GRANT SELECT,INSERT,UPDATE,DELETE on group_member to davical_app
GRANT SELECT,INSERT,UPDATE,DELETE on principal to davical_app
GRANT SELECT,INSERT,UPDATE,DELETE on relationship_type to davical_app
GRANT SELECT,INSERT,UPDATE,DELETE on sync_tokens to davical_app
DBD::Pg::db do failed: ERROR: relation "sync_tokens" does not exist at
./update-davical-database line 400, <PERMS> line 36.
GRANT SELECT,INSERT,UPDATE,DELETE on sync_changes to davical_app
DBD::Pg::db do failed: ERROR: relation "sync_changes" does not exist at
./update-davical-database line 400, <PERMS> line 37.
GRANT SELECT,INSERT,UPDATE,DELETE on grants to davical_app
DBD::Pg::db do failed: ERROR: relation "grants" does not exist at
./update-davical-database line 400, <PERMS> line 38.
GRANT SELECT,INSERT,UPDATE,DELETE on dav_principal to davical_app
DBD::Pg::db do failed: ERROR: relation "dav_principal" does not exist at
./update-davical-database line 400, <PERMS> line 39.
GRANT SELECT,INSERT,UPDATE,DELETE on access_ticket to davical_app
DBD::Pg::db do failed: ERROR: relation "access_ticket" does not exist at
./update-davical-database line 400, <PERMS> line 40.
GRANT SELECT,INSERT,UPDATE,DELETE on dav_binding to davical_app
DBD::Pg::db do failed: ERROR: relation "dav_binding" does not exist at
./update-davical-database line 400, <PERMS> line 41.
GRANT SELECT,INSERT,UPDATE,DELETE on calendar_alarm to davical_app
DBD::Pg::db do failed: ERROR: relation "calendar_alarm" does not exist
at ./update-davical-database line 400, <PERMS> line 42.
GRANT SELECT,INSERT,UPDATE,DELETE on calendar_attendee to davical_app
DBD::Pg::db do failed: ERROR: relation "calendar_attendee" does not
exist at ./update-davical-database line 400, <PERMS> line 43.
GRANT SELECT,INSERT,UPDATE,DELETE on addressbook_resource to davical_app
DBD::Pg::db do failed: ERROR: relation "addressbook_resource" does not
exist at ./update-davical-database line 400, <PERMS> line 44.
GRANT SELECT,INSERT,UPDATE,DELETE on addressbook_address_adr to davical_app
DBD::Pg::db do failed: ERROR: relation "addressbook_address_adr" does
not exist at ./update-davical-database line 400, <PERMS> line 45.
GRANT SELECT,INSERT,UPDATE,DELETE on addressbook_address_tel to davical_app
DBD::Pg::db do failed: ERROR: relation "addressbook_address_tel" does
not exist at ./update-davical-database line 400, <PERMS> line 46.
GRANT SELECT,INSERT,UPDATE,DELETE on addressbook_address_email to
davical_app
DBD::Pg::db do failed: ERROR: relation "addressbook_address_email" does
not exist at ./update-davical-database line 400, <PERMS> line 47.
GRANT SELECT,UPDATE on relationship_type_rt_id_seq to davical_app
GRANT SELECT,UPDATE on dav_id_seq to davical_app
GRANT SELECT,UPDATE on usr_user_no_seq to davical_app
GRANT SELECT,UPDATE on roles_role_no_seq to davical_app
GRANT SELECT,UPDATE on session_session_id_seq to davical_app
GRANT SELECT,UPDATE on principal_type_principal_type_id_seq to davical_app
GRANT SELECT,UPDATE on sync_tokens_sync_token_seq to davical_app
DBD::Pg::db do failed: ERROR: relation "sync_tokens_sync_token_seq" does
not exist at ./update-davical-database line 400, <PERMS> line 56.
GRANT SELECT,INSERT on time_zone to davical_app
GRANT SELECT on supported_locales to davical_app
GRANT SELECT on awl_db_revision to davical_app
GRANT SELECT on principal_type to davical_app
Database permissions updated.

Any help would be appreciated. This happened after I made a pg_dump from
my production server and loaded onto this test server to test the upgrade.

Thanks,
Ben Johnsey

Michael,

Looking at the database, it looks like the public schema is owned by
user postgres. All the tables are owned by davical_dba, but a lot of
the functions are owned by postgres. Could these owner differences be
causing the problem?

Thanks,
Ben Johnsey



Michael Rasmussen wrote:
The test and production database share the same configuration and user
permissions? - pg_hba.conf - davical_dba Access via unix socket or TCP/IP
-- Hilsen/Regards Michael Rasmussen

On Tue, 27 Apr 2010 14:53:41 -0500
Ben Johnsey <benjohnsey at gmail.com> wrote:

> Michael,
>
> Looking at the database, it looks like the public schema is owned by
> user postgres. All the tables are owned by davical_dba, but a lot of
> the functions are owned by postgres. Could these owner differences be
> causing the problem?
>
What functions are you referring to?
If you are logged into postgres and connect to davical (assuming that
is the name of the schema) using this command - \d - should show all
tables, indexes, sequences, and views defined in the schema. For every
line of output you should something like this:
List of relations
Schema | Name | Type | Owner
--------+--------------------------------------+----------+-------------
public | access_ticket | table | davical_dba
public | addressbook_address_adr | table | davical_dba
public | addressbook_address_email | table | davical_dba
public | addressbook_address_tel | table | davical_dba
public | addressbook_resource | table | davical_dba
public | awl_db_revision | table | davical_dba
public | caldav_data | table | davical_dba
public | calendar_alarm | table | davical_dba
public | calendar_attendee | table | davical_dba
public | calendar_item | table | davical_dba
public | collection | table | davical_dba
public | dav_binding | table | davical_dba
public | dav_id_seq | sequence | davical_dba
public | dav_principal | view | davical_dba
public | freebusy_ticket | table | davical_dba
public | grants | table | davical_dba
public | group_member | table | davical_dba
public | locks | table | davical_dba
public | principal | table | davical_dba
public | principal_type | table | davical_dba
public | principal_type_principal_type_id_seq | sequence | davical_dba
public | property | table | davical_dba
public | relationship | table | davical_dba
public | relationship_type | table | davical_dba
public | relationship_type_rt_id_seq | sequence | davical_dba
public | role_member | table | davical_dba
public | roles | table | davical_dba
public | roles_role_no_seq | sequence | davical_dba
public | session | table | davical_dba
public | session_session_id_seq | sequence | davical_dba
public | supported_locales | table | davical_dba
public | sync_changes | table | davical_dba
public | sync_tokens | table | davical_dba
public | sync_tokens_sync_token_seq | sequence | davical_dba
public | time_zone | table | davical_dba
public | tmp_password | table | davical_dba
public | usr | table | davical_dba
public | usr_setting | table | davical_dba
public | usr_user_no_seq | sequence | davical_dba
(39 rows)


--
Hilsen/Regards
Michael Rasmussen

Get my public GnuPG keys:
michael <at> rasmussen <dot> cc
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xD3C9A00E
mir <at> datanom <dot> net
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE501F51C
mir <at> miras <dot> org
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE3E80917
--------------------------------------------------------------
Love is in the offing. Be affectionate to one who adores you.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.morphoss.com/pipermail/davical-users/attachments/20100427/8e3348c3/attachment-0001.pgp>
-------------- next part --------------

On Tue, 2010-04-27 at 12:39 -0500, Ben Johnsey wrote:
> My update-davical-database is failing. At the beginning it says schema
> version is 1.2.5 but when it tries to apply 1.2.6 patch, it says it is
> not 1.2.5.

It is possible that there is an issue with the rows in the
awl_db_revision table. Can you post the output of:

SELECT * FROM awl_db_revision;

In fact it looks like there's an obscure bug in the check_db_revision()
function and I'm just trying to see what it is.

Thanks,
Andrew.

> Debug below:
>
> The database is version 8.1 currently at revision 1.2.5.

> Looking at patches[21] (1.2.6.sql)
> Applying patch 1.2.6.sql ... Password for user postgres:
> Failed to apply revision 1.2.6.sql to the database!
> failed!
> psql:./patches/1.2.6.sql:388: ERROR: Database has not been upgraded to 1.2.5


> Any help would be appreciated. This happened after I made a pg_dump from
> my production server and loaded onto this test server to test the upgrade.


------------------------------------------------------------------------
andrew (AT) morphoss (DOT) com +64(272)DEBIAN
You are deeply attached to your friends and acquaintances.
------------------------------------------------------------------------

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <http://lists.morphoss.com/pipermail/davical-users/attachments/20100428/ea680f5f/attachment.pgp>
-------------- next part --------------

On Wed, 2010-04-28 at 09:57 +1200, Andrew McMillan wrote:
> On Tue, 2010-04-27 at 12:39 -0500, Ben Johnsey wrote:
> > My update-davical-database is failing. At the beginning it says schema
> > version is 1.2.5 but when it tries to apply 1.2.6 patch, it says it is
> > not 1.2.5.
>
> It is possible that there is an issue with the rows in the
> awl_db_revision table. Can you post the output of:
>
> SELECT * FROM awl_db_revision;
>
> In fact it looks like there's an obscure bug in the check_db_revision()
> function and I'm just trying to see what it is.

OK. The bug is definitely in check_db_revision(). It seems likely that
you have somehow got two rows in your awl_db_revision for version 1.2.5.
If you could paste the following function definition into a psql session
against the database, and then try running the update again:


CREATE or REPLACE FUNCTION check_db_revision( INT, INT, INT ) RETURNS BOOLEAN AS '
DECLARE
major ALIAS FOR $1;
minor ALIAS FOR $2;
patch ALIAS FOR $3;
matching INT;
BEGIN
SELECT COUNT(*) INTO matching FROM awl_db_revision
WHERE (schema_major = major AND schema_minor = minor AND schema_patch > patch)
OR (schema_major = major AND schema_minor > minor)
OR (schema_major > major)
;
IF matching >= 1 THEN
RAISE EXCEPTION ''Database revisions after %.%.% have already been applied.'', major, minor, patch;
RETURN FALSE;
END IF;
SELECT COUNT(*) INTO matching FROM awl_db_revision
WHERE schema_major = major AND schema_minor = minor AND schema_patch = patch;
IF matching >= 1 THEN
RAISE EXCEPTION ''Database has not been upgraded to %.%.%'', major, minor, patch;
RETURN FALSE;
END IF;
RETURN TRUE;
END;
' LANGUAGE 'plpgsql';


Cheers,
Andrew.

------------------------------------------------------------------------
andrew (AT) morphoss (DOT) com +64(272)DEBIAN
Be cheerful while you are alive.
-- Phathotep, 24th Century B.C.

------------------------------------------------------------------------

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <http://lists.morphoss.com/pipermail/davical-users/attachments/20100428/bb861c5b/attachment.pgp>
-------------- next part --------------

Andrew,

Here is the data you requested:

schema_id | schema_major | schema_minor | schema_patch | schema_name
| applied_on
-----------+--------------+--------------+--------------+-------------+---------
----------------------
1 | 1 | 1 | 0 | Dawn |
2009-06- 15 19:23:05.338375-05
2 | 1 | 2 | 5 | Mai |
2009-06- 15 19:23:05.443422-05
1 | 1 | 1 | 0 | Dawn |
2009-06- 08 18:29:41.09464-05
2 | 1 | 2 | 5 | Mai |
2009-06- 08 18:29:41.522693-05
1 | 1 | 1 | 0 | Dawn |
2009-06- 08 18:29:41.09464-05
2 | 1 | 2 | 5 | Mai |
2009-06- 08 18:29:41.522693-05
1 | 1 | 1 | 0 | Dawn |
2009-06- 08 18:29:41.09464-05
2 | 1 | 2 | 5 | Mai |
2009-06- 08 18:29:41.522693-05
1 | 1 | 1 | 0 | Dawn |
2009-06- 08 18:29:41.09464-05
2 | 1 | 2 | 5 | Mai |
2009-06- 08 18:29:41.522693-05
(10 rows)


I see there are duplicate rows like you said. I also applied the patch
you sent and that did not seem to help. I still got the same error.
Should I remove the duplicate rows?

Thanks,
Ben


On 4/27/2010 5:04 PM, Andrew McMillan wrote:
> On Wed, 2010-04-28 at 09:57 +1200, Andrew McMillan wrote:
>
>> On Tue, 2010-04-27 at 12:39 -0500, Ben Johnsey wrote:
>>
>>> My update-davical-database is failing. At the beginning it says schema
>>> version is 1.2.5 but when it tries to apply 1.2.6 patch, it says it is
>>> not 1.2.5.
>>>
>> It is possible that there is an issue with the rows in the
>> awl_db_revision table. Can you post the output of:
>>
>> SELECT * FROM awl_db_revision;
>>
>> In fact it looks like there's an obscure bug in the check_db_revision()
>> function and I'm just trying to see what it is.
>>
> OK. The bug is definitely in check_db_revision(). It seems likely that
> you have somehow got two rows in your awl_db_revision for version 1.2.5.
> If you could paste the following function definition into a psql session
> against the database, and then try running the update again:
>
>
> CREATE or REPLACE FUNCTION check_db_revision( INT, INT, INT ) RETURNS BOOLEAN AS '
> DECLARE
> major ALIAS FOR $1;
> minor ALIAS FOR $2;
> patch ALIAS FOR $3;
> matching INT;
> BEGIN
> SELECT COUNT(*) INTO matching FROM awl_db_revision
> WHERE (schema_major = major AND schema_minor = minor AND schema_patch> patch)
> OR (schema_major = major AND schema_minor> minor)
> OR (schema_major> major)
> ;
> IF matching>= 1 THEN
> RAISE EXCEPTION ''Database revisions after %.%.% have already been applied.'', major, minor, patch;
> RETURN FALSE;
> END IF;
> SELECT COUNT(*) INTO matching FROM awl_db_revision
> WHERE schema_major = major AND schema_minor = minor AND schema_patch = patch;
> IF matching>= 1 THEN
> RAISE EXCEPTION ''Database has not been upgraded to %.%.%'', major, minor, patch;
> RETURN FALSE;
> END IF;
> RETURN TRUE;
> END;
> ' LANGUAGE 'plpgsql';
>
>
> Cheers,
> Andrew.
>
> ------------------------------------------------------------------------
> andrew (AT) morphoss (DOT) com +64(272)DEBIAN
> Be cheerful while you are alive.
> -- Phathotep, 24th Century B.C.
>
> ------------------------------------------------------------------------
>
>

On Tue, 2010-04-27 at 19:46 -0500, Ben Johnsey wrote:
> Andrew,
>
> Here is the data you requested:
>
> schema_id | schema_major | schema_minor | schema_patch | schema_name
> | applied_on
> -----------+--------------+--------------+--------------+-------------+---------
> ----------------------
> 1 | 1 | 1 | 0 | Dawn |
> 2009-06- 15 19:23:05.338375-05
> 2 | 1 | 2 | 5 | Mai |
> 2009-06- 15 19:23:05.443422-05
> 1 | 1 | 1 | 0 | Dawn |
> 2009-06- 08 18:29:41.09464-05
> 2 | 1 | 2 | 5 | Mai |
> 2009-06- 08 18:29:41.522693-05
> 1 | 1 | 1 | 0 | Dawn |
> 2009-06- 08 18:29:41.09464-05
> 2 | 1 | 2 | 5 | Mai |
> 2009-06- 08 18:29:41.522693-05
> 1 | 1 | 1 | 0 | Dawn |
> 2009-06- 08 18:29:41.09464-05
> 2 | 1 | 2 | 5 | Mai |
> 2009-06- 08 18:29:41.522693-05
> 1 | 1 | 1 | 0 | Dawn |
> 2009-06- 08 18:29:41.09464-05
> 2 | 1 | 2 | 5 | Mai |
> 2009-06- 08 18:29:41.522693-05
> (10 rows)
>
>
> I see there are duplicate rows like you said. I also applied the patch
> you sent and that did not seem to help. I still got the same error.
> Should I remove the duplicate rows?

Hi Ben,

Getting rid of the duplicate rows should solve it for you. I'm not sure
why my new function doesn't get it right - I'll look at that a little
harder I guess :-)

I wonder *how* you managed to get all these duplicate rows though. All
of the database updates should be in a transaction, so something very
odd has happened here.

Cheers,
Andrew.

>
> Thanks,
> Ben
>
>
> On 4/27/2010 5:04 PM, Andrew McMillan wrote:
> > On Wed, 2010-04-28 at 09:57 +1200, Andrew McMillan wrote:
> >
> >> On Tue, 2010-04-27 at 12:39 -0500, Ben Johnsey wrote:
> >>
> >>> My update-davical-database is failing. At the beginning it says schema
> >>> version is 1.2.5 but when it tries to apply 1.2.6 patch, it says it is
> >>> not 1.2.5.
> >>>
> >> It is possible that there is an issue with the rows in the
> >> awl_db_revision table. Can you post the output of:
> >>
> >> SELECT * FROM awl_db_revision;
> >>
> >> In fact it looks like there's an obscure bug in the check_db_revision()
> >> function and I'm just trying to see what it is.
> >>
> > OK. The bug is definitely in check_db_revision(). It seems likely that
> > you have somehow got two rows in your awl_db_revision for version 1.2.5.
> > If you could paste the following function definition into a psql session
> > against the database, and then try running the update again:
> >
> >
> > CREATE or REPLACE FUNCTION check_db_revision( INT, INT, INT ) RETURNS BOOLEAN AS '
> > DECLARE
> > major ALIAS FOR $1;
> > minor ALIAS FOR $2;
> > patch ALIAS FOR $3;
> > matching INT;
> > BEGIN
> > SELECT COUNT(*) INTO matching FROM awl_db_revision
> > WHERE (schema_major = major AND schema_minor = minor AND schema_patch> patch)
> > OR (schema_major = major AND schema_minor> minor)
> > OR (schema_major> major)
> > ;
> > IF matching>= 1 THEN
> > RAISE EXCEPTION ''Database revisions after %.%.% have already been applied.'', major, minor, patch;
> > RETURN FALSE;
> > END IF;
> > SELECT COUNT(*) INTO matching FROM awl_db_revision
> > WHERE schema_major = major AND schema_minor = minor AND schema_patch = patch;
> > IF matching>= 1 THEN
> > RAISE EXCEPTION ''Database has not been upgraded to %.%.%'', major, minor, patch;
> > RETURN FALSE;
> > END IF;
> > RETURN TRUE;
> > END;
> > ' LANGUAGE 'plpgsql';
> >
> >
> > Cheers,
> > Andrew.
> >
> > ------------------------------------------------------------------------
> > andrew (AT) morphoss (DOT) com +64(272)DEBIAN
> > Be cheerful while you are alive.
> > -- Phathotep, 24th Century B.C.
> >
> > ------------------------------------------------------------------------
> >
> >
>

------------------------------------------------------------------------
andrew (AT) morphoss (DOT) com +64(272)DEBIAN
Open Source: the difference between trust and antitrust
------------------------------------------------------------------------

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <http://lists.morphoss.com/pipermail/davical-users/attachments/20100428/295c54fe/attachment.pgp>
-------------- next part --------------

Andrew,

I got rid of the duplicates and that didn't help either..so maybe there
is nothing wrong with your function.

Can you think of anything else it could be. On my test machine, I just
deleted the database and re-created it with create-database.sh and
everything works, so there has to be some difference somewhere, I just
can't figure out what it is.

Current output of awl_db_revision is below:

schema_id | schema_major | schema_minor | schema_patch | schema_name
| applied_on
-----------+--------------+--------------+--------------+-------------+-------------------------------
1 | 1 | 1 | 0 | Dawn |
2009-06-15 19:23:05.338375-05
2 | 1 | 2 | 5 | Mai |
2009-06-15 19:23:05.443422-05
(2 rows)

Output of update-davical-database is the same. Anything else you can
think of that might be causing this?

Thanks,
Ben

On 4/28/2010 12:40 AM, Andrew McMillan wrote:
> On Tue, 2010-04-27 at 19:46 -0500, Ben Johnsey wrote:
>
>> Andrew,
>>
>> Here is the data you requested:
>>
>> schema_id | schema_major | schema_minor | schema_patch | schema_name
>> | applied_on
>> -----------+--------------+--------------+--------------+-------------+---------
>> ----------------------
>> 1 | 1 | 1 | 0 | Dawn |
>> 2009-06- 15 19:23:05.338375-05
>> 2 | 1 | 2 | 5 | Mai |
>> 2009-06- 15 19:23:05.443422-05
>> 1 | 1 | 1 | 0 | Dawn |
>> 2009-06- 08 18:29:41.09464-05
>> 2 | 1 | 2 | 5 | Mai |
>> 2009-06- 08 18:29:41.522693-05
>> 1 | 1 | 1 | 0 | Dawn |
>> 2009-06- 08 18:29:41.09464-05
>> 2 | 1 | 2 | 5 | Mai |
>> 2009-06- 08 18:29:41.522693-05
>> 1 | 1 | 1 | 0 | Dawn |
>> 2009-06- 08 18:29:41.09464-05
>> 2 | 1 | 2 | 5 | Mai |
>> 2009-06- 08 18:29:41.522693-05
>> 1 | 1 | 1 | 0 | Dawn |
>> 2009-06- 08 18:29:41.09464-05
>> 2 | 1 | 2 | 5 | Mai |
>> 2009-06- 08 18:29:41.522693-05
>> (10 rows)
>>
>>
>> I see there are duplicate rows like you said. I also applied the patch
>> you sent and that did not seem to help. I still got the same error.
>> Should I remove the duplicate rows?
>>
> Hi Ben,
>
> Getting rid of the duplicate rows should solve it for you. I'm not sure
> why my new function doesn't get it right - I'll look at that a little
> harder I guess :-)
>
> I wonder *how* you managed to get all these duplicate rows though. All
> of the database updates should be in a transaction, so something very
> odd has happened here.
>
> Cheers,
> Andrew.
>
>
>> Thanks,
>> Ben
>>
>>
>> On 4/27/2010 5:04 PM, Andrew McMillan wrote:
>>
>>> On Wed, 2010-04-28 at 09:57 +1200, Andrew McMillan wrote:
>>>
>>>
>>>> On Tue, 2010-04-27 at 12:39 -0500, Ben Johnsey wrote:
>>>>
>>>>
>>>>> My update-davical-database is failing. At the beginning it says schema
>>>>> version is 1.2.5 but when it tries to apply 1.2.6 patch, it says it is
>>>>> not 1.2.5.
>>>>>
>>>>>
>>>> It is possible that there is an issue with the rows in the
>>>> awl_db_revision table. Can you post the output of:
>>>>
>>>> SELECT * FROM awl_db_revision;
>>>>
>>>> In fact it looks like there's an obscure bug in the check_db_revision()
>>>> function and I'm just trying to see what it is.
>>>>
>>>>
>>> OK. The bug is definitely in check_db_revision(). It seems likely that
>>> you have somehow got two rows in your awl_db_revision for version 1.2.5.
>>> If you could paste the following function definition into a psql session
>>> against the database, and then try running the update again:
>>>
>>>
>>> CREATE or REPLACE FUNCTION check_db_revision( INT, INT, INT ) RETURNS BOOLEAN AS '
>>> DECLARE
>>> major ALIAS FOR $1;
>>> minor ALIAS FOR $2;
>>> patch ALIAS FOR $3;
>>> matching INT;
>>> BEGIN
>>> SELECT COUNT(*) INTO matching FROM awl_db_revision
>>> WHERE (schema_major = major AND schema_minor = minor AND schema_patch> patch)
>>> OR (schema_major = major AND schema_minor> minor)
>>> OR (schema_major> major)
>>> ;
>>> IF matching>= 1 THEN
>>> RAISE EXCEPTION ''Database revisions after %.%.% have already been applied.'', major, minor, patch;
>>> RETURN FALSE;
>>> END IF;
>>> SELECT COUNT(*) INTO matching FROM awl_db_revision
>>> WHERE schema_major = major AND schema_minor = minor AND schema_patch = patch;
>>> IF matching>= 1 THEN
>>> RAISE EXCEPTION ''Database has not been upgraded to %.%.%'', major, minor, patch;
>>> RETURN FALSE;
>>> END IF;
>>> RETURN TRUE;
>>> END;
>>> ' LANGUAGE 'plpgsql';
>>>
>>>
>>> Cheers,
>>> Andrew.
>>>
>>> ------------------------------------------------------------------------
>>> andrew (AT) morphoss (DOT) com +64(272)DEBIAN
>>> Be cheerful while you are alive.
>>> -- Phathotep, 24th Century B.C.
>>>
>>> ------------------------------------------------------------------------
>>>
>>>
>>>
>>
> ------------------------------------------------------------------------
> andrew (AT) morphoss (DOT) com +64(272)DEBIAN
> Open Source: the difference between trust and antitrust
> ------------------------------------------------------------------------
>
>

On 28 Apr 2010, at 16:58, Ben Johnsey wrote:

> Andrew,
>
> I got rid of the duplicates and that didn't help either..so maybe there
> is nothing wrong with your function.
>


Nope, there is still a bug in Andrew's function. try this...


CREATE or REPLACE FUNCTION check_db_revision( INT, INT, INT ) RETURNS BOOLEAN AS '
DECLARE
major ALIAS FOR $1;
minor ALIAS FOR $2;
patch ALIAS FOR $3;
matching INT;
BEGIN
SELECT COUNT(*) INTO matching FROM awl_db_revision
WHERE (schema_major = major AND schema_minor = minor AND schema_patch > patch)
OR (schema_major = major AND schema_minor > minor)
OR (schema_major > major)
;
IF matching >= 1 THEN
RAISE EXCEPTION ''Database revisions after %.%.% have already been applied.'', major, minor, patch;
RETURN FALSE;
END IF;
SELECT COUNT(*) INTO matching FROM awl_db_revision
WHERE schema_major = major AND schema_minor = minor AND schema_patch = patch;
IF matching < 1 THEN
RAISE EXCEPTION ''Database has not been upgraded to %.%.%'', major, minor, patch;
RETURN FALSE;
END IF;
RETURN TRUE;
END;
' LANGUAGE 'plpgsql';


Regards,
Keith



-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2439 bytes
Desc: not available
URL: <http://lists.morphoss.com/pipermail/davical-users/attachments/20100429/dac7f55e/attachment.bin>
-------------- next part --------------

Thanks Keith, I got the upgrade done, but now I have other problems.

I think my data base was screwed up, so I just dumped it and created a
new one, cause I couldn't get anything to work after the upgrade and
users were missing in the admin interface.

Now with a new database no events show up in Lightning. I can create
new events and they are getting put in the database, but the do not show
back up on the calendar. Any ideas on that?

The only error I found in the apache log was this, but I am not sure it
is related:

DAViCal: LOG: Browse:Principal:DoQuery: Query: QF: ERROR: syntax error
at end of input at character 416, referer:
http://calendar.pinnaclerestaurantcorp.com/admin.php?action=browse&t=principal&type=1

Thanks,
Ben



On 4/29/2010 4:38 AM, Keith Smith wrote:
> On 28 Apr 2010, at 16:58, Ben Johnsey wrote:
>
>
>> Andrew,
>>
>> I got rid of the duplicates and that didn't help either..so maybe there
>> is nothing wrong with your function.
>>
>>
>
> Nope, there is still a bug in Andrew's function. try this...
>
>
> CREATE or REPLACE FUNCTION check_db_revision( INT, INT, INT ) RETURNS BOOLEAN AS '
> DECLARE
> major ALIAS FOR $1;
> minor ALIAS FOR $2;
> patch ALIAS FOR $3;
> matching INT;
> BEGIN
> SELECT COUNT(*) INTO matching FROM awl_db_revision
> WHERE (schema_major = major AND schema_minor = minor AND schema_patch> patch)
> OR (schema_major = major AND schema_minor> minor)
> OR (schema_major> major)
> ;
> IF matching>= 1 THEN
> RAISE EXCEPTION ''Database revisions after %.%.% have already been applied.'', major, minor, patch;
> RETURN FALSE;
> END IF;
> SELECT COUNT(*) INTO matching FROM awl_db_revision
> WHERE schema_major = major AND schema_minor = minor AND schema_patch = patch;
> IF matching< 1 THEN
> RAISE EXCEPTION ''Database has not been upgraded to %.%.%'', major, minor, patch;
> RETURN FALSE;
> END IF;
> RETURN TRUE;
> END;
> ' LANGUAGE 'plpgsql';
>
>
> Regards,
> Keith
>
>
>
>

On Thu, 2010-04-29 at 18:42 -0500, Ben Johnsey wrote:
> Thanks Keith, I got the upgrade done, but now I have other problems.
>
> I think my data base was screwed up, so I just dumped it and created a
> new one, cause I couldn't get anything to work after the upgrade and
> users were missing in the admin interface.
>
> Now with a new database no events show up in Lightning. I can create
> new events and they are getting put in the database, but the do not show
> back up on the calendar. Any ideas on that?
>
> The only error I found in the apache log was this, but I am not sure it
> is related:
>
> DAViCal: LOG: Browse:Principal:DoQuery: Query: QF: ERROR: syntax error
> at end of input at character 416, referer:
> http://calendar.pinnaclerestaurantcorp.com/admin.php...

If there is a QF: logged I certainly want to know :-)

The logs should give the full query too, not just the fact of a syntax
error in the query. The PostgreSQL log should also log the query error.

However this error is not the result of a failure in the CalDAV side of
things, which would all have a 'caldav.php' URL, but is from when you
are in the 'list of user principals' screen in the admin page.


Did you keep a backup of your database? If users were missing from the
admin interface, it's possible that some of your users were 'Inactive'
and you just needed to make them active again.

I'd certainly like to solve the underlying problem if possible, so
perhaps if it's not too confidential, and if you do have that backup, it
would be good to see it so I could try and work out what might have gone
wrong.

Thanks,
Andrew.

--
------------------------------------------------------------------------
andrew (AT) morphoss (DOT) com +64(272)DEBIAN
You will always have good luck in your personal affairs.
------------------------------------------------------------------------

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <http://lists.morphoss.com/pipermail/davical-users/attachments/20100430/640084f8/attachment.pgp>
-------------- next part --------------