Keith Pierno writes:
> The backup used was from well after the failover time which is why I
> was concerned. Interestingly enough the logs are still all prefixed
> with 0004... That just makes this problem extremely bizarre.
Hmm, that *is* weird. It seems like the new primary must have rever
The backup used was from well after the failover time which is why I
was concerned. Interestingly enough the logs are still all prefixed
with 0004... That just makes this problem extremely bizarre.
Current log listing:
[postg...@db01pri pgwalarchives]# ls -ltr
total 82028
-rw--- 1 p
Keith Pierno writes:
> I was able to find the file, which was from the date of the failure
> (Tuesday June 9th). My question is why the backup from this morning
> would all of a sudden require a file from the 9th even though 5 hours
> of logs were able to be applied?
It was apparently busy applyi
I was able to find the file, which was from the date of the failure
(Tuesday June 9th). My question is why the backup from this morning
would all of a sudden require a file from the 9th even though 5 hours
of logs were able to be applied? I ended up doing another hotbackup and
restoring the dat
Thanks for the prompt response. If such a file is needed for recovery
it was never created by postgres. The current archiving process creates
uses rsync to archive the WAL files to a shared archive area. In the
past and on my other cluster we do not see .history files on the
primary server and
Keith Pierno writes:
> Thanks for the prompt response. If such a file is needed for recovery
> it was never created by postgres. The current archiving process creates
> uses rsync to archive the WAL files to a shared archive area. In the
> past and on my other cluster we do not see .history files
"Keith Pierno" writes:
> 2009-06-15 13:25:12 EDT <::> PANIC: unexpected timeline ID 6 (after 4) in
> checkpoint record
Hmm. It's complaining because it didn't find timeline 6 mentioned in
the timeline history file it read (if any). Maybe you forgot to archive
or restore the .history fi
The following bug has been logged online:
Bug reference: 4854
Logged by: Keith Pierno
Email address: kpie...@lulu.com
PostgreSQL version: 8.3.6
Operating system: Red Hat Enterprise Linux AS release 4 (Nahant Update 6)
PPC64
Description:Problems with replaying WAL file
Hi.
Umm, windows7 can't declare support yet. :-(
However, Information thinks that it is glad.
I want to try it early.
Regards,
Hiroshi Saito
- Original Message -
From: "Michael Schurat"
The following bug has been logged online:
Bug reference: 4852
Logged by: Mic
"Hiromichi Nakajima" writes:
> I execute sql below:
> INSERT INTO A_TBL ( OPE_DATE) VALUES ( '2009-06-15 18:29:58.156')
> and show value with sql below:
> select TO_CHAR ( OP_DATE, '-MM-DD HH24:MI:SS.MS.US')
> It must show as '2009-06-15 18:29:58.156.156000'
> but sometimes '2009-06-15 18:29
The following bug has been logged online:
Bug reference: 4853
Logged by: Hiromichi Nakajima
Email address: hirol...@yahoo.co.jp
PostgreSQL version: 8.3.7
Operating system: RedHatEnterpriseLinux ES3
Description:millisecond is incorrect?
Details:
for example
'OPE_DATE
The following bug has been logged online:
Bug reference: 4852
Logged by: Michael Schurat
Email address: i...@schurat.org
PostgreSQL version: 8.3.7
Operating system: Windows Seven
Description:PostgreSQL ODBC driver doesn't work
Details:
Hi PostgreSQL-Team,
After ins
Hi All,
Postgres 'psql' client is getting hang in 'stat' call while connecting
to postgres server.
Pstack output:
11017: ./bin/psql -U postgres configdb
stat (ff3f5640, ffbff578)
My machine details:
SunOS my_machine 5.10 Generic_120011-14 sun4u sparc SUNW,Sun-Fire-V245
13 matches
Mail list logo
