On Mon, Oct 15, 2012 at 3:31 PM, Craig Ringer wrote:
>
> OK, that sounds more like a problem. It wasn't clear from your original
> post that it was replaying used sequence values.
>
> SIGINT should normally just terminate the statement, eg:
>
> regress=# SELECT pg_sleep(100);
> ERROR: canceling
You misunderstand me.
According to the server logs I have sent in the first message process
received signal 2 (it is SIGINT) and according to the documentation this
signal should not couse server crash. Wrong values of sequences does not
mean hole in generated values, but sequence started to genera
On 10/15/2012 04:17 PM, Michał Hankiewicz wrote:
You misunderstand me.
According to the server logs I have sent in the first message process
received signal 2 (it is SIGINT) and according to the documentation this
signal should not couse server crash. Wrong values of sequences does not
mean hole
On 10/12/2012 09:35 PM, hankiew...@gmail.com wrote:
5) after recovery was completed we have discovered that sequences on
production database had wrong values
To follow up on Tom's explanation, if you're relying on sequences not
having "holes" then your design is dangerously mistaken. A simple
hankiew...@gmail.com writes:
> The list of steps to reproduce bug:
> 1) Create two database on single server instance (production and sandbox)
> 2) On production perform normal operations (we use Trac with over 50 active
> users)
> 3) on the sandbox database start explain plan of query
> 4) while e
The following bug has been logged on the website:
Bug reference: 7600
Logged by: Database crash with data corruption
Email address: hankiew...@gmail.com
PostgreSQL version: 9.2.1
Operating system: Linux
Description:
We experienced database crash.
Our configuration:
S
