next XID is in shmem now...
Backends fetch 1024 XIDs now and place them in shmem.
There is space in VariableCache struct for OIDs as well
but I didn't change GetNewObjectId() due to the
CheckMaxObjectId() stuff... Bruce ?
All other LLL stuff will be #ifdef-ed...
Vadim
Backends fetch 1024 XIDs now and place them in shmem.
There is space in VariableCache struct for OIDs as well
but I didn't change GetNewObjectId() due to the
CheckMaxObjectId() stuff... Bruce ?
What can I do to help? Is the problem that a backend can set the next
oid by specifiying an oid greater than the current one?
All other LLL stuff will be #ifdef-ed...
As far as I am concerned, you don't need use #ifdef.
--
Bruce Momjian | 830 Blythe Avenue
maillist@candle.pha.pa.us | Drexel Hill, Pennsylvania 19026
+ If your life is a hard drive, | (610) 353-9879(w)
+ Christ can be your backup. | (610) 853-3000(h)
Bruce Momjian wrote:
Backends fetch 1024 XIDs now and place them in shmem.
There is space in VariableCache struct for OIDs as well
but I didn't change GetNewObjectId() due to the
CheckMaxObjectId() stuff... Bruce ?What can I do to help? Is the problem that a backend can set the next
oid by specifiying an oid greater than the current one?
No problem - I just havn't time to think about this, sorry.
All other LLL stuff will be #ifdef-ed...
As far as I am concerned, you don't need use #ifdef.
I'm not sure how much ready/robust this will be in 6.4.
This is long-term project...
Vadim
Bruce Momjian wrote:
Backends fetch 1024 XIDs now and place them in shmem.
There is space in VariableCache struct for OIDs as well
but I didn't change GetNewObjectId() due to the
CheckMaxObjectId() stuff... Bruce ?What can I do to help? Is the problem that a backend can set the next
oid by specifiying an oid greater than the current one?No problem - I just havn't time to think about this, sorry.
All other LLL stuff will be #ifdef-ed...
As far as I am concerned, you don't need use #ifdef.
I'm not sure how much ready/robust this will be in 6.4.
This is long-term project...
Any chance on getting the 30-second pg_log syncing, so we can improve
the default pgsql performance, and not do fsync on every transaction by
default?
--
Bruce Momjian | 830 Blythe Avenue
maillist@candle.pha.pa.us | Drexel Hill, Pennsylvania 19026
+ If your life is a hard drive, | (610) 353-9879(w)
+ Christ can be your backup. | (610) 853-3000(h)