Re: [BUGS] BUG #8236: wal_sync_method open_datasync unavailable
On Tuesday, June 18, 2013 10:55 AM Ivan wrote >Sync method ":open_datasync" daclared as supported ( >http://www.postgresql.org/docs/8.4/static/runtime-config-wal.html ) >But after changing this parameter I've got the following error: >FATAL: invalid value for parameter "wal_sync_method": "open_datasync" >HINT: Available values: fsync, fdatasync, open_sync. The open_datasync may not supported by your system. Can you please check what are types of syncs supported in your system. Use the pg_test_fsync tool which is present in contrib folder. Regards, Hari babu. -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] initdb fail to execute
On Sunday, May 05, 2013 1:15 AM Jinu K J wrote: >Hi, >We are trying install postgresql 9.2.3 version for windows xp. >Below issue happen only for this particular PC. >Other windows XP installations are ok. >Here initdb command failed mentioning that , it is able to find postgres , but version mismatched. Can you please check is there any other version of postgres present in the machine? Regards, Hari babu.
[BUGS] BUG #8091: No permissions on the table file causing recovery failure
As the following raised bug is not received by the bugs mailing list. Forwarding the same to mailing list. http://www.postgresql.org/message-id/E1USmqv-0006X0-5X@wrigleys.postgresql.o rg Please check the above defect needs any handling? Regards, Hari babu. -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #7643: Issuing a shutdown request while server startup leads to server hang
Tom Lane writes: >I concluded that it probably wasn't a good idea to have the additional state transition in SIGINT handling. Generally >PM_STARTUP means "we're running the startup process and nothing else", and that's useful state info that we shouldn't >throw away lightly. I tested the patch, it is working fine. I have a query regarding the changing of pmState only incase of SIGTERM but not incase of SIGINT. Is there any reason to handle like this? or Is it ok to modify the handling of pmState in SIGTERM same as SIGINT? Regards, Hari babu. -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #7643: Issuing a shutdown request while server startup leads to server hang
>haribabu.ko...@huawei.com writes:
> Problem Reproduction:
> 1. Add recovery.conf to the database directory.
> 2. Start the server
> 3. Issue the shutdown request
> and the shutdown request timing should be such that below server logs
should
> print.
> Log:
> ./postgres -D data -p 3335
> LOG: database system was shut down in recovery at 2012-11-08 19:42:42 IST
> LOG: entering standby mode
> LOG: received fast shutdown request
> LOG: consistent recovery state reached at 0/17D0700
> LOG: record with zero length at 0/17D0700
> Problem reproduced in 9.3 head.
>After further investigation, I can't reproduce this and I don't believe
>your patch fixes it. What happens when I try this is
>* postmaster gets SIGINT, sends SIGTERM to startup process
>* startup process exits with exit(1)
>* postmaster sees that as a startup crash and exits, per the first
>test in reaper()
>So the log trace I'm getting looks like
>LOG: received fast shutdown request
>LOG: startup process (PID 9772) exited with exit code 1
>LOG: aborting startup due to startup process failure
>Now, transitioning to PM_WAIT_BACKENDS state earlier, as your patch
>proposes, might make the log look a bit nicer because the logic in
>reaper() wouldn't think the exit was a "crash". But it's not going to
>have anything to do with whether the startup process exits on the signal
>or not. What seems to have happened for you is that the startup process
>ignored the SIGTERM signal, but it's not at all obvious why.
>We're going to need more details about how to reproduce this.
>I speculate it might have something to do with the specific
>restore_command you're using.
The problem occurs only when active server is restarting by just adding a
recovery.conf file to the data directory.
No need of specifying any restore command. or the standby server restart
also can lead to this problem.
The startup process sends "PMSIGNAL_RECOVERY_STARTED" to postmaster only
incase of "InArchiveRecovery" flag is enabled.
The SIGINT signal should reach postmaster before the
"PMSIGNAL_RECOVERY_STARTED" sent by the startup process.
with the following code change in the startupXlog function, the issue can
reproduce very easily.
if (InArchiveRecovery && IsUnderPostmaster)
{
PublishStartupProcessInformation();
SetForwardFsyncRequests();
kill (PostmasterPid, SIGINT);
SendPostmasterSignal(PMSIGNAL_RECOVERY_STARTED);
bgwriterLaunched = true;
}
Please let me know if I miss anything.
Regards,
Hari babu.
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] BUG #7643: Issuing a shutdown request while server startup leads to server hang
For defect 7643 which is described in the following mail,
http://archives.postgresql.org/message-id/E1TWWd4-0008AD-9E@wrigleys.postgre
sql.org
The problem identified as the postmaster handling SIGUSR1 after SIGINT
signal leads to the problem as
bgwriter process is not signaled to terminate by the postmaster as it was
not exist during the processing of
SIGINT signal and after that during the processing of SIGUSR1 signal the
process got created.
As the postmaster is waiting for the bgwriter process to terminate in the
further shutdown follow leads the postmaster process to wait until the
Bgwriter process stops, which enters into a deadlock.
The issue is occurring only incase of SIGINT signal and it was handled for
SIGTERM signal as during the processing of
SIGTERM signal the pmState is modified which blocks the further start of
bgwriter.
The following patch handles the SIGINT signal also the same way as the
SIGTERM signal for the pmState.
*** a/src/backend/postmaster/postmaster.c
--- b/src/backend/postmaster/postmaster.c
***
*** 2258,2270 pmdie(SIGNAL_ARGS)
signal_child(BgWriterPID, SIGTERM);
if (WalReceiverPID != 0)
signal_child(WalReceiverPID, SIGTERM);
! if (pmState == PM_RECOVERY)
{
- /*
- * Only startup, bgwriter, and
checkpointer should be active
- * in this state; we just signaled the
first two, and we don't
- * want to kill checkpointer yet.
- */
pmState = PM_WAIT_BACKENDS;
}
else if (pmState == PM_RUN ||
--- 2258,2277
signal_child(BgWriterPID, SIGTERM);
if (WalReceiverPID != 0)
signal_child(WalReceiverPID, SIGTERM);
!
! /*
! * In the case of pmState as PM_STARTUP, to avoid
further startup
! * of bgwriter and checkpointer incase of standby
or in archieve
! * recovery mode because we are already in the
process of handling
! * fast shutdown.
! *
! * In the case of pmState as PM_RECOVERY, only
startup, bgwriter
! * and checkpointer should be active in this
state; we just
! * signaled the first two, and we don't want to
kill checkpointer
! * yet.
! */
! if (pmState == PM_RECOVERY || pmState ==
PM_STARTUP)
{
pmState = PM_WAIT_BACKENDS;
}
else if (pmState == PM_RUN ||
Regards,
Hari babu.
