alvherre

Hi,

It seems the greylisting setup stopped quarantining emails?  I'm getting
a lot more spam in pgsql-hackers and the other lists I moderate, and
nothing in the headers suggest that they were greylisted at all.

Did something happen?

Hello!  This is just a test, please ignore.

If you don't ignore it, I'll ignore you.

Thanks,

Huh, you know you can de-duplicate them at your end, right?  Actually I
prefer to get the private copy, so that I get the email immediately even
if the list server is down or slow.

peter pilsl wrote:

> But there is a problem now: There are also entries in fn_kat which dont
> have corresponding entries in fn_dokumente and this entries should be
> listed too. With the proper count=0 !!

Your problem is not on the GROUP BY, but rather that you need an outer
join.  Try something like

select k.kategorie,count(d.oid) from fn_kat k left join fn_dokumente d
on k.id=d.kategorie group by k.kategorie;

Actually, if you are modifying the same blocks over and over it will
help *less*, because applying each record needs to occur only after the
previous records that modify the same block have been applied.

So you have two possibilities: you skip that record and try to apply the
next one, hoping that that record applies to a block that's not locked,
(which means you have to remember the skipped record and apply it
sometime in the future), or you put the process to sleep until the lock
has been released.

Oh, I see.  Fact is, Postgres defines it like a plain integer column and
attaches a DEFAULT clause.  That's it.  There's no magic to prevent it
from being modified.

The SQL standard specifies a strange beast called GENERATED BY which has
all sorts of funny behaviors, one of which is what you describe.  There
have been attempts at implementing the semantics described be the spec,
but they are so contorted that so far there hasn't been definitive
success.  It is expected that in the next release (8.4) something will
get done about it.

Samantha Atkins wrote:
> OK, I read it again. I don't see anything about how the timezone is
> specified for this type of column.

It is not -- that's the point.

Magicloud Wang wrote:
> Dear,
> I think database has its own operation journal, and different journal
> filesystem does give different performance. So if I put database file on a
> non-journal filesystem, would it be safe? Does this like using a raw device?

Regular database files need metadata journalling (data=writeback mount
option for ext3).  This is quite faster than full-blown journalling
which is what you get with default ext3 mount options.  WAL files
(pg_xlog) do not need any kind of journalling, so you can save the
overhead and put them on an ext2 filesystem (or any other nonjournalled
filesystem).

It doesn't.  Just do not update the ID -- what use do you have for that
anyway?  If you want to prevent it, you can put a trigger to the column,
but IMHO it would be a waste of your time and machine resources.

No, it doesn't mean that.  It means that you are trying to insert an
empty string.  Try this:

    insert into T_Admin(name,key,regDate,isLock,realName)
    values('aaa','aaa',NULL,'1','aaa');

Similarly, the NULL timestamp column in the file you give to COPY should
not contain empty quotes.

Ashish Karalkar wrote:

> Thanks for your answer actually that was the part of full query here is the actuall plan

I think you are confusing this for "here is a completely different plan
for a completely different query that has nothing to do whatsoever to
what I was asking before".

On this plan it looks like you need an index on otid.  Or maybe not.
It's hard to tell with only an EXPLAIN.

It's not just you.  Much as I am annoyed by top-posting, I am much more
so by people who top-post at the bottom.  Hey, did I say something
stupid?  No -- think about it.  These guys do exactly the same thing as
top-posters, except it is much worse because the actual text they wrote
is harder to find.

Gregory Stark wrote:

> bgwriter is started already when doing recovery, right? Perhaps things could
> be helped by telling bgwriter to behave differently during recovery.

No.

Guy Rouillier wrote:

> (2) delete all the individual addressees so only the list is left, then
> change that from CC to TO

Why do you do that?  It's unnecessary.

> (3) change my from identity to the one used for the list; although the list
> always posts to the identity I have set up for mailing lists, for some
> reason Thunderbird selects a different identity when I reply.

Probably the easiest way to handle this on the postgresql.org server
side is to configure the other identity as an alias, so that it allows
you to post unmoderated with both.  For this, see
http://mail.postgresql.org/mj/mj_wwwusr?domain=postgresql.org

Howard Cole wrote:
> Hello everyone,
>
> I take it from the lack of response that nobody knows how to kill a
> connection from the postgresql side on windows?

You can't, short of sending a signal to the process or restarting the
service.

SHOW integer_timestamp;

(actually, IIRC, this is one of the params that the server will send you
at session start).

IIRC the standard's definition of MERGE is still subject to the race
condition :-)  It seems mostly defined for OLAP, and assumes rather
static data.

Does this mean that Sun will run PostgreSQL next year?  Seems scary.

Guillaume Cottenceau wrote:

> I have noticed that others (Alvaro, Joshua) suggest to set
> vacuum_cost_delay as low as 10 or 20 ms,

My suggestion is to set it as *high* as 10 or 20 ms.  Compared to the
original default of 0ms.  This is just because I'm lazy enough not to
have done any measuring of the exact consequences of such a setting, and
out of fear that a very high value could provoke some sort of disaster.

I must admit that changing the vacuum_delay_limit isn't something that
I'm used to recommending.  Maybe it does make sense considering
readahead effects and the new "ring buffer" stuff.

Not on 8.2 (or earlier), because it can only process one table at a
time, so if it ever takes much longer than 5 minutes for vacuuming other
tables, this table will be neglected for at least that long -- and
probably a lot longer actually.

On 8.3 this should be somewhat less of a problem because autovacuum can
process more than one table at a time.  It will still be a problem if
there are several tables that take much longer than 5 minutes, but it
should be much less severe.