headers
Tom Lane | 1 Aug 2009 01:18
Picon

Re: Fix corrupt pg_toast table?

Michael Clark <codingninja <at> gmail.com> writes:
> On Fri, Jul 31, 2009 at 5:24 PM, Greg Stark <gsstark <at> mit.edu> wrote:
>>> Now I am getting:
>>> ERROR: could not access status of transaction 3839923882

>> How long has this database been in use? That's a very high transaction
>> number that would only be reached on a heavily used database after a
>> reasonably long period of use. If that's not likely than a likely
>> possibility is that your table has been overwritten with garbage.
>> Possibly by a filesystem bug or hardware failure.

> Not really that long.  The database was created in early June, and if that
> is supposed to be a transaction count (3839923882), then yeah that seems way
> out there.

It seems certain that you're looking at corrupt data.  Trashed data
frequently manifests this way, because the transaction ID is the first
field of tuple headers that the database can cross-check with any
amount of rigor.

At this point we know that at least two unrelated disk blocks have been
clobbered by something (first that index page, and now this).  There's
no very good reason to think there are only two :-(.  I'd bet at least
a cheese sandwich on hardware problems.  Test and fix/replace your
hardware, then go back to your last backup (I hope you've got one).

			regards, tom lane

--

-- 
Sent via pgsql-admin mailing list (pgsql-admin <at> postgresql.org)
(Continue reading)

Permalink | Reply | 1 comment |
headers
Benjamin Krajmalnik | 1 Aug 2009 07:51
Favicon

Re: Error in creating the backend query

I believe you may be right - need to do some more testing.
Apparently the error which I saw in the log was generated while
debugging the stored procedure using SQL Studio for PostgreSQL.  I guess
it has its own interpreter for plpgsql and must be typecasting while
executing each row.

We can consider this closed unless I see it occur again.
Sorry for the false alarm.

> -----Original Message-----
> From: pgsql-admin-owner <at> postgresql.org [mailto:pgsql-admin-
> owner <at> postgresql.org] On Behalf Of Benjamin Krajmalnik
> Sent: Wednesday, July 29, 2009 5:00 PM
> To: Tom Lane
> Cc: Alvaro Herrera; pgsql-admin <at> postgresql.org
> Subject: Re: [ADMIN] Error in creating the backend query
> 
> I wish that were the case.
> I am running 8.3.7 built from the FreeBSD ports.
> All insertions and updates to that table (or any others) are done
> exclusively through that (or other) stored procedures.
> We only use ad-hoc queries for selecting data for presentation
> purposes.
> Our code does not cast any column to its type.
> Just to make sure that this was indeed the source, we went ahead and
> typecast one of the assigned values, and the generated code had a
> "double cast", such as
> 
> Column = 'value'::VARCHAR::varchar
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Vladimir Rusinov | 1 Aug 2009 10:20
Gravatar

Re: out of memory



On Sat, Aug 1, 2009 at 1:20 AM, Fabricio <fabrixio1 <at> hotmail.com> wrote:


Hi

Some one know why this is happening?

I change the OS to 64 bits and now the oom-killer not hapend but Postgres is still showing out of memory

Linux SERVER 2.6.18-92.el5 #1 SMP Tue Apr 29 13:16:15 EDT 2008 x86_64 x86_64 x86_64 GNU/Linux
Red Hat Enterprise Linux Server release 5.2 (Tikanga)
PostgreSQL 8.1.15
32GB RAM

My postgresql.conf:
# - Memory -

shared_buffers = 1048576                        # min 16 or max_connections*2, 8KB each
temp_buffers = 1024                     # min 100, 8KB each
max_prepared_transactions = 20         # can be 0 or more
# note: increasing max_prepared_transactions costs ~600 bytes of shared memory
# per transaction slot, plus lock space (see max_locks_per_transaction).
work_mem = 1024                 # min 64, size in KB
maintenance_work_mem = 65536            # min 1024, size in KB
max_stack_depth = 2048                  # min 100, size in KB



kernel messages:
Jul 31 11:50:08 SERVER kernel: postmaster[7686]: segfault at 00007fff3feb1bb0 rip 00002b2f7e17e1a8 rsp 00007fff3feb1b90 error 6
Jul 31 15:41:55 SERVER kernel: postmaster[4737]: segfault at 00007fff3feb1bb0 rip 00002b2f7e1851a8 rsp 00007fff3feb1b90 error 6

PostgreSQL log:
<2009-07-31 15:41:55 MDT    7253 > LOG:  could not fork new process for connection: Cannot allocate memory
<2009-07-31 15:41:55 MDT    7253 > LOG:  could not fork new process for connection: Cannot allocate memory
<2009-07-31 15:41:55 MDT 10.27.41.74(2606) aforeglobal sysaforeglobal 7423 startup> FATAL:  out of memory
<2009-07-31 15:41:55 MDT    7253 > LOG:  could not fork new process for connection: Cannot allocate memory
<2009-07-31 15:41:55 MDT    7253 > LOG:  could not fork new process for connection: Cannot allocate memory
<2009-07-31 15:41:55 MDT 10.27.36.219(3859) db user 7424 startup> FATAL:  out of memory
<2009-07-31 15:41:55 MDT 10.20.216.82(1966) db user 7431 startup> FATAL:  out of memory
TopMemoryContext: 164432 total in 6 blocks; 5368 free (1 chunks); 159064 used
MdSmgr: 0 total in 0 blocks; 0 free (0 chunks); 0 used
LockTable (locallock hash): 8192 total in 1 blocks; 3744 free (0 chunks); 4448 used
Timezones: 52560 total in 2 blocks; 3744 free (0 chunks); 48816 used
ErrorContext: 8192 total in 1 blocks; 8160 free (4 chunks); 32 used
<2009-07-31 15:41:55 MDT 10.33.128.38(4458) db user 7434 startup> FATAL:  out of memory
<2009-07-31 15:41:55 MDT 10.33.128.38(4458) db user 7434 startup> DETAIL:  Failed on request of size 24000.
TopMemoryContext: 164432 total in 6 blocks; 5368 free (1 chunks); 159064 used
MdSmgr: 0 total in 0 blocks; 0 free (0 chunks); 0 used
LockTable (locallock hash): 8192 total in 1 blocks; 3744 free (0 chunks); 4448 used
Timezones: 52560 total in 2 blocks; 3744 free (0 chunks); 48816 used
ErrorContext: 8192 total in 1 blocks; 8160 free (4 chunks); 32 used
<2009-07-31 15:41:55 MDT 10.33.128.38(4459) db user 7435 startup> FATAL:  out of memory
<2009-07-31 15:41:55 MDT 10.33.128.38(4459) db user 7435 startup> DETAIL:  Failed on request of size 24000.
TopMemoryContext: 164432 total in 6 blocks; 5368 free (1 chunks); 159064 used
MdSmgr: 0 total in 0 blocks; 0 free (0 chunks); 0 used
LockTable (locallock hash): 8192 total in 1 blocks; 3744 free (0 chunks); 4448 used
Timezones: 52560 total in 2 blocks; 3744 free (0 chunks); 48816 used
ErrorContext: 8192 total in 1 blocks; 8160 free (4 chunks); 32 used
<2009-07-31 15:41:55 MDT 10.33.128.38(4460) db user 7436 startup> FATAL:  out of memory
<2009-07-31 15:41:55 MDT 10.33.128.38(4460) db user 7436 startup> DETAIL:  Failed on request of size 24000.
<2009-07-31 15:41:55 MDT 10.33.128.38(4461) db user 7438 startup> FATAL:  out of memory
<2009-07-31 15:41:55 MDT 10.33.128.38(4462) db user 7439 startup> FATAL:  out of memory
<2009-07-31 15:41:55 MDT 10.33.128.38(4463) db user 7440 startup> FATAL:  out of memory
<2009-07-31 15:41:55 MDT 10.20.219.194(3594) db user 7433 startup> FATAL:  out of memory
<2009-07-31 15:41:55 MDT 10.33.128.38(4464) db user 7441 startup> FATAL:  out of memory
<2009-07-31 15:41:55 MDT 10.33.128.38(4465) db user 7442 startup> FATAL:  out of memory
<2009-07-31 15:41:55 MDT 10.33.128.31(1263) db user 7447 startup> FATAL:  out of memory
<2009-07-31 15:41:55 MDT 10.44.5.43(3498) db user 7450 startup> FATAL:  out of memory
<2009-07-31 15:41:55 MDT 10.27.36.219(3860) db user 7448 startup> FATAL:  out of memory
<2009-07-31 15:41:55 MDT 10.33.128.10(35976) db user 7460 idle> LOG:  unexpected EOF on client connection
<2009-07-31 15:41:55 MDT    7253 > LOG:  server process (PID 4737) was terminated by signal 11
<2009-07-31 15:41:55 MDT    7253 > LOG:  terminating any other active server processes
<2009-07-31 15:41:55 MDT 10.33.128.10(35976) db user 7460 idle> WARNING:  terminating connection because of crash of another server process


Before crash:

date & free -m
Fri Jul 31 15:40:01 MDT 2009
 15:40:01 up  4:48,  3 users,  load average: 2.64, 3.04, 3.58

             total       used       free     shared    buffers     cached
Mem:         32187      22292       9895          0        164      19824
-/+ buffers/cache:       2303      29884
Swap:         1983          0       1983

After crash:

date & free -m
Fri Jul 31 15:45:01 MDT 2009
 15:45:01 up  4:53,  3 users,  load average: 4.45, 3.99, 3.80

             total       used       free     shared    buffers     cached
Mem:         32187      14726      17460          0        165      13850
-/+ buffers/cache:        710      31477
Swap:         1983          0       1983

Hm, It looks weird.
BTW, I assume that 24000 in "DETAIL:  Failed on request of size 24000" is size in bytes, but may be it's size in kilobytes? o_O

How many connections (active and max) do you have?
Are you sure that nothing else could eat memory (e.g. some poorly-written cronjob?)
How many VIRT memory does postmaster have before the crash?

Here is some suggersions:
Check memory limits in /etc/security/limits.conf and in `ulimit -a`.
tail /var/log/audit/audit.log (it might be something interesting there especially if you are running selinux)
Try to upgrade to 8.1.17 (it should be safe and fast operation).
Check your kernerl's shm settings.
Check fsm settings.

HTH


--
Vladimir Rusinov
http://greenmice.info/
Permalink | Reply | 1 comment |
headers
Emanuel Calvo Franco | 1 Aug 2009 18:11
Picon

Re: out of memory

>
> Some one know why this is happening?
>
> I change the OS to 64 bits and now the oom-killer not hapend but Postgres is
> still showing out of memory
>
> Linux SERVER 2.6.18-92.el5 #1 SMP Tue Apr 29 13:16:15 EDT 2008 x86_64 x86_64
> x86_64 GNU/Linux
> Red Hat Enterprise Linux Server release 5.2 (Tikanga)
> PostgreSQL 8.1.15
> 32GB RAM
>
> My postgresql.conf:
> # - Memory -
>
> shared_buffers = 1048576                        # min 16 or
> max_connections*2, 8KB each
> temp_buffers = 1024                     # min 100, 8KB each
> max_prepared_transactions = 20         # can be 0 or more
> # note: increasing max_prepared_transactions costs ~600 bytes of shared
> memory
> # per transaction slot, plus lock space (see max_locks_per_transaction).
> work_mem = 1024                 # min 64, size in KB
> maintenance_work_mem = 65536            # min 1024, size in KB
> max_stack_depth = 2048                  # min 100, size in KB
>

What about the shmmax and shmall kernel parametters?
Which values you are managing?

-- 
              Emanuel Calvo Franco
      www.emanuelcalvofranco.com.ar

--

-- 
Sent via pgsql-admin mailing list (pgsql-admin <at> postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin
Permalink | Reply | 0 comments |
headers
Fabricio | 3 Aug 2009 02:17
Picon
Favicon

Re: out of memory



thanks Vladimir and Emanuel

    >How many connections (active and max) do you have?
max_connections = 2000
Active 1000

  >Are you sure that nothing else could eat memory (e.g. some poorly-written cronjob?)
There are 2 or 3  ligth cronjob's
but the free command show free memory... why? :s


  >How many VIRT memory does postmaster have before the crash?
8518m

 >Here is some suggersions:
 >Check memory limits in /etc/security/limits.conf and in `ulimit -a`.
The config file is the default
[postgres <at> SERVER ~]$ ulimit -a
core file size          (blocks, -c) 0
data seg size           (kbytes, -d) unlimited
scheduling priority             (-e) 0
file size               (blocks, -f) unlimited
pending signals                 (-i) 268287
max locked memory       (kbytes, -l) 32
max memory size         (kbytes, -m) unlimited
open files                      (-n) 1024
pipe size            (512 bytes, -p) 8
POSIX message queues     (bytes, -q) 819200
real-time priority              (-r) 0
stack size              (kbytes, -s) 10240
cpu time               (seconds, -t) unlimited
max user processes              (-u) 268287
virtual memory          (kbytes, -v) unlimited
file locks                      (-x) unlimited


 >tail /var/log/audit/audit.log (it might be something interesting there especially if you are running selinux)
selinux is disabled

 >Try to upgrade to 8.1.17 (it should be safe and fast operation).
I will update

  >Check your kernerl's shm settings.
kernel.shmmax = 68719476736
kernel.shmall = 4294967296
Are the default, i think are too big already

 >Check fsm settings.
max_fsm_pages = 180000



regards...




Date: Sat, 1 Aug 2009 12:20:27 +0400
Subject: Re: [ADMIN] out of memory
From: vladimir <at> greenmice.info
To: fabrixio1 <at> hotmail.com
CC: pgsql-admin <at> postgresql.org; alvherre <at> commandprompt.com



On Sat, Aug 1, 2009 at 1:20 AM, Fabricio <fabrixio1 <at> hotmail.com> wrote:


Hi

Some one know why this is happening?

I change the OS to 64 bits and now the oom-killer not hapend but Postgres is still showing out of memory

Linux SERVER 2.6.18-92.el5 #1 SMP Tue Apr 29 13:16:15 EDT 2008 x86_64 x86_64 x86_64 GNU/Linux
Red Hat Enterprise Linux Server release 5.2 (Tikanga)
PostgreSQL 8.1.15
32GB RAM

My postgresql.conf:
# - Memory -

shared_buffers = 1048576                        # min 16 or max_connections*2, 8KB each
temp_buffers = 1024                     # min 100, 8KB each
max_prepared_transactions = 20         # can be 0 or more
# note: increasing max_prepared_transactions costs ~600 bytes of shared memory
# per transaction slot, plus lock space (see max_locks_per_transaction).
work_mem = 1024                 # min 64, size in KB
maintenance_work_mem = 65536            # min 1024, size in KB
max_stack_depth = 2048                  # min 100, size in KB



kernel messages:
Jul 31 11:50:08 SERVER kernel: postmaster[7686]: segfault at 00007fff3feb1bb0 rip 00002b2f7e17e1a8 rsp 00007fff3feb1b90 error 6
Jul 31 15:41:55 SERVER kernel: postmaster[4737]: segfault at 00007fff3feb1bb0 rip 00002b2f7e1851a8 rsp 00007fff3feb1b90 error 6

PostgreSQL log:
<2009-07-31 15:41:55 MDT    7253 > LOG:  could not fork new process for connection: Cannot allocate memory
<2009-07-31 15:41:55 MDT    7253 > LOG:  could not fork new process for connection: Cannot allocate memory
<2009-07-31 15:41:55 MDT 10.27.41.74(2606) aforeglobal sysaforeglobal 7423 startup> FATAL:  out of memory
<2009-07-31 15:41:55 MDT    7253 > LOG:  could not fork new process for connection: Cannot allocate memory
<2009-07-31 15:41:55 MDT    7253 > LOG:  could not fork new process for connection: Cannot allocate memory
<2009-07-31 15:41:55 MDT 10.27.36.219(3859) db user 7424 startup> FATAL:  out of memory
<2009-07-31 15:41:55 MDT 10.20.216.82(1966) db user 7431 startup> FATAL:  out of memory
TopMemoryContext: 164432 total in 6 blocks; 5368 free (1 chunks); 159064 used
MdSmgr: 0 total in 0 blocks; 0 free (0 chunks); 0 used
LockTable (locallock hash): 8192 total in 1 blocks; 3744 free (0 chunks); 4448 used
Timezones: 52560 total in 2 blocks; 3744 free (0 chunks); 48816 used
ErrorContext: 8192 total in 1 blocks; 8160 free (4 chunks); 32 used
<2009-07-31 15:41:55 MDT 10.33.128.38(4458) db user 7434 startup> FATAL:  out of memory
<2009-07-31 15:41:55 MDT 10.33.128.38(4458) db user 7434 startup> DETAIL:  Failed on request of size 24000.
TopMemoryContext: 164432 total in 6 blocks; 5368 free (1 chunks); 159064 used
MdSmgr: 0 total in 0 blocks; 0 free (0 chunks); 0 used
LockTable (locallock hash): 8192 total in 1 blocks; 3744 free (0 chunks); 4448 used
Timezones: 52560 total in 2 blocks; 3744 free (0 chunks); 48816 used
ErrorContext: 8192 total in 1 blocks; 8160 free (4 chunks); 32 used
<2009-07-31 15:41:55 MDT 10.33.128.38(4459) db user 7435 startup> FATAL:  out of memory
<2009-07-31 15:41:55 MDT 10.33.128.38(4459) db user 7435 startup> DETAIL:  Failed on request of size 24000.
TopMemoryContext: 164432 total in 6 blocks; 5368 free (1 chunks); 159064 used
MdSmgr: 0 total in 0 blocks; 0 free (0 chunks); 0 used
LockTable (locallock hash): 8192 total in 1 blocks; 3744 free (0 chunks); 4448 used
Timezones: 52560 total in 2 blocks; 3744 free (0 chunks); 48816 used
ErrorContext: 8192 total in 1 blocks; 8160 free (4 chunks); 32 used
<2009-07-31 15:41:55 MDT 10.33.128.38(4460) db user 7436 startup> FATAL:  out of memory
<2009-07-31 15:41:55 MDT 10.33.128.38(4460) db user 7436 startup> DETAIL:  Failed on request of size 24000.
<2009-07-31 15:41:55 MDT 10.33.128.38(4461) db user 7438 startup> FATAL:  out of memory
<2009-07-31 15:41:55 MDT 10.33.128.38(4462) db user 7439 startup> FATAL:  out of memory
<2009-07-31 15:41:55 MDT 10.33.128.38(4463) db user 7440 startup> FATAL:  out of memory
<2009-07-31 15:41:55 MDT 10.20.219.194(3594) db user 7433 startup> FATAL:  out of memory
<2009-07-31 15:41:55 MDT 10.33.128.38(4464) db user 7441 startup> FATAL:  out of memory
<2009-07-31 15:41:55 MDT 10.33.128.38(4465) db user 7442 startup> FATAL:  out of memory
<2009-07-31 15:41:55 MDT 10.33.128.31(1263) db user 7447 startup> FATAL:  out of memory
<2009-07-31 15:41:55 MDT 10.44.5.43(3498) db user 7450 startup> FATAL:  out of memory
<2009-07-31 15:41:55 MDT 10.27.36.219(3860) db user 7448 startup> FATAL:  out of memory
<2009-07-31 15:41:55 MDT 10.33.128.10(35976) db user 7460 idle> LOG:  unexpected EOF on client connection
<2009-07-31 15:41:55 MDT    7253 > LOG:  server process (PID 4737) was terminated by signal 11
<2009-07-31 15:41:55 MDT    7253 > LOG:  terminating any other active server processes
<2009-07-31 15:41:55 MDT 10.33.128.10(35976) db user 7460 idle> WARNING:  terminating connection because of crash of another server process


Before crash:

date & free -m
Fri Jul 31 15:40:01 MDT 2009
 15:40:01 up  4:48,  3 users,  load average: 2.64, 3.04, 3.58

             total       used       free     shared    buffers     cached
Mem:         32187      22292       9895          0        164      19824
-/+ buffers/cache:       2303      29884
Swap:         1983          0       1983

After crash:

date & free -m
Fri Jul 31 15:45:01 MDT 2009
 15:45:01 up  4:53,  3 users,  load average: 4.45, 3.99, 3.80

             total       used       free     shared    buffers     cached
Mem:         32187      14726      17460          0        165      13850
-/+ buffers/cache:        710      31477
Swap:         1983          0       1983

Hm, It looks weird.
BTW, I assume that 24000 in "DETAIL:  Failed on request of size 24000" is size in bytes, but may be it's size in kilobytes? o_O

How many connections (active and max) do you have?
Are you sure that nothing else could eat memory (e.g. some poorly-written cronjob?)
How many VIRT memory does postmaster have before the crash?

Here is some suggersions:
Check memory limits in /etc/security/limits.conf and in `ulimit -a`.
tail /var/log/audit/audit.log (it might be something interesting there especially if you are running selinux)
Try to upgrade to 8.1.17 (it should be safe and fast operation).
Check your kernerl's shm settings.
Check fsm settings.

HTH


--
Vladimir Rusinov
http://greenmice.info/

Únete a la celebración de Messenger y sigue siendo parte de esta historia
Permalink | Reply | 0 comments |
headers
Gnanam | 3 Aug 2009 12:50

PITR archive_timeout Command


Hi,

I have a basic and quick question related to "archive_timeout" command in
PITR.

I've set "archive_timeout" to 1800 seconds (30 minutes) in
"postgresql.conf", which means WAL archives are generated every 30 minutes. 
So, if for an example my WAL archives are  generated at the following time:
	9:00 am
	9:30 am
	10:00 am
	10:30 am
	11:00 am, etc.

I specify PITR recovery time at 10:15 am in "recovery.conf".  My question
is, to what time my database is recovered back?  At which stage of the
following my database is reverted back:
	1) Exactly the database was at 10:15 am 
	2) Exactly the database was at 10:00 am, because the last WAL archive
before 10:15 am was at 10:00 am.

Regards,
Gnanam
-- 
View this message in context: http://www.nabble.com/PITR-archive_timeout-Command-tp24788681p24788681.html
Sent from the PostgreSQL - admin mailing list archive at Nabble.com.

--

-- 
Sent via pgsql-admin mailing list (pgsql-admin <at> postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin
Permalink | Reply | 7 comments |
headers
Ian Lea | 3 Aug 2009 13:17
Picon

Re: PITR archive_timeout Command

1) Exactly the database was at 10:15 am

From http://www.postgresql.org/docs/8.3/static/continuous-archiving.html

"There is nothing that says we have to replay the WAL entries all the
way to the end. We could stop the replay at any point and have a
consistent snapshot of the database as it was at that time. Thus, this
technique supports point-in-time recovery: it is possible to restore
the database to its state at any time since your base backup was
taken."

--
Ian.

On Mon, Aug 3, 2009 at 11:50 AM, Gnanam<gnanam <at> zoniac.com> wrote:
>
> Hi,
>
> I have a basic and quick question related to "archive_timeout" command in
> PITR.
>
> I've set "archive_timeout" to 1800 seconds (30 minutes) in
> "postgresql.conf", which means WAL archives are generated every 30 minutes.
> So, if for an example my WAL archives are  generated at the following time:
>        9:00 am
>        9:30 am
>        10:00 am
>        10:30 am
>        11:00 am, etc.
>
> I specify PITR recovery time at 10:15 am in "recovery.conf".  My question
> is, to what time my database is recovered back?  At which stage of the
> following my database is reverted back:
>        1) Exactly the database was at 10:15 am
>        2) Exactly the database was at 10:00 am, because the last WAL archive
> before 10:15 am was at 10:00 am.
>
> Regards,
> Gnanam
> --
> View this message in context: http://www.nabble.com/PITR-archive_timeout-Command-tp24788681p24788681.html
> Sent from the PostgreSQL - admin mailing list archive at Nabble.com.
>
>
> --
> Sent via pgsql-admin mailing list (pgsql-admin <at> postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-admin
>

--

-- 
Sent via pgsql-admin mailing list (pgsql-admin <at> postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin
Permalink | Reply | 6 comments |
headers
Gnanam | 3 Aug 2009 13:27

Re: PITR archive_timeout Command


Hi Ian,

Ian Lea wrote:
> 
> "We could stop the replay at any point and have a
> consistent snapshot of the database as it was at that time. Thus, this
> technique supports point-in-time recovery: it is possible to restore
> the database to its state at any time since your base backup was
> taken."
> 

I got your point, again I've another simple question which I still don't
understand clearly.  Can I set my "archive_timeout" to 3600 seconds (1
hour), so that atleast I save my WAL archive storage space, because if it is
set to 1800 seconds (30 minutes), it is fast filling.  Setting it in this
way affect the PITR recovery process to consistent snapshot as the database
was at that time?  Will I be able to recover my database upto 10:15 am?

-- 
View this message in context: http://www.nabble.com/PITR-archive_timeout-Command-tp24788681p24789154.html
Sent from the PostgreSQL - admin mailing list archive at Nabble.com.

--

-- 
Sent via pgsql-admin mailing list (pgsql-admin <at> postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin
Permalink | Reply | 5 comments |
headers
Gnanam | 3 Aug 2009 13:35

Re: PITR archive_timeout Command


Essentially, my question here is

1) What is the advantage / disadvantage of setting "archive_timeout" command
to too small or too high value?
2) What is the impact of setting this value during PITR recovery process?

-- 
View this message in context: http://www.nabble.com/PITR-archive_timeout-Command-tp24788681p24789235.html
Sent from the PostgreSQL - admin mailing list archive at Nabble.com.

--

-- 
Sent via pgsql-admin mailing list (pgsql-admin <at> postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin
Permalink | Reply | 4 comments |
headers
Venkateswara Rao Bondada | 3 Aug 2009 14:55
Favicon

Create table command fails with permission denied

Hi,

I’m new to PostgreSQL, and currently facing an issue with PostgreSQL 7.4 database. I’m getting the following error when tried to create a table. Please let me know the steps (with queries) that I should take care to resolve this issue.

 

cms=# create table test(id character varying(80));

ERROR:  could not create relation "test": Permission denied

 

Thanks in advance,

Venkat

Permalink | Reply | 1 comment |

Gmane