Tom Lane escribió:
Alvaro Herrera [EMAIL PROTECTED] writes:
I don't advocate changing that ERROR to anything else. The message
wording, as Tom says, can easily be changed -- I think this patch should
be enough. Feel free to propose better wording.
Minor gripe: all three variants of the
On Thu, 2007-12-06 at 11:33 -0300, Alvaro Herrera wrote:
Tom Lane escribió:
Alvaro Herrera [EMAIL PROTECTED] writes:
I don't advocate changing that ERROR to anything else. The message
wording, as Tom says, can easily be changed -- I think this patch should
be enough. Feel free to
Simon Riggs escribió:
Sorry to come in on late on this: That wording is better, but it still
doesn't explain why it has occurred or what the user should do about it.
I think we will get other complaints saying why has my autovacuum been
canceled? and what should I do about this?.
Perhaps
On Thu, 2007-12-06 at 12:03 -0300, Alvaro Herrera wrote:
Simon Riggs escribió:
Sorry to come in on late on this: That wording is better, but it still
doesn't explain why it has occurred or what the user should do about it.
I think we will get other complaints saying why has my autovacuum
Simon Riggs [EMAIL PROTECTED] writes:
True. We can say task will be automatically re-scheduled, so that
people understand the message and don't start asking us.
How about temporarily canceling autovacuum task? This is accurate
regardless of the origin of the SIGINT.
Tom Lane escribió:
Simon Riggs [EMAIL PROTECTED] writes:
True. We can say task will be automatically re-scheduled, so that
people understand the message and don't start asking us.
How about temporarily canceling autovacuum task? This is accurate
regardless of the origin of the SIGINT.
On Thu, 2007-12-06 at 12:24 -0300, Alvaro Herrera wrote:
Tom Lane escribió:
Simon Riggs [EMAIL PROTECTED] writes:
True. We can say task will be automatically re-scheduled, so that
people understand the message and don't start asking us.
How about temporarily canceling autovacuum
Gregory Stark [EMAIL PROTECTED] writes:
I guess we should capture this error with a PG_TRY and silently abort instead.
Just a NOTICE or INFO should be sufficient. Other errors should of course be
rethrown.
This falls in the category of destabilizing the code for purely
cosmetic reasons, and
Tom Lane [EMAIL PROTECTED] writes:
This falls in the category of destabilizing the code for purely
cosmetic reasons, and would be a foolish change to make at RC1 time.
I suppose. Expect to have more bug reports like this one then though.
We could change the text of the ERROR message
Gregory Stark escribió:
Tom Lane [EMAIL PROTECTED] writes:
This falls in the category of destabilizing the code for purely
cosmetic reasons, and would be a foolish change to make at RC1 time.
I suppose. Expect to have more bug reports like this one then though.
We could change the
Alvaro Herrera [EMAIL PROTECTED] writes:
I don't advocate changing that ERROR to anything else. The message
wording, as Tom says, can easily be changed -- I think this patch should
be enough. Feel free to propose better wording.
Minor gripe: all three variants of the message should follow
Alvaro Herrera [EMAIL PROTECTED] writes:
Bruce Momjian escribió:
Magnus Hagander wrote:
On Fri, Nov 30, 2007 at 10:13:53AM +, Gregory Stark wrote:
Mike C. [EMAIL PROTECTED] writes:
ERROR: canceling statement due to user request
CONTEXT: automatic analyze of table
como es el pg_dump y pg_restore que usas?
Saludos Fernando
Mike C. wrote:
The following bug has been logged online:
Bug reference: 3790
Logged by: Mike C.
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.3beta3
Operating system: Linux 2.6.16.21-0.8-xen #1 SMP Mon
13 matches
Mail list logo
