Hello all,
I'm now working on performance tuning for PostgreSQL application.
I know shared_buffers and sort_mem have huge impacts for the performance.
If a disk sort (called tape sort in the code) is occured, we need to
increase sort_mem value. Then I found it is difficult to get a
reasonable va
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:
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 funct
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 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
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 f
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 X
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 pr
-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:
CREATE
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
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 ()
"El destino baraja y nosotros jugamos
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
Dun
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 funct
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> From the example case it's not hard to imagine situations where
> we will want lots of subtransactions; just using exceptions in functions
> will implicitly open new ones! (This kind of bothers me because of the
> possibly very fast use of Xids, acceler
"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
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
>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
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
"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
> 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 origi
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 g
> 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
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 di
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 i
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 looked
> "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
> 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 REPLAC
27 matches
Mail list logo
