AFAICS the problem here is that this test doesn't use MultiXactIds at
all in 9.2, but it does in 9.3. I vaguely recall Noah tried to convince
me to put in an optimization which would have avoided this issue; I will
give that a thought. I don't think I will be able to get it done for
9.3.1 though.
On 10/02/2013 06:19 PM, Bruce Momjian wrote:
> On Tue, Sep 24, 2013 at 06:43:19PM +, dennis.noord...@helsinki.fi wrote:
>> The following bug has been logged on the website:
>>
>> Bug reference: 8469
>> Logged by: Dennis
>> Email address: dennis.noord...@helsinki.fi
>> Postgre
The following bug has been logged on the website:
Bug reference: 8500
Logged by: Kriton Kyrimis
Email address: kyri...@alumni.princeton.edu
PostgreSQL version: 9.2.4
Operating system: Scientific Linux 6.4
Description:
The version of postgis, available in the postgresq
I spent a lot of time looking at this issue. Your problem scenario can
be reduced to the following test case:
CREATE TABLE t (a INT);
INSERT INTO t VALUES (1);
The three sessions need to execute the following commands, in this
sequence:
-- Session 1
/* 1 */ BEGIN;
SELECT * FROM t FOR UPDATE;
-
Re: Bruce Momjian 2013-10-02 <20131002170628.gc5...@momjian.us>
> That is very interesting, and it certainly should not be failing.
>
> I am surprised it got an oid that was one less than the desired one,
> 18803. Is there any mention of 18803 in the SQL file?
18803 wasn't mentioned anywhere, ju
2013/10/4 Heikki Linnakangas
> On 02.10.2013 14:57,
> manindra.sarkar@brightnorth.**co.ukwrote:
>
>> Excel does not seem to respond with any data - but does give an idea that
>> it
>> has made some sort of a connection with the database. SQL commands fail
>> from
>> being executed.
>>
>
It is st
On 02.10.2013 14:57, manindra.sar...@brightnorth.co.uk wrote:
Excel does not seem to respond with any data - but does give an idea that it
has made some sort of a connection with the database. SQL commands fail from
being executed.
I'm afraid you'll have to provide a lot more details for anyone
