And how often do you need to redefine a trigger (as opposed to its
underlying function), anyway?
I just want to know why not supported.
It's not a serious problem.
Tom Lane wrote:
Christopher Kings-Lynne [EMAIL PROTECTED] writes:
Is threre any reason not to support CREATE OR REPLACE
only
CB == Christopher Browne [EMAIL PROTECTED] writes:
CB futile discussions ask for it. Notably, on an SMP system, it
CB would be a neat idea for complex queries involving joins to
CB split themselves so that different parts run in separate
CB threads.
You don't really need
I've been knocking around a bit with user level locks and I have a few
suggestions/questions:
First, the pg_locks view lists user level locks but doesn't really say
much about them. For example, for traditional locks we get the xid but
for user locks we don't really get anything useful. I
Merlin Moncure wrote:
Second,
Is there a reason why user level locks are completely undocumented?
AFAICT, There is no mention of them in anywhere in the docs,
particularly 12.4, which describes methods for application managed
concurrency. The availability of cooperative long term locks is
On Mon, Sep 13, 2004 at 01:34:05PM -0400, Merlin Moncure wrote:
First, the pg_locks view lists user level locks but doesn't really say
much about them. For example, for traditional locks we get the xid but
for user locks we don't really get anything useful. I looked in
lockfuncs.c and
Merlin Moncure wrote:
Second,
Is there a reason why user level locks are completely undocumented?
AFAICT, There is no mention of them in anywhere in the docs,
particularly 12.4, which describes methods for application managed
concurrency. The availability of cooperative long term locks
Peter Eisentraut [EMAIL PROTECTED] writes:
That's the whole problem. I don't think anyone objects to the user lock
principle, but as long as it's GPL, we won't support it. It was
probably a mistake to accept this module in the first place. I believe
some people have been trying to get
I said some time ago that I would pester contrib authors about fixing
license issues, but it still hasn't gotten to the top of my to-do list
:-(
AFAIK nothing at all has been done on this score.
If Merlin is hot about contrib/userlock right now, he's welcome to try
to contact the original
Merlin Moncure [EMAIL PROTECTED] writes:
... is there any merit to promoting the user lock wrappers out of contrib
Dunno. Yours is the first message I can recall in quite a long time
indicating that anyone was using userlocks. I thought the code was kind
of dying on the vine. Of course it's
Alvaro Herrera [EMAIL PROTECTED] writes:
ISTM it would be better to have pg_locks show only system locks, and
another view, say pg_userlocks, to show user locks. This would allow to
show different data; for example, the PID of the process involved.
I think this is a bad idea, at least for the
Robert Treat...
On Friday 10 September 2004 17:58, Bruce Momjian wrote:
Devrim GUNDUZ wrote:
Hi,
AFAIR there was a thread about SELECT FOR UPDATE NOWAIT
availability in
{7.5,8.0}, 7-8 months ago.
Now we have LOCK TABLE ... NOWAIT; but I wonder whether we'll have the
SELECT
On Sun, Sep 12, 2004 at 08:28:42PM -0400, Tom Lane wrote:
1. During CommitSubTransaction, release the lock on the subtransaction's
XID (but not any of its other locks). This means that the number of
locks held due to just transaction XIDs is no more than the subxact
nesting depth, rather
Dave Page [EMAIL PROTECTED] writes:
[ in list of contrib modules that don't build on Windows ]
pg_logger
deprecated; use redirect_stderr (BTW, is it default on win32 now?)
Yes, it's the default on Win32 (installer releases anyhoo). I take it
this should be removed from /contrib then.
I
BTW, I'm not going to make the lock release/XactLockTableWait fix just yet,
because exhaustion of shared memory provides an easy test case for a
problem that I want to fix first. What I noticed while testing the
reported case is that you get
WARNING: out of shared memory
CONTEXT: PL/pgSQL
This is the first I have ever heard user locks, but I have more than
once wanted a lock that would persist beyond the end of a transaction.
Do these do that?
Paul
Merlin Moncure [EMAIL PROTECTED] writes:
... is there any merit to promoting the user lock wrappers out of contrib
Dunno.
On Mon, Sep 13, 2004 at 08:06:08PM -0400, Paul Tillotson wrote:
This is the first I have ever heard user locks, but I have more than
once wanted a lock that would persist beyond the end of a transaction.
Do these do that?
Yes.
--
Alvaro Herrera (alvherre[a]dcc.uchile.cl)
El destino baraja
I wrote:
I don't actually like StartAbortedSubTransaction at all --- ISTM that if
you get a failure trying to enter a subxact, it's better *not* to enter
the subxact and instead to treat the error as putting the calling xact
in abort state.
Actually, the more I think about this the more I
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Anyone working on the libpq interface to prepared statements?
We could really use that for DBD::Pg. Alternatively, if someone
knows a trick to prepare an INSERT statement without knowing
the data types, that would be neat too. For example:
On Mon, Sep 13, 2004 at 08:40:46PM -0400, Tom Lane wrote:
The remaining calls of GetCurrentTransactionId would mostly be the ones
in heapam.c that are labeling tuples about to be written to disk.
One minor point is that GetCurrentTransactionId would now become a
routine with a nonzero
Alvaro Herrera [EMAIL PROTECTED] writes:
Just to be sure I understand your proposal: the idea is that a
subtransaction would not have a TransactionId assigned right away, but
instead the first call to GetCurrentTransactionId in the subxact would
assign it (and call SubTransSetParent and
Greg Stark wrote:
Mischa Sandberg [EMAIL PROTECTED] writes:
I take it that it is a very reasonable assumption that only a small proportion
of index records are actually invalid (else Yurk why use the index?).
That's faulty logic, the percentage of tuples that are valid is entirely
independent
Tom Lane schrieb:
Can you provide a concrete test case?
houres later I'v located the problem. Its not heavy load but
subtransactions in Triggers. It's very easy to recreate:
the problem is this Syntax :
CREATE OR REPLACE FUNCTION do_standard_mgc() RETURNS TRIGGER AS'
BEGIN
BEGIN
--prob also
Tom Lane schrieb:
Yeah, I ran into that earlier today while trying to reproduce your
problem. It's fixed by this pending patch. I didn't see any freeze-up
of the system after running out of lock memory, though. It seemed to
release the locks just fine.
Yeah this error is away now.
Now i got the
Tom Lane schrieb:
Can I see a stack trace from that? Or at least the verbose form of the
error message?
actually i dunno know how to create a stack trace. I will do some
research. Verbose output (debug5)
TEST=# UPDATE art SET ak_res=0;
WARNING: out of shared memory
CONTEXT: PL/pgSQL
Daniel Schuchardt [EMAIL PROTECTED] writes:
Tom Lane schrieb:
Can I see a stack trace from that? Or at least the verbose form of the
error message?
WARNING: 53200: out of shared memory
LOCATION: ShmemAlloc, shmem.c:185
STATEMENT: SELECT count(*) FROM art;
ERROR: 53200: out
25 matches
Mail list logo
