Arvind,
It seems this is Firewall issue.Server side(where as postgresql
installed) port(Ex:5432 default) was not opened to access postgres instance
from client machines. please stop firewalls on windows 7 machine and try to
connect from client machine.
Best Regards,
Chiru
On Mon, May 27, 2013 a
I have installed postgres server 9.3 on windows 7 network for the first time.
The systems are connected on wifi network.
Server in installed and working normal.
configured pghba with
host all all0.0.0.0/0md5
hostall all ::1/128
Sadly the flashback didn't work...do you need to do a vacuum for it to
work.. I haven't...
Cheers
Ash
On Sun, May 26, 2013 at 8:28 PM, Amit Langote wrote:
> On Mon, May 27, 2013 at 12:10 PM, Ash Damle wrote:
> > WAL was not set or archive ..
> >
> > Thus I would conclude that PITR was not act
On Mon, May 27, 2013 at 12:10 PM, Ash Damle wrote:
> WAL was not set or archive ..
>
> Thus I would conclude that PITR was not activated.. correct?
>
Without a WAL archive (that is, archive_mode=on with appropriate
archive_command set), you would not be able to do a PITR.
I think we would have to
flashback in postgresql：
http://blog.163.com/digoal@126/blog/static/163877040201251911813661/
make a backup before try the method
2013/5/27 Ash Damle
> I don't know if I have PITR on.. how can I check?
>
> Have a backup buts it from a little while ago.. currently pulling it up on
> another ma
WAL was not set or archive ..
Thus I would conclude that PITR was not activated.. correct?
Ash
On Sun, May 26, 2013 at 7:39 PM, Ash Damle wrote:
> I don't know if I have PITR on.. how can I check?
>
> Have a backup buts it from a little while ago.. currently pulling it up on
> another machine
I don't know if I have PITR on.. how can I check?
Have a backup buts it from a little while ago.. currently pulling it up on
another machine and then will extract that data, but its not 100% current
... :(
Ash
On Sun, May 26, 2013 at 7:36 PM, Amit Langote wrote:
> On Mon, May 27, 2013 at 11:27
On Mon, May 27, 2013 at 11:27 AM, Ash Damle wrote:
> Hello. I have some data that was accidently deleted.
> I have not done a vacuum etc.
>
> I know the raw text of the data should be in the xlog file.
>
> However when using xlogdump of pg_filedump I am not able to get a complete
> non compressed
Hello. I have some data that was accidently deleted.
I have not done a vacuum etc.
I know the raw text of the data should be in the xlog file.
However when using xlogdump of pg_filedump I am not able to get a complete
non compressed version of the data. Is the xlog compressed in a standard
way th
On Mon, May 27, 2013 at 10:56 AM, 高健 wrote:
> Hi:
> Thanks for Jov's reply.
> I traced it again, and found they are really for autovacuum.
> I found that
> some will call proc_exit() from within AutoVacLauncherMain function,
> some will call proc_exit() from within AutoVacWorkerMain function.
>
>
Hi:
Thanks for Jov's reply.
I traced it again, and found they are really for autovacuum.
I found that
some will call proc_exit() from within AutoVacLauncherMain function,
some will call proc_exit() from within AutoVacWorkerMain function.
But I wonder why not using only a few daemon , instead of
On Sat, May 25, 2013 at 8:42 AM, Dan Birken wrote:
> I am running a pg_receivexlog 9.2 client against a 9.1 server. It seems to
> work. Comments in the code seem to indicate that this setup is workable.
>
> However, pg_receivexlog is not part of the 9.1 source tree nor the rpm
> package (as far
12 matches
Mail list logo
