Re: [BUGS] BUG #8496: psqlODBC driver does not work well via Excel

[Heikki Linnakangas]

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 to be 
able to help you.


- Heikki


--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

Re: [BUGS] BUG #8496: psqlODBC driver does not work well via Excel

[Pavel Stehule]

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 strange - I used pg ODBC driver together with MS Excel without any
issue.

Regards

Pavel



>
> I'm afraid you'll have to provide a lot more details for anyone to be able
> to help you.
>
> - Heikki
>
>
> --
> Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/**mailpref/pgsql-bugs
>

Re: [BUGS] pg_upgrade 9.0->9.2 failure: Mismatch of relation OID in database

[Christoph Berg]

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, just 18804 like the log says.

> If you create a
> cluster with just your schema and no data, can you upgrade that cleanly?

I haven't tried that yet. This is on a customer machine we don't have
access to except when arranging a remote desktop session. I'll see if
I can do some tests there.

Mit freundlichen Grüßen,
Christoph Berg
-- 
Tel.: +49 (0)21 61 / 46 43-187
credativ GmbH, HRB Mönchengladbach 12080, USt-ID-Nummer: DE204566209
Hohenzollernstr. 133, 41061 Mönchengladbach
Geschäftsführung: Dr. Michael Meskes, Jörg Folz, Sascha Heuer


-- 
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

Re: [BUGS] BUG #8434: Why does dead lock occur many times ?

[Alvaro Herrera]

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;

-- Session 2
/* 2 */ BEGIN;
UPDATE t SET a = 2; -- blocks waiting on S1

-- Session 3
/* 3 */ BEGIN;
UPDATE t SET a = 3; -- blocks
-- this is waiting on S1, but since S2 is also waiting on S1 and will acquire a
-- conflicting lock first, this session will only be released after S2 releases
-- its own lock.

Session 1
/* 4 */ UPDATE t SET a = 4;
COMMIT; -- releases session 2
BEGIN;
SELECT * FROM t FOR UPDATE; -- blocks waiting on S2 (*)

Session 2:
/* 5 */ COMMIT; -- releases session 1
BEGIN;
UPDATE t SET a = 5; -- blocks waiting on S3

Session 1:
/* 6 */ UPDATE t SET a = 6; -- blocks waiting on S3

At this point, all sessions are blocked on their UPDATE commands, and
deadlock is reported.  (For debugging, it's useful to set a very large
deadlock_timeout and examine pg_locks, etc.)

The point at which things started to go wrong was where the session 1's
SELECT FOR UPDATE with the (*) was allowed to continue after session 2
commits.  In 9.2 that session remains blocked, and instead we release
session 3.

The problem is the handling of following of the update chain during a
lock command; the question is should sessions be blocked waiting for
locks on future versions of the row?  They currently don't block, which
is what leads the SELECT FOR UPDATE to continue; but if we make them
block, other things break.  I initially toyed with the following patch,
which removes the deadlock the above report and also your original test
case:

--- a/src/backend/access/heap/heapam.c
+++ b/src/backend/access/heap/heapam.c
@@ -4832,15 +4832,12 @@ l4:
xmax = HeapTupleHeaderGetRawXmax(mytup.t_data);
 
/*
-* If this tuple is updated and the key has been modified (or
-* deleted), what we do depends on the status of the updating
-* transaction: if it's live, we sleep until it finishes; if it 
has
-* committed, we have to fail (i.e. return HeapTupleUpdated); 
if it
-* aborted, we ignore it. For updates that didn't touch the 
key, we
-* can just plough ahead.
+* If this tuple is updated, what we do depends on the status 
of the
+* updating transaction: if it's live, we sleep until it 
finishes; if
+* it has committed, we have to fail (i.e. return 
HeapTupleUpdated); if
+* it aborted, we ignore it.
 */
