Boszormenyi Zoltan writes:
> Thanks. I just tried the patch on current GIT HEAD and
> gives some offset warnings but no rejects. Also, it compiles
> without warnings and still works as it should.
> Should I post a new patch that applies cleanly?
Offsets are not a problem --- if you tried to keep
2012-12-08 15:30 keltezéssel, Andres Freund írta:
On 2012-10-18 22:40:15 +0200, Boszormenyi Zoltan wrote:
2012-10-18 20:08 keltezéssel, Tom Lane írta:
Alvaro Herrera writes:
Boszormenyi Zoltan escribió:
this is the latest one, fixing a bug in the accounting
of per-statement lock timeout hand
On 2012-10-18 22:40:15 +0200, Boszormenyi Zoltan wrote:
> 2012-10-18 20:08 keltezéssel, Tom Lane írta:
> >Alvaro Herrera writes:
> >>Boszormenyi Zoltan escribió:
> >>>this is the latest one, fixing a bug in the accounting
> >>>of per-statement lock timeout handling and tweaking
> >>>some comments.
2012-10-18 20:08 keltezéssel, Tom Lane írta:
Alvaro Herrera writes:
Boszormenyi Zoltan escribió:
this is the latest one, fixing a bug in the accounting
of per-statement lock timeout handling and tweaking
some comments.
Tom, are you able to give this patch some more time on this commitfest?
I
Alvaro Herrera writes:
> Boszormenyi Zoltan escribió:
>> this is the latest one, fixing a bug in the accounting
>> of per-statement lock timeout handling and tweaking
>> some comments.
> Tom, are you able to give this patch some more time on this commitfest?
I'm still hoping to get to it, but I'
Boszormenyi Zoltan escribió:
> Hi,
>
> this is the latest one, fixing a bug in the accounting
> of per-statement lock timeout handling and tweaking
> some comments.
Tom, are you able to give this patch some more time on this commitfest?
(If not, I think it would be fair to boot it to CF3; this i
Hi,
this is the latest one, fixing a bug in the accounting
of per-statement lock timeout handling and tweaking
some comments.
Best regards,
Zoltán Böszörményi
--
--
Zoltán Böszörményi
Cybertec Schönig & Schönig GmbH
Gröhrmühlgasse 26
A-2700 Wiener Neustadt, Austr
Hi,
2012-09-22 20:49 keltezéssel, Tom Lane írta:
Boszormenyi Zoltan writes:
new version with a lot more cleanup is attached.
I looked at this patch, and frankly I'm rather dismayed. It's a mess.
I hope you won't find this one a mess. I tried to address all your complaints.
[rather long d
2012-09-22 20:49 keltezéssel, Tom Lane írta:
Boszormenyi Zoltan writes:
new version with a lot more cleanup is attached.
I looked at this patch, and frankly I'm rather dismayed. It's a mess.
Thank you for the kind words. :-)
To start at the bottom level, the changes to PGSemaphoreLock bro
Boszormenyi Zoltan writes:
> new version with a lot more cleanup is attached.
I looked at this patch, and frankly I'm rather dismayed. It's a mess.
To start at the bottom level, the changes to PGSemaphoreLock broke it,
and seem probably unnecessary anyway. As coded, calling the "condition
chec
Hi,
new version with a lot more cleanup is attached.
2012-07-22 22:03 keltezéssel, Boszormenyi Zoltan írta:
Attached is the revised (and a lot leaner, more generic) lock timeout patch,
which introduces new functionality for the timeout registration framework.
The new functionality is called "ex
2012-07-17 06:32 keltezéssel, Alvaro Herrera írta:
Excerpts from Tom Lane's message of vie jul 13 18:23:31 -0400 2012:
Boszormenyi Zoltan writes:
Try SET deadlock_timeout = 0;
Actually, when I try that I get
ERROR: 0 is outside the valid range for parameter "deadlock_timeout" (1 ..
2147483
Excerpts from Tom Lane's message of vie jul 13 18:23:31 -0400 2012:
>
> Boszormenyi Zoltan writes:
> >>> Try SET deadlock_timeout = 0;
>
> Actually, when I try that I get
>
> ERROR: 0 is outside the valid range for parameter "deadlock_timeout" (1 ..
> 2147483647)
>
> So I don't see any bug
2012-07-14 00:36 keltezéssel, Tom Lane írta:
Alvaro Herrera writes:
For what it's worth, I would appreciate it if you would post the lock
timeout patch for the upcoming commitfest.
+1. I think it's reasonable to get the infrastructure patch in now,
but we are running out of time in this commi
Alvaro Herrera writes:
> For what it's worth, I would appreciate it if you would post the lock
> timeout patch for the upcoming commitfest.
+1. I think it's reasonable to get the infrastructure patch in now,
but we are running out of time in this commitfest (and there's still
a lot of patches th
Boszormenyi Zoltan writes:
>>> Try SET deadlock_timeout = 0;
Actually, when I try that I get
ERROR: 0 is outside the valid range for parameter "deadlock_timeout" (1 ..
2147483647)
So I don't see any bug here. The places that are unconditionally doing
"enable_timeout_after(..., DeadlockTimeou
Excerpts from Boszormenyi Zoltan's message of vie jul 13 18:11:27 -0400 2012:
> Regarding the lock_timeout functionality: the patch can be reduced to
> about half of its current size and it would be a lot less intrusive if the
> LockAcquire() callers don't need to report the individual object typ
2012-07-13 23:51 keltezéssel, Tom Lane írta:
Boszormenyi Zoltan writes:
While doing it, I discovered another bug you introduced.
enable_timeout_after(..., 0); would set an alarm instead of ignoring it.
Try SET deadlock_timeout = 0;
Hm. I don't think it's a bug for enable_timeout_after(..., 0)
Boszormenyi Zoltan writes:
> While doing it, I discovered another bug you introduced.
> enable_timeout_after(..., 0); would set an alarm instead of ignoring it.
> Try SET deadlock_timeout = 0;
Hm. I don't think it's a bug for enable_timeout_after(..., 0) to cause
a timeout ... but we'll have to
Boszormenyi Zoltan writes:
> It means that StatementTimeout losts its precision. It would trigger
> in the future counting from "now" instead of counting from
> GetCurrentStatementStartTimestamp().
That is, in fact, better not worse. Note the comment in the existing
code:
* Begin state
2012-07-13 22:32 keltezéssel, Boszormenyi Zoltan írta:
2012-07-12 19:05 keltezéssel, Tom Lane írta:
I haven't really looked at the second patch yet, but at minimum that
will need some rebasing to match the API tweaks here.
Yes, I will do that.
While doing it, I discovered another bug you in
2012-07-12 19:05 keltezéssel, Tom Lane írta:
Here is a revised version of the timeout-infrastructure patch.
I whacked it around quite a bit, notably:
* I decided that the most convenient way to handle the initialization
issue was to combine establishment of the signal handler with resetting
of t
2012-07-11 22:59 keltezéssel, Tom Lane írta:
I wrote:
I'm starting to look at this patch now.
After reading this further, I think that the "sched_next" option is a
bad idea and we should get rid of it. AFAICT, what it is meant to do
is (if !sched_next) automatically do "disable_all_timeouts(tr
2012-07-11 21:47 keltezéssel, Tom Lane írta:
Boszormenyi Zoltan writes:
Attached are the refreshed patches. InitializeTimeouts() can be called
twice and PGSemaphoreTimedLock() returns bool now. This saves
two calls to get_timeout_indicator().
I'm starting to look at this patch now. There are
Here is a revised version of the timeout-infrastructure patch.
I whacked it around quite a bit, notably:
* I decided that the most convenient way to handle the initialization
issue was to combine establishment of the signal handler with resetting
of the per-process variables. So handle_sig_alarm
Alvaro Herrera writes:
> Excerpts from Tom Lane's message of mié jul 11 15:47:47 -0400 2012:
>> ... that means we need a pretty consistent scheme for
>> where to call InitializeTimeouts. But we already have the same issue
>> with respect to on_proc_exit callbacks, so we can just add
>> Initializ
I wrote:
> I'm starting to look at this patch now.
After reading this further, I think that the "sched_next" option is a
bad idea and we should get rid of it. AFAICT, what it is meant to do
is (if !sched_next) automatically do "disable_all_timeouts(true)" if
the particular timeout happens to fire
Excerpts from Tom Lane's message of mié jul 11 15:47:47 -0400 2012:
>
> Boszormenyi Zoltan writes:
> > Attached are the refreshed patches. InitializeTimeouts() can be called
> > twice and PGSemaphoreTimedLock() returns bool now. This saves
> > two calls to get_timeout_indicator().
>
> I'm start
Boszormenyi Zoltan writes:
> Attached are the refreshed patches. InitializeTimeouts() can be called
> twice and PGSemaphoreTimedLock() returns bool now. This saves
> two calls to get_timeout_indicator().
I'm starting to look at this patch now. There are a number of cosmetic
things I don't care f
2012-07-04 17:25 keltezéssel, Alvaro Herrera írta:
Excerpts from Boszormenyi Zoltan's message of mié jul 04 07:03:44 -0400 2012:
2012-07-03 23:38 keltezéssel, Alvaro Herrera írta:
I don't understand why PGSemaphoreTimedLock() is not broken. I mean
surely you need a bool return to let the calle
Excerpts from Boszormenyi Zoltan's message of mié jul 04 07:03:44 -0400 2012:
>
> 2012-07-03 23:38 keltezéssel, Alvaro Herrera írta:
> >
> > I don't understand why PGSemaphoreTimedLock() is not broken. I mean
> > surely you need a bool return to let the caller know whether the
> > acquisition su
Excerpts from Boszormenyi Zoltan's message of mié jul 04 06:32:46 -0400 2012:
> 2012-07-04 12:09 keltezéssel, Boszormenyi Zoltan írta:
> > You just broke initdb with this cleanup. :-)
Ouch.
> > initdb starts postgres --single, that doesn't do BackendInitialize(),
> > only PostgresMain(). So, yo
2012-07-03 23:38 keltezéssel, Alvaro Herrera írta:
I don't understand why PGSemaphoreTimedLock() is not broken. I mean
surely you need a bool return to let the caller know whether the
acquisition succeeded or failed?
Well, this is the same interface PGSemaphoreTryLock() uses.
By this reasonin
2012-07-04 12:09 keltezéssel, Boszormenyi Zoltan írta:
2012-07-03 23:31 keltezéssel, Alvaro Herrera írta:
Excerpts from Boszormenyi Zoltan's message of vie jun 29 14:30:28 -0400 2012:
Does anyone have a little time to look at the latest timeout framework
with the registration interface and the
2012-07-03 23:31 keltezéssel, Alvaro Herrera írta:
Excerpts from Boszormenyi Zoltan's message of vie jun 29 14:30:28 -0400 2012:
Does anyone have a little time to look at the latest timeout framework
with the registration interface and the 2nd patch too? I am at work
until Friday next week, aft
I don't understand why PGSemaphoreTimedLock() is not broken. I mean
surely you need a bool return to let the caller know whether the
acquisition succeeded or failed? AFAICS you are relying on
get_timeout_indicator() but this seems to me the wrong thing to do ...
(not to mention how ugly it is t
Excerpts from Boszormenyi Zoltan's message of vie jun 29 14:30:28 -0400 2012:
> Does anyone have a little time to look at the latest timeout framework
> with the registration interface and the 2nd patch too? I am at work
> until Friday next week, after that I will be on vacation for two weeks.
> J
2012-06-27 10:34 keltezéssel, Boszormenyi Zoltan írta:
2012-06-26 18:49 keltezéssel, Alvaro Herrera írta:
Excerpts from Boszormenyi Zoltan's message of mar jun 26 12:43:34 -0400 2012:
So, should I keep the enum TimeoutName? Are global variables for
keeping dynamically assigned values preferred
Excerpts from Boszormenyi Zoltan's message of mar jun 26 12:43:34 -0400 2012:
> So, should I keep the enum TimeoutName? Are global variables for
> keeping dynamically assigned values preferred over the enum?
> Currently we have 5 timeout sources in total, 3 of them are used by
> regular backends,
2012-06-26 18:12 keltezéssel, Alvaro Herrera írta:
Excerpts from Boszormenyi Zoltan's message of mar jun 26 03:59:06 -0400 2012:
2012-06-26 06:59 keltezéssel, Alvaro Herrera írta:
I cleaned up the framework patch a bit. My version's attached. Mainly,
returning false for failure in some code p
Excerpts from Boszormenyi Zoltan's message of mar jun 26 03:59:06 -0400 2012:
>
> 2012-06-26 06:59 keltezéssel, Alvaro Herrera írta:
> > I cleaned up the framework patch a bit. My version's attached. Mainly,
> > returning false for failure in some code paths that are only going to
> > have the c
Robert Haas writes:
> On Tue, Jun 26, 2012 at 8:03 AM, Boszormenyi Zoltan wrote:
>> I know, but it doesn't feel right to "register" static functionality.
> We do it elsewhere. The overhead is pretty minimal compared to other
> things we already do during startup, and avoiding the need for the
>
On Tue, Jun 26, 2012 at 8:03 AM, Boszormenyi Zoltan wrote:
> I know, but it doesn't feel right to "register" static functionality.
We do it elsewhere. The overhead is pretty minimal compared to other
things we already do during startup, and avoiding the need for the
array to have a fixed-size se
2012-06-26 13:50 keltezéssel, Robert Haas írta:
On Tue, Jun 26, 2012 at 3:59 AM, Boszormenyi Zoltan wrote:
Well, I can make the registration interface similar to how LWLocks
are treated, but that doesn't avoid modification of the base_timeouts
array in case a new internal use case arises. Say:
On Tue, Jun 26, 2012 at 3:59 AM, Boszormenyi Zoltan wrote:
> Well, I can make the registration interface similar to how LWLocks
> are treated, but that doesn't avoid modification of the base_timeouts
> array in case a new internal use case arises. Say:
>
> #define USER_TIMEOUTS 4
>
> int n_t
2012-06-26 06:59 keltezéssel, Alvaro Herrera írta:
I cleaned up the framework patch a bit. My version's attached. Mainly,
returning false for failure in some code paths that are only going to
have the caller elog(FATAL) is rather pointless -- it seems much better
to just have the code itself do
I cleaned up the framework patch a bit. My version's attached. Mainly,
returning false for failure in some code paths that are only going to
have the caller elog(FATAL) is rather pointless -- it seems much better
to just have the code itself do the elog(FATAL). In any case, I
searched for report
Excerpts from Boszormenyi Zoltan's message of mar jun 19 12:44:04 -0400 2012:
> OK, all 4 Check* functions are now moved back into proc.c,
> nothing outside of timeout.c touches anything in it. New patches
> are attached.
Yeah, I like this one better, thanks.
It seems to me that the "check" fun
Excerpts from Boszormenyi Zoltan's message of mar jun 19 04:44:35 -0400 2012:
>
> 2012-06-18 19:46 keltezéssel, Alvaro Herrera írta:
> > Excerpts from Boszormenyi Zoltan's message of vie may 11 03:54:13 -0400
> > 2012:
> >> Hi,
> >>
> >> another rebasing and applied the GIT changes in
> >> ada8f
2012-06-18 19:46 keltezéssel, Alvaro Herrera írta:
Excerpts from Boszormenyi Zoltan's message of vie may 11 03:54:13 -0400 2012:
Hi,
another rebasing and applied the GIT changes in
ada8fa08fc6cf5f199b6df935b4d0a730aaa4fec to the
Windows implementation of PGSemaphoreTimedLock.
Hi,
I gave the f
BTW it doesn't seem that datatype/timestamp.h is really necessary in
timeout.h.
--
Álvaro Herrera
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make c
Excerpts from Boszormenyi Zoltan's message of vie may 11 03:54:13 -0400 2012:
> Hi,
>
> another rebasing and applied the GIT changes in
> ada8fa08fc6cf5f199b6df935b4d0a730aaa4fec to the
> Windows implementation of PGSemaphoreTimedLock.
Hi,
I gave the framework patch a look. One thing I'm not s
2012-04-23 15:08 keltezéssel, Marc Cousin írta:
On Mon, 2012-04-23 at 10:53 +0200, Boszormenyi Zoltan wrote:
2012-04-10 09:02 keltezéssel, Boszormenyi Zoltan írta:
2012-04-06 14:47 keltezéssel, Cousin Marc írta:
On 05/04/12 08:02, Boszormenyi Zoltan wrote:
2012-04-04 21:30 keltezéssel, Alvaro
On Mon, 2012-04-23 at 10:53 +0200, Boszormenyi Zoltan wrote:
> 2012-04-10 09:02 keltezéssel, Boszormenyi Zoltan írta:
> > 2012-04-06 14:47 keltezéssel, Cousin Marc írta:
> >> On 05/04/12 08:02, Boszormenyi Zoltan wrote:
> >>> 2012-04-04 21:30 keltezéssel, Alvaro Herrera írta:
> I think this pa
2012-04-08 11:24 keltezéssel, Boszormenyi Zoltan írta:
2012-04-06 14:47 keltezéssel, Cousin Marc írta:
On 05/04/12 08:02, Boszormenyi Zoltan wrote:
2012-04-04 21:30 keltezéssel, Alvaro Herrera írta:
I think this patch is doing two things: first touching infrastructure
stuff and then adding loc
2012-04-06 14:47 keltezéssel, Cousin Marc írta:
On 05/04/12 08:02, Boszormenyi Zoltan wrote:
2012-04-04 21:30 keltezéssel, Alvaro Herrera írta:
I think this patch is doing two things: first touching infrastructure
stuff and then adding lock_timeout on top of that. Would it work to
split the pa
On 05/04/12 08:02, Boszormenyi Zoltan wrote:
> 2012-04-04 21:30 keltezéssel, Alvaro Herrera írta:
>> I think this patch is doing two things: first touching infrastructure
>> stuff and then adding lock_timeout on top of that. Would it work to
>> split the patch in two pieces?
>>
>
> Sure. Attached
I think this patch is doing two things: first touching infrastructure
stuff and then adding lock_timeout on top of that. Would it work to
split the patch in two pieces?
--
Álvaro Herrera
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7
2012-04-04 17:12 keltezéssel, Boszormenyi Zoltan írta:
2012-04-04 16:22 keltezéssel, Boszormenyi Zoltan írta:
2012-04-04 15:17 keltezéssel, Boszormenyi Zoltan írta:
Hi,
2012-04-04 12:30 keltezéssel, Boszormenyi Zoltan írta:
Hi,
attached is a patch to implement a framework to simplify and
cor
59 matches
Mail list logo
