On 5/10/07, Spiegelberg, Greg <[EMAIL PROTECTED]> wrote:
List,
Check out the value for t1_s_seq on connection #1.
1: db=# select nextval('t1_s_seq');
nextval
-
1
(1 row)
And check the value for t1_s_seq on connection #2.
2: db=# select nextval('t1_s_seq');
nextval
On 8/24/07, Kenji Morishige <[EMAIL PROTECTED]> wrote:
>
> I've got 2 identical servers configured exactly the same way, except for
> some
> minor differences for the WAL logging directories. I have both machines
> set up
> as a NFS server and client, so that the WAL archive gets written out to
>
Hello list
I have a question concerning the continuous archiving process. The manual
says:
To make use of the backup, you will need to keep around all the WAL segment
files generated during and after the file system backup. To aid you in doing
this, the pg_stop_backup function creates a *backup h
On 10/19/07, Kevin Grittner <[EMAIL PROTECTED]> wrote:
>
> >>> On Fri, Oct 19, 2007 at 1:40 AM, in message
> <[EMAIL PROTECTED]>, "Mikko
> Partio"
> <[EMAIL PROTECTED]> wrote:
> >
> > I'm trying to figure out the minimum requ
Hello list
I have a largish postgresql (8.3) instance with autovacuum turned on. I am
doing some heavy importing and I want to vacuum the relevant tables manually
since autovacuum seems to trigger the vacuum in the middle of the import
process which slows things down.
Now, the problem is that I c
On Fri, Feb 22, 2008 at 5:44 PM, Alvaro Herrera <[EMAIL PROTECTED]>
wrote:
> Mikko Partio escribió:
>
> > Now, the problem is that I cannot turn autovacuum off! I have tried to
> set
> > autovacuum = off at postgresql.conf with no avail. I have also tried to
> >
On Fri, Feb 22, 2008 at 7:01 PM, Mikko Partio <[EMAIL PROTECTED]> wrote:
>
>
> On Fri, Feb 22, 2008 at 5:44 PM, Alvaro Herrera <
> [EMAIL PROTECTED]> wrote:
>
> > Mikko Partio escribió:
> >
> > > Now, the problem is that I cannot turn autovacuum off
Hello list
an interrupted vacuum full has just caused a PG instance to restart and
recover. Background:
select version();
version
--
PostgreSQL
On Sun, Mar 30, 2008 at 12:05 AM, Tom Lane <[EMAIL PROTECTED]> wrote:
> "Mikko Partio" <[EMAIL PROTECTED]> writes:
> > 2008-03-29 22:25:15 EET [26841]: [3-1] PANIC: cannot abort transaction
> > 3778747509, it was already committed
>
> Yeah, th
On Sun, Mar 30, 2008 at 6:40 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
> It would be good to fix it I suppose, but what with VACUUM FULL being on
> the edge of deprecation anyway, it's hard to muster enthusiasm for doing
> a (probably) large additional amount of work on it, I think most
> hackers w
Hello all
my struggle with the database continues (see earlier thread titled "too many
trigger records found for relation xyz").
Today, I created yet another to table to the same database. Everything went
ok, no errors or anything, but when I checked pg_tables -view I saw two
tables with the same
On Wed, Apr 9, 2008 at 4:47 PM, Mikko Partio <[EMAIL PROTECTED]> wrote:
> Hello all
>
> my struggle with the database continues (see earlier thread titled "too
> many trigger records found for relation xyz").
>
> Today, I created yet another to table to the same
On Tue, Apr 15, 2008 at 9:36 AM, Mikko Partio <[EMAIL PROTECTED]> wrote:
>
>
> On Wed, Apr 9, 2008 at 4:47 PM, Mikko Partio <[EMAIL PROTECTED]> wrote:
>
> > Hello all
> >
> > my struggle with the database continues (see earlier thread titled "too
On Thu, Apr 17, 2008 at 1:36 PM, Pavan Deolasee <[EMAIL PROTECTED]>
wrote:
> On Thu, Apr 17, 2008 at 3:38 PM, Mikko Partio <[EMAIL PROTECTED]> wrote:
>
> >
> > 2008-04-17 13:05:30 EEST [8435]: [32-1] ERROR: could not open relation
> > 1663/16386/359232: No
On Thu, Apr 17, 2008 at 6:10 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
> "Mikko Partio" <[EMAIL PROTECTED]> writes:
> > Seems like the whole db is falling apart.
>
> I think you've got really serious filesystem-level problems. Have you
> tried running a
On Thu, Apr 17, 2008 at 6:59 PM, Mikko Partio <[EMAIL PROTECTED]> wrote:
>
>
> On Thu, Apr 17, 2008 at 6:10 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
>
> > "Mikko Partio" <[EMAIL PROTECTED]> writes:
> > > Seems like the whole db is falling apar
On Thu, Apr 17, 2008 at 7:06 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
> "Mikko Partio" <[EMAIL PROTECTED]> writes:
> > On Thu, Apr 17, 2008 at 6:10 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
> >> I think you've got really serious filesystem-level
On Thu, Apr 17, 2008 at 7:08 PM, Mikko Partio <[EMAIL PROTECTED]> wrote:
>
>
> On Thu, Apr 17, 2008 at 7:06 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
>
> > "Mikko Partio" <[EMAIL PROTECTED]> writes:
> > > On Thu, Apr 17, 2008 at 6:10 PM, Tom La
On Tue, Apr 22, 2008 at 12:02 PM, Michael Monnerie <
[EMAIL PROTECTED]> wrote:
> What I had twice (on different customers, once SCSI once SATA) is that a
> broken hard disk reports no errors, but delivers different data than
> what was written before. Very nasty, as the RAID controller doesn't see
On Mon, Jun 30, 2008 at 3:30 PM, Thomas Bräutigam <
[EMAIL PROTECTED]> wrote:
> Hello all,
>
> I have a pretty huge Postgres DB, about 1,3 to 1,5 Terra. What do you guys
> recommend on RAID Levels for this Database. Which does Postgres recommend,
> and with which do Postgres run very good or in t
Hi
I'm currently testing Pg 9.0.0 alpha 4 and the hot standby feature (with
streaming replication) is working great. I tried to take a filesystem backup
from a hot standby, but I guess that is not possible since executing "SELECT
pg_start_backup('ss')" returns an error? Or can I just tar $PGDATA a
Hi
got the following line at postgresql log:
May 16 01:17:35 xxx postgres[25550]: [1-1] LOG: could not truncate
directory "pg_subtrans": apparent wraparound
I assume this does not refer to xid wraparound? Should I be worried?
Database has only a few users and probably noone accessed it during
On Wed, May 19, 2010 at 10:01 PM, Tom Lane wrote:
> Mikko Partio writes:
> > got the following line at postgresql log:
> > May 16 01:17:35 xxx postgres[25550]: [1-1] LOG: could not truncate
> > directory "pg_subtrans": apparent wraparound
>
> What's i
On Wed, May 19, 2010 at 3:21 PM, Ray Stell wrote:
> On Wed, May 19, 2010 at 08:40:04AM +0300, Mikko Partio wrote:
> >
> > May 16 01:17:35 xxx postgres[25550]: [1-1] LOG: could not truncate
> > directory "pg_subtrans": apparent wraparound
> >
>
> http:/
On Thu, May 20, 2010 at 7:53 PM, Alvaro Herrera wrote:
> Excerpts from Mikko Partio's message of jue may 20 00:39:00 -0400 2010:
> > On Wed, May 19, 2010 at 3:21 PM, Ray Stell wrote:
>
> > > http://archives.postgresql.org/pgsql-general/2007-06/msg01050.php
> >
> > Browsing through that thread I c
On Sun, May 23, 2010 at 9:02 PM, Tom Lane wrote:
> Mikko Partio writes:
> > got the following line at postgresql log:
>
> > May 16 01:17:35 xxx postgres[25550]: [1-1] LOG: could not truncate
> > directory "pg_subtrans": apparent wraparound
>
> > Post
On Mon, May 24, 2010 at 10:55 PM, Simon Riggs wrote:
> On Mon, 2010-05-24 at 08:46 +0300, Mikko Partio wrote:
>
> > It was freshly initdb'd with beta1 binaries, the contents were loded
> > from a pg_dump file. The number of transactions is very small, we're
>
Hello list
I have two a machine cluster with PostgreSQL 9.0.4 and streaming
replication. In a normal situation I did a failover -- touched the trigger
file in standby to promote it to production mode. I have done this
previously without any complications but now the to-be-production-database
had a
>
>
> http://archives.postgresql.org/pgsql-hackers/2008-12/msg01335.php
> According to the above thread, this issue seems to exist for a few years,
> and be unsolved yet. Could you provide a self-contained test case?
I can try ...
In related to this, after the failover we got several other worry
29 matches
Mail list logo
