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
Hari Babu writes: > 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? AFAICT the "smart shutdown" code path is okay: it transitions to PM_WAIT_READONLY state, and then PostmasterStateMachine issues SIGTERM to the startup process and goes to PM_WAIT_BACKENDS state. Perhaps this could be done more clearly but I'm disinclined to mess with it. regards, tom lane -- 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] Prepared Statement Name Truncation
-BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 Gavin Flower asks: > Would it be appropriate to make it a WARNING in 9.2.2, then > increase the length in 9.3? No: revisions are reserved for bug fixes. This would be more of a behavior fix and as such would go into a major version. Gavan Schneider wrote: > (Wild speculation) There may be a "sweet spot" using even shorter > identifiers than is the case now, with full disambiguation, which > might improve overall performance. I really don't think the length is really a bottleneck, but others can correct me if it is. Tom Lane wrote: > There's some possible value in having a non-default option to throw > error for overlength names, but TBH I fear that it won't buy all that > much, because people won't think to turn it on when testing. > > Given the historical volume of complaints (to wit, none up to now), > I can't get very excited about changing the behavior here. I think > we're more likely to annoy users than accomplish anything useful. Well, as with many other things, a lack of complaints does not indicate there is no problem. I've certainly seen this problem in the wild before, but have not bothered to file an official bug report or anything. Perhaps my bad, but the problem is out there. How would you feel about switching from NOTICE to WARNING, Tom? That seems to make a lot more sense as we are changing the user's input, which warrants more than a notice IMO. Separately, what are the objections to raising the size limit to 128? - -- Greg Sabino Mullane g...@turnstep.com End Point Corporation http://www.endpoint.com/ PGP Key: 0x14964AC8 201211211525 http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8 -BEGIN PGP SIGNATURE- iEYEAREDAAYFAlCtOYMACgkQvJuQZxSWSsjmEQCfb6GOEs7jwst1ao70L+j8IW5q gNYAn110QAhwjuhUSW3/uexvU+StsfZz =iw6q -END PGP SIGNATURE- -- 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] Prepared Statement Name Truncation
2012/11/21 Greg Sabino Mullane : > > -BEGIN PGP SIGNED MESSAGE- > Hash: RIPEMD160 > > Gavin Flower asks: > >> Would it be appropriate to make it a WARNING in 9.2.2, then >> increase the length in 9.3? > > No: revisions are reserved for bug fixes. This would be more of > a behavior fix and as such would go into a major version. > > Gavan Schneider wrote: >> (Wild speculation) There may be a "sweet spot" using even shorter >> identifiers than is the case now, with full disambiguation, which >> might improve overall performance. > > I really don't think the length is really a bottleneck, but others > can correct me if it is. > > Tom Lane wrote: >> There's some possible value in having a non-default option to throw >> error for overlength names, but TBH I fear that it won't buy all that >> much, because people won't think to turn it on when testing. >> >> Given the historical volume of complaints (to wit, none up to now), >> I can't get very excited about changing the behavior here. I think >> we're more likely to annoy users than accomplish anything useful. > > Well, as with many other things, a lack of complaints does not indicate > there is no problem. I've certainly seen this problem in the wild before, > but have not bothered to file an official bug report or anything. Perhaps > my bad, but the problem is out there. How would you feel about switching > from NOTICE to WARNING, Tom? That seems to make a lot more sense as we > are changing the user's input, which warrants more than a notice IMO. > > Separately, what are the objections to raising the size limit to 128? significantly larger catalog Pavel > > - -- > Greg Sabino Mullane g...@turnstep.com > End Point Corporation http://www.endpoint.com/ > PGP Key: 0x14964AC8 201211211525 > http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8 > -BEGIN PGP SIGNATURE- > > iEYEAREDAAYFAlCtOYMACgkQvJuQZxSWSsjmEQCfb6GOEs7jwst1ao70L+j8IW5q > gNYAn110QAhwjuhUSW3/uexvU+StsfZz > =iw6q > -END PGP SIGNATURE- > > > > > -- > Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-bugs -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
