Robert Haas wrote:
>> I wonder whether this patch shouldn't be rejected with a request
>> that the timeout framework be submitted to the next CF.
> I think "Returned with Feedback" would be more appropriate than
> "Rejected", since we're asking for a rework, rather than saying -
> we just don'
On Mon, Aug 2, 2010 at 3:09 PM, Kevin Grittner
wrote:
> Marc Cousin wrote:
>
>> This time, it's this case that doesn't work :
>
>> I really feel that the timeout framework is the way to go here.
>
> Since Zoltán also seems to feel this way:
>
> http://archives.postgresql.org/message-id/4c516c3a.6
Boszormenyi Zoltan wrote:
> Kevin Grittner írta:
>> I wonder whether this patch shouldn't be rejected with a request
>> that the timeout framework be submitted to the next CF. Does
>> anyone feel this approach (without the framework) should be
>> pursued further?
>
> I certainly think so, the
Hi,
Kevin Grittner írta:
> Marc Cousin wrote:
>
>
>> This time, it's this case that doesn't work :
>>
>
>
>> I really feel that the timeout framework is the way to go here.
>>
>
> Since Zoltán also seems to feel this way:
>
> http://archives.postgresql.org/message-id/4c516
Marc Cousin wrote:
> This time, it's this case that doesn't work :
> I really feel that the timeout framework is the way to go here.
Since Zoltán also seems to feel this way:
http://archives.postgresql.org/message-id/4c516c3a.6090...@cybertec.at
I wonder whether this patch shouldn't be r
The Monday 02 August 2010 13:59:59, Boszormenyi Zoltan wrote :
> >
> > Also, I made sure that only one or two timeout causes (one of
> > deadlock_timeout
> > and lock_timeout in the first case or statement_timeout plus one of the
> > other two)
> > can be active at a time.
>
> A little clarificati
Boszormenyi Zoltan írta:
> Marc Cousin írta:
>
>> The Thursday 29 July 2010 13:55:38, Boszormenyi Zoltan wrote :
>>
>>
>>> I fixed this by adding CheckLockTimeout() function that works like
>>> CheckStatementTimeout() and ensuring that the same start time is
>>> used for both deadlock_ti
Marc Cousin írta:
> The Thursday 29 July 2010 13:55:38, Boszormenyi Zoltan wrote :
>
>> I fixed this by adding CheckLockTimeout() function that works like
>> CheckStatementTimeout() and ensuring that the same start time is
>> used for both deadlock_timeout and lock_timeout if both are active.
>>
Excerpts from Boszormenyi Zoltan's message of jue jul 29 07:55:38 -0400 2010:
> Hi,
>
> Marc Cousin írta:
> > Hi, I've been reviewing this patch for the last few days. Here it is :
> >
> ...
> > * Are there dangers?
> > As it is a guc, it could be set globally, is that a danger ?
> >
>
>
The Thursday 29 July 2010 13:55:38, Boszormenyi Zoltan wrote :
> I fixed this by adding CheckLockTimeout() function that works like
> CheckStatementTimeout() and ensuring that the same start time is
> used for both deadlock_timeout and lock_timeout if both are active.
> The preference of errors if
Hi,
first, thanks for the review.
> Hi, I've been reviewing this patch for the last few days. Here it is :
>
> * Submission review
> * Is the patch in context diff format?
> Yes
>
> * Does it apply cleanly to the current CVS HEAD?
> Yes
>
> * Does it include reasonable tests, necessary doc
Hi, I've been reviewing this patch for the last few days. Here it is :
* Submission review
* Is the patch in context diff format?
Yes
* Does it apply cleanly to the current CVS HEAD?
Yes
* Does it include reasonable tests, necessary doc patches, etc?
Doc patches are there.
There are no reg
Hi,
Tom Lane írta:
> Boszormenyi Zoltan writes:
>
>> You expressed stability concerns coming from this patch.
>> Were these concerns because of locks timing out making
>> things fragile or because of general feelings about introducing
>> such a patch at the end of the release cycle? I was thin
Boszormenyi Zoltan writes:
> You expressed stability concerns coming from this patch.
> Were these concerns because of locks timing out making
> things fragile or because of general feelings about introducing
> such a patch at the end of the release cycle? I was thinking
> about the former, hence
Tom Lane írta:
> Robert Haas writes:
>
>> On Thu, Jan 21, 2010 at 9:41 AM, Boszormenyi Zoltan wrote:
>>
>>> I would like a mini-review on the change I made in the latest
>>> patch by introducing the validator function. Is it enough
>>> to check for
>>>(source == PGC_S_DEFAULT || sourc
Robert Haas writes:
> On Thu, Jan 21, 2010 at 10:59 AM, Tom Lane wrote:
>> Why is this a good idea at all? I can easily see somebody feeling that
>> he'd like autovacuums to fail rather than block on locks for a long
>> time, for example.
> What I can see happening is someone setting this GUC i
On Thu, Jan 21, 2010 at 10:59 AM, Tom Lane wrote:
> Robert Haas writes:
>> On Thu, Jan 21, 2010 at 9:41 AM, Boszormenyi Zoltan wrote:
>>> I would like a mini-review on the change I made in the latest
>>> patch by introducing the validator function. Is it enough
>>> to check for
>>> (source ==
Robert Haas writes:
> On Thu, Jan 21, 2010 at 9:41 AM, Boszormenyi Zoltan wrote:
>> I would like a mini-review on the change I made in the latest
>> patch by introducing the validator function. Is it enough
>> to check for
>> (source == PGC_S_DEFAULT || source == PGC_S_SESSION)
>> to ensure on
On Thu, Jan 21, 2010 at 9:41 AM, Boszormenyi Zoltan wrote:
> Thanks. So it means that this patch will considered for 9.1.
Yeah, I think that's best.
> I would like a mini-review on the change I made in the latest
> patch by introducing the validator function. Is it enough
> to check for
> (so
Hi,
Robert Haas írta:
> 2010/1/21 Boszormenyi Zoltan :
>
>> Tom Lane írta:
>>
>>> Robert Haas writes:
>>>
I think that it is a very bad idea to implement this feature in a way
that is not 100% portable.
>>> Agreed, this is not acceptable. If there were no p
2010/1/21 Boszormenyi Zoltan :
> Tom Lane írta:
>> Robert Haas writes:
>>> I think that it is a very bad idea to implement this feature in a way
>>> that is not 100% portable.
>>
>> Agreed, this is not acceptable. If there were no possible way to
>> implement the feature portably, we *might* cons
Tom Lane írta:
> Robert Haas writes:
>
>> 2010/1/20 Boszormenyi Zoltan :
>>
>>> Attached with the proposed modification to lift the portability concerns.
>>>
>
>
>> I think that it is a very bad idea to implement this feature in a way
>> that is not 100% portable.
>>
>
> Agr
Robert Haas writes:
> 2010/1/20 Boszormenyi Zoltan :
>> Attached with the proposed modification to lift the portability concerns.
> I think that it is a very bad idea to implement this feature in a way
> that is not 100% portable.
Agreed, this is not acceptable. If there were no possible way to
2010/1/20 Boszormenyi Zoltan :
> Attached with the proposed modification to lift the portability concerns.
> Fixed the missing check for get_rel_name() and one typo ("transation")
> Introduced checks for semtimedop() and sem_timedwait() in configure.in
> and USE_LOCK_TIMEOUT in port.h depending on
Hi,
I wrote:
> Okay, after reading google it seems you're right that OS X lacks
> sem_timedwait().
Jaime Casanova írta:
> If that's the case then others timeouts should be failing on os x, no?
> But i have never hear that
>
among others, I found this reference on the missing
sem_timedwait() f
If that's the case then others timeouts should be failing on os x, no?
But i have never hear that
2010/1/20, Boszormenyi Zoltan :
> Boszormenyi Zoltan írta:
>> Tom Lane írta:
>>
>>> Greg Stark writes:
>>>
>>>
we already have statement timeout it seems the natural easy to implement
this
Boszormenyi Zoltan írta:
> Tom Lane írta:
>
>> Greg Stark writes:
>>
>>
>>> we already have statement timeout it seems the natural easy to implement
>>> this is with more hairy logic to calculate the timeout until the next of the
>>> three timeouts should fire and set sigalarm. I sympat
Tom Lane írta:
> Greg Stark writes:
>
>> we already have statement timeout it seems the natural easy to implement
>> this is with more hairy logic to calculate the timeout until the next of the
>> three timeouts should fire and set sigalarm. I sympathize with whoever tries
>> to work that throu
Tom Lane írta:
> Boszormenyi Zoltan writes:
>
>> [ 5-pg85-locktimeout-14-ctxdiff.patch ]
>>
>
> I took a quick look at this. I am not qualified to review the Win32
> implementation of PGSemaphoreTimedLock, but I am afraid that both of
> the other ones are nonstarters on portability ground
Greg Stark writes:
> we already have statement timeout it seems the natural easy to implement
> this is with more hairy logic to calculate the timeout until the next of the
> three timeouts should fire and set sigalarm. I sympathize with whoever tries
> to work that through though, the logic is ha
we already have statement timeout it seems the natural easy to implement
this is with more hairy logic to calculate the timeout until the next of the
three timeouts should fire and set sigalarm. I sympathize with whoever tries
to work that through though, the logic is hairy enough with just the two
On Tue, Jan 19, 2010 at 7:10 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Tue, Jan 19, 2010 at 6:40 PM, Tom Lane wrote:
>>> A larger question, which I think has been raised before but I have not
>>> seen a satisfactory answer for, is whether the system will behave sanely
>>> at all with this
Robert Haas writes:
> On Tue, Jan 19, 2010 at 6:40 PM, Tom Lane wrote:
>> A larger question, which I think has been raised before but I have not
>> seen a satisfactory answer for, is whether the system will behave sanely
>> at all with this type of patch in place.
> I am not too sure what you th
On Tue, Jan 19, 2010 at 6:40 PM, Tom Lane wrote:
> A larger question, which I think has been raised before but I have not
> seen a satisfactory answer for, is whether the system will behave sanely
> at all with this type of patch in place. I don't really think that a
> single lock timeout applica
Boszormenyi Zoltan writes:
> [ 5-pg85-locktimeout-14-ctxdiff.patch ]
I took a quick look at this. I am not qualified to review the Win32
implementation of PGSemaphoreTimedLock, but I am afraid that both of
the other ones are nonstarters on portability grounds. sem_timedwait()
and semtimedop() d
Boszormenyi Zoltan escribió:
> May I change the interface of XactLockTableWait()
> and MultiXactIdWait()? Not the return value, only the number
> of parameters. E.g. with the relation name, like in the attached
> patch. This solves the problem of bad error messages...
> What do you think?
We alre
Jaime Casanova írta:
> 2010/1/15 Boszormenyi Zoltan :
>
>> Jaime Casanova írta:
>>
>>> 2010/1/13 Boszormenyi Zoltan :
>>>
>>>
> Your smaller patch is attached, with the above strangeness. :-)
>
>
>
>
> ok, the patch is more simpler than before and seems to
2010/1/15 Boszormenyi Zoltan :
> Jaime Casanova írta:
>> 2010/1/13 Boszormenyi Zoltan :
>>
Your smaller patch is attached, with the above strangeness. :-)
ok, the patch is more simpler than before and seems to be doing things right...
it passes regression tests and my own tests...
Jaime Casanova írta:
> 2010/1/13 Boszormenyi Zoltan :
>
>>> Your smaller patch is attached, with the above strangeness. :-)
>>>
>>>
>
> you still had to add this parameter to the postgresql.conf.sample in
> the section about lock management
>
Attached with the required change.
Thanks
2010/1/13 Boszormenyi Zoltan :
>>
>> Your smaller patch is attached, with the above strangeness. :-)
>>
you still had to add this parameter to the postgresql.conf.sample in
the section about lock management
--
Atentamente,
Jaime Casanova
Soporte y capacitación de PostgreSQL
Asesoría y desarrollo
Boszormenyi Zoltan írta:
> Tom Lane írta:
>
>> Boszormenyi Zoltan writes:
>>
>>
>>> Tom Lane írta:
>>>
>>>
If this patch is touching those parts of relcache.c, it probably needs
rethinking.
>>
>>
>>> What I did there is to check th
Tom Lane írta:
> Boszormenyi Zoltan writes:
>
>> Tom Lane írta:
>>
>>> If this patch is touching those parts of relcache.c, it probably needs
>>> rethinking.
>>>
>
>
>> What I did there is to check the return value of LockRelationOid()
>> and also elog(PANIC) if the lock wasn't a
Boszormenyi Zoltan writes:
> Tom Lane írta:
>> If this patch is touching those parts of relcache.c, it probably needs
>> rethinking.
> What I did there is to check the return value of LockRelationOid()
> and also elog(PANIC) if the lock wasn't available.
> Does it need rethinking?
Yes. What you
2010/1/13 Boszormenyi Zoltan :
>>
>> well, i actually think that PANIC is too high for this...
>>
>
> Well, it tries to lock and then open a critical system index.
> Failure to open it has PANIC, it seemed appropriate to use
> the same error level if the lock failure case.
>
if you try to open a c
Jaime Casanova írta:
> 2010/1/13 Boszormenyi Zoltan :
>
>> Tom Lane írta:
>>
>>> If this patch is touching those parts of relcache.c, it probably needs
>>> rethinking.
>>>
>>>
>> What I did there is to check the return value of LockRelationOid()
>>
>
> the hunk was because a dif
Jaime Casanova írta:
> 2010/1/13 Boszormenyi Zoltan :
>
>> Tom Lane írta:
>>
>>> If this patch is touching those parts of relcache.c, it probably needs
>>> rethinking.
>>>
>>>
>> What I did there is to check the return value of LockRelationOid()
>>
>
> the hunk was because a dif
2010/1/13 Boszormenyi Zoltan :
> Tom Lane írta:
>>
>> If this patch is touching those parts of relcache.c, it probably needs
>> rethinking.
>>
>
> What I did there is to check the return value of LockRelationOid()
the hunk was because a diference in the position (i guess patch accept
a hunk of rea
Tom Lane írta:
> Jaime Casanova writes:
>
>> it has a hunk failed when trying to apply i guess it's because of
>> Tom's refactor of relcache.c
>>
>
> If this patch is touching those parts of relcache.c, it probably needs
> rethinking.
>
> regards, tom lane
>
>
The
Jaime Casanova writes:
> it has a hunk failed when trying to apply i guess it's because of
> Tom's refactor of relcache.c
If this patch is touching those parts of relcache.c, it probably needs
rethinking.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-h
49 matches
Mail list logo
