Subject: Re: [OT?] Problems with majordomo

* Alvaro Herrera <alvherre <at> dcc.uchile.cl> [310804, 16:10]:
> On Fri, Aug 27, 2004 at 08:15:27PM -0300, Marc G. Fournier wrote:
> 
> > there are two ways in which a message would drop off the face of the earth 
> > ... Spamassassin scored it high enough to be considered spam, or the virus 
> > checker detected a virus :(  In both cases, the messages are just drop'd 
> > into /dev/null ...
> 
> Don't forget my problem with mail being lost in the air with a strange
> error message from a postmaster somewhere in the relay chain (I suspect
> commandprompt.com).  It was never resolved, and I had one person telling
> me a week ago that he could not subscribe to the list for this reason (I
> had to subscribe him manually).
> 
> > On Fri, 27 Aug 2004, Ennio-Sr wrote:
> > 
> > >I'm experiencing some weird behaviour by majordomo-owner (not answering
> > >my posts, even older than a week) and also with pgsql-novice and cygwin,
> > >I addressed a few posts to them which are nowhere to be seen (a search
> > >in the Archives also gives no result!); neither do I receive any
> > >acknowledgemt of reject or stall, which I set for. Even with 'general'
> > >there seem to be problems: I saw a couple of posts mailed recently, but
> > >couldn't see my answers, although the selfcopy is set.
> > >Could anibody explain what is going on?
> 
> > >P.S. I do receive other people's post, apparently all of them.
> 
> You don't know if you receive them all ... remember, maybe there is some
> data loss, but the records of data loss is also lost.
> 

Re: expected both swapped tables to have TOAST tables

On Tuesday 31 August 2004 3:52 pm, Tom Lane wrote:
> Steve Crawford <scrawford <at> pinpointresearch.com> writes:
> > I tried to truncate a table and received the following error:
> > "expected both swapped tables to have TOAST tables".
> > Googling provided no insight. What does it mean?
>
> It's a bug.  You probably dropped the last toastable column from
> the table.

Thanks. This table was created from another table as a "create table 
foo as select * from bar limit 0" followed by an "alter table foo 
drop column lastcolumn" so that would make sense.

As long as this isn't indicitave of future problems with this table I 
won't worry as it is only being used for a couple weeks for debugging 
and will only have inserts from here on out.

Cheers,
Steve

---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
      subscribe-nomail command to majordomo <at> postgresql.org so that your
      message can get through to the mailing list cleanly

Re: Multicolumn Primary Key

On Tuesday 31 August 2004 3:49 pm, Matthew T. O'Connor wrote:
> Thomas F.O'Connell wrote:
> > On Aug 31, 2004, at 4:34 PM, Martijn van Oosterhout wrote:
> >> Otherwise, have you VACUUM ANALYZEd recently?
> >
> > Argh! That seems to have been it. I have pg_autovacuum running,
> > so it didn't occur to me.
>
> pg_autovacuum only knows about table activity that has taken place
> while it's running.  Example:  Table A has an analyze threshold of
> 1000, if you perform 999 updates on table A, then kill and restart
> pg_autovacuum, you will have to perform another 1000 updates before
> pg_autovacuum performs an ANALYZE.  This is a large limitation of
> the current implementation.
>
> I tried to fix this for 8.0, but my autovacuum improvements didn't
> make the cut.

As a quick-'n'-dirty "fix", what about a command-line option to 
autovacuum that tells it to vacuum analyze all tables on startup? At 
least it would start in a somewhat known condition.

Cheers,
Steve

---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
      joining column's datatypes do not match

Re: Multicolumn Primary Key

Steve Crawford wrote:
> On Tuesday 31 August 2004 3:49 pm, Matthew T. O'Connor wrote:
>>pg_autovacuum only knows about table activity that has taken place
>>while it's running.  Example:  Table A has an analyze threshold of
>>1000, if you perform 999 updates on table A, then kill and restart
>>pg_autovacuum, you will have to perform another 1000 updates before
>>pg_autovacuum performs an ANALYZE.  This is a large limitation of
>>the current implementation.
>>
>>I tried to fix this for 8.0, but my autovacuum improvements didn't
>>make the cut.
> 
> As a quick-'n'-dirty "fix", what about a command-line option to 
> autovacuum that tells it to vacuum analyze all tables on startup? At 
> least it would start in a somewhat known condition.

I thought having pg_autovacuum do that, but seemed like overkill, but 
perhaps a command line option wouldn't be a bad thing.  However, you 
could also just as easily do a manual vacuum analyze whenever you like.

Matthew

---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
      joining column's datatypes do not match

Suppress output from psql?

Is there a way 'within' psql to suppress output?

One of our cron scripts calls a sql file which contains various database
commands (ALTER TABLEs, UPDATEs, etc) and various user-defined functions.
So within this sql file there are various SELECT * FROM myFunction(); which
sends output to the user from cron. I can't see anyway to suppress this from
the psql docs and I don't believe that I can suppress it from cron 
either (I'll do
some more checking there).

Thanks
Ron

---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?

               http://archives.postgresql.org

Re: Suppress output from psql?

Ron St-Pierre <rstpierre <at> syscor.com> writes:

> Is there a way 'within' psql to suppress output?
>
> One of our cron scripts calls a sql file which contains various database
> commands (ALTER TABLEs, UPDATEs, etc) and various user-defined functions.
> So within this sql file there are various SELECT * FROM myFunction(); which
> sends output to the user from cron. I can't see anyway to suppress this from
> the psql docs and I don't believe that I can suppress it from cron
> either (I'll do
> some more checking there).

How about putting ">/dev/null 2>&1" after the command line in your crontab?

Or redirect it to a file if you think you might need it...

-Doug
--

-- 
Let us cross over the river, and rest under the shade of the trees.
   --T. J. Jackson, 1863

---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?

               http://archives.postgresql.org

Re: Representating a family tree

On Sun, 29 Aug 2004 Guy Naor wrote

> Hi,
> 
> Are there any built in or known structures I can use in Postgres to represent a family tree?

I'll go out on a limb here. Not really, but, ...

> The usual tree representations in SQL are for regular hierarchy of 
> data, but on a family each node had usually 2 parents and a few child
> nodes. What will be the best way to represent something like this in an
> efficient manner?

Well, the way I have usually done this is a table of individuals, a
table of marriages, and one or more relationship tables. 

Some people would reduce the number of relationship tables by including
an entry for the first child in the marriage record, and including an
entry for the next younger sibling in the individual record. I think I
prefer to use the relationship records for all relationships.

Further details would depend heavily on what you might mean by "marriage"
or "family". For instance, do you only want to deal with family of last
official record, or do you want to record the birth parents and maybe
even all adoption/foster relationships? Etc. These decisions would
determine the number and structure of the relationship records,
essentially.

Anyway, as far as I know, there is no family tree type structure in
PostGreSQL. (I can't think of any database except a custom database that

Error Message Importing Into PostgreSQL (Using phpPgAdmin)

Re: Large Databases

On Tue, 2004-08-31 at 15:07, Joe Conway wrote:

> I suppose there *may* be some fundamental technical difference that 
> makes Postgres less reliable than Oracle when using NFS, but I'm not 
> sure what it would be -- if anyone knows of one, please speak up . 
> Early testing on NFS mounted NAS has been favorable, i.e. at least the 
> data does not get corrupted as it did on the SAN. And like I said, our 
> only other option appears to be spreading the data over multiple 
> volumes, which is a route we'd rather not take.

I have been doing a *lot* of testing of PG 7.4 over NFS with a couple of
EMC Celerras and have had excellent results thus far.

My best NFS results were within about 15% of the speed of my best SAN
results.

However, my results changed drastically under the 2.6 kernel, when the
NFS results stayed about the same as 2.4, but the SAN jumped about 50%
in transactions per second.

---------------------------(end of broadcast)---------------------------
TIP 7: don't forget to increase your free space map settings

Python Postgresql support?

Is it possible to build the python postgresql support library
on Mac OSX 10.3.5 with the default python install?

Adding "--with-python" gets an error message about libpython
not being a shared library when attempting to build postgresql.
(pg 7.4.5)

Thanks for any pointers.

Jerry

---------------------------(end of broadcast)---------------------------
TIP 8: explain analyze is your friend