Обсуждение: Logging statements with errors in PostgreSQL 8.1

Поиск
Список
Период
Сортировка

Logging statements with errors in PostgreSQL 8.1

От
Radcon Entec
Дата:
Greetings!

I am using PostgreSQL 8.3, as are most of our customers.  But we still have at least one who is using PostgreSQL 8.1.  The log files from that customer are showing repeated syntax errors, but they are not giving me any information about where the errors are coming from.  Here's a sample from an old 8.1 installation on my machine:

2009-06-02 13:26:32 user postgres ERROR:  syntax error at or near "OWNED" at character 39
2009-06-02 13:26:32 user postgres ERROR:  syntax error at or near "OWNED" at character 45
2009-06-02 13:26:32 user postgres ERROR:  syntax error at or near "OWNED" at character 62
2009-06-02 13:26:32 user postgres ERROR:  syntax error at or near "OWNED" at character 53

On the other hand, my PostgreSQL 8.3 installation reports errors like this:

2009-10-21 15:16:45 EDT ERROR:  relation "schedule_plan" does not exist
2009-10-21 15:16:45 EDT STATEMENT:  select max_heating_rev_interval, max_cooling_rev_interval, name, high_heating_limit, low_heating_limit, high_heating_correction, low_heating_correction, high_cooling_limit, low_cooling_limit, high_cooling_correction, low_cooling_correction from schedule_plan

Is there any way to get a PostgreSQL 8.1 installation to report the statements that caused the error, as the 8.3 installation does? 

I notice that the 8.3 log file also reports (frequently) loading the plugin_debugger.dll library.  Is the problem that that library was not available in 8.1?

Thanks very much!

RobR 

Re: Logging statements with errors in PostgreSQL 8.1

От
Adrian Klaver
Дата:
On Monday 26 October 2009 5:48:42 am Radcon Entec wrote:
> Greetings!
>
> I am using PostgreSQL 8.3, as are most of our customers.  But we still have
> at least one who is using PostgreSQL 8.1.  The log files from that customer
> are showing repeated syntax errors, but they are not giving me any
> information about where the errors are coming from.  Here's a sample from
> an old 8.1 installation on my machine:
>
> 2009-06-02 13:26:32 user postgres ERROR:  syntax error at or near "OWNED"
> at character 39 2009-06-02 13:26:32 user postgres ERROR:  syntax error at
> or near "OWNED" at character 45 2009-06-02 13:26:32 user postgres ERROR:
> syntax error at or near "OWNED" at character 62 2009-06-02 13:26:32 user
> postgres ERROR:  syntax error at or near "OWNED" at character 53
>
> On the other hand, my PostgreSQL 8.3 installation reports errors like this:
>
> 2009-10-21 15:16:45 EDT ERROR:  relation "schedule_plan" does not exist
> 2009-10-21 15:16:45 EDT STATEMENT:  select max_heating_rev_interval,
> max_cooling_rev_interval, name, high_heating_limit, low_heating_limit,
> high_heating_correction, low_heating_correction, high_cooling_limit,
> low_cooling_limit, high_cooling_correction, low_cooling_correction from
> schedule_plan
>
> Is there any way to get a PostgreSQL 8.1 installation to report the
> statements that caused the error, as the 8.3 installation does?
>
> I notice that the 8.3 log file also reports (frequently) loading the
> plugin_debugger.dll library.  Is the problem that that library was not
> available in 8.1?
>
> Thanks very much!
>
> RobR

http://www.postgresql.org/docs/8.1/interactive/runtime-config-logging.html
See:
log_min_error_statement (string)

--
Adrian Klaver
aklaver@comcast.net

Re: Logging statements with errors in PostgreSQL 8.1

От
John R Pierce
Дата:
Radcon Entec wrote:
> Is there any way to get a PostgreSQL 8.1 installation to report the
> statements that caused the error, as the 8.3 installation does?

see
http://www.postgresql.org/docs/8.1/static/runtime-config-logging.html#RUNTIME-CONFIG-LOGGING-WHAT
specifically, log_statement, and log_line_prefix
<http://www.postgresql.org/docs/8.1/static/runtime-config-logging.html#RUNTIME-CONFIG-LOGGING-WHAT>

afaik, these options are just about identical from 8.1 to 8.3, so look
at your 8.3 postgresql.conf file, and you should be able to copy those
options to the 8.1 file.