Andreas wrote:
>
> AFAICS, we have some alternatives:
> - try to grab the currently created files/syslog/eventlog.
> Seems hard to
> do, because we'd depend on additional external tools.
> - redirect stderr to a postgresql.conf known file.
> Disadvantage: breaks
> piping.
> - maintain a sharedMem for the latest messages. Disadvantage: limited
> space, no access to older entries after postmaster restart.
> - additional log_destination "file". Disadvantage: Yet Another File
> besides the redirected stderr, but this seems a minor problem.
>
Another alternative would be to add code to the admin tool to get the log
via scp or a similar method. IMHO PostgreSQL is doing the right thing here
by using the OS logging, and breaking that isn't a good idea when there are
other ways to solve the problem.
---------------------------(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