-   if (!(old_infomask & HEAP_XMAX_INVALID) &&
-   (mytup.t_data->t_infomask2 & HEAP_KEYS_UPDATED))
+   if (!(old_infomask & HEAP_XMAX_INVALID))
{
TransactionId update_xid;
 

However, the differences in behavior this causes (visible by running the
isolation tests) don't look good to me.  It's quite possible that there
are other bugs elsewhere.

Sadly, I have to look at other things now and I won't have time to
research this further until after next week's minor releases; so
whatever we decide to do, if anything, will not be in 9.3.1.

Thanks for the report.

-- 
Álvaro Herrerahttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services


-- 
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

[BUGS] BUG #8500: Upgrade to postgis 2.1 breaks existing databases

[kyrimis]

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 postgresql yum repository for
postgis 9.2, was recently upgraded to version 2.1. This breaks existing
databases built with postgis 2.0, as queries involving postgis fail with the
error message "ERROR:  could not access file "$libdir/postgis-2.0": No such
file or directory"


This includes backing up the databases, so upgrading them to use postgis 2.1
may not even be an option, if a hard upgrade is required.


I have downgraded all postgis2_92 packages to version 2.0.4 and excluded
them from future upgrades, but I'd recommend reverting to that version in
the repositories, as well. At the very least, please ensure that version
2.0.x of the packages remains available in the future. Better still, provide
alternative postgis21_92-* packages, for those wishing to use the latest
version, without affecting those that use the previous version.



-- 
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

Re: [BUGS] BUG #8469: Xpath behaviour unintuitive / arguably wrong

[Stefan Kaltenbrunner]

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
>> PostgreSQL version: 9.3.0
>> Operating system:   FreeBSD 9.2-RC4
>> Description:
>>
>> Hi,
>>
>>
>> After upgrading an 8.1 version to 9.3.0 I am suddenly seeing text fields
>> containing "&" where they are populated from XML. This may be a
>> coincidence and the problem may have existed earlier, in any case, now I
>> noticed.
>>
>>
>> I extract the text content of XML nodes using xpath, from something like:
>>
>>
>> Jones & Smith
>>
>>
>> The reason I end up with "&" is the IMHO rather odd xpath behaviour:
>>
>>
>> # select xpath('/a/text()', (select xmlelement(name "a", 'A & B')));
>>
>>
>>  xpath 
>> ---
>>  {"A & B"}
>>
>>
>> The canonical contents of "a" is "A & B". At first search I've found some
>> rather heated debates about this with bits of name calling; I certainly do
>> not want to get into that and I apologize in advance to those who feel very
>> strongly about this.
>>
>>
>> I've seen one "fix" describe the problem as:
>>
>>
>> ""DESCRIPTION: Submitter invokes following statement:
>> SELECT (XPATH('/*/text()', '<'))[1].
>> He expect (escaped) result "<", but gets "<"
>> """
>>
>>
>> With respect, this "bug" makes no sense as this produces in fact the right
>> result. The actual value of  is "<", it's just escaped when serialized
>> to XML. If  were to actually contain "<", it'd be serialized as
>> "<". It should not be possible to be blindly cast to a text type, but
>> explicitly serialized as such.
>>
>>
>> At least the reviewer at:
>>
>>
>> http://www.postgresql.org/message-id/201106291934.23089.rsmog...@softperience.eu
> 
> There are two other similar bug reports on this from February and March
> of this year:
> 
>   
> http://www.postgresql.org/message-id/e1u1fkl-0002rd...@wrihigleys.postgresql.org

I think that should be:
http://www.postgresql.org/message-id/e1u1fkl-0002rd...@wrigleys.postgresql.org


>   
> http://www.postgresql.org/message-id/e1uhyuw-0001oj...@wrigleys.postgresql.org
> 
> Someone who knows XML needs to take leadership on this and propose a
> patch.

agreed


Stefan


-- 
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

Re: [BUGS] BUG #8470: 9.3 locking/subtransaction performance regression

[Alvaro Herrera]

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.

-- 
Álvaro Herrerahttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services


-- 
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs