Re: autovauum integration patch: Attempt #4
| От | Matthew T. O'Connor |
|---|---|
| Тема | Re: autovauum integration patch: Attempt #4 |
| Дата | |
| Msg-id | 410FAD27.6090207@zeut.net обсуждение исходный текст |
| Ответ на | Re: autovauum integration patch: Attempt #4 (Tom Lane <tgl@sss.pgh.pa.us>) |
| Ответы |
Re: autovauum integration patch: Attempt #4
|
| Список | pgsql-patches |
Tom Lane wrote:
> "Matthew T. O'Connor" <matthew@zeut.net> writes:
>>I agree. The thought had crossed my mind that autovac should shut down
>>first, but I'm really not sure how to make that happen.
>
> You have to issue the kill() when the postmaster first receives the
> shutdown signal, rather than waiting till after all backends exit.
> Also, there needs to be some provision for sending a SIGINT to whichever
> backend is actually running an autovac-commanded vacuum. One way to do
> this is for autovac, when it gets the SIGUSR2, to turn around and do
> PQqueryCancel (sp?) against the active connection. I'm not sure offhand
> how to shoehorn that into your code.
Ok, I'll see what I can do about this.
>>Right, I didn't want to use GUC vars for this. As I said in the other
>>email, I will take a whack at using a new special .autovacpasswd file in
>>the $PGDATA dir.
>
> I'd go with autovac.parms or some such. $PGDATA isn't anyone's home dir
> (normally) and there's no need to tuck config files out of sight.
Ok. I assume I can crib from the code that uses the .pgpass file.
> On platforms with no local ident support, that would equate to making
> autovac unusable. I think it's a must-fix.
Ok.
>>I looked into changing my elog calls to ereport, but ....
>
> DBAs are ordinary users in this context. I think elog is okay for stuff
> that only a developer would ever see, but DBAs want translated messages.
Oh, I didn't understand that ereport provided translatable messages
whereas elog does not. That makes sense. I'll change the elog calls.
>>Ok, some of this cruft is related to its roots as a stand-alone app. I
>>will fix this too. So the correct answer here is to skip the
>>elog/ereport and call proc_exit(), or should I just downgrade the elog
>>to NOTICE and then call proc_exit()? Lemme know and I'll fix.
>
> Actually what I was thinking of was removing the sigsetjmp block (which
> would need updated anyway if you keep it). That would cause elog(ERROR)
> to go to proc_exit itself. You cannot avoid the issue by not using
> elog(ERROR), because you are (or will be) calling subroutines that might
> use it.
Ok, If I remove the sigsetjmp block, is there anything else I need to
do, or can I just rip out everything between the {}'s?
Thanks again for the comments. I have a full plate at work today, but
I'm going to try to leave at five and spend the evening fixing as much
of this as possible.
Matthew
В списке pgsql-patches по дате отправления: