| Commit message (Collapse) | Author | Age |
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
2. varsup.c:ReadNewTransactionId(): don't read nextXid from disk -
this func doesn't allocate next xid, so ShmemVariableCache->nextXid
may be used (but GetNewTransactionId() must be called first).
3. vacuum.c: change elog(ERROR, "Child item....") to elog(NOTICE) -
this is not ERROR, proper handling is just not implemented, yet.
4. s_lock.c: increase S_MAX_BUSY by 2 times.
5. shmem.c:GetSnapshotData(): have to call ReadNewTransactionId()
_after_ SpinAcquire(ShmemIndexLock).
|
|
|
|
|
| |
in CommitTransaction().
2. Changes in GetSnapshotData().
|
| |
|
|
|
|
|
|
|
|
| |
through MAXBACKENDS array entries used to be fine when MAXBACKENDS = 64.
It's not so cool with MAXBACKENDS = 1024 (or more!), especially not in a
frequently-used routine like SIDelExpiredDataEntries. Repair by making
procState array size be the soft MaxBackends limit rather than the hard
limit, and by converting SIGetProcStateLimit() to a macro.
|
| |
|
|
|
|
| |
real affect now.
|
|
|
|
| |
complaints (and some of my own).
|
|
|
|
|
|
|
| |
2. Much faster btree tuples deletion in the case when first on page
index tuple is deleted (no movement to the left page(s)).
3. Remember blkno of new root page in BTPageOpaque of
left/right siblings when root page is splitted.
|
|
|
|
|
| |
This change brings the default size of the main shmem block back under 1MB,
which is a fairly popular value for the kernel's SHMMAX parameter.
|
|
|
|
|
|
| |
shared memory space allocation. It's a wonder we have not seen bug
reports traceable to this area ... it's quite clear that the routine
dir_realloc() has never worked correctly, for example.
|
|
|
|
|
|
|
|
|
| |
of MAXBACKENDS is now 1024, since all it's costing is about 32 bytes of memory
per array slot. configure's --with-maxbackends switch now controls DEF_MAXBACKENDS
which is simply the default value of the postmaster's -N switch. Thus,
the out-of-the-box configuration will still limit you to 64 backends,
but you can go up to 1024 backends simply by restarting the postmaster with
a different -N switch --- no rebuild required.
|
|
|
|
| |
postmaster will release whatever it did get before dying.
|
|
|
|
|
|
|
|
|
| |
(--with-maxbackends). Add a postmaster switch (-N backends) that allows
the limit to be reduced at postmaster start time. (You can't increase it,
sorry to say, because there are still some fixed-size arrays.)
Grab the number of semaphores indicated by min(MAXBACKENDS, -N) at
postmaster startup, so that this particular form of bogus configuration
is exposed immediately rather than under heavy load.
|
| |
|
| |
|
|
|
|
|
| |
LOCK TABLE IN ... MODE
...implemented
|
| |
|
|
|
|
| |
New code for locking buffer' context.
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
> tprintf.patch
>
> tprintf.patch
>
> adds functions and macros which implement a conditional trace package
> with the ability to change flags and numeric options of running
> backends at runtime.
> Options/flags can be specified in the command line and/or read from
> the file pg_options in the data directory.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
> sinval.patch
>
> fixes a problem in SI cache which causes table overflow if some
> backend is idle for a long time while other backends keep adding
> entries.
> It uses the new signal handling implemented in tprintf.patch.
> I have also increacasesed the max number of backends from 32 to 64
> and the table size from 1000 to 5000.
> I don't know if anybody is working on SI, but until another
> solution is found this patch fixes the problem. I have received
> messages from other people reporting the same problem which I
> fixed many months ago.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
shmem_exit to replace exitpg().
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|