Gah, hit wrong key combination and the email sent early.
Anyway, after that 'sleep' mess at the bottom is:
T1 or T2: Sleeping too long -- lets run deadlock detection code
T1 or T2: Kill off random participant of deadlock.
The other participant is then allowed to continue their work.
On Sat, 2003
On Fri, Feb 21, 2003 at 06:15:31PM -0500, Tom Lane wrote:
> "Ross J. Reedstrom" <[EMAIL PROTECTED]> writes:
>
> I'm worried about cases like "Africa/Benin" for places that just happen
> to be on the prime meridian, but don't call their time GMT or UTC.
> Looking at a globe, it also seems possible
On Fri, Feb 21, 2003 at 05:45:53PM -0600, Ross J. Reedstrom wrote:
> On Fri, Feb 21, 2003 at 06:15:31PM -0500, Tom Lane wrote:
> > "Ross J. Reedstrom" <[EMAIL PROTECTED]> writes:
>
> >
> > I'm worried about cases like "Africa/Benin" for places that just happen
> > to be on the prime meridian, but
On Thu, Feb 20, 2003 at 04:19:21PM -0500, Tom Lane wrote:
> "Ross J. Reedstrom" <[EMAIL PROTECTED]> writes:
> > On Thu, Feb 20, 2003 at 03:21:09PM -0500, Tom Lane wrote:
> >> Provide a portable way of getting libc to tell us whether it likes TZ,
> >> and I'll be glad to fix this.
>
> > Dang that l
Going through the issues in doing dirty reads in foreign keys I've come up
with a few cases that I'm fairly uncertain about how to handle with
regards to deadlocks and figured I should ask for advice because I think
I'm missing something painfully obvious, but don't get large enough blocks
of time
Brandon Craig Rhodes <[EMAIL PROTECTED]> writes:
> While learning how to read query trees, I have been puzzled by the
> assertion in the manual that the :resultRelations of an INSERT holds
> `the table (or view!) where the changes take effect,' because in all
> of the INSERTs I have generated the r
In the examples I've seen, in the consistent method we have:
if (GIST_LEAF(entry)) [...]
but in compress we have:
if (entry->leafkey) [...]
I can see what the latter's doing, but I'm not sure what GIST_LEAF
does, or why you'd want to use it.
Also, I noticed this in src/backend/access/gist:
Alvaro,
you're welcome to put your hands on to GiST.
Me and Teodor hoped to add concurrency last year but we were too busy.
I consider concurrency issue the most important. There are also
some thoughts about improvement of GiST interface, though.
Regards,
Oleg
On Thu, 27
>
> Just as a suggestion: In most of my applications, we have a security
layer
> which is implemented through server-side functions. These functions
keep a
> table updated which contains:
>
> lock_table
> record_id
> lock_user
> time_locked
That's an excellent and even portable idea.
>
> This all
