loupicciano at comcast
Aug 3, 2010, 1:39 PM
Views: 344
Permalink
|
|
Re: DBMail imapd - cannot read messageblks
|
|
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" <paul [at] nfg>
To: "DBMail mailinglist" <dbmail [at] dbmail>
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.
|
Re: DBMail imapd - cannot read messageblks
