-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I know it's very early, but I think this is going to be important if you
want people (like me) who want to help test.
First off, the only reference to nested transaction I could find in the
documentation is a note that PostgreSQL does not have
Jonathan M. Gardner wrote:
Should I submit documentation changes to the sgml files for nested
transcations? It will most likely be wrong, but maybe enough will be
right that those who know better won't have to spend much time.
It would certainly be appreciated if you could work on this.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Saturday 17 July 2004 9:55 am, Peter Eisentraut wrote:
Jonathan M. Gardner wrote:
Should I submit documentation changes to the sgml files for nested
transcations? It will most likely be wrong, but maybe enough will be
right that those who
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Check out this gem.
= CREATE TABLE t (i int);
= CREATE OR REPLACE FUNCTION test() RETURNS VOID
LANGUAGE 'plpgsql' AS '
BEGIN
INSERT INTO t VALUES (1);
EXECUTE ''BEGIN'';
DELETE FROM t;
EXECUTE ''ROLLBACK'';
RETURN;
END
';
= SELECT test();
If we do not add timeline numbers to WAL file names, we will be forced
to destroy information during recovery. Consider the following
scenario:
1. You have a WAL directory containing, say, WAL segments 0010 to 0020
(for the purposes of this example I won't bother typing out realistic
16-digit
On Sat, Jul 17, 2004 at 12:20:27PM -0700, Jonathan M. Gardner wrote:
= CREATE TABLE t (i int);
= CREATE OR REPLACE FUNCTION test() RETURNS VOID
LANGUAGE 'plpgsql' AS '
BEGIN
INSERT INTO t VALUES (1);
EXECUTE ''BEGIN'';
DELETE FROM t;
EXECUTE ''ROLLBACK'';
RETURN;
END
';
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi all,
I'm doing some experiments with NT, I din't expect this behaviuor:
create table test ( a integer );
insert into test values (3);
insert into test values (4);
insert into test values (5);
insert into test values (6);
SESSION 1;
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi all,
still experimenting NT:
kalman=# begin;
BEGIN
kalman=# select * from a;
ERROR: relation a does not exist
kalman=# begin;
BEGIN
kalman=# select * from test;
ERROR: current transaction is aborted, commands ignored until end of transaction block
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi all,
I'm compiling the last postgres CVS version and I get:
vacuum.c: In function `repair_frag':
vacuum.c:1528: warning: unused variable `myXID'
Regards
Gaetano Mendola
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.4 (MingW32)
Comment: Using
elein wrote:
The new plperl returns sets by having
the function return an array.
This requires that the entire array be
built before anything is returned.
It seems to me that that does not scale
very well. The technique of RETURN NEXT;
scales much better.
Indeed.
For example, you maybe
Related to autovacuum work, I was looking into the new vacuum delay
functionality. I might be missing something, but I can't find anything
on it in the developer docs. Is that right?
Also, in the default postgresql.conf there is:
#vacuum_cost_naptime = 50 # 0-1000 milliseconds
however
Matthew T. O'Connor wrote:
Related to autovacuum work, I was looking into the new vacuum delay
functionality. I might be missing something, but I can't find anything
on it in the developer docs. Is that right?
Also, in the default postgresql.conf there is:
#vacuum_cost_naptime = 50
On Sun, Jul 18, 2004 at 01:06:39AM +0200, Gaetano Mendola wrote:
I'm doing some experiments with NT, I din't expect this behaviuor:
First of all, let me point that the behavior on deadlock has been agreed
to change. Instead of only aborting the innermost transaction, it will
abort the whole
On Sun, Jul 18, 2004 at 01:07:32AM +0200, Gaetano Mendola wrote:
kalman=# begin;
BEGIN
kalman=# select * from a;
ERROR: relation a does not exist
kalman=# begin;
BEGIN
kalman=# select * from test;
ERROR: current transaction is aborted, commands ignored until end of
transaction block
Alvaro Herrera [EMAIL PROTECTED] writes:
First of all, let me point that the behavior on deadlock has been agreed
to change. Instead of only aborting the innermost transaction, it will
abort the whole transaction tree.
Who agreed to that? Your example is entirely unconvincing --- deadlock
is
On Sun, Jul 18, 2004 at 01:16:17AM -0400, Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
First of all, let me point that the behavior on deadlock has been agreed
to change. Instead of only aborting the innermost transaction, it will
abort the whole transaction tree.
Who agreed
Gaetano Mendola [EMAIL PROTECTED] writes:
why SESSION 1 was unblocked ?
...
Why that commit unblock the SESSION 1?
IMHO session 1 should have been unblocked in both cases as soon as
session 2's subtransaction failed. We have always made a practice
of releasing a transaction's locks
I decided to produce a nice simple example, so that anyone could
hopefully replicate what I am seeing.
The scenario is the same as before (the 11 steps), but the CREATE TABLE
and COPY step has been reduced to:
CREATE TABLE test0 (filler VARCHAR(120));
COPY test0 FROM '/data0/dump/test0.dat'
18 matches
Mail list logo
