On 2013-04-12 20:02:07 +0300, Tarvi Pillessaar wrote:
> On 12.04.2013 17:04, Andres Freund wrote:
> >On the other hand, at
> >least in the first example you haven't even committed the transaction so
> >there's nothing that could flush the transaction unless we we would
> >*always* flush nextval()
On 12.04.2013 17:04, Andres Freund wrote:
On the other hand, at
least in the first example you haven't even committed the transaction so
there's nothing that could flush the transaction unless we we would
*always* flush nextval() immediately if needs to get new values which
doesn't seem reasonab
On 2013-04-12 10:47:52 -0400, Tom Lane wrote:
> Andres Freund writes:
> > Thats caused by the fact that you didn't do anything that forces a WAL
> > flush since you didn't do any inserts or such. If you would do any
> > DML in the nextval() calling transaction this shouldn't happen (unless
> > you
Andres Freund writes:
> Thats caused by the fact that you didn't do anything that forces a WAL
> flush since you didn't do any inserts or such. If you would do any
> DML in the nextval() calling transaction this shouldn't happen (unless
> you use synchronous_commit=off).
> Now, there's a legitimat
On 2013-04-12 12:27:01 +, tar...@gmail.com wrote:
> The following bug has been logged on the website:
>
> Bug reference: 8059
> Logged by: Tarvi Pillessaar
> Email address: tar...@gmail.com
> PostgreSQL version: 9.2.4
> Operating system: linux
> Description:
>
> V
The following bug has been logged on the website:
Bug reference: 8059
Logged by: Tarvi Pillessaar
Email address: tar...@gmail.com
PostgreSQL version: 9.2.4
Operating system: linux
Description:
Very simple example:
postgres@sbox /usr/local/pgsql $ /usr/local/pgsql/bin
