Hi Tom,
We have different databases with different versions.
I checked the database with *version 8.2.4* by running the below query
echo select timestamp with time zone \'epoch\' + 1206970200 \* INTERVAL \'1
second\'\; | psql template1
?column?
---
2008-03-31 23
ng on host "localhost" and accepting
TCP/IP connections on port 5432?
Can anybody please tell me how to solve this problem
Thanks and Regards
Shilpa
---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings
command and tried to
access *psql dbname, *
It gives a message *"database shutting down" *
As far as i know, this msg appears only when a restart command is given.
Please let me know if my understanding is right and what could have gone
wrong for the db to shutdown.
Thanks and Regar
Thanks for the reply.
I am sure i didn't issue the restart command. i only did the reload.
I'll find out from my other team mates if they issued any restart
command by mistake.
Thanks again.
Regards,
Shilpa
Andrew Sullivan wrote:
On Thu, Feb 21, 2008 at 04:01:00PM +1030, Shilp
every now
and then so that we can delete the old log files?
How often do we take a base filesystem backup keeping in mind that our
systems are 24 x 7.
Any suggestions are appreciated.
Thanks and Regards,
Shilpa
---(end of broadcast)---
TIP 9
Shilpa Sudhakar wrote:
Hi Vishal,
Below is the setup in the postgresql.conf file
fsync = true# turns forced synchronization on or off
wal_sync_method = fsync # the default varies across platforms:
#wal_buffers = 8# min 4, 8KB each
#commit_delay = 0
Thanks loads Dawid,
I'll test the process on the TEST box and note down the time it takes.
Dawid Kuroczko wrote:
On Fri, Feb 22, 2008 at 12:23 AM, Shilpa Sudhakar
<[EMAIL PROTECTED]> wrote:
Since the wal logs keep increasing, do we take the base backup every now
and then so
t
to pg_xlog directly.
In this way i can avoid a separate process of deleting old files.
Please let me know if my understanding is right.
Thanks and Regards,
Shilpa
Vishal Arora wrote:
> Date: Mon, 25 Feb 2008
Thanks for the link Vishal
Regards,
Shilpa
Vishal Arora wrote:
You can have a warm standby system in place. Pls check this link -
http://archives.postgresql.org/sydpug/2006-10/msg1.php
> Date: Mon, 25
arate process of deleting old files.
>
> Please let me know if my understanding is right.
>
> Thanks and Regards,
> Shilpa
>
>
>
> Vishal Arora wrote:
> >
> >
> >
> >
> >
> >
-
Hi Tom,
We have different databases with different versions.
I checked the database with *version 8.2.4* by running the below query
echo select timestamp with time zone \'epoch\' + 1206970200 \* INTERVAL
\'1 second\'\; | psql template1
?column?
---
2008-03-31 2
ults
From 2008, the DST ends on first Sunday of April and not on the last
Sun of March.
Thanks
[EMAIL PROTECTED] wrote:
On Fri, Mar 07, 2008 at 09:26:51AM +1030, Shilpa Sudhakar wrote:
Hi Tom,
We have different databases with different versions.
I checked the database with *version 8
Hi Alvaro,
Thanks for the info.
I assume Postgresql should have already known about the DST changes in
Australia.
I'll check the mailing list from the link you sent to see if there's
anything regarding this.
Thanks and Regards,
Alvaro Herrera wrote:
Shilpa Sudhakar wrote
Hi Tom,
If DST changes are done in version 8.2.5 and up, is there any way to
recompile the timezone files in our existing versions without upgrading.
Thanks
Tom Lane wrote:
Alvaro Herrera <[EMAIL PROTECTED]> writes:
Shilpa Sudhakar wrote:
From 2008, the DST ends on first Sun
Hi Tom,
I live in Adelaide Australia. I checked in 3 servers and all of them
have "Australia/South" when i ran "show timezone"
For the new timezone files, do i need to apply a timezone patch?
Thanks
Tom Lane wrote:
Shilpa Sudhakar <[EMAIL PROTECTED]>
he OS zonefile or from the newer version of Postgres zonefiles.
Thanks
Tom Lane wrote:
Alvaro Herrera <[EMAIL PROTECTED]> writes:
Shilpa Sudhakar wrote:
If DST changes are done in version 8.2.5 and up, is there any way to
recompile the timezone files in our existing versions withou
I copied the system zonefiles into the postgres database and it works
fine now. This is anyway a temporary solution until we upgrade all our
systems.
Thanks to all for your suggestions and help.
Tom Lane wrote:
Shilpa Sudhakar <[EMAIL PROTECTED]> writes:
As i said, we have version
low error:
FATAL: Ident authentication failed for user "abc"
Should i put an entry in pg_ident.conf file?
Is using ident still the right way to go? Is LDAP a better option
because when we login to the server, we login with our LDAP username and
password.
Thanks and Regards,
Shilpa
18 matches
Mail list logo