From: | Francisco Olarte <folarte(at)peoplecall(dot)com> |
---|---|
To: | Dave Johansen <davejohansen(at)gmail(dot)com> |
Cc: | "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: Inserting from multiple processes? |
Date: | 2015-06-29 11:44:24 |
Message-ID: | CA+bJJbwOjmbAddPqauDZsi0k-SHP566bfXbBPDXHQyDchr6wBw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Hi Dave:
On Mon, Jun 29, 2015 at 6:32 AM, Dave Johansen <davejohansen(at)gmail(dot)com> wrote:
> The issue is that the following uses 5 XIDs when I would only expect it to
> us 1:
> BEGIN;
> SELECT insert_test_no_dup('2015-01-01', 1, 1);
....
> END;
I see.
> It appears that the unique violation that is caught and ignored increments
> the XID even though I didn't expect that to happen. I agree that our
> software was burning XIDs needlessly and Postgres handled this situation as
> best as it could. It also sounds like Postgres 9.5 adds features to support
> this sort of use more efficiently, but the XID incrementing on the unique
> violation seems like it could/should be fixed, if it hasn't been already.
IIRC you were using BEGIN/EXCEPTION, which I think uses a savepoint
internally, which maybe what is burning the xid on every execution (
it probably needs one to implement rollback to savepoint properly ).
I've done a simple test which burns one very time the exception is
raised ( using a division by zero ).
If this is your case you may be able to work around it using a
conditional insert instead of an exception, and as you are using a
function the potential ugliness will remain encapsulated ( it may even
be faster, as the docs explicitly say exception blocks are expensive,
but as usual YMMV depending on the exact query and the collision ratio
).
Francisco Olarte.
From | Date | Subject | |
---|---|---|---|
Next Message | Xavier 12 | 2015-06-29 12:04:43 | Re: pg_xlog on a hot_stanby slave |
Previous Message | Andreas Joseph Krogh | 2015-06-29 10:15:51 | Need for re-index after pg_upgrade |