Re: [PATCHES] [GENERAL] dropping role w/dependent objects
On Tuesday 01 May 2007 9:34 pm, Tom Lane wrote: > "Ed L." <[EMAIL PROTECTED]> writes: > > [ enlarge MAX_REPORTED_DEPS to 2000 ] > > I was about to apply this, but stopped to reflect that it is > probably not such a hot idea. My concern is that enormously > long error message detail fields are likely to break client > software, particularly GUI clients. A poor (e.g., truncated) > display isn't unlikely, and a crash not entirely out of the > question. Moreover, who's to say that 2000 is enough lines to > cover all cases? And if it's not, aren't you faced with an > even bigger problem? > > Perhaps a better solution is to keep MAX_REPORTED_DEPS where > it is, and arrange that when it's exceeded, the *entire* list > of dependencies gets reported to the postmaster log; we can > expect that that will work. We still send the same > just-the-count message to the client. We could add a hint > suggesting to look in the postmaster log for the details. This > would require some refactoring of checkSharedDependencies's > API, I suppose, but doesn't seem especially difficult. Fair enough. Something, anything, in the server log would suffice to identify the problem specifics which are now hidden. Unfortunately, I won't get to it anytime soon. Ed ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [PATCHES] [GENERAL] dropping role w/dependent objects
"Ed L." <[EMAIL PROTECTED]> writes: > [ enlarge MAX_REPORTED_DEPS to 2000 ] I was about to apply this, but stopped to reflect that it is probably not such a hot idea. My concern is that enormously long error message detail fields are likely to break client software, particularly GUI clients. A poor (e.g., truncated) display isn't unlikely, and a crash not entirely out of the question. Moreover, who's to say that 2000 is enough lines to cover all cases? And if it's not, aren't you faced with an even bigger problem? Perhaps a better solution is to keep MAX_REPORTED_DEPS where it is, and arrange that when it's exceeded, the *entire* list of dependencies gets reported to the postmaster log; we can expect that that will work. We still send the same just-the-count message to the client. We could add a hint suggesting to look in the postmaster log for the details. This would require some refactoring of checkSharedDependencies's API, I suppose, but doesn't seem especially difficult. regards, tom lane ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [PATCHES] [HACKERS] autovacuum does not start in HEAD
ITAGAKI Takahiro wrote:
> I wrote:
> > I found that autovacuum launcher does not launch any workers in HEAD.
>
> The attached autovacuum-fix.patch could fix the problem. I changed
> to use 'greater or equal' instead of 'greater' at the decision of
> next autovacuum target.
I developed a different fix, which is possible due to the addition of
TimestampDifferenceExceeds to the TimestampTz API. (Thanks Tom).
It continues to work for me here, but please confirm that it fixes the
bug you reported -- I don't have a low-resolution platform handy.
--
Alvaro Herrerahttp://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
Index: src/backend/postmaster/autovacuum.c
===
RCS file: /home/alvherre/Code/cvs/pgsql/src/backend/postmaster/autovacuum.c,v
retrieving revision 1.42
diff -c -p -r1.42 autovacuum.c
*** src/backend/postmaster/autovacuum.c 18 Apr 2007 16:44:18 - 1.42
--- src/backend/postmaster/autovacuum.c 2 May 2007 01:53:02 -
*** AutoVacLauncherMain(int argc, char *argv
*** 549,556
if (can_launch && AutoVacuumShmem->av_startingWorker != INVALID_OFFSET)
{
- long secs;
- int usecs;
WorkerInfo worker = (WorkerInfo) MAKE_PTR(AutoVacuumShmem->av_startingWorker);
if (current_time == 0)
--- 549,554
*** AutoVacLauncherMain(int argc, char *argv
*** 566,576
* startingWorker pointer before trying to connect; only low-level
* problems, like fork() failure, can get us here.
*/
! TimestampDifference(worker->wi_launchtime, current_time,
! &secs, &usecs);
!
! /* ignore microseconds, as they cannot make any difference */
! if (secs > autovacuum_naptime)
{
LWLockRelease(AutovacuumLock);
LWLockAcquire(AutovacuumLock, LW_EXCLUSIVE);
--- 564,571
* startingWorker pointer before trying to connect; only low-level
* problems, like fork() failure, can get us here.
*/
! if (TimestampDifferenceExceeds(worker->wi_launchtime, current_time,
! autovacuum_naptime * 1000))
{
LWLockRelease(AutovacuumLock);
LWLockAcquire(AutovacuumLock, LW_EXCLUSIVE);
*** AutoVacLauncherMain(int argc, char *argv
*** 618,630
if (elem != NULL)
{
avl_dbase *avdb = DLE_VAL(elem);
- long secs;
- int usecs;
-
- TimestampDifference(current_time, avdb->adl_next_worker, &secs, &usecs);
! /* do we have to start a worker? */
! if (secs <= 0 && usecs <= 0)
launch_worker(current_time);
}
else
--- 613,625
if (elem != NULL)
{
avl_dbase *avdb = DLE_VAL(elem);
! /*
! * launch a worker if next_worker is right now or it is in the
! * past
! */
! if (TimestampDifferenceExceeds(avdb->adl_next_worker,
! current_time, 0))
launch_worker(current_time);
}
else
*** do_start_worker(void)
*** 1037,1058
if (dbp->adl_datid == tmp->adw_datid)
{
- TimestampTz curr_plus_naptime;
- TimestampTz next = dbp->adl_next_worker;
-
- curr_plus_naptime =
- TimestampTzPlusMilliseconds(current_time,
- autovacuum_naptime * 1000);
-
/*
! * What we want here if to skip if next_worker falls between
* the current time and the current time plus naptime.
*/
! if (timestamp_cmp_internal(current_time, next) > 0)
! skipit = false;
! else if (timestamp_cmp_internal(next, curr_plus_naptime) > 0)
! skipit = false;
! else
skipit = true;
break;
--- 1032,1046
if (dbp->adl_datid == tmp->adw_datid)
{
/*
! * Skip this database if its next_worker value falls between
* the current time and the current time plus naptime.
*/
! if (TimestampDifferenceExceeds(current_time,
! dbp->adl_next_worker, 0) &&
! !TimestampDifferenceExceeds(current_time,
! dbp->adl_next_worker,
! autovacuum_naptime * 1000))
skipit = true;
break;
---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
Re: [PATCHES] MSVC installation wrapper script
Dave Page wrote: > Per previous discussion with Magnus, the attached batch file (rename to > install.bat) is a wrapper script for the MSVC installer. It sets up the > environment before installing (to allow zic.exe to run properly), and > removes the need to explicitly call perl on the command line. > > This should be added to src/tools/msvc Applied. I took out the check for src\tools\msvc, since the script in general doesn't work outside the msvc directory. (it needs to be in the same dir as install.pl). We could fix that, but I don't really see the point, so I kept it simple :-) //Magnus ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
[PATCHES] MSVC installation wrapper script
Per previous discussion with Magnus, the attached batch file (rename to install.bat) is a wrapper script for the MSVC installer. It sets up the environment before installing (to allow zic.exe to run properly), and removes the need to explicitly call perl on the command line. This should be added to src/tools/msvc Regards, Dave. @echo off REM $PostgreSQL$ if NOT "%1"=="" GOTO RUN_INSTALL echo Invalid command line options. echo Usage: "install.bat " echo. exit /b 1 :RUN_INSTALL SETLOCAL if exist src\tools\msvc\buildenv.bat call src\tools\msvc\buildenv.bat if exist buildenv.bat call buildenv.bat perl install.pl "%1" exit /b %ERRORLEVEL% ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [PATCHES] plpgpsm
Hello, I actualised sql/psm patch: added: * last Tom's plpgsql patches (some fixes and enum support) * scrollable cursor's support new version is on http://www.pgsql.cz/patches/plpgpsm0501.diff.gz Regard Pavel Stehule Your patch has been added to the PostgreSQL unapplied patches list at: http://momjian.postgresql.org/cgi-bin/pgpatches It will be applied as soon as one of the PostgreSQL committers reviews and approves it. --- _ Chcete sdilet sve obrazky a hudbu s prateli? http://messenger.msn.cz/ ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
