There are some silly bugs in the script:
- forgot to export PGDATA and PATH after changing them
- forgot to mention the need to edit test.sql (COPY line needs path to
dump file)
Apologies - I will submit a fixed version a little later
regards
Mark
Mark Kirkwood wrote:
A script to run the whole bu
Hi everyone,
I've decided to attempt to nail all known bugs in pg_dump for 7.5 :)
So, please send me ALL your known bugs/issues with pg_dump, pg_dumpall
and pg_restore. Note that I am NOT interested in feature requests, ONLY
bugs.
A bug is considered to be an issue in pg_dump that means that wh
"Matthew T. O'Connor" <[EMAIL PROTECTED]> writes:
> 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?
You are not missing anything. I already nagged Jan about
Mark Kirkwood <[EMAIL PROTECTED]> writes:
> - anything >=128393 rows in test0.dat results in 2 or more archived
> logs, and recovery fails on the second log (and gives the zero length
> redo at 0/1E0 message).
Zero length record is not an error, it's the normal way of detecting
end-of-log.
On Sun, Jul 18, 2004 at 01:38:57AM -0400, Tom Lane wrote:
> 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.
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' US
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 immedi
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.
>
>
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 --- deadloc
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
> transacti
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 tr
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 = 5
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 ps
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 selec
-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 Gn
-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 bloc
-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;
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;
>
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 fil
-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(
-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
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. Ple
-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 nes
23 matches
Mail list logo
