> Can you break out a test case from the restore script and send it to
> Alvaro and me? If it's still failing on CVS tip then there's something
> else going on here ...
Mmm, I tried and created a dump of the purchaseorder_line table only, but its
restore didn't fail in 50+ attempts ;(. Obviously
What exact commands are you using for both the backup and the restore?
- at boot time the linux box mount a smb share '/mnt/walarchive810'
- I have modified postgresql.conf parameter
archive_command='cp -i /mnt/walarchive810/%f - now I have run a script wich updates a database in the lin
Frank van Vugt <[EMAIL PROTECTED]> writes:
> Hmm, the patch mentioned for ExecMain.c won't apply to my base version, so I
> went for a fresh cvs checkout of REL8_1_STABLE instead. It took a while,
> since Slack's version of Bison is too old and I needed to get a more recent
> one.
> Anyway, the
> Hm, I'm wondering if the toast-vs-index bug could be relevant. Could
> you try 8.1 branch tip? Or at least apply this patch:
>
> http://archives.postgresql.org/pgsql-committers/2005-11/msg00439.php
Hmm, the patch mentioned for ExecMain.c won't apply to my base version, so I
went for a fresh c
Frank van Vugt <[EMAIL PROTECTED]> writes:
> FYI, it's a plain v8.1 with the given patch on autovacuum.c and an earlier
> patch from Tom for the distinct bug which only touches ExecMain.c and
> ExecUtils.c
Hm, I'm wondering if the toast-vs-index bug could be relevant. Could
you try 8.1 branch t
> > I've changed autovacuum.c per this diff, I 'hope' I misinterpreted what
> > needed to be done (see below):
>
> No, that diff is exactly what I applied. But I think you must have done
> something else wrong
That's a bit harsh ;)
> , because while I can reproduce the crash easily on
> the unp
Frank van Vugt wrote:
>
> > No. There are two StartTransactionCommand calls in autovacuum.c, and
> > what I'm suggesting is to add the ActiveSnapshot assignment after each
> > one.
>
> I've changed autovacuum.c per this diff, I 'hope' I misinterpreted what
> needed
> to be done (see below):
N
> No. There are two StartTransactionCommand calls in autovacuum.c, and
> what I'm suggesting is to add the ActiveSnapshot assignment after each
> one.
> Done.
I've changed autovacuum.c per this diff, I 'hope' I misinterpreted what needed
to be done (see below):
==
Alvaro,
> Hum, I'm unable to reproduce the problem here; could you give me the
> code for the functions in the functional indexes for tables 164956 or
> 227469? They must be non-trivial SQL functions AFAICT (I'm rather
> unable to figure out their shape based only on the backtrace.)
Obviously th
What exact commands are you using for both the backup and the restore?
On Mon, Nov 28, 2005 at 02:38:27PM +0100, [EMAIL PROTECTED] wrote:
> Is it possible to do an online backup from linux to windows ?
>
> Postgres : 8.1.0
> linux : Centos 4.2 , 32 bit
> windows : 2000 Server , 32 bit
>
> When I
Sounds like it's an issue with your PATH.
On Sat, Nov 26, 2005 at 03:07:13PM +0530, Kishore Negi wrote:
>
>
> Hi All,
>
> I have a scenario where I have to uninstall PostgreSQL 7.0 (Default
> with Suse 10.0) & need to install PostgreSQL8.0.4 on Suse10.0.
>
> Can anyone help in this ?
>
> I h
Tom Lane wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > The attached patch should correct the problem, but I'd like to make sure
> > it does ...
>
> Rather than that, I'd suggest just setting ActiveSnapshot
> unconditionally after each of the StartTransactionCommand calls in
> autovacuum.
Stefano Reksten <[EMAIL PROTECTED]> writes:
> SELECT length(name), name from test;
> length |name
> +
>4 | test
> Should not a char(10) insert 6 padding spaces?
It does, as you can see in the above output; but the padding spaces are
considered semantically insign
On Mon, Nov 28, 2005 at 05:49:02PM +0100, Stefano Reksten wrote:
> Should not a char(10) insert 6 padding spaces? Or am I missing something
> like an update in the SQL standard?
char_length()
regards
--
Paweł Bernat; uselessness' lover;
select''as email;
Slowly and surely the unix crept up on th
Hello list,
maybe I am missing something. Look at this:
CREATE TABLE test (name character(10));
INSERT INTO test VALUES ('test');
SELECT '<' || name || '>' FROM test;
?column?
--
SELECT length(name), name from test;
length |name
+
4 | test
Should no
Frank van Vugt <[EMAIL PROTECTED]> writes:
> Tom, is your patch meant for the exact same location?
No. There are two StartTransactionCommand calls in autovacuum.c, and
what I'm suggesting is to add the ActiveSnapshot assignment after each
one.
regards, tom lane
-
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > The attached patch should correct the problem, but I'd like to make sure
> > it does ...
> Rather than that, I'd suggest just setting ActiveSnapshot
> unconditionally after each of the StartTransactionCommand calls in
> autovacuum.c, ie make the cod
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> The attached patch should correct the problem, but I'd like to make sure
> it does ...
Rather than that, I'd suggest just setting ActiveSnapshot
unconditionally after each of the StartTransactionCommand calls in
autovacuum.c, ie make the code look just
Is it possible to do an online backup from linux to windows ?
Postgres : 8.1.0
linux : Centos 4.2 , 32 bit
windows : 2000 Server , 32 bit
When I try to start recovery process on windows I'm getting the following error:
FATAL: incorrect checksum in control file
thank you
-
Alvaro Herrera wrote:
> Frank van Vugt wrote:
>
> > Since I started to use v8.1 I've been seeing incidental segfaults of the
> > autovacuum process, probably when it is kicking in at some particular point
> > during the pg_restore of a database:
[...]
> The attached patch should correct the pr
Frank van Vugt wrote:
> Since I started to use v8.1 I've been seeing incidental segfaults of the
> autovacuum process, probably when it is kicking in at some particular point
> during the pg_restore of a database:
Hum, I'm unable to reproduce the problem here; could you give me the
code for the
Frank van Vugt wrote:
> L.S.
>
> Since I started to use v8.1 I've been seeing incidental segfaults of the
> autovacuum process, probably when it is kicking in at some particular point
> during the pg_restore of a database:
The problem appears to be that autovacuum is forgetting to set a
snapsho
L.S.
Since I started to use v8.1 I've been seeing incidental segfaults of the
autovacuum process, probably when it is kicking in at some particular point
during the pg_restore of a database:
<-2005-11-28 09:39:12 CET>LOG: autovacuum process (PID 5075) was terminated
by signal 11
<-2005-11-28
23 matches
Mail list logo
