On Ter, Jul 7, 2015 at 2:51 , Adrian Klaver
wrote:
On 07/07/2015 06:44 AM, Filipe Pina wrote:
On Ter, Jul 7, 2015 at 2:31 , Alban Hertroys
wrote:
On 7 July 2015 at 12:55, Filipe Pina
wrote:
On Ter, Jul 7, 2015 at 1:41 , Adrian Klaver
wrote:
Still not sure what is you
On Ter, Jul 7, 2015 at 2:31 , Alban Hertroys wrote:
On 7 July 2015 at 12:55, Filipe Pina
wrote:
On Ter, Jul 7, 2015 at 1:41 , Adrian Klaver
wrote:
Still not sure what is you are trying to accomplish. Is it really
necessary
that every transaction be serialized? Or to put it another way
g locks, but implementing this "serialization failure"
handler is becoming a major headache...
Thanks guys!
On Ter, Jul 7, 2015 at 1:41 , Adrian Klaver
wrote:
On 07/06/2015 07:15 AM, Filipe Pina wrote:
Yes, I've tried to come up with guideline to enumerate tables used in
each p
wrote:
On 07/04/2015 10:49 AM, Filipe Pina wrote:
Thanks for the suggestion. I read that some people do use that
strategy
for maintenance sometimes but it's no feasible in this scenario.
I would have to disallow new connections AND kill all existing
connections (as there would be an existing
k TABLE
-> FUNCTION C
> TABLE is not locked anymore because function B frees it as soon
as it returns
Is there someway to have a function that locks some tables on the
"outter" transaction instead of its own subtransaction?
On Seg, Jul 6, 2015 at 3:08 , Filipe Pina
wrote:
cuted?
EG:
UPDATE pg_database
SET datallowconn FALSE
WHERE datname = 'your_database' ;
START TRANSACTION;
COMMIT;
UPDATE pg_database
SET datallowconn TRUE
WHERE datname = 'your_database' ;
On Fri, Jul 3, 2015 at 1:25 PM, Filipe Pina
wrote:
> So,
that performance would be
worse...
Thanks,
Filipe
On Sex, Jun 12, 2015 at 5:25 , Filipe Pina
wrote:
Exactly, that’s why there’s a limit on the retry number. On the
last try I wanted something like full lockdown to make sure the
transaction will not fail due to serialiazation failure (if no o
Kevin, assuming you will have some time to confirm that it has been fixed in
some version some time next week, I’ve compiled the test steps in
http://pastebin.com/4Uqc2kPv <http://pastebin.com/4Uqc2kPv>
Thanks once again
> On 17/06/2015, at 14:40, Filipe Pina wrote:
>
> Hi Kev
.
On Qua, Jun 17, 2015 at 2:45 , Bill Moran
wrote:
On Tue, 16 Jun 2015 13:33:12 +0001
Filipe Pina wrote:
I have these 2 tables:
CREATE TABLE "stuff" ("number" integer NOT NULL PRIMARY KEY,
"title"
varchar(40) NOT NULL);
CREATE TABLE "stuff_ext&quo
buntu
4.8.2-19ubuntu1) 4.8.2, 64-bit
Though I still get the failures on 9.4.4..
On Qua, Jun 17, 2015 at 12:52 , Kevin Grittner
wrote:
Filipe Pina wrote:
if drop the foreign key constraint on stuff_ext table there are
no failures at all…
It is my recollection that we were excluding the qu
e a problem)..
On Qua, Jun 17, 2015 at 2:45 , Bill Moran
wrote:
On Tue, 16 Jun 2015 13:33:12 +0001
Filipe Pina wrote:
I have these 2 tables:
CREATE TABLE "stuff" ("number" integer NOT NULL PRIMARY KEY,
"title"
varchar(40) NOT NULL);
CREATE TABLE "
I have these 2 tables:
CREATE TABLE "stuff" ("number" integer NOT NULL PRIMARY KEY, "title"
varchar(40) NOT NULL);
CREATE TABLE "stuff_ext" ("stuff_ptr_id" integer NOT NULL PRIMARY KEY,
"extra" integer NOT NULL);
ALTER TABLE "stuff_ext" ADD CONSTRAINT
"stuff_ext_stuff_ptr_id_5a4ee8edae53404b"
and over, the first one to reach
max_retries would activate that “global lock” making the other one wait and
then the second one would also be able to successfully commit...
> On 11/06/2015, at 20:27, Tom Lane wrote:
>
> Filipe Pina writes:
>> It will try 5 times to execute e
[ original question posted in
http://stackoverflow.com/questions/30789279/django-postgresql-retry-transaction-last-try-must-go-in
for easier read ]
I have a Django+PostgreSQL.
For data integrity pg is setup for serializable transactions, so I'm
retrying the transaction (in a generic class) as:
S(transaction.*)’)
pl = plpy.execute('INSERT INTO core_transaction VALUES(transaction2.*)')
return 1
END
$$
LANGUAGE plpythonu;
> On 02/06/2015, at 15:51, Adrian Klaver wrote:
>
> On 06/02/2015 03:10 AM, Filipe Pina wrote:
>> HI Adrian,
>>
>> I had a
gn I don't really like to have specific SQL code
> into a generic python function.
>
> I agree it is cumbersome, and I also badly miss more powerful input for
> python function (after all, plpython can already return composite types,
> which is awesome)
>
>
> Cheers,
ote:
>
> On 06/01/2015 07:42 AM, Filipe Pina wrote:
>> Thanks for the reply anyway, it's a pity though, it'd be useful..
>>
>> Another bump I've found along the pl/python road: insert ROWTYPE in table..
>> Maybe you have some hint on that? :)
>>
>&g
Thanks
On Sex, Mai 29, 2015 at 2:00 , Peter Eisentraut wrote:
On 5/18/15 10:52 AM, Filipe Pina wrote:
But one of the functions I need to create needs to accept an array
of
records.
PL/Python doesn't support that. Some more code needs to be written to
support that. You did everything correctly. I don't know of a good
workaround.
Hello,
I'm building an app in Django and I want to have some functions
directly in postgres. I'd prefer to use pl/python for the functions as
it'd look better in Django migration files (python code within python
code, instead of using PLPGSQL).
But one of the functions I need to create needs
Exactly, my point was not to repeat point 4 but the whole step.
Upon serialization failure exception it would re-read data from database,
perform the same something with data and save it. And point 2 is the part
that fails in my "restart wrapper" function in the code I posted in
stackoverflow, it
y "restart" the failed transactions...
-Original Message-
From: Bill Moran [mailto:wmo...@potentialtech.com]
Sent: 3 de abril de 2015 23:07
To: Filipe Pina
Cc: Postgresql General
Subject: Re: [GENERAL] Serializable transaction restart/re-execute
On Fri, 3 Apr 2015 15:35:14 +0100
Fil
l and insightful
and I'll definitely accept it as answer. If you have the time to elaborate
on a working example using dblink it would definitely by a nice bonus :)
Thank you once again
On Mon, Apr 6, 2015 at 3:22 PM, Kevin Grittner wrote:
> Filipe Pina wrote:
>
> > I come from a GT
h I wouldn't know where to start).
Thanks once again.
On Mon, Apr 6, 2015 at 12:42 PM, Bill Moran
wrote:
> On Mon, 6 Apr 2015 10:41:25 +0100
> Filipe Pina wrote:
>
> > Hi Bill, thanks for the quick reply.
> >
> > I had read about SAVEPOINTs but I also read I cannot
t;restart" the failed transactions...
On Fri, Apr 3, 2015 at 11:07 PM, Bill Moran
wrote:
> On Fri, 3 Apr 2015 15:35:14 +0100
> Filipe Pina wrote:
>
> > Hello,
> >
> > I come from a GTM background and once of the transactional features
> there are the ?Transact
Hello,
I come from a GTM background and once of the transactional features there are
the “Transaction Restarts”.
Transaction restart is when we have two concurrent processes reading/writing to
the same region/table of the database, the last process to commit will “see”
that the database is not
25 matches
Mail list logo
