Paul,
Some info you requested (all of our databases are UTF8):
Verification of encoding:
Name | Owner | Encoding | Collation | Ctype | Access privileges
-----------------+--------------------+----------+-------------+-------------+-
<maildb> | <mailowner> | UTF8 | en_US.UTF-8 | en_US.UTF-8 | (etc)
I have used sql/postgresql/create_tables.pgsql to build this database.
Specifically, here's the definition of the dbmail_messageblks table, with the
bytea messageblk:
CREATE TABLE dbmail_messageblks (
messageblk_idnr INT8 DEFAULT nextval('dbmail_messageblk_idnr_seq'),
physmessage_id INT8 REFERENCES dbmail_physmessage(id)
ON DELETE CASCADE ON UPDATE CASCADE,
messageblk BYTEA NOT NULL,
blocksize INT8 DEFAULT '0' NOT NULL,
is_header INT2 DEFAULT '0' NOT NULL,
PRIMARY KEY (messageblk_idnr)
);
Now, wait a minute. This bit of code - from
sql/postgresql/migrate_from_2.0_to_2.2.pgsql - looks like it may do exactly
what I need. Can you verify?:
BEGIN;
CREATE CAST (text AS bytea) WITHOUT FUNCTION;
ALTER TABLE dbmail_messageblks ADD blk_bytea bytea;
UPDATE dbmail_messageblks SET blk_bytea = CAST(messageblk::text AS bytea);
ALTER TABLE dbmail_messageblks DROP COLUMN messageblk;
ALTER TABLE dbmail_messageblks RENAME blk_bytea TO messageblk;
ALTER TABLE dbmail_messageblks ALTER messageblk SET not null;
DROP CAST (text AS bytea);
COMMIT;
if so, again, this is misleading. We built 2.2.16 from scratch, no upgrading.
So it would make sense that the create scripts would be appropriate to the
version built by the source tree, no? Perhaps a bit of renaming would make
sense - simply calling the create_tables.pgsql something which indicates its
version would be VERY helpful... ! Even a little annotation in the header of
each file would save a lot of time.
The first question: which version of the database does the create-tables.pgsql
create? Again, is there any simply documentation which would help a first-timer
know which scripts to step through? Seems like there are quite a few gotchas
here.
Lou
----- Original Message -----
From: "Paul J Stevens" <[email protected]>
To: "DBMail mailinglist" <[email protected]>
Sent: Tuesday, August 3, 2010 3:05:30 PM
Subject: Re: [Dbmail] DBMail daemons segfaulting
On 08/03/2010 07:38 PM, Lou Picciano wrote:
> Paul,
>
> Output of your proposed debugging routine; everything seems to work.
> Select inbox through the fetch command shown below...
No, it doesn't look right at all. Is that the result of a simple message
insertion like I showed? If so, please share your dbmail.conf and
postgresql schema.
I suspect there's a problem with the database encoding used....
>
> SIGNIFICANTLY, however, as I've reported: A mail client can login
> properly, and 'see' the header line in its inbox Remember, we've
> already received a bunch of email, on various virtualized domains, and
> have used your import utility for a few thousand more... I think we're
> beyond the basics.
Mmm, I consider your problem to be rather basic.
> Problem seems to be at the point of 'translating' dbmail messageblks
> (binary, bytea in PostgreSQL) into something an email client can read?
> Note the long binary string 'message body'... Help!
Yep. Like I said, smells like an encoding problem.
>
> (By way of documentation example, where are the full docs to these
> debugging commands? Where would one have found them?) Lou
Eh, nowhere. On the list maybe. Or the IMAP rfc.
> PS - For what it's worth, we have lots of output in errorlog, but have
> _never_ gotten anything written to logfile.
That's normal. The logfile only contains stdout/stderr for the daemons.
The errorlog contains the actual logging stream.
_______________________________________________
DBmail mailing list
[email protected]
http://mailman.fastxs.nl/cgi-bin/mailman/listinfo/dbmail
