Hi,
On 09/21/2010 05:48 PM, Kevin Grittner wrote:
OK, I'd say it's a little rough yet, but it works. Is this
reasonable?:
http://git.postgresql.org/gitweb?p=users/kgrittn/postgres.git;a=commitdiff;h=b8eca245ab63725d0fbfc3b5969f4a17fc765f2c
I only get a: 404 - Unknown commit object on that
Markus Wanner mar...@bluegap.ch wrote:
I only get a: 404 - Unknown commit object on that link. Did you
push your work?
Yeah, but it has since been blown away (at my request) as part of my
attempt to get it based on the new git conversion. Sorry about
that. Attached is an mbox
Kevin Grittner kevin.gritt...@wicourts.gov wrote:
I'm not excited about inventing an API with just one use-case;
it's unlikely that you actually end up with anything generally
useful. (SHM_QUEUE seems like a case in point...) Especially
when there are so many other constraints on what
On 20/09/10 18:12, Kevin Grittner wrote:
On the Serializable Snapshot Isolation thread, Heikki pointed out a
collection of objects in an HTAB which didn't really need its key on
VirtualTransactionId, but there isn't really any other useful key,
either. One of these objects may live and die,
Kevin,
On 09/20/2010 05:12 PM, Kevin Grittner wrote:
SHM_QUEUE objects provide the infrastructure for maintaining a
shared memory linked list, but they don't do anything about the
allocation and release of the space for the objects.
Did you have a look at my dynshmem stuff? It tries to solve
Heikki Linnakangas heikki.linnakan...@enterprisedb.com wrote:
In the SSI patch, you'd also need a way to insert an existing
struct into a hash table. You currently work around that by using
a hash element that contains only the hash key, and a pointer to
the SERIALIZABLEXACT struct. It isn't
Markus Wanner mar...@bluegap.ch wrote:
On 09/20/2010 05:12 PM, Kevin Grittner wrote:
SHM_QUEUE objects provide the infrastructure for maintaining a
shared memory linked list, but they don't do anything about the
allocation and release of the space for the objects.
Did you have a look at
On Mon, 2010-09-20 at 18:37 +0300, Heikki Linnakangas wrote:
SHM_QUEUE objects provide the infrastructure for maintaining a
shared memory linked list, but they don't do anything about the
allocation and release of the space for the objects. So it occurs
to me that I'm using an HTAB for
Simon Riggs si...@2ndquadrant.com wrote:
My understanding is that we used to have that and it was removed
for the reasons Heikki states. There are still vestigial bits
still in code.
Not exactly impressed with the SHM_QUEUE stuff though, so I
appreciate the sentiment that Kevin expresses.
On 20/09/10 19:04, Kevin Grittner wrote:
Heikki Linnakangasheikki.linnakan...@enterprisedb.com wrote:
In the SSI patch, you'd also need a way to insert an existing
struct into a hash table. You currently work around that by using
a hash element that contains only the hash key, and a pointer
Kevin Grittner kevin.gritt...@wicourts.gov writes:
Simon Riggs si...@2ndquadrant.com wrote:
My understanding is that we used to have that and it was removed
for the reasons Heikki states. There are still vestigial bits
still in code.
There's nothing vestigial about SHM_QUEUE --- it's used by
On Mon, 2010-09-20 at 12:35 -0400, Tom Lane wrote:
Kevin Grittner kevin.gritt...@wicourts.gov writes:
Simon Riggs si...@2ndquadrant.com wrote:
My understanding is that we used to have that and it was removed
for the reasons Heikki states. There are still vestigial bits
still in code.
Tom Lane t...@sss.pgh.pa.us wrote:
There's nothing vestigial about SHM_QUEUE --- it's used by the
lock manager. But it's intended to link together structs whose
existence is managed by somebody else.
Yep, that's exactly my problem.
I'm not excited about inventing an API with just one
On 09/20/2010 06:09 PM, Kevin Grittner wrote:
Yeah, I mostly followed that thread. If such a feature was present,
it might well make sense to use it for this; however, I've got
enough trouble selling the SSI technology without making it
dependent on something else which was clearly quite
Markus Wanner mar...@bluegap.ch wrote:
I'm wondering how you want to implement the memory allocation part
Based on the feedback I've received, it appears that the only sane
way to do that in the current shared memory environment is to
allocate a fixed size of memory to hold these entries on
On 09/20/2010 08:06 PM, Kevin Grittner wrote:
Obviously, if there were a dynamic way to add to the entries as
needed, there would be one less setting (hard-coded or GUC) to worry
about getting right. Too low means transactions need to be
canceled. Too high means you're wasting space which
16 matches
Mail list logo
