Please update and reply

In an attempt to reduce the amount of undeliverable and bounced email we
request that you remove the domains *@delinvest.com, @delgroup.com and
*@lynch-mayer.com from your mailing lists.  You are sending multiple
emails to invalid addresses on our servers.  Should you not be able to
comply you will receive a request for every piece of email that you
send.  Please confirm the deletion of our domains from your server.


Thank you,
Postmaster
Delaware Investments
postmaster@delinvest.com


-----Original Message-----
From: Postmaster
Sent: Thursday, July 08, 1999 10:43 AM
To: Postmaster
Subject: Notification: Inbound Mail Failure


The following recipients did not receive the attached mail.  A NDR was not
sent to the originator for the following recipients for one of the following
reasons:


    * The Delivery Status Notification options did not request failure
notification, or requested no notification.

    * The message was of precedence bulk.



NDR reasons are listed with each recipient, along with the notification
requested for that recipient,
or the precedence.

<listserv-postgres@delinvest.com> listserv-postgres@delinvest.com
    MSEXCH:IMS:Delaware Group:PHL-1818:HOOPER 0 (000C05A6) Unknown
Recipient
    Precedence: bulk

The message that caused this notification was:


 <<Re: [BUGS] General Bug Report: Files greater than 1 GB are created while
sorting >>
Bruce Momjian <maillist@candle.pha.pa.us> writes:
> I have renamed these sort temp tables to pg_sorttemp so they will not be
> confused with actual temp tables.

I didn't realize that the names generated for temp tables were so close
to those generated for temp files.  Changing one or the other does seem
like a good idea.  But I do not like "pg_sorttemp" because fd.c's
temporary-file mechanism is used for more things than just sorting.
Hash joins, for example.  Can we think of a better name?

Alternatively, how about including the user-given name for a temp table
into its real name?  That would be helpful for debugging, I'm sure.
I'm thinking of something like

    snprintf(newrelname, NAMEDATALEN, "pg_temp.%d.%u.%s",
         (int) MyProcPid, uniqueId++, userrelname);

(relying on snprintf to truncate the user name if too long, here).


> You are safe up to 2 gigs, and at that point, the OS will can cause a
> problem.  The new naming should make the cause clearer.  Don't know if
> we can get this done in 6.5.1 because the change to segment these
> requires some work.  Looks like the psort code goes right to fd/*,
> bypassing the storage manager.

Yes, it will take some thought to figure out how to handle multi-segment
temp files without cluttering the code too badly.  I think it can be
handled inside fd.c, though.

Note that under ordinary circumstances, the data being processed by a
sort or hash join will be written into several temp files that each get
just a fraction of the data; so you would not actually see a problem
until you got to several-times-2-Gig total data volume.

            regards, tom lane