Hi
2015-02-19 21:42 GMT+01:00 Juan Pablo L. jpablolorenze...@hotmail.com:
Hello, i have created a function (in C) that receives an array that
contains tuples of ID's and values.
The function is to execute updates on each ID assigning the value, but if
one of these operation fails (does not
Hello, i have created a function (in C) that receives an array that contains
tuples of ID's and values.
The function is to execute updates on each ID assigning the value, but if one
of these operation fails (does not meet certain criteria)
inside the function i would like to rollback and
Just an update, it was making a mistake, the execution of PQexecute, to
execute the query, was wrapped in a function called PGresult
*db_execute() that was returning the PGresult as NULL, i completely
forgot this, inside that function the exception was being caught and
discarded so by the time
Hello, i have created a function (in C) that receives an array that
contains tuples of ID's and values.
The function is to execute updates on each ID assigning the value, but if
one of these operation fails (does not meet certain criteria)
inside the function i would like to rollback and leave
The function is to execute updates on each ID assigning the value, but if
one of these operation fails (does not meet certain criteria)
inside the function i would like to rollback and leave everything
untouched, in case other ID;s were already updated previously,
and come back to the caller
Hi Thanks Chris, yes i have already tested ereport and even made up my own
sql state to report and error but from the application i can not access
this error code directly (through the PQexec,PQresultErrorField,etc
functions because the PGresult returns NULL) but i have to register a
callback
Juan Pablo L wrote:
Hello, i have created a function (in C) that receives an array that
contains tuples of ID's and values.
Why are you writing a C function? Sounds like you could accomplish the
same with a plpgsql function, with much less effort.
The function is to execute updates on each
Thank you Alvaro, i m afraid ereport seems to be the way, that it is
complicated to catch this error code in the code of the caller. cause you
have to use a callback etc etc
On 19 February 2015 at 15:57, Alvaro Herrera alvhe...@2ndquadrant.com
wrote:
Juan Pablo L wrote:
Hi, i want previous
Hi, i want previous updates to rollback ... like nothing happened (a normal
begin/rollback behaviour)
On 19 February 2015 at 15:34, Alvaro Herrera alvhe...@2ndquadrant.com
wrote:
Juan Pablo L wrote:
Hello, i have created a function (in C) that receives an array that
contains tuples of ID's
Juan Pablo L wrote:
Hi, i want previous updates to rollback ... like nothing happened (a normal
begin/rollback behaviour)
Ah, so ereport() is exactly what you want, like Chris Mair said.
Assuming you wrote it correctly, you should see the ERROR line in the
server logs (set
On 2/19/2015 1:41 PM, Juan Pablo L wrote:
Hi, i want previous updates to rollback ... like nothing happened (a
normal begin/rollback behaviour)
so thrown an exception. The actual rollback has to be invoked by the
client application program, which should catch the error thrown by the
query
On 2/19/2015 2:02 PM, Juan Pablo L wrote:
Thank you Alvaro, i m afraid ereport seems to be the way, that it is
complicated to catch this error code in the code of the caller. cause
you have to use a callback etc etc
a query that triggers ereport(ERROR,) should return a PGresult* that
you
Thank you, i will try this, honestly i was checking if PGResult is NULL,
when i trigger the exception i always get NULL so i did not any further but
i will try this .
On 19 February 2015 at 16:22, John R Pierce pie...@hogranch.com wrote:
On 2/19/2015 2:02 PM, Juan Pablo L wrote:
Thank you
i tried this but the call to PQresultErrorField(PGresult, PG_DIAG_SQLSTATE)
is returning NULL, this is what trigger the exception in the function code:
ereport(ERROR,(errcode(ERRCODE_SQL_ROUTINE_EXCEPTION),errmsg(Plan with id
%s does not allow balance with id %s,plan_id,in_balanceid)));
and this
On 12/28/2014 05:04 PM, David G Johnston wrote:
Adrian Klaver-4 wrote
On 12/28/2014 10:06 AM, Viktor Shitkovskiy wrote:
I include my own scripts. Each of them creates some table or makes some
changes to existing tables.
It is hard to say where to go from here without more information.
On Mon, Dec 29, 2014 at 8:49 AM, Adrian Klaver adrian.kla...@aklaver.com
wrote:
On 12/28/2014 05:04 PM, David G Johnston wrote:
Adrian Klaver-4 wrote
On 12/28/2014 10:06 AM, Viktor Shitkovskiy wrote:
I include my own scripts. Each of them creates some table or makes some
changes to
On 12/29/2014 07:59 AM, David Johnston wrote:
On Mon, Dec 29, 2014 at 8:49 AM, Adrian Klaver
adrian.kla...@aklaver.com mailto:adrian.kla...@aklaver.comwrote:
On 12/28/2014 05:04 PM, David G Johnston wrote:
Adrian Klaver-4 wrote
On 12/28/2014 10:06 AM, Viktor Shitkovskiy wrote:
On Mon, Dec 29, 2014 at 9:39 AM, Adrian Klaver adrian.kla...@aklaver.com
wrote:
On 12/29/2014 07:59 AM, David Johnston wrote:
Anyway, the third undocumented bug is that --single-transactions gets to
send its COMMIT even if ON_ERROR_STOP
takes hold before the end of the script. I imagined
On Mon, Dec 29, 2014 at 9:49 AM, David Johnston david.g.johns...@gmail.com
wrote:
On Mon, Dec 29, 2014 at 9:39 AM, Adrian Klaver adrian.kla...@aklaver.com
wrote:
On 12/29/2014 07:59 AM, David Johnston wrote:
Anyway, the third undocumented bug is that --single-transactions gets to
send its
On 12/29/2014 08:49 AM, David Johnston wrote:
On Mon, Dec 29, 2014 at 9:39 AM, Adrian Klaver
adrian.kla...@aklaver.com mailto:adrian.kla...@aklaver.comwrote:
On 12/29/2014 07:59 AM, David Johnston wrote:
Anyway, the third undocumented bug is that --single-transactions
gets
Copying -bugs to gain broader attention and opinions.
On Mon, Dec 29, 2014 at 10:06 AM, Adrian Klaver adrian.kla...@aklaver.com
wrote:
On 12/29/2014 08:49 AM, David Johnston wrote:
On Mon, Dec 29, 2014 at 9:39 AM, Adrian Klaver
adrian.kla...@aklaver.com mailto:adrian.kla...@aklaver.comwrote:
On 12/29/2014 09:38 AM, David Johnston wrote:
Copying -bugs to gain broader attention and opinions.
On Mon, Dec 29, 2014 at 10:06 AM, Adrian Klaver
adrian.kla...@aklaver.com mailto:adrian.kla...@aklaver.comwrote:
On 12/29/2014 08:49 AM, David Johnston wrote:
On Mon, Dec 29, 2014
On Mon, Dec 29, 2014 at 3:07 PM, Adrian Klaver adrian.kla...@aklaver.com
wrote:
On 12/29/2014 09:38 AM, David Johnston wrote:
This is one of those glass half full/empty situations, where it is
down to the eye of the beholder. I would also say this a perfect
example of why tests
On 12/29/2014 02:28 PM, David Johnston wrote:
On Mon, Dec 29, 2014 at 3:07 PM, Adrian Klaver
adrian.kla...@aklaver.com mailto:adrian.kla...@aklaver.comwrote:
On 12/29/2014 09:38 AM, David Johnston wrote:
This is one of those glass half full/empty situations,
where it
On Mon, Dec 29, 2014 at 3:37 PM, Adrian Klaver adrian.kla...@aklaver.com
wrote:
On 12/29/2014 02:28 PM, David Johnston wrote:
On Mon, Dec 29, 2014 at 3:07 PM, Adrian Klaver
adrian.kla...@aklaver.com mailto:adrian.kla...@aklaver.comwrote:
On 12/29/2014 09:38 AM, David Johnston wrote:
On 12/29/2014 02:55 PM, David Johnston wrote:
On Mon, Dec 29, 2014 at 3:37 PM, Adrian Klaver
adrian.kla...@aklaver.com mailto:adrian.kla...@aklaver.comwrote:
On 12/29/2014 02:28 PM, David Johnston wrote:
On Mon, Dec 29, 2014 at 3:07 PM, Adrian Klaver
On Mon, Dec 29, 2014 at 4:38 PM, Adrian Klaver adrian.kla...@aklaver.com
wrote:
On 12/29/2014 02:55 PM, David Johnston wrote:
On Mon, Dec 29, 2014 at 3:37 PM, Adrian Klaver
adrian.kla...@aklaver.com mailto:adrian.kla...@aklaver.comwrote:
On 12/29/2014 02:28 PM, David Johnston wrote:
On 12/29/2014 03:56 PM, David Johnston wrote:
So you think psql should issue COMMIT; even if it is exiting due to
ON_ERROR_STOP?
I say yes, if it is a non-SQL error. As Viktor stated, SQL errors abort
the transaction.
Whether you do or don't can you show me where in the
On Mon, Dec 29, 2014 at 5:09 PM, Adrian Klaver adrian.kla...@aklaver.com
wrote:
On 12/29/2014 03:56 PM, David Johnston wrote:
So you think psql should issue COMMIT; even if it is exiting due to
ON_ERROR_STOP?
I say yes, if it is a non-SQL error. As Viktor stated, SQL errors abort
the
On 12/29/2014 04:26 PM, David Johnston wrote:
On Mon, Dec 29, 2014 at 5:09 PM, Adrian Klaver
adrian.kla...@aklaver.com mailto:adrian.kla...@aklaver.comwrote:
On 12/29/2014 03:56 PM, David Johnston wrote:
So you think psql should issue COMMIT; even if it is exiting
due to
Hello.
I'm trying to execute an sql script file in a single transation. The file
contains includes for some other scripts which in my example create some
tables. It looks like this:
\include ../tables/table1.cre
\include ../tables/table2.cre
...
\include ../tables/table10.cre
I'm
You did not show the complete script.
Did you remember to start the transaction with BEGIN; and end with
COMMIT;?
eg:
BEGIN;
\include ../tables/table1.cre
\include ../tables/table2.cre
...
\include ../tables/table10.cre
COMMIT;
On Sun, Dec 28, 2014 at 3:02 AM, Viktor Shitkovskiy
On 12/28/2014 12:02 AM, Viktor Shitkovskiy wrote:
Hello.
I'm trying to execute an sql script file in a single transation. The
file contains includes for some other scripts which in my example create
some tables. It looks like this:
\include ../tables/table1.cre
\include
I use --single-transaction flag. But anyway, adding BEGIN and COMMIT
doesn't change anything. I stil get that problem.
On Sun, Dec 28, 2014 at 5:43 PM, Melvin Davidson melvin6...@gmail.com
wrote:
You did not show the complete script.
Did you remember to start the transaction with BEGIN; and
I include my own scripts. Each of them creates some table or makes some
changes to existing tables.
Yes, I want a complete rollback.
Where is the \include coming from?
What is in the tableX.cre files?
So if I am following you want a complete rollback on non-SQL or SQL
errors, correct?
On 12/28/2014 10:06 AM, Viktor Shitkovskiy wrote:
I include my own scripts. Each of them creates some table or makes some
changes to existing tables.
It is hard to say where to go from here without more information. The
options you are passing to psql all have caveats:
AUTOCOMMIT
When
Adrian Klaver-4 wrote
On 12/28/2014 10:06 AM, Viktor Shitkovskiy wrote:
I include my own scripts. Each of them creates some table or makes some
changes to existing tables.
It is hard to say where to go from here without more information.
really?
This seems like a documentation bug (or, at
So should I report a bug somewhere?
As a workaround I'm currently using a wrapper bash script that parses the
source psql script and checks if the 'include' and 'copy-from' files do
really exist.
On Mon, Dec 29, 2014 at 4:04 AM, David G Johnston
david.g.johns...@gmail.com wrote:
I would
hi, some days ago I have a problem I want to solve.
The situation is the following:
I have a connection to a remote DB (with it's different from mine, of
course).
The querys I do are between sql-transactions
1 - Whate happens If during executing a query my pc loose the network
connection? what
On Thu, Aug 25, 2011 at 9:35 AM, uanacho uana...@gmail.com wrote:
hi, some days ago I have a problem I want to solve.
The situation is the following:
I have a connection to a remote DB (with it's different from mine, of
course).
The querys I do are between sql-transactions
Wait, are you
-
From: pgsql-general-ow...@postgresql.org [mailto:pgsql-general-
ow...@postgresql.org] On Behalf Of Craig Ringer
Sent: Sunday, May 23, 2010 8:48 PM
To: Ken Winter
Cc: PostgreSQL pg-general List
Subject: Re: [GENERAL] ROLLBACK in a function
On 24/05/10 02:51, Ken Winter wrote:
How can I write
How can I write a PL/PgSQL function that rolls back every database change it
has done?
I'm about to write a set of database test functions. Each function needs to
do some INSERT, UPDATE, or DELETE actions, test whether they had their
intended effect, and then roll back the test changes to
On 24/05/10 02:51, Ken Winter wrote:
How can I write a PL/PgSQL function that rolls back every database
change it has done?
Have it raise an exception, causing the surrounding transaction to
terminate with an error.
Another function calling yours can still catch the exception and handle
Hi all,
I have a transaction where I get a rollback failure if a sql error is
returned. I dont know why the rollback fails!!
Does anyone have any suggestions or information about this case?
Thanks B.R,
Mai Fawzy
On Tue, Apr 20, 2010 at 2:54 PM, mai fawzy maifawzy.emai...@gmail.com wrote:
Hi all,
I have a transaction where I get a rollback failure if a sql error is
returned. I dont know why the rollback fails!!
Does anyone have any suggestions or information about this case?
Got a simple test case
On 2009-01-28, Abdul Rahman abr_...@yahoo.com wrote:
--0-2110834523-1233119974=:72728
Content-Type: text/plain; charset=us-ascii
Dear All,
Yesterday I canceled a running query because it was taking long time
(more than 12 minutes) to delete lots of records. Today when I
executed the same
Well Jaime,
I executed all the delete queries one by one. Now I am unable to understand
that why it took sufficient time to run the last query before cancellation.
i.e. delete from ci_cif_v where req_id='0824100207';
This morning it performed the delete operation and deleted certain number
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Abdul Rahman wrote:
Very nice!
Most probably it was waiting for something else. This is the reason the
query executed today and clearly showed certain number of rows deleted.
But what ELSE?
It could be a ton of things, but as an example, if you
Dear All,
Yesterday I canceled a running query because it was taking long time (more than
12 minutes) to delete lots of records. Today when I executed the same query it
hardly took few seconds to finish. It clearly explores that PostgreSQL does not
perform rollback action. Is it true?
Abdul Rahman wrote:
Dear All,
Yesterday I canceled a running query because it was taking long time
(more than 12 minutes) to delete lots of records. Today when I
executed the same query it hardly took few seconds to finish. It
clearly explores that PostgreSQL does not perform rollback
Thanks Justin,
Answers of your technical
questions are as under:
What does the sql statement look like?
delete from ci_cif_v where
req_id='0824100207';
Where was the statement run?
On SQL pan of pgAdmin-III
How was the statement killed?
By
clicking the Cancel Query button -
What do the logs show?
On Wed, Jan 28, 2009 at 12:19 AM, Abdul Rahman abr_...@yahoo.com wrote:
Dear All,
PostgreSQL does not perform rollback action. Is it true?
no. postgresql executes all statements that are outside an explicit
transaction in its own implicit one [1] executing commit at the end,
if you cancelled
On Wed, Jan 28, 2009 at 12:56 AM, Abdul Rahman abr_...@yahoo.com wrote:
What do the logs show?
Message just showed the time it took to delete certain number of records.
can you show that message? copy 'n pasted from logs!!
--
Atentamente,
Jaime Casanova
Soporte y capacitación de PostgreSQL
Welcome Jcasanov,
Here is the output of the log files:
2009-01-27 09:24:18 FATAL: the database system is starting up
2009-01-27 09:24:19 LOG: database system was shut down at 2009-01-26 18:34:53
2009-01-27 09:24:19 LOG: checkpoint record is at 0/1B9F92C8
2009-01-27 09:24:19 LOG: redo record
On Wed, Jan 28, 2009 at 1:29 AM, Abdul Rahman abr_...@yahoo.com wrote:
Welcome Jcasanov,
Here is the output of the log files:
2009-01-27 09:24:18 FATAL: the database system is starting up
2009-01-27 09:24:19 LOG: database system was shut down at 2009-01-26
18:34:53
2009-01-27 09:24:19
Thanks Jaime,
Plz consider the actual log files to explore the issue in detail. Because I
have pasted the log files of client machine, I am using (sorry).
2009-01-27 18:29:25 STATEMENT: delete from ci_cin_type_v where
req_id='0824100207'
delete from ci_cust_type_v where
, January 28, 2009 12:08:28 PM
Subject: Re: [GENERAL] Rollback of Query Cancellation
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Its very possible that the reason that the query was because there was a
lock on the table. If you run select * from pg_stat_activity while the
query is running
On Wed, Jan 28, 2009 at 2:10 AM, Abdul Rahman abr_...@yahoo.com wrote:
Thanks Jaime,
Plz consider the actual log files to explore the issue in detail. Because I
have pasted the log files of client machine, I am using (sorry).
2009-01-27 18:29:25 STATEMENT: delete from ci_cin_type_v where
Hi
I would like to be able to mark a point in my postgres database.
After that I want to change a few things and rollback to that point.
Does postgres support such a thing? Is it possible for me to do this?
--
Adrian Moisey
Systems Administrator | CareerJunction | Your Future Starts Here.
am Wed, dem 09.07.2008, um 15:38:52 +0200 mailte Adrian Moisey folgendes:
Hi
I would like to be able to mark a point in my postgres database.
After that I want to change a few things and rollback to that point.
Does postgres support such a thing? Is it possible for me to do this?
Is
On Wed, Jul 9, 2008 at 6:38 AM, Adrian Moisey
[EMAIL PROTECTED] wrote:
I would like to be able to mark a point in my postgres database. After
that I want to change a few things and rollback to that point. Does
postgres support such a thing? Is it possible for me to do this?
Sure. Check out
On Wed, Jul 09, 2008 at 03:38:52PM +0200, Adrian Moisey wrote:
Hi
I would like to be able to mark a point in my postgres database.
After that I want to change a few things and rollback to that point.
Does postgres support such a thing? Is it possible for me to do this?
Well, transactions
Hi
I would like to be able to mark a point in my postgres database.
After that I want to change a few things and rollback to that point.
Does postgres support such a thing? Is it possible for me to do this?
Well, transactions do that. If you want to do this inside a
transaction, the term
am Wed, dem 09.07.2008, um 15:59:00 +0200 mailte Adrian Moisey folgendes:
Hi
I would like to be able to mark a point in my postgres database.
After that I want to change a few things and rollback to that point.
Does postgres support such a thing? Is it possible for me to do this?
Hi
I would like to be able to mark a point in my postgres database.
After that I want to change a few things and rollback to that point.
Does postgres support such a thing? Is it possible for me to do this?
Well, transactions do that. If you want to do this inside a
transaction, the term
On Wed, Jul 9, 2008 at 10:32 AM, Adrian Moisey
[EMAIL PROTECTED] wrote:
Hi
I would like to be able to mark a point in my postgres database.
After that I want to change a few things and rollback to that point.
Does
postgres support such a thing? Is it possible for me to do this?
Well,
Adrian Moisey wrote:
Hi
I would like to be able to mark a point in my postgres database. After
that I want to change a few things and rollback to that point. Does
postgres support such a thing? Is it possible for me to do this?
A crude way of doing it, which I've done in the past on test
On Jul 9, 2008, at 6:38 AM, Adrian Moisey wrote:
I would like to be able to mark a point in my postgres database.
After that I want to change a few things and rollback to that
point. Does postgres support such a thing? Is it possible for me
to do this?
This seems to be exactly what
On Wed, 2008-07-09 at 15:38 +0200, Adrian Moisey wrote:
I would like to be able to mark a point in my postgres database.
After that I want to change a few things and rollback to that
point.
Does postgres support such a thing? Is it possible for me to do this?
* Transactions ;-)
* PITR
Adrian Moisey wrote:
Hi
I would like to be able to mark a point in my postgres database.
After that I want to change a few things and rollback to that point.
Does postgres support such a thing? Is it possible for me to do this?
Well, transactions do that. If you want to do this inside a
Once again, I'm trying to translate my knowledge of Informix to
PostgreSQL. I tried the manual and Google, but could not find anything
relevant.
Informix keeps transaction logs in a dedicated, pre-allocated disk
area that, until very recent versions, could not grow dynamically. It
is the DBA's
Jeff Larsen [EMAIL PROTECTED] writes:
Informix keeps transaction logs in a dedicated, pre-allocated disk
area that, until very recent versions, could not grow dynamically. It
is the DBA's responsibility to continually backup these transaction
logs so the space may be recycled. As such,
Hi all!
First of all I'm new to this list, please be gentle :-) Next I'd like to
mention that I've already searched the documentation and the archives,
but couldn't find the answer to my question.
I'm running a production/development database using PostgreSQL 8.1 on a
Debian server. Due to some
On 1/26/07, M.A. Oude Kotte [EMAIL PROTECTED] wrote:
Now I've found the WAL files in the pg_xlog directory, and started
browsing around for documentation on what I can do with those. But all I
can find is that you can use them to restore your database after a crash
or a custom backup. But I
* M. A. Oude Kotte:
I'm running a production/development database using PostgreSQL 8.1 on a
Debian server. Due to some bad code in one of our applications who use
this database, some of the data was modified incorrectly the last few
days. The idea is that I would like to restore the entire
Florian Weimer [EMAIL PROTECTED] writes:
In theory, this should be possible (especially if you haven't switched
off full page writes).
Not really --- the WAL records are not designed to carry full
information about the preceding state of the page, so you can't use them
to undo. (Example: a
On Jan 26, 9:45 am, [EMAIL PROTECTED] (Tom Lane) wrote:
Florian Weimer [EMAIL PROTECTED] writes:
In theory, this should be possible (especially if you haven't switched
off full page writes).Not really --- the WAL records are not designed to
carry full
information about the preceding
Hi,
First, apologies if my question is a bit off-course. Please feel free to
direct me to a different mailing list if not appropriate.
I'm currently trying to embed Senna full text search engine
(http://qwik.jp/senna/) into postgres. I'm trying to achieve this by
using triggers (implemented in
hi all,may be i asked too many questions,Let me rephrase this,What do u think are the best strategies for rolling back to previous schema version.What i think is, (a) having a table which will log version updates.
(b) having stored procedures Rollback_from_1.0.0.3_to_1.0.0.2()
hi all,I am sure this problem has been thought of before but I haven't found any good solution to this yet.
Problem: We release schema with versions 1.0.0.1, 1.0.0.2, 1.0.0.3 for example. Now client installs version
1.0.0.1 in year the 2001 and then upgrades to version 1.0.0.2 in year the 2004
This has already been implemented in CVS as a psql \set variable:
ON_ERROR_ROLLBACK = 'interactive'
and will appear in 8.1.
---
Michael Paesold wrote:
Tom Lane wrote:
Michael Paesold [EMAIL PROTECTED] writes:
For portability's sake commit successful transactions and rollback those
that fail.
Rick
[EMAIL PROTECTED] wrote on 04/25/2005 05:53:11 PM:
Dann Corbit [EMAIL PROTECTED] writes:
Probably, turning fsync off would be helpful, since you know it is
read-only.
Wouldn't make any difference: a
If an
applicationtransaction is known to be read-only, is there any reason to
prefer COMMIT or ROLLBACK for closing that transaction? Would there be any
performance difference between the two commands?
-
David Parker wrote:
If an application transaction is known to be read-only, is there any
reason to prefer COMMIT or ROLLBACK for closing that transaction? Would
there be any performance difference between the two commands?
Doesn't matter.
--
Bruce Momjian|
: [GENERAL] rollback vs. commit for closing read-only
transaction
David Parker wrote:
If an application transaction is known to be read-only, is there any
reason to prefer COMMIT or ROLLBACK for closing that transaction?
Would
there be any performance difference between the two commands
Dann Corbit [EMAIL PROTECTED] writes:
Probably, turning fsync off would be helpful, since you know it is
read-only.
Wouldn't make any difference: a transaction that hasn't modified the
database doesn't bother to write any commit/abort WAL record at all.
regards, tom
I assume this is to be saved for 8.1.
This has been saved for the 8.1 release:
http:/momjian.postgresql.org/cgi-bin/pgpatches2
---
Michael Paesold wrote:
Tom Lane wrote:
Michael Paesold [EMAIL PROTECTED]
Bruce Momjian [EMAIL PROTECTED] writes:
I assume this is to be saved for 8.1.
This has been saved for the 8.1 release:
http:/momjian.postgresql.org/cgi-bin/pgpatches2
It is not remotely ready to apply yet, so please do not put it in the
queue.
regards, tom lane
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
I assume this is to be saved for 8.1.
This has been saved for the 8.1 release:
http:/momjian.postgresql.org/cgi-bin/pgpatches2
It is not remotely ready to apply yet, so please do not put it in the
queue.
That queue isn't for
Bruce Momjian [EMAIL PROTECTED] wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
I assume this is to be saved for 8.1.
I assumed that to, so I did not want to disturb any more now.
This has been saved for the 8.1 release:
http:/momjian.postgresql.org/cgi-bin/pgpatches2
Tom Lane wrote:
It is not
On Fri, Oct 08, 2004 at 08:40:56PM +0200, Michael Paesold wrote:
I hope you will be willing to comment on the issues when times come. I am
not really satisfied myself, but without further discussion I did not want
to continue to work on it. Anyway, I understand this is not the right time
Michael Paesold [EMAIL PROTECTED] writes:
I though the postgres behaviour of rolling back the whole transaction was
standard?
Not really.
If that is not the case, I don't understand why core seems to be
against a mode (GUC), where an implicit savepoint is generated before each
statement so
If a function generates an exception, do I need to rollback manually?
--
Rory Campbell-Lange
[EMAIL PROTECTED]
www.campbell-lange.net
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
Chris Bitmead writes:
Is this behaviour some kind of standard? Can it be changed?
In the past the answer to the question "Does a statement-level error
warrant a transaction abort?" has usually hinged on the interpretation of
the following clauses of the SQL92 standard.
3.3.4.1 Exceptions
hello all,
I would like to mention something in this regard.
I have executed all the commands given here in the same order, but what
the
auther is saying that after insert fails whatever u have inserted rolls
back,
this is not the case .
as all of us knows Postgre works in autocommit mode,
Kshipra wrote:
hello all,
I would like to mention something in this regard.
I have executed all the commands given here in the same order, but what the
auther is saying that after insert fails whatever u have inserted rolls back,
this is not the case .
as all of us knows Postgre works in
Hello,
We are in the process of evaluating PostgreSQL ,
we could not perform ROLLBACK function in pgsql .
It got aborted .
Tell us how ROLLBACK is to be executed.
thanks
Kshipra
97 matches
Mail list logo
