On Mon, Jan 09, 2006 at 08:50:36PM -0500, Tom Lane wrote:
> pg_sleep seems like a better idea to me too.
ok, renamed again.
> Why is the function defined to take numeric rather than float8?
> float8 is a whole lot easier to work with internally.
ok, changed.
> The proposed regression test seems
Joachim Wieland <[EMAIL PROTECTED]> writes:
> On Mon, Jan 09, 2006 at 08:50:36PM -0500, Tom Lane wrote:
>> The proposed regression test seems unacceptably fragile, as well as
>> rather pointless.
> Why is it fragile?
As your own comment pointed out, the test would "fail" on a heavily
loaded syste
Attached is a WIP patch that adds reference counting for TupleDescs. Two
issues that I ran into while implementing it:
(1) How should the lifetime of a TupleDesc be managed? The existing
ResourceOwner stuff seems to assume that it is managing "per-query"
resources. A TupleDesc will often live beyo
Neil Conway <[EMAIL PROTECTED]> writes:
> (1) How should the lifetime of a TupleDesc be managed? The existing
> ResourceOwner stuff seems to assume that it is managing "per-query"
> resources.
Yeah. I was envisioning two different approaches: for TupleDesc
references from long-lived data structur
On Sun, Jan 08, 2006 at 04:13:01PM +1300, Mark Kirkwood wrote:
> After re-examining the original code, it looks like it was not actually
> vulnerable to a race condition! (it does the UPDATE, then if not found
> will do an INSERT, and handle unique violation with a repeat of the same
> UPDATE -
Jim C. Nasby wrote:
On Sun, Jan 08, 2006 at 04:13:01PM +1300, Mark Kirkwood wrote:
After re-examining the original code, it looks like it was not actually
vulnerable to a race condition! (it does the UPDATE, then if not found
will do an INSERT, and handle unique violation with a repeat of the
On Tue, Jan 10, 2006 at 11:31:13AM +0100, Joachim Wieland wrote:
> No, cancelling the sleep works (at least for Unix). Isn't cancelling
> implemented via a signal that interrupts select() ?
>
> Anyway, I've changed it, removing the ~2000s limit is a good point.
> + while (secs > 1.0)
> + {
Jim C. Nasby wrote:
On Tue, Jan 10, 2006 at 11:31:13AM +0100, Joachim Wieland wrote:
No, cancelling the sleep works (at least for Unix). Isn't cancelling
implemented via a signal that interrupts select() ?
Anyway, I've changed it, removing the ~2000s limit is a good point.
+ while (
Mark Kirkwood wrote:
Jim C. Nasby wrote:
On Sun, Jan 08, 2006 at 04:13:01PM +1300, Mark Kirkwood wrote:
What happens if someone deletes the row between the failed insert and
the second update? :)
In this example the rows in the summary table never get deleted by
DELETE operations on that
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> Jim C. Nasby wrote:
>> Won't this result in a call to pg_sleep with a long sleep time ending up
>> sleeping noticeably longer than requested?
> Looks like it to me.
Something on the order of 1% longer, hm? (1 extra clock tick per second,
probably.) C
Tom Lane said:
> Andrew Dunstan <[EMAIL PROTECTED]> writes:
>> Jim C. Nasby wrote:
>>> Won't this result in a call to pg_sleep with a long sleep time ending
>>> up sleeping noticeably longer than requested?
>
>> Looks like it to me.
>
> Something on the order of 1% longer, hm? (1 extra clock tick
11 matches
Mail list logo
