[EMAIL PROTECTED] wrote:
>The question is *why* you feel you need that, ie what are you using
>these for? As was already mentioned upthread, it's usually better
>to avoid explicit locking altogether, if you can.
Scenario 1. One has objects belong to a metaclass. Certain operations changes
metacl
"Ilja Golshtein" <[EMAIL PROTECTED]> writes:
> I need table level locks for cooperative usage in my application.
> LOCK TABLE table_name in EXCLUSIVE MODE
> and
> LOCK TABLE table_name in SHARED MODE
> perfectly suit my needs.
The question is *why* you feel you need that, ie what are you using
th
>>> Why do you want to lock at all?
>
>> It's long and sad story ;(
>
>If you don't explain what you're trying to accomplish, you're unlikely
>to get useful advice.
Tom,
I need table level locks for cooperative usage in my application.
LOCK TABLE table_name in EXCLUSIVE MODE
and
LOCK TABLE tabl
"Ilja Golshtein" <[EMAIL PROTECTED]> writes:
>> Why do you want to lock at all?
> It's long and sad story ;(
If you don't explain what you're trying to accomplish, you're unlikely
to get useful advice.
regards, tom lane
---(end of broadcast)-
>But seriously, why block autovacuum? It no visible effect on the table.
I DO NOT want to block autovacuum.
I need lock modes do not interfere with anything else just to use in my
application.
user_locks is fine, while it does not provide waiting (only immediate Yes or
No).
>Why do you want to
On Mon, Dec 25, 2006 at 02:58:26PM +0300, Ilja Golshtein wrote:
> Hello!
>
> I need table locks to provide application logic. Just very common lock types
> with very common behavior - Shared and Exclusive.
>
> Which PostgreSQL's lock modes should be preferred in order to avoid conflicts
> with
Hello!
I need table locks to provide application logic. Just very common lock types
with very common behavior - Shared and Exclusive.
Which PostgreSQL's lock modes should be preferred in order to avoid conflicts
with autovacuum and suchlike?
Or, may be, the best option for me is a contrib mod
On 3/11/06, Bill Moseley <[EMAIL PROTECTED]> wrote:
> I need to insert a row, but how that row is inserted depends on the
> number of items existing in the table. I initially thought
> SERIALIZABLE would help, but that only keeps me from seeing changes
> until the commit in that session.
serializ
I need to insert a row, but how that row is inserted depends on the
number of items existing in the table. I initially thought
SERIALIZABLE would help, but that only keeps me from seeing changes
until the commit in that session.
Am I correct that if I need to insert a row into a table that contai
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > No spinlock. I was going to just grab a snapshot as it existed. If it
> > changes while I am grabbing it, I just try again.
>
> Unless, of course, you follow a now-dangling pointer and cause a backend
> crash. But even without that, how do you kn
Bruce Momjian <[EMAIL PROTECTED]> writes:
> No spinlock. I was going to just grab a snapshot as it existed. If it
> changes while I am grabbing it, I just try again.
Unless, of course, you follow a now-dangling pointer and cause a backend
crash. But even without that, how do you know whether y
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > I am thinking of a tcl/tk app that can go in and grab information from
> > backends by querying the actual structure values. Does gdb
> > automatically halt the running app?
>
> Yes. I suppose this is no big problem if you start a backend to be
>
Bruce Momjian <[EMAIL PROTECTED]> writes:
> I am thinking of a tcl/tk app that can go in and grab information from
> backends by querying the actual structure values. Does gdb
> automatically halt the running app?
Yes. I suppose this is no big problem if you start a backend to be
used only as t
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > I want to write an admin utility that will view backend SQL queries, and
> > be able to view locks and statistics using gdb on the running backend.
>
> gdb on a backend doesn't seem to me like a reasonable component of a
> production situation. I w
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > I want to write an admin utility that will view backend SQL queries, and
> > be able to view locks and statistics using gdb on the running backend.
>
> gdb on a backend doesn't seem to me like a reasonable component of a
> production situation. I w
Bruce Momjian <[EMAIL PROTECTED]> writes:
> I want to write an admin utility that will view backend SQL queries, and
> be able to view locks and statistics using gdb on the running backend.
gdb on a backend doesn't seem to me like a reasonable component of a
production situation. I was thinking
I want to write an admin utility that will view backend SQL queries, and
be able to view locks and statistics using gdb on the running backend.
> "Dale Anderson" <[EMAIL PROTECTED]> writes:
> > Is there any way to view the locks being held on a table??
>
> There is not any good way --- lock.
17 matches
Mail list logo
