On 01/29/2014 08:03 PM, Florian Weimer wrote:
> On 01/29/2014 09:07 AM, Craig Ringer wrote:
>
>> A challenge I've found when approaching this from the ORM side has been
>> getting people to care. The sentiment has tended to be along the lines
>> of: No other DBMS does this or requires this, why do
Florian Weimer wrote:
> Can you use other JDBC drivers (except SQLite) to insert
> Java Strings into NUMERIC columns and Java ints into text
> columns?
The JDBC specification can be downloaded from here:
http://download.oracle.com/otndocs/jcp/jdbc-4_1-mrel-spec/index.html
Check out appendix B.
On Wed, Jan 29, 2014 at 3:09 PM, Neil Harkins wrote:
> Note the number of exclusive locks in my first message, it is equal to the
> number of threads (20). Also, the ALTER was not running then, apologies
> if that was not clear.
Not all locks are on tables. Each transaction holds an Exclusive
Note the number of exclusive locks in my first message, it is equal to the
number of threads (20). Also, the ALTER was not running then, apologies if
that was not clear.
On Wednesday, January 29, 2014, Thomas Kellerer wrote:
> Neil Harkins wrote on 29.01.2014 23:37:
>
>> I totally understand DDL
Neil Harkins wrote on 29.01.2014 23:37:
I totally understand DDL taking exclusive locks, the problem here seems to be
that the *SELECTs*
are taking out exclusive locks, locking out the ALTER, which feels like a bug.
The SELECT is not holding an exclusive lock, it's holing a *shared* lock, but
I totally understand DDL taking exclusive locks, the problem here seems to
be that the *SELECTs* are taking out exclusive locks, locking out the
ALTER, which feels like a bug.
On Wednesday, January 29, 2014, Peter Eisentraut wrote:
> On 1/29/14, 4:59 PM, Neil Harkins wrote:
> > Why are those exc
On 1/29/14, 4:59 PM, Neil Harkins wrote:
> Why are those exclusive locks present?
> Can't the database rely on mvcc for those reads
> without locking? The autocommit should be
> increasing the xid used for the reads, so the
> ALTER should be able to slip in-between?
One would think so, but it's mo
Hi all, I'm curious if anyone can explain or suggest some debugging to
explain some odd locking behavior I am able to reproduce on pg 9.2.1
I start a test program with 20 threads (autocommit=1), all
executing the same SELECT query with a LEFT OUTER JOIN,
1~2 per second. Then I execute an ALTER to
On Wed, Jan 29, 2014 at 5:26 PM, Jeff Janes wrote:
> On Wed, Jan 29, 2014 at 6:15 AM, Pedro Salgueiro <
> pedro.salgue...@cortex-intelligence.com> wrote:
>
>> Hi,
>>
>> In the past couple of days I have been trying Continuous Archiving and
>> Point-in-Time Recovery (PITR) and I have some doubts.
On Wed, Jan 29, 2014 at 6:15 AM, Pedro Salgueiro <
pedro.salgue...@cortex-intelligence.com> wrote:
> Hi,
>
> In the past couple of days I have been trying Continuous Archiving and
> Point-in-Time Recovery (PITR) and I have some doubts.
>
> I successfully configured postgresql to perform the archiv
Found the problem.
When a restore is made, a new timeline is created.
The problem is that when a restore is made, the default behavior is to
restore the timeline used while creating the base backup, thus ignoring the
new timeline together with the changes made after the restore.
The solution to t
On 01/29/2014 08:29 AM, Tom Lane wrote:
Craig Ringer writes:
On 01/29/2014 02:01 PM, Tom Lane wrote:
I wish ORMs would go away sometimes too, and I recognise that there are
certain kinds of broken and stupid that it makes no sense to cater to. I
just don't think this is one of them - this
Craig Ringer writes:
> On 01/29/2014 02:01 PM, Tom Lane wrote:
>> Sorry, that is *just* as dangerous as implicit casts to text were.
>> It would bite a different set of queries, but not any less painfully.
> I'd be interested in some examples of that. It's clear that implicit
> casts *to* text we
On Wed, Jan 29, 2014 at 03:05:23PM +0800, Craig Ringer wrote:
> This is a painful issue for a significant group
Yes.
> They've been taught not to care about the DB and write
> "database-agnostic" code, but they're seeing Pg features that're so
> useful that they'd like to bend that and start usin
Is there any way to set max memory a postgres connection can use in
postgres or linux[centOS 5.6 64bit]?
Thanks
Bhushan
On Wed, Jan 29, 2014 at 8:39 PM, Bhushan Pathak
wrote:
> Bruce -
> Will go through the blog posts. Thanks for the info.
>
> Raghav -
> I have not executed analyze after the up
On 01/29/2014 12:07 AM, Craig Ringer wrote:
On 01/29/2014 02:36 PM, David Johnston wrote:
The "correct" solution would seem to be for ORMs to "bind unknown" against
the input but only when the supplied string is meant to be a representation
of a PostgreSQL type as opposed to being actual string
Bruce -
Will go through the blog posts. Thanks for the info.
Raghav -
I have not executed analyze after the upgrade.
-- Bhushan
On Wed, Jan 29, 2014 at 7:49 AM, Raghavendra <
raghavendra@enterprisedb.com> wrote:
> Thanks
>
> On 27 Jan 2014 22:35, "Bhushan Pathak" wrote:
> >
> > Hello,
On Wed, Jan 29, 2014 at 2:07 AM, Craig Ringer wrote:
> On 01/29/2014 02:36 PM, David Johnston wrote:
>>
>> The "correct" solution would seem to be for ORMs to "bind unknown" against
>> the input but only when the supplied string is meant to be a representation
>> of a PostgreSQL type as opposed to
I'm trying to setup SQL 2000 replication to PostgreSQL 9.x, and follow
those steps:
1) setup the publisher and distributor in SQL 2000
2) setup the article (12 tables)
3) setup the linked server to PostgreSQL and executed some queries to
test (with success)
4) created the 12 tables in PostgreSQ
Hi,
In the past couple of days I have been trying Continuous Archiving and
Point-in-Time Recovery (PITR) and I have some doubts.
I successfully configured postgresql to perform the archive of the wal
files, using the following properties in postgresql.conf
archive_mode = on
> wal_level = archive
On 01/29/2014 09:07 AM, Craig Ringer wrote:
A challenge I've found when approaching this from the ORM side has been
getting people to care. The sentiment has tended to be along the lines
of: No other DBMS does this or requires this, why do we have to jump
through hoops just to make PostgreSQL ha
On 01/29/2014 02:36 PM, David Johnston wrote:
>
> The "correct" solution would seem to be for ORMs to "bind unknown" against
> the input but only when the supplied string is meant to be a representation
> of a PostgreSQL type as opposed to being actual string data. The ORM is free
> to provide the
22 matches
Mail list logo
