Обсуждение: [HACKERS] POC: Sharing record typmods between backends
Hi hackers, Tuples can have type RECORDOID and a typmod number that identifies a "blessed" TupleDesc in a backend-private cache. To support the sharing of such tuples through shared memory and temporary files, I think we need a typmod registry in shared memory. Here's a proof-of-concept patch for discussion. I'd be grateful for any feedback and/or flames. This is a problem I ran into in my parallel hash join project. Robert pointed it out to me and told me to go read tqueue.c for details, and my first reaction was: I'll code around this by teaching the planner to avoid sharing tuples from paths that produce transient record types based on tlist analysis[1]. Aside from being a cop-out, that approach doesn't work because the planner doesn't actually know what types the executor might come up with since some amount of substitution for structurally-similar records seems to be allowed[2] (though I'm not sure I can explain that). So... we're gonna need a bigger boat. The patch uses typcache.c's backend-private cache still, but if the backend is currently "attached" to a shared registry then it functions as a write though cache. There is no cache-invalidation problem because registered typmods are never unregistered. parallel.c exports the leader's existing record typmods into a shared registry, and attaches to it in workers. A DSM detach hook returns backends to private cache mode when parallelism ends. Some thoughts: * Maybe it would be better to have just one DSA area, rather than the one controlled by execParallel.c (for executor nodes to use) and this new one controlled by parallel.c (for the ParallelContext). Those scopes are approximately the same at least in the parallel query case, but... * It would be nice for the SharedRecordTypeRegistry to be able to survive longer than a single parallel query, perhaps in a per-session DSM segment. Perhaps eventually we will want to consider a query-scoped area, a transaction-scoped area and a session-scoped area? I didn't investigate that for this POC. * It seemed to be a reasonable goal to avoid allocating an extra DSM segment for every parallel query, so the new DSA area is created in-place. 192KB turns out to be enough to hold an empty SharedRecordTypmodRegistry due to dsa.c's superblock allocation scheme (that's two 64KB size class superblocks + some DSA control information). It'll create a new DSM segment as soon as you start using blessed records, and will do so for every parallel query you start from then on with the same backend. Erm, maybe adding 192KB to every parallel query DSM segment won't be popular... * Perhaps simplehash + an LWLock would be better than dht, but I haven't looked into that. Can it be convinced to work in DSA memory and to grow on demand? Here's one way to hit the new code path, so that record types blessed in a worker are accessed from the leader: CREATE TABLE foo AS SELECT generate_series(1, 10) AS x; CREATE OR REPLACE FUNCTION make_record(n int) RETURNS RECORD LANGUAGE plpgsql PARALLEL SAFE AS $$ BEGIN RETURN CASE n WHEN 1 THEN ROW(1) WHEN 2 THEN ROW(1, 2) WHEN 3 THEN ROW(1, 2, 3) WHEN 4 THEN ROW(1, 2, 3, 4) ELSE ROW(1, 2, 3, 4, 5) END; END; $$; SET force_parallel_mode = 1; SELECT make_record(x) FROM foo; PATCH 1. Apply dht-v3.patch[3]. 2. Apply shared-record-typmod-registry-v1.patch. 3. Apply rip-out-tqueue-remapping-v1.patch. [1] https://www.postgresql.org/message-id/CAEepm%3D2%2Bzf7L_-eZ5hPW5%3DUS%2Butdo%3D9tMVD4wt7ZSM-uOoSxWg%40mail.gmail.com [2] https://www.postgresql.org/message-id/CA+TgmoZMH6mJyXX=YLSOvJ8jULFqGgXWZCr_rbkc1nJ+177VSQ@mail.gmail.com [3] https://www.postgresql.org/message-id/flat/CAEepm%3D3d8o8XdVwYT6O%3DbHKsKAM2pu2D6sV1S_%3D4d%2BjStVCE7w%40mail.gmail.com -- Thomas Munro http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Вложения
On Fri, Apr 7, 2017 at 5:21 PM, Thomas Munro <thomas.munro@enterprisedb.com> wrote: > * It would be nice for the SharedRecordTypeRegistry to be able to > survive longer than a single parallel query, perhaps in a per-session > DSM segment. Perhaps eventually we will want to consider a > query-scoped area, a transaction-scoped area and a session-scoped > area? I didn't investigate that for this POC. This seems like the right way to go. I think there should be one extra patch in this patch stack, to create a per-session DSA area (and perhaps a "SharedSessionState" struct?) that worker backends can attach to. It could be created when you first run a parallel query, and then reused for all parallel queries for the rest of your session. So, after you've run one parallel query, all future record typmod registrations would get pushed (write-through style) into shmem, for use by other backends that you might start in future parallel queries. That will avoid having to copy the leader's registered record typmods into shmem for every query going forward (the behaviour of the current POC patch). > * Perhaps simplehash + an LWLock would be better than dht, but I > haven't looked into that. Can it be convinced to work in DSA memory > and to grow on demand? Any views on this? > 1. Apply dht-v3.patch[3]. > 2. Apply shared-record-typmod-registry-v1.patch. > 3. Apply rip-out-tqueue-remapping-v1.patch. Here's a rebased version of the second patch (the other two still apply). It's still POC code only and still uses a per-parallel-context DSA area for space, not the per-session one I am now proposing we develop, if people are in favour of the approach. In case it wasn't clear from my earlier description, a nice side effect of using a shared typmod registry is that you can delete 85% of tqueue.c (see patch #3), so if you don't count the hash table implementation we come out about even in terms of lines of code. -- Thomas Munro http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Вложения
On Tue, May 30, 2017 at 1:09 AM, Thomas Munro <thomas.munro@enterprisedb.com> wrote: >> * Perhaps simplehash + an LWLock would be better than dht, but I >> haven't looked into that. Can it be convinced to work in DSA memory >> and to grow on demand? Simplehash provides an option to provide your own allocator function to it. So in the allocator function, you can allocate memory from DSA. After it reaches some threshold it expands the size (double) and it will again call the allocator function to allocate the bigger memory. You can refer pagetable_allocate in tidbitmap.c. -- Regards, Dilip Kumar EnterpriseDB: http://www.enterprisedb.com
On Tue, May 30, 2017 at 2:45 AM, Dilip Kumar <dilipbalaut@gmail.com> wrote: > On Tue, May 30, 2017 at 1:09 AM, Thomas Munro > <thomas.munro@enterprisedb.com> wrote: >>> * Perhaps simplehash + an LWLock would be better than dht, but I >>> haven't looked into that. Can it be convinced to work in DSA memory >>> and to grow on demand? > > Simplehash provides an option to provide your own allocator function > to it. So in the allocator function, you can allocate memory from DSA. > After it reaches some threshold it expands the size (double) and it > will again call the allocator function to allocate the bigger memory. > You can refer pagetable_allocate in tidbitmap.c. That only allows the pagetable to be shared, not the hash table itself. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
On Wed, May 31, 2017 at 10:57 AM, Robert Haas <robertmhaas@gmail.com> wrote: >> Simplehash provides an option to provide your own allocator function >> to it. So in the allocator function, you can allocate memory from DSA. >> After it reaches some threshold it expands the size (double) and it >> will again call the allocator function to allocate the bigger memory. >> You can refer pagetable_allocate in tidbitmap.c. > > That only allows the pagetable to be shared, not the hash table itself. I agree with you. But, if I understand the use case correctly we need to store the TupleDesc for the RECORD in shared hash so that it can be shared across multiple processes. I think this can be achieved with the simplehash as well. For getting this done, we need some fixed shared memory for holding static members of SH_TYPE and the process which creates the simplehash will be responsible for copying these static members to the shared location so that other processes can access the SH_TYPE. And, the dynamic part (the actual hash entries) can be allocated using DSA by registering SH_ALLOCATE function. -- Regards, Dilip Kumar EnterpriseDB: http://www.enterprisedb.com
On Wed, May 31, 2017 at 11:16 AM, Dilip Kumar <dilipbalaut@gmail.com> wrote: > I agree with you. But, if I understand the use case correctly we need > to store the TupleDesc for the RECORD in shared hash so that it can be > shared across multiple processes. I think this can be achieved with > the simplehash as well. > > For getting this done, we need some fixed shared memory for holding > static members of SH_TYPE and the process which creates the simplehash > will be responsible for copying these static members to the shared > location so that other processes can access the SH_TYPE. And, the > dynamic part (the actual hash entries) can be allocated using DSA by > registering SH_ALLOCATE function. Well, SH_TYPE's members SH_ELEMENT_TYPE *data and void *private_data are not going to work in DSM, because they are pointers. You can doubtless come up with a way around that problem, but I guess the question is whether that's actually any better than just using DHT. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
On Wed, May 31, 2017 at 12:53 PM, Robert Haas <robertmhaas@gmail.com> wrote: > Well, SH_TYPE's members SH_ELEMENT_TYPE *data and void *private_data > are not going to work in DSM, because they are pointers. You can > doubtless come up with a way around that problem, but I guess the > question is whether that's actually any better than just using DHT. Probably I misunderstood the question. I assumed that we need to bring in DHT only for achieving this goal. But, if the question is simply the comparison of DHT vs simplehash for this particular case then I agree that DHT is a more appropriate choice. -- Regards, Dilip Kumar EnterpriseDB: http://www.enterprisedb.com
On 2017-05-31 13:27:28 -0400, Dilip Kumar wrote: > On Wed, May 31, 2017 at 12:53 PM, Robert Haas <robertmhaas@gmail.com> wrote: > > Well, SH_TYPE's members SH_ELEMENT_TYPE *data and void *private_data > > are not going to work in DSM, because they are pointers. You can > > doubtless come up with a way around that problem, but I guess the > > question is whether that's actually any better than just using DHT. > > Probably I misunderstood the question. I assumed that we need to bring > in DHT only for achieving this goal. But, if the question is simply > the comparison of DHT vs simplehash for this particular case then I > agree that DHT is a more appropriate choice. Yea, I don't think simplehash is the best choice here. It's worthwhile to use it for performance critical bits, but using it for everything would just increase code size without much benefit. I'd tentatively assume that anonymous record type aren't going to be super common, and that this is going to be the biggest bottleneck if you use them. - Andres
On Wed, May 31, 2017 at 1:46 PM, Andres Freund <andres@anarazel.de> wrote: > On 2017-05-31 13:27:28 -0400, Dilip Kumar wrote: >> On Wed, May 31, 2017 at 12:53 PM, Robert Haas <robertmhaas@gmail.com> wrote: >> > Well, SH_TYPE's members SH_ELEMENT_TYPE *data and void *private_data >> > are not going to work in DSM, because they are pointers. You can >> > doubtless come up with a way around that problem, but I guess the >> > question is whether that's actually any better than just using DHT. >> >> Probably I misunderstood the question. I assumed that we need to bring >> in DHT only for achieving this goal. But, if the question is simply >> the comparison of DHT vs simplehash for this particular case then I >> agree that DHT is a more appropriate choice. > > Yea, I don't think simplehash is the best choice here. It's worthwhile > to use it for performance critical bits, but using it for everything > would just increase code size without much benefit. I'd tentatively > assume that anonymous record type aren't going to be super common, and > that this is going to be the biggest bottleneck if you use them. Did you mean "not going to be"? -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
On May 31, 2017 11:28:18 AM PDT, Robert Haas <robertmhaas@gmail.com> wrote: >On Wed, May 31, 2017 at 1:46 PM, Andres Freund <andres@anarazel.de> >wrote: >> On 2017-05-31 13:27:28 -0400, Dilip Kumar wrote: >>> On Wed, May 31, 2017 at 12:53 PM, Robert Haas ><robertmhaas@gmail.com> wrote: >>> > Well, SH_TYPE's members SH_ELEMENT_TYPE *data and void >*private_data >>> > are not going to work in DSM, because they are pointers. You can >>> > doubtless come up with a way around that problem, but I guess the >>> > question is whether that's actually any better than just using >DHT. >>> >>> Probably I misunderstood the question. I assumed that we need to >bring >>> in DHT only for achieving this goal. But, if the question is simply >>> the comparison of DHT vs simplehash for this particular case then I >>> agree that DHT is a more appropriate choice. >> >> Yea, I don't think simplehash is the best choice here. It's >worthwhile >> to use it for performance critical bits, but using it for everything >> would just increase code size without much benefit. I'd tentatively >> assume that anonymous record type aren't going to be super common, >and >> that this is going to be the biggest bottleneck if you use them. > >Did you mean "not going to be"? Err, yes. Thanks -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
On Thu, Jun 1, 2017 at 6:29 AM, Andres Freund <andres@anarazel.de> wrote: > On May 31, 2017 11:28:18 AM PDT, Robert Haas <robertmhaas@gmail.com> wrote: >>> On 2017-05-31 13:27:28 -0400, Dilip Kumar wrote: [ ... various discussion in support of using DHT ... ] Ok, good. Here's a new version that introduces a per-session DSM segment to hold the shared record typmod registry (and maybe more things later). The per-session segment is created the first time you run a parallel query (though there is handling for failure to allocate that allows the parallel query to continue with no workers) and lives until your leader backend exits. When parallel workers start up, they see its handle in the per-query segment and attach to it, which puts typcache.c into write-through cache mode so their idea of record typmods stays in sync with the leader (and each other). I also noticed that I could delete even more of tqueue.c than before: it doesn't seem to have any remaining reason to need to know the TupleDesc. One way to test this code is to apply just 0003-rip-out-tqueue-remapping-v3.patch and then try the example from the first message in this thread to see it break, and then try again with the other two patches applied. By adding debugging trace you can see that the worker pushes a bunch of TupleDescs into shmem, they get pulled out by the leader when it sees the tuples, and then on a second invocation the (new) worker can reuse them: it finds matches already in shmem from the first invocation. I used a DSM segment with a TOC and a DSA area inside that, like the existing per-query DSM segment, but obviously you could spin it various different ways. One example: just have a DSA area and make a new kind of TOC thing that deals in dsa_pointers. Better ideas? I believe combo CIDs should also go in there, to enable parallel write, but I'm not 100% sure: that's neither per-session nor per-query data, that's per-transaction. So perhaps the per-session DSM could hold a per-session DSA and a per-transaction DSA, where the latter is reset for each transaction, just like TopTransactionContext (though dsa.c doesn't have a 'reset thyself' function currently). That seems like a good place to store a shared combo CID hash table using DHT. Thoughts? -- Thomas Munro http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Вложения
On 2017-07-10 21:39:09 +1200, Thomas Munro wrote: > Here's a new version that introduces a per-session DSM segment to hold > the shared record typmod registry (and maybe more things later). You like to switch it up. *.patchset.tgz??? ;) It does concern me that we're growing yet another somewhat different hashtable implementation. Yet I don't quite see how we could avoid it. dynahash relies on proper pointers, simplehash doesn't do locking (and shouldn't) and also relies on pointers, although to a much lesser degree. All the open coded tables aren't a good match either. So I don't quite see an alternative, but I'd love one. Regards, Andres diff --git a/src/backend/lib/dht.c b/src/backend/lib/dht.c new file mode 100644 index 00000000000..2fec70f7742 --- /dev/null +++ b/src/backend/lib/dht.c FWIW, not a big fan of dht as a filename (nor of dsa.c). For one DHT usually refers to distributed hash tables, which this is not, and for another the abbreviation is so short it's not immediately understandable, and likely to conflict further. I think it'd possibly ok to have dht as symbol prefixes, but rename the file to be longer. + * To deal with currency, it has a fixed size set of partitions, each of which + * is independently locked. s/currency/concurrency/ I presume. + * Each bucket maps to a partition; so insert, find + * and iterate operations normally only acquire one lock. Therefore, good + * concurrency is achieved whenever they don't collide at the lock partition s/they/operations/? + * level. However, when a resize operation begins, all partition locks must + * be acquired simultaneously for a brief period. This is only expected to + * happen a small number of times until a stable size is found, since growth is + * geometric. I'm a bit doubtful that we need partitioning at this point, and that it doesn't actually *degrade* performance for your typmod case. + * Resizing is done incrementally so that no individual insert operation pays + * for the potentially large cost of splitting all buckets. I'm not sure this is a reasonable tradeoff for the use-case suggested so far, it doesn't exactly make things simpler. We're not going to grow much. +/* The opaque type used for tracking iterator state. */ +struct dht_iterator; +typedef struct dht_iterator dht_iterator; Isn't it actually the iterator state? Rather than tracking it? Also, why is it opaque given you're actually defining it below? Guess you'd moved it at some point. +/* + * The set of parameters needed to create or attach to a hash table. The + * members tranche_id and tranche_name do not need to be initialized when + * attaching to an existing hash table. + */ +typedef struct +{ + Size key_size; /* Size of the key (initial bytes of entry) */ + Size entry_size; /* Total size of entry */ Let's use size_t, like we kind of concluded in the thread you started: http://archives.postgresql.org/message-id/25076.1489699457%40sss.pgh.pa.us :) + dht_compare_function compare_function; /* Compare function */ + dht_hash_function hash_function; /* Hash function */ Might be worth explaining that these need to provided when attaching because they're possibly process local. Did you test this with EXEC_BACKEND? + int tranche_id; /* The tranche ID to use for locks. */ +} dht_parameters; +struct dht_iterator +{ + dht_hash_table *hash_table; /* The hash table we are iterating over. */ + bool exclusive; /* Whether to lock buckets exclusively. */ + Size partition; /* The index of the next partition to visit. */ + Size bucket; /* The index of the next bucket to visit. */ + dht_hash_table_item *item; /* The most recently returned item. */ + dsa_pointer last_item_pointer; /* The last item visited. */ + Size table_size_log2; /* The table size when we started iterating. */ + bool locked; /* Whether the current partition is locked. */ Haven't gotten to the actual code yet, but this kinda suggest we leave a partition locked when iterating? Hm, that seems likely to result in a fair bit of pain... +/* Iterating over the whole hash table. */ +extern void dht_iterate_begin(dht_hash_table *hash_table, + dht_iterator *iterator, bool exclusive); +extern void *dht_iterate_next(dht_iterator *iterator); +extern void dht_iterate_delete(dht_iterator *iterator); s/delete/delete_current/? Otherwise it looks like it's part of manipulating just the iterator. +extern void dht_iterate_release(dht_iterator *iterator); I'd add lock to to the name. +/* + * An item in the hash table. This wraps the user's entry object in an + * envelop that holds a pointer back to the bucket and a pointer to the next + * item in the bucket. + */ +struct dht_hash_table_item +{ + /* The hashed key, to avoid having to recompute it. */ + dht_hash hash; + /* The next item in the same bucket. */ + dsa_pointer next; + /* The user's entry object follows here. */ + char entry[FLEXIBLE_ARRAY_MEMBER]; What's the point of using FLEXIBLE_ARRAY_MEMBER here? And isn't using a char going to lead to alignment problems? +/* The number of partitions for locking purposes. */ +#define DHT_NUM_PARTITIONS_LOG2 7 Could use some justification. +/* + * The head object for a hash table. This will be stored in dynamic shared + * memory. + */ +typedef struct +{ Why anonymous? Not that it hurts much, but seems weird to deviate just here. +/* + * Create a new hash table backed by the given dynamic shared area, with the + * given parameters. + */ +dht_hash_table * +dht_create(dsa_area *area, const dht_parameters *params) +{ + dht_hash_table *hash_table; + dsa_pointer control; + + /* Allocate the backend-local object representing the hash table. */ + hash_table = palloc(sizeof(dht_hash_table)); Should be documented that this uses caller's MemoryContext. + /* Set up the array of lock partitions. */ + { + int i; + + for (i = 0; i < DHT_NUM_PARTITIONS; ++i) + { + LWLockInitialize(PARTITION_LOCK(hash_table, i), + hash_table->control->lwlock_tranche_id); + hash_table->control->partitions[i].count = 0; + } I'd store hash_table->control->lwlock_tranche_id and partitions[i] in local vars. Possibly hash_table->control too. +/* + * Detach from a hash table. This frees backend-local resources associated + * with the hash table, but the hash table will continue to exist until it is + * either explicitly destroyed (by a backend that is still attached to it), or + * the area that backs it is returned to the operating system. + */ +void +dht_detach(dht_hash_table *hash_table) +{ + /* The hash table may have been destroyed. Just free local memory. */ + pfree(hash_table); +} Somewhat inclined to add debugging refcount - seems like bugs around that might be annoying to find. Maybe also add an assert ensuring that no locks are held? +/* + * Look up an entry, given a key. Returns a pointer to an entry if one can be + * found with the given key. Returns NULL if the key is not found. If a + * non-NULL value is returned, the entry is locked and must be released by + * calling dht_release. If an error is raised before dht_release is called, + * the lock will be released automatically, but the caller must take care to + * ensure that the entry is not left corrupted. The lock mode is either + * shared or exclusive depending on 'exclusive'. This API seems a bit fragile. +/* + * Returns a pointer to an exclusively locked item which must be released with + * dht_release. If the key is found in the hash table, 'found' is set to true + * and a pointer to the existing entry is returned. If the key is not found, + * 'found' is set to false, and a pointer to a newly created entry is related. "is related"? + */ +void * +dht_find_or_insert(dht_hash_table *hash_table, + const void *key, + bool *found) +{ + size_t hash; + size_t partition_index; + dht_partition *partition; + dht_hash_table_item *item; + + hash = hash_table->params.hash_function(key, hash_table->params.key_size); + partition_index = PARTITION_FOR_HASH(hash); + partition = &hash_table->control->partitions[partition_index]; + + Assert(hash_table->control->magic == DHT_MAGIC); + Assert(!hash_table->exclusively_locked); Why just exclusively locked? Why'd shared be ok? +/* + * Unlock an entry which was locked by dht_find or dht_find_or_insert. + */ +void +dht_release(dht_hash_table *hash_table, void *entry) +{ + dht_hash_table_item *item = ITEM_FROM_ENTRY(entry); + size_t partition_index = PARTITION_FOR_HASH(item->hash); + bool deferred_resize_work = false; + + Assert(hash_table->control->magic == DHT_MAGIC); Assert lock held (LWLockHeldByMe()) +/* + * Begin iterating through the whole hash table. The caller must supply a + * dht_iterator object, which can then be used to call dht_iterate_next to get + * values until the end is reached. + */ +void +dht_iterate_begin(dht_hash_table *hash_table, + dht_iterator *iterator, + bool exclusive) +{ + Assert(hash_table->control->magic == DHT_MAGIC); + + iterator->hash_table = hash_table; + iterator->exclusive = exclusive; + iterator->partition = 0; + iterator->bucket = 0; + iterator->item = NULL; + iterator->last_item_pointer = InvalidDsaPointer; + iterator->locked = false; + + /* Snapshot the size (arbitrary lock to prevent size changing). */ + LWLockAcquire(PARTITION_LOCK(hash_table, 0), LW_SHARED); + ensure_valid_bucket_pointers(hash_table); + iterator->table_size_log2 = hash_table->size_log2; + LWLockRelease(PARTITION_LOCK(hash_table, 0)); Hm. So we're introducing some additional contention on partition 0 - probably ok. +/* + * Move to the next item in the hash table. Returns a pointer to an entry, or + * NULL if the end of the hash table has been reached. The item is locked in + * exclusive or shared mode depending on the argument given to + * dht_iterate_begin. The caller can optionally release the lock by calling + * dht_iterate_release, and then call dht_iterate_next again to move to the + * next entry. If the iteration is in exclusive mode, client code can also + * call dht_iterate_delete. When the end of the hash table is reached, or at + * any time, the client may call dht_iterate_end to abandon iteration. + */ I'd just shorten the end to "at any time the client may call dht_iterate_end to ..." +/* + * Release the most recently obtained lock. This can optionally be called in + * between calls to dht_iterator_next to allow other processes to access the + * same partition of the hash table. + */ +void +dht_iterate_release(dht_iterator *iterator) +{ + Assert(iterator->locked); + LWLockRelease(PARTITION_LOCK(iterator->hash_table, iterator->partition)); + iterator->locked = false; +} + +/* + * Terminate iteration. This must be called after iteration completes, + * whether or not the end was reached. The iterator object may then be reused + * for another iteration. + */ +void +dht_iterate_end(dht_iterator *iterator) +{ + Assert(iterator->hash_table->control->magic == DHT_MAGIC); + if (iterator->locked) + LWLockRelease(PARTITION_LOCK(iterator->hash_table, + iterator->partition)); +} + +/* + * Print out debugging information about the internal state of the hash table. + */ +void +dht_dump(dht_hash_table *hash_table) +{ + size_t i; + size_t j; + + Assert(hash_table->control->magic == DHT_MAGIC); + + for (i = 0; i < DHT_NUM_PARTITIONS; ++i) + LWLockAcquire(PARTITION_LOCK(hash_table, i), LW_SHARED); Should probably assert & document that no locks are held - otherwise there's going to be ugly deadlocks. And that's an unlikely thing to try. + ensure_valid_bucket_pointers(hash_table); + + fprintf(stderr, + "hash table size = %zu\n", (size_t) 1 << hash_table->size_log2); + for (i = 0; i < DHT_NUM_PARTITIONS; ++i) + { + dht_partition *partition = &hash_table->control->partitions[i]; + size_t begin = BUCKET_INDEX_FOR_PARTITION(i, hash_table->size_log2); + size_t end = BUCKET_INDEX_FOR_PARTITION(i + 1, hash_table->size_log2); + + fprintf(stderr, " partition %zu\n", i); + fprintf(stderr, + " active buckets (key count = %zu)\n", partition->count); + + for (j = begin; j < end; ++j) + { + size_t count = 0; + dsa_pointer bucket = hash_table->buckets[j]; + + while (DsaPointerIsValid(bucket)) + { + dht_hash_table_item *item; + + item = dsa_get_address(hash_table->area, bucket); + + bucket = item->next; + ++count; + } + fprintf(stderr, " bucket %zu (key count = %zu)\n", j, count); + } + if (RESIZE_IN_PROGRESS(hash_table)) + { + size_t begin; + size_t end; + + begin = BUCKET_INDEX_FOR_PARTITION(i, hash_table->size_log2 - 1); + end = BUCKET_INDEX_FOR_PARTITION(i + 1, + hash_table->size_log2 - 1); + + fprintf(stderr, " old buckets (key count = %zu)\n", + partition->old_count); + + for (j = begin; j < end; ++j) + { + size_t count = 0; + dsa_pointer bucket = hash_table->old_buckets[j]; + + while (DsaPointerIsValid(bucket)) + { + dht_hash_table_item *item; + + item = dsa_get_address(hash_table->area, bucket); + + bucket = item->next; + ++count; + } + fprintf(stderr, + " bucket %zu (key count = %zu)\n", j, count); + } + } + } + + for (i = 0; i < DHT_NUM_PARTITIONS; ++i) + LWLockRelease(PARTITION_LOCK(hash_table, i)); +} I'd put this below actual "production" code. - Andres
Hi, diff --git a/src/backend/access/common/tupdesc.c b/src/backend/access/common/tupdesc.c index 9fd7b4e019b..97c0125a4ba 100644 --- a/src/backend/access/common/tupdesc.c +++ b/src/backend/access/common/tupdesc.c @@ -337,17 +337,75 @@ DecrTupleDescRefCount(TupleDesc tupdesc){ Assert(tupdesc->tdrefcount > 0); - ResourceOwnerForgetTupleDesc(CurrentResourceOwner, tupdesc); + if (CurrentResourceOwner != NULL) + ResourceOwnerForgetTupleDesc(CurrentResourceOwner, tupdesc); if (--tupdesc->tdrefcount == 0) FreeTupleDesc(tupdesc);} What's this about? CurrentResourceOwner should always be valid here, no? If so, why did that change? I don't think it's good to detach this from the resowner infrastructure... /* - * Compare two TupleDesc structures for logical equality + * Compare two TupleDescs' attributes for logical equality * * Note: we deliberately do not check the attrelid and tdtypmodfields. * This allows typcache.c to use this routine to see if a cached record type * matches a requested type, andis harmless for relcache.c's uses. + */ +bool +equalTupleDescAttrs(Form_pg_attribute attr1, Form_pg_attribute attr2) +{ comment not really accurate, this routine afaik isn't used by typcache.c? /* - * Magic numbers for parallel state sharing. Higher-level code should use - * smaller values, leaving these very large ones for use by this module. + * Magic numbers for per-context parallel state sharing. Higher-level code + * should use smaller values, leaving these very large ones for use by this + * module. */#define PARALLEL_KEY_FIXED UINT64CONST(0xFFFFFFFFFFFF0001)#define PARALLEL_KEY_ERROR_QUEUE UINT64CONST(0xFFFFFFFFFFFF0002) @@ -63,6 +74,16 @@#define PARALLEL_KEY_ACTIVE_SNAPSHOT UINT64CONST(0xFFFFFFFFFFFF0007)#define PARALLEL_KEY_TRANSACTION_STATE UINT64CONST(0xFFFFFFFFFFFF0008)#define PARALLEL_KEY_ENTRYPOINT UINT64CONST(0xFFFFFFFFFFFF0009) +#define PARALLEL_KEY_SESSION_DSM UINT64CONST(0xFFFFFFFFFFFF000A) + +/* Magic number for per-session DSM TOC. */ +#define PARALLEL_SESSION_MAGIC 0xabb0fbc9 + +/* + * Magic numbers for parallel state sharing in the per-session DSM area. + */ +#define PARALLEL_KEY_SESSION_DSA UINT64CONST(0xFFFFFFFFFFFF0001) +#define PARALLEL_KEY_RECORD_TYPMOD_REGISTRY UINT64CONST(0xFFFFFFFFFFFF0002) Not this patch's fault, but this infrastructure really isn't great. We should really replace it with a shmem.h style infrastructure, using a dht hashtable as backing... +/* The current per-session DSM segment, if attached. */ +static dsm_segment *current_session_segment = NULL; + I think it'd be better if we had a proper 'SessionState' and 'BackendSessionState' infrastructure that then contains the dsm segment etc. I think we'll otherwise just end up with a bunch of parallel infrastructures. +/* + * A mechanism for sharing record typmods between backends. + */ +struct SharedRecordTypmodRegistry +{ + dht_hash_table_handle atts_index_handle; + dht_hash_table_handle typmod_index_handle; + pg_atomic_uint32 next_typmod; +}; + I think the code needs to explain better how these are intended to be used. IIUC, atts_index is used to find typmods by "identity", and typmod_index by the typmod, right? And we need both to avoid all workers generating different tupledescs, right? Kinda guessable by reading typecache.c, but that shouldn't be needed. +/* + * A flattened/serialized representation of a TupleDesc for use in shared + * memory. Can be converted to and from regular TupleDesc format. Doesn't + * support constraints and doesn't store the actual type OID, because this is + * only for use with RECORD types as created by CreateTupleDesc(). These are + * arranged into a linked list, in the hash table entry corresponding to the + * OIDs of the first 16 attributes, so we'd expect to get more than one entry + * in the list when named and other properties differ. + */ +typedef struct SerializedTupleDesc +{ + dsa_pointer next; /* next with the same same attribute OIDs */ + int natts; /* number of attributes in the tuple */ + int32 typmod; /* typmod for tuple type */ + bool hasoid; /* tuple has oid attribute in its header */ + + /* + * The attributes follow. We only ever access the first + * ATTRIBUTE_FIXED_PART_SIZE bytes of each element, like the code in + * tupdesc.c. + */ + FormData_pg_attribute attributes[FLEXIBLE_ARRAY_MEMBER]; +} SerializedTupleDesc; Not a fan of a separate tupledesc representation, that's just going to lead to divergence over time. I think we should rather change the normal tupledesc representation to be compatible with this, and 'just' have a wrapper struct for the parallel case (with next and such). +/* + * An entry in SharedRecordTypmodRegistry's attribute index. The key is the + * first REC_HASH_KEYS attribute OIDs. That means that collisions are + * possible, but that's OK because SerializedTupleDesc objects are arranged + * into a list. + */ +/* Parameters for SharedRecordTypmodRegistry's attributes hash table. */ +const static dht_parameters srtr_atts_index_params = { + sizeof(Oid) * REC_HASH_KEYS, + sizeof(SRTRAttsIndexEntry), + memcmp, + tag_hash, + LWTRANCHE_SHARED_RECORD_ATTS_INDEX +}; + +/* Parameters for SharedRecordTypmodRegistry's typmod hash table. */ +const static dht_parameters srtr_typmod_index_params = { + sizeof(uint32), + sizeof(SRTRTypmodIndexEntry), + memcmp, + tag_hash, + LWTRANCHE_SHARED_RECORD_TYPMOD_INDEX +}; + I'm very much not a fan of this representation. I know you copied the logic, but I think it's a bad idea. I think the key should just be a dsa_pointer, and then we can have a proper tag_hash that hashes the whole thing, and a proper comparator too. Just have /** Combine two hash values, resulting in another hash value, with decent bit* mixing.** Similar to boost's hash_combine().*/ static inline uint32 hash_combine(uint32 a, uint32 b) {a ^= b + 0x9e3779b9 + (a << 6) + (a >> 2);return a; } and then hash everything. +/* + * Make sure that RecordCacheArray is large enough to store 'typmod'. + */ +static void +ensure_record_cache_typmod_slot_exists(int32 typmod) +{ + if (RecordCacheArray == NULL) + { + RecordCacheArray = (TupleDesc *) + MemoryContextAllocZero(CacheMemoryContext, 64 * sizeof(TupleDesc)); + RecordCacheArrayLen = 64; + } + + if (typmod >= RecordCacheArrayLen) + { + int32 newlen = RecordCacheArrayLen * 2; + + while (typmod >= newlen) + newlen *= 2; + + RecordCacheArray = (TupleDesc *) repalloc(RecordCacheArray, + newlen * sizeof(TupleDesc)); + memset(RecordCacheArray + RecordCacheArrayLen, 0, + (newlen - RecordCacheArrayLen) * sizeof(TupleDesc *)); + RecordCacheArrayLen = newlen; + } +} Do we really want to keep this? Could just have an equivalent dynahash for the non-parallel case? /* * lookup_rowtype_tupdesc_internal --- internal routine to lookup a rowtype @@ -1229,15 +1347,49 @@ lookup_rowtype_tupdesc_internal(Oid type_id, int32 typmod, bool noError) /* * It'sa transient record type, so look in our record-type table. */ - if (typmod < 0 || typmod >= NextRecordTypmod) + if (typmod >= 0) { - if (!noError) - ereport(ERROR, - (errcode(ERRCODE_WRONG_OBJECT_TYPE), - errmsg("record type has not been registered"))); - return NULL; + /* It is already in our local cache? */ + if (typmod < RecordCacheArrayLen && + RecordCacheArray[typmod] != NULL) + return RecordCacheArray[typmod]; + + /* Are we attached to a SharedRecordTypmodRegistry? */ + if (CurrentSharedRecordTypmodRegistry.shared != NULL) Why do we want to do lookups in both? I don't think it's a good idea to have a chance that you could have the same typmod in both the local registry (because it'd been created before the shared one) and in the shared (because it was created in a worker). Ah, that's for caching purposes? If so, see my above point that we shouldn't have a serialized version of typdesc (yesyes, constraints will be a bit ugly). +/* + * If we are attached to a SharedRecordTypmodRegistry, find or create a + * SerializedTupleDesc that matches 'tupdesc', and return its typmod. + * Otherwise return -1. + */ +static int32 +find_or_allocate_shared_record_typmod(TupleDesc tupdesc) +{ + SRTRAttsIndexEntry *atts_index_entry; + SRTRTypmodIndexEntry *typmod_index_entry; + SerializedTupleDesc *serialized; + dsa_pointer serialized_dp; + Oid hashkey[REC_HASH_KEYS]; + bool found; + int32 typmod; + int i; + + /* If not even attached, nothing to do. */ + if (CurrentSharedRecordTypmodRegistry.shared == NULL) + return -1; + + /* Try to find a match. */ + memset(hashkey, 0, sizeof(hashkey)); + for (i = 0; i < tupdesc->natts; ++i) + hashkey[i] = tupdesc->attrs[i]->atttypid; + atts_index_entry = (SRTRAttsIndexEntry *) + dht_find_or_insert(CurrentSharedRecordTypmodRegistry.atts_index, + hashkey, + &found); + if (!found) + { + /* Making a new entry. */ + memcpy(atts_index_entry->leading_attr_oids, + hashkey, + sizeof(hashkey)); + atts_index_entry->serialized_tupdesc = InvalidDsaPointer; + } + + /* Scan the list we found for a matching serialized one. */ + serialized_dp = atts_index_entry->serialized_tupdesc; + while (DsaPointerIsValid(serialized_dp)) + { + serialized = + dsa_get_address(CurrentSharedRecordTypmodRegistry.area, + serialized_dp); + if (serialized_tupledesc_matches(serialized, tupdesc)) + { + /* Found a match, we are finished. */ + typmod = serialized->typmod; + dht_release(CurrentSharedRecordTypmodRegistry.atts_index, + atts_index_entry); + return typmod; + } + serialized_dp = serialized->next; + } + + /* We didn't find a matching entry, so let's allocate a new one. */ + typmod = (int) + pg_atomic_fetch_add_u32(&CurrentSharedRecordTypmodRegistry.shared->next_typmod, + 1); + + /* Allocate shared memory and serialize the TupleDesc. */ + serialized_dp = serialize_tupledesc(CurrentSharedRecordTypmodRegistry.area, + tupdesc); + serialized = (SerializedTupleDesc *) + dsa_get_address(CurrentSharedRecordTypmodRegistry.area, serialized_dp); + serialized->typmod = typmod; + + /* + * While we still hold the atts_index entry locked, add this to + * typmod_index. That's important because we don't want anyone to be able + * to find a typmod via the former that can't yet be looked up in the + * latter. + */ + typmod_index_entry = + dht_find_or_insert(CurrentSharedRecordTypmodRegistry.typmod_index, + &typmod, &found); + if (found) + elog(ERROR, "cannot create duplicate shared record typmod"); + typmod_index_entry->typmod = typmod; + typmod_index_entry->serialized_tupdesc = serialized_dp; + dht_release(CurrentSharedRecordTypmodRegistry.typmod_index, + typmod_index_entry); What if we fail to allocate memory for the entry in typmod_index? - Andres
Hi, Please find attached a new patch series. I apologise in advance for 0001 and note that the patchset now weighs in at ~75kB compressed. Here are my in-line replies to your two reviews: On Tue, Jul 25, 2017 at 10:09 PM, Andres Freund <andres@anarazel.de> wrote: > It does concern me that we're growing yet another somewhat different > hashtable implementation. Yet I don't quite see how we could avoid > it. dynahash relies on proper pointers, simplehash doesn't do locking > (and shouldn't) and also relies on pointers, although to a much lesser > degree. All the open coded tables aren't a good match either. So I > don't quite see an alternative, but I'd love one. Yeah, I agree. To deal with data structures with different pointer types, locking policy, inlined hash/eq functions etc, perhaps there is a way we could eventually do 'policy based design' using the kind of macro trickery you started where we generate N different hash table variations but only have to maintain source code for one chaining hash table implementation? Or perl scripts that effectively behave as a cfront^H^H^H nevermind. I'm not planning to investigate that for this cycle. > > diff --git a/src/backend/lib/dht.c b/src/backend/lib/dht.c > new file mode 100644 > index 00000000000..2fec70f7742 > --- /dev/null > +++ b/src/backend/lib/dht.c > > FWIW, not a big fan of dht as a filename (nor of dsa.c). For one DHT > usually refers to distributed hash tables, which this is not, and for > another the abbreviation is so short it's not immediately > understandable, and likely to conflict further. I think it'd possibly > ok to have dht as symbol prefixes, but rename the file to be longer. OK. Now it's ds_hash_table.{c,h}, where "ds" stands for "dynamic shared". Better? If we were to do other data structures in DSA memory they could follow that style: ds_red_black_tree.c, ds_vector.c, ds_deque.c etc and their identifier prefix would be drbt_, dv_, dd_ etc. Do you want to see a separate patch to rename dsa.c? Got a better name? You could have spoken up earlier :-) It does sound like a bit like the thing from crypto or perhaps a scary secret government department. > + * To deal with currency, it has a fixed size set of partitions, each of which > + * is independently locked. > > s/currency/concurrency/ I presume. Fixed. > + * Each bucket maps to a partition; so insert, find > + * and iterate operations normally only acquire one lock. Therefore, good > + * concurrency is achieved whenever they don't collide at the lock partition > > s/they/operations/? Fixed. > + * level. However, when a resize operation begins, all partition locks must > + * be acquired simultaneously for a brief period. This is only expected to > + * happen a small number of times until a stable size is found, since growth is > + * geometric. > > I'm a bit doubtful that we need partitioning at this point, and that it > doesn't actually *degrade* performance for your typmod case. Yeah, partitioning not needed for this case, but this is supposed to be more generally useful. I thought about making the number of partitions a construction parameter, but it doesn't really hurt does it? > + * Resizing is done incrementally so that no individual insert operation pays > + * for the potentially large cost of splitting all buckets. > > I'm not sure this is a reasonable tradeoff for the use-case suggested so > far, it doesn't exactly make things simpler. We're not going to grow > much. Yeah, designed to be more generally useful. Are you saying you would prefer to see the DHT patch split into an initial submission that does the simplest thing possible, so that the unlucky guy who causes the hash table to grow has to do all the work of moving buckets to a bigger hash table? Then we could move the more complicated incremental growth stuff to a later patch. > +/* The opaque type used for tracking iterator state. */ > +struct dht_iterator; > +typedef struct dht_iterator dht_iterator; > > Isn't it actually the iterator state? Rather than tracking it? Also, why > is it opaque given you're actually defining it below? Guess you'd moved > it at some point. Improved comment. The iterator state is defined below in the .h, but with a warning that client code mustn't access it; it exists in the header only because it's very useful to be able to but dht_iterator on the stack which requires the client code to have its definition, but I want to reserve the right to change it arbitrarily in future. > +/* > + * The set of parameters needed to create or attach to a hash table. The > + * members tranche_id and tranche_name do not need to be initialized when > + * attaching to an existing hash table. > + */ > +typedef struct > +{ > + Size key_size; /* Size of the key (initial bytes of entry) */ > + Size entry_size; /* Total size of entry */ > > Let's use size_t, like we kind of concluded in the thread you started: > http://archives.postgresql.org/message-id/25076.1489699457%40sss.pgh.pa.us > :) Sold. > + dht_compare_function compare_function; /* Compare function */ > + dht_hash_function hash_function; /* Hash function */ > > Might be worth explaining that these need to provided when attaching > because they're possibly process local. Did you test this with > EXEC_BACKEND? Added explanation. I haven't personally tested with EXEC_BACKEND but I believe one of my colleagues had something else that uses DHT this running on a Windows box and didn't shout at me, and I see no reason to think it shouldn't work: as explained in the new comment, every attacher has to supply the function pointers from their own process space (and standard footgun rules apply if you don't supply compatible functions). > + int tranche_id; /* The tranche ID to use for locks. */ > +} dht_parameters; > > > +struct dht_iterator > +{ > + dht_hash_table *hash_table; /* The hash table we are iterating over. */ > + bool exclusive; /* Whether to lock buckets exclusively. */ > + Size partition; /* The index of the next partition to visit. */ > + Size bucket; /* The index of the next bucket to visit. */ > + dht_hash_table_item *item; /* The most recently returned item. */ > + dsa_pointer last_item_pointer; /* The last item visited. */ > + Size table_size_log2; /* The table size when we started iterating. */ > + bool locked; /* Whether the current partition is locked. */ > > Haven't gotten to the actual code yet, but this kinda suggest we leave a > partition locked when iterating? Hm, that seems likely to result in a > fair bit of pain... By default yes, but you can release the lock with dht_iterate_release_lock() and it'll be reacquired when you call dht_iterate_next(). If you do that, then you'll continue iterating after where you left off without visiting any item that you've already visited, because the pointers are stored in pointer order (even though the most recently visited item may have been freed rendering the pointer invalid, we can still use its pointer to skip everything already visited by numerical comparison without dereferencing it, and it's indeterminate whether anything added while you were unlocked is visible to you). Maintaining linked lists in a certain order sucks, but DHT doesn't allow duplicate keys and grows when load factor exceeds X so unless your hash function is busted... This is complicated, and in the category that I would normally want a stack of heavy unit tests for. If you don't feel like making decisions about this now, perhaps iteration (and incremental resize?) could be removed, leaving only the most primitive get/put hash table facilities -- just enough for this purpose? Then a later patch could add them back, with a set of really convincing unit tests... > +/* Iterating over the whole hash table. */ > +extern void dht_iterate_begin(dht_hash_table *hash_table, > + dht_iterator *iterator, bool exclusive); > +extern void *dht_iterate_next(dht_iterator *iterator); > +extern void dht_iterate_delete(dht_iterator *iterator); > > s/delete/delete_current/? Otherwise it looks like it's part of > manipulating just the iterator. Done. > +extern void dht_iterate_release(dht_iterator *iterator); > > I'd add lock to to the name. Done. > +/* > + * An item in the hash table. This wraps the user's entry object in an > + * envelop that holds a pointer back to the bucket and a pointer to the next > + * item in the bucket. > + */ > +struct dht_hash_table_item > +{ > + /* The hashed key, to avoid having to recompute it. */ > + dht_hash hash; > + /* The next item in the same bucket. */ > + dsa_pointer next; > + /* The user's entry object follows here. */ > + char entry[FLEXIBLE_ARRAY_MEMBER]; > > What's the point of using FLEXIBLE_ARRAY_MEMBER here? And isn't using a > char going to lead to alignment problems? Fixed. No longer using a member 'entry', just a comment that user data follows and a macro to find it based on MAXALIGN(sizeof(dht_hash_table_item)). > +/* The number of partitions for locking purposes. */ > +#define DHT_NUM_PARTITIONS_LOG2 7 > > Could use some justification. Added. Short version: if it's good enough for the buffer pool... > +/* > + * The head object for a hash table. This will be stored in dynamic shared > + * memory. > + */ > +typedef struct > +{ > > Why anonymous? Not that it hurts much, but seems weird to deviate just > here. Fixed. > +/* > + * Create a new hash table backed by the given dynamic shared area, with the > + * given parameters. > + */ > +dht_hash_table * > +dht_create(dsa_area *area, const dht_parameters *params) > +{ > + dht_hash_table *hash_table; > + dsa_pointer control; > + > + /* Allocate the backend-local object representing the hash table. */ > + hash_table = palloc(sizeof(dht_hash_table)); > > Should be documented that this uses caller's MemoryContext. Done. > + /* Set up the array of lock partitions. */ > + { > + int i; > + > + for (i = 0; i < DHT_NUM_PARTITIONS; ++i) > + { > + LWLockInitialize(PARTITION_LOCK(hash_table, i), > + hash_table->control->lwlock_tranche_id); > + hash_table->control->partitions[i].count = 0; > + } > > I'd store hash_table->control->lwlock_tranche_id and partitions[i] in > local vars. Possibly hash_table->control too. Tidied up. I made local vars for partitions and tranche_id. > +/* > + * Detach from a hash table. This frees backend-local resources associated > + * with the hash table, but the hash table will continue to exist until it is > + * either explicitly destroyed (by a backend that is still attached to it), or > + * the area that backs it is returned to the operating system. > + */ > +void > +dht_detach(dht_hash_table *hash_table) > +{ > + /* The hash table may have been destroyed. Just free local memory. */ > + pfree(hash_table); > +} > > Somewhat inclined to add debugging refcount - seems like bugs around > that might be annoying to find. Maybe also add an assert ensuring that > no locks are held? Added assert that not locks are held. In an earlier version I had reference counts. Then I realised that it wasn't really helping anything. The state of being 'attached' to a dht_hash_table isn't really the same as holding a heavyweight resource like a DSM segment or a file which is backed by kernel resources. 'Attaching' is just something you have to do to get a backend-local palloc()-ated object required to interact with the hash table, and since it's just a bit of memory there is no strict requirement to detach from it, if you're happy to let MemoryContext do that for you. To put it in GC terms, there is no important finalizer here. Here I am making the same distinction that we make between stuff managed by resowner.c (files etc) and stuff managed by MemoryContext (memory); in the former case it's an elog()-gable offence not to close things explicitly in non-error paths, but in the latter you're free to do that, or pfree earlier. If in future we create more things that can live in DSA memory, I'd like them to be similarly free-and-easy. Make sense? In any case this use user of DHT remains attached for the backend's lifetime. > +/* > + * Look up an entry, given a key. Returns a pointer to an entry if one can be > + * found with the given key. Returns NULL if the key is not found. If a > + * non-NULL value is returned, the entry is locked and must be released by > + * calling dht_release. If an error is raised before dht_release is called, > + * the lock will be released automatically, but the caller must take care to > + * ensure that the entry is not left corrupted. The lock mode is either > + * shared or exclusive depending on 'exclusive'. > > This API seems a bit fragile. Do you mean "... the caller must take care to ensure that the entry is not left corrupted"? This is the same as anything protected by LWLocks including shared buffers. If you error out, locks are released and you had better not have left things in a bad state. I guess this comment is really just about what C++ people call "basic exception safety". Or something else? > +/* > + * Returns a pointer to an exclusively locked item which must be released with > + * dht_release. If the key is found in the hash table, 'found' is set to true > + * and a pointer to the existing entry is returned. If the key is not found, > + * 'found' is set to false, and a pointer to a newly created entry is related. > > "is related"? Fixed. > + */ > +void * > +dht_find_or_insert(dht_hash_table *hash_table, > + const void *key, > + bool *found) > +{ > + size_t hash; > + size_t partition_index; > + dht_partition *partition; > + dht_hash_table_item *item; > + > + hash = hash_table->params.hash_function(key, hash_table->params.key_size); > + partition_index = PARTITION_FOR_HASH(hash); > + partition = &hash_table->control->partitions[partition_index]; > + > + Assert(hash_table->control->magic == DHT_MAGIC); > + Assert(!hash_table->exclusively_locked); > > Why just exclusively locked? Why'd shared be ok? It wouldn't be OK. I just didn't have the state required to assert that. Fixed. I think in future it should be allowed to lock more than one partition (conceptually more than one entry) at a time, but only after figuring out a decent API to support doing that in deadlock-avoiding order. I don't have a need or a plan for that yet. For the same reason it's not OK to use dht_find[_or_insert] while any iterator has locked a partition, which wasn't documented (is now) and isn't currently assertable. > +/* > + * Unlock an entry which was locked by dht_find or dht_find_or_insert. > + */ > +void > +dht_release(dht_hash_table *hash_table, void *entry) > +{ > + dht_hash_table_item *item = ITEM_FROM_ENTRY(entry); > + size_t partition_index = PARTITION_FOR_HASH(item->hash); > + bool deferred_resize_work = false; > + > + Assert(hash_table->control->magic == DHT_MAGIC); > > Assert lock held (LWLockHeldByMe()) Added this, and a couple more. > +/* > + * Begin iterating through the whole hash table. The caller must supply a > + * dht_iterator object, which can then be used to call dht_iterate_next to get > + * values until the end is reached. > + */ > +void > +dht_iterate_begin(dht_hash_table *hash_table, > + dht_iterator *iterator, > + bool exclusive) > +{ > + Assert(hash_table->control->magic == DHT_MAGIC); > + > + iterator->hash_table = hash_table; > + iterator->exclusive = exclusive; > + iterator->partition = 0; > + iterator->bucket = 0; > + iterator->item = NULL; > + iterator->last_item_pointer = InvalidDsaPointer; > + iterator->locked = false; > + > + /* Snapshot the size (arbitrary lock to prevent size changing). */ > + LWLockAcquire(PARTITION_LOCK(hash_table, 0), LW_SHARED); > + ensure_valid_bucket_pointers(hash_table); > + iterator->table_size_log2 = hash_table->size_log2; > + LWLockRelease(PARTITION_LOCK(hash_table, 0)); > > Hm. So we're introducing some additional contention on partition 0 - > probably ok. It would be cute to use MyProcPid % DHT_NUM_PARTITIONS, but that might be a deadlock hazard if you have multiple iterators on the go at once. Otherwise iterators only ever lock partitions in order. > +/* > + * Move to the next item in the hash table. Returns a pointer to an entry, or > + * NULL if the end of the hash table has been reached. The item is locked in > + * exclusive or shared mode depending on the argument given to > + * dht_iterate_begin. The caller can optionally release the lock by calling > + * dht_iterate_release, and then call dht_iterate_next again to move to the > + * next entry. If the iteration is in exclusive mode, client code can also > + * call dht_iterate_delete. When the end of the hash table is reached, or at > + * any time, the client may call dht_iterate_end to abandon iteration. > + */ > > I'd just shorten the end to "at any time the client may call > dht_iterate_end to ..." Done. > [snip] > + > +/* > + * Print out debugging information about the internal state of the hash table. > + */ > +void > +dht_dump(dht_hash_table *hash_table) > +{ > + size_t i; > + size_t j; > + > + Assert(hash_table->control->magic == DHT_MAGIC); > + > + for (i = 0; i < DHT_NUM_PARTITIONS; ++i) > + LWLockAcquire(PARTITION_LOCK(hash_table, i), LW_SHARED); > > Should probably assert & document that no locks are held - otherwise > there's going to be ugly deadlocks. And that's an unlikely thing to try. OK. > [snip] > +} > > I'd put this below actual "production" code. Done. On Tue, Aug 1, 2017 at 9:08 AM, Andres Freund <andres@anarazel.de> wrote: > Hi, > > diff --git a/src/backend/access/common/tupdesc.c b/src/backend/access/common/tupdesc.c > index 9fd7b4e019b..97c0125a4ba 100644 > --- a/src/backend/access/common/tupdesc.c > +++ b/src/backend/access/common/tupdesc.c > @@ -337,17 +337,75 @@ DecrTupleDescRefCount(TupleDesc tupdesc) > { > Assert(tupdesc->tdrefcount > 0); > > - ResourceOwnerForgetTupleDesc(CurrentResourceOwner, tupdesc); > + if (CurrentResourceOwner != NULL) > + ResourceOwnerForgetTupleDesc(CurrentResourceOwner, tupdesc); > if (--tupdesc->tdrefcount == 0) > FreeTupleDesc(tupdesc); > } > > What's this about? CurrentResourceOwner should always be valid here, no? > If so, why did that change? I don't think it's good to detach this from > the resowner infrastructure... The reason is that I install a detach hook shared_record_typmod_registry_detach() in worker processes to clear out their typmod registry. It runs at a time when there is no CurrentResourceOwner. It's a theoretical concern only today, because workers are not reused. If a workers lingered in a waiting room and then attached to a new session DSM from a different leader, then it needs to remember nothing of the previous leader's typmods. > /* > - * Compare two TupleDesc structures for logical equality > + * Compare two TupleDescs' attributes for logical equality > * > * Note: we deliberately do not check the attrelid and tdtypmod fields. > * This allows typcache.c to use this routine to see if a cached record type > * matches a requested type, and is harmless for relcache.c's uses. > + */ > +bool > +equalTupleDescAttrs(Form_pg_attribute attr1, Form_pg_attribute attr2) > +{ > > comment not really accurate, this routine afaik isn't used by > typcache.c? I removed this whole hunk and left equalTupleDescs() alone, because I no longer needed to make that change in this new version. See below. > /* > - * Magic numbers for parallel state sharing. Higher-level code should use > - * smaller values, leaving these very large ones for use by this module. > + * Magic numbers for per-context parallel state sharing. Higher-level code > + * should use smaller values, leaving these very large ones for use by this > + * module. > */ > #define PARALLEL_KEY_FIXED UINT64CONST(0xFFFFFFFFFFFF0001) > #define PARALLEL_KEY_ERROR_QUEUE UINT64CONST(0xFFFFFFFFFFFF0002) > @@ -63,6 +74,16 @@ > #define PARALLEL_KEY_ACTIVE_SNAPSHOT UINT64CONST(0xFFFFFFFFFFFF0007) > #define PARALLEL_KEY_TRANSACTION_STATE UINT64CONST(0xFFFFFFFFFFFF0008) > #define PARALLEL_KEY_ENTRYPOINT UINT64CONST(0xFFFFFFFFFFFF0009) > +#define PARALLEL_KEY_SESSION_DSM UINT64CONST(0xFFFFFFFFFFFF000A) > + > +/* Magic number for per-session DSM TOC. */ > +#define PARALLEL_SESSION_MAGIC 0xabb0fbc9 > + > +/* > + * Magic numbers for parallel state sharing in the per-session DSM area. > + */ > +#define PARALLEL_KEY_SESSION_DSA UINT64CONST(0xFFFFFFFFFFFF0001) > +#define PARALLEL_KEY_RECORD_TYPMOD_REGISTRY UINT64CONST(0xFFFFFFFFFFFF0002) > > Not this patch's fault, but this infrastructure really isn't great. We > should really replace it with a shmem.h style infrastructure, using a > dht hashtable as backing... Well, I am trying to use the established programming style. We already have a per-query DSM with a TOC indexed by magic numbers (and executor node IDs). I add a per-session DSM with a TOC indexed by a different set of magic numbers. We could always come up with something better and fix it in both places later? > +/* The current per-session DSM segment, if attached. */ > +static dsm_segment *current_session_segment = NULL; > + > > I think it'd be better if we had a proper 'SessionState' and > 'BackendSessionState' infrastructure that then contains the dsm segment > etc. I think we'll otherwise just end up with a bunch of parallel > infrastructures. I'll have to come back to you on this one. > +/* > + * A mechanism for sharing record typmods between backends. > + */ > +struct SharedRecordTypmodRegistry > +{ > + dht_hash_table_handle atts_index_handle; > + dht_hash_table_handle typmod_index_handle; > + pg_atomic_uint32 next_typmod; > +}; > + > > I think the code needs to explain better how these are intended to be > used. IIUC, atts_index is used to find typmods by "identity", and > typmod_index by the typmod, right? And we need both to avoid > all workers generating different tupledescs, right? Kinda guessable by > reading typecache.c, but that shouldn't be needed. Fixed. > +/* > + * A flattened/serialized representation of a TupleDesc for use in shared > + * memory. Can be converted to and from regular TupleDesc format. Doesn't > + * support constraints and doesn't store the actual type OID, because this is > + * only for use with RECORD types as created by CreateTupleDesc(). These are > + * arranged into a linked list, in the hash table entry corresponding to the > + * OIDs of the first 16 attributes, so we'd expect to get more than one entry > + * in the list when named and other properties differ. > + */ > +typedef struct SerializedTupleDesc > +{ > + dsa_pointer next; /* next with the same same attribute OIDs */ > + int natts; /* number of attributes in the tuple */ > + int32 typmod; /* typmod for tuple type */ > + bool hasoid; /* tuple has oid attribute in its header */ > + > + /* > + * The attributes follow. We only ever access the first > + * ATTRIBUTE_FIXED_PART_SIZE bytes of each element, like the code in > + * tupdesc.c. > + */ > + FormData_pg_attribute attributes[FLEXIBLE_ARRAY_MEMBER]; > +} SerializedTupleDesc; > > Not a fan of a separate tupledesc representation, that's just going to > lead to divergence over time. I think we should rather change the normal > tupledesc representation to be compatible with this, and 'just' have a > wrapper struct for the parallel case (with next and such). OK. I killed this. Instead I flattened tupleDesc to make it usable directly in shared memory as long as there are no constraints. There is still a small wrapper SharedTupleDesc, but that's just to bolt a 'next' pointer to them so we can chain together TupleDescs with the same OIDs. The new 0001 patch changes tupdesc->attrs[i]->foo with TupleDescAttr(tupdesc, i)->foo everywhere in the tree, so that the change from attrs[i] to &attrs[i] can be hidden. > +/* > + * An entry in SharedRecordTypmodRegistry's attribute index. The key is the > + * first REC_HASH_KEYS attribute OIDs. That means that collisions are > + * possible, but that's OK because SerializedTupleDesc objects are arranged > + * into a list. > + */ > > +/* Parameters for SharedRecordTypmodRegistry's attributes hash table. */ > +const static dht_parameters srtr_atts_index_params = { > + sizeof(Oid) * REC_HASH_KEYS, > + sizeof(SRTRAttsIndexEntry), > + memcmp, > + tag_hash, > + LWTRANCHE_SHARED_RECORD_ATTS_INDEX > +}; > + > +/* Parameters for SharedRecordTypmodRegistry's typmod hash table. */ > +const static dht_parameters srtr_typmod_index_params = { > + sizeof(uint32), > + sizeof(SRTRTypmodIndexEntry), > + memcmp, > + tag_hash, > + LWTRANCHE_SHARED_RECORD_TYPMOD_INDEX > +}; > + > > I'm very much not a fan of this representation. I know you copied the > logic, but I think it's a bad idea. I think the key should just be a > dsa_pointer, and then we can have a proper tag_hash that hashes the > whole thing, and a proper comparator too. Just have > > /* > * Combine two hash values, resulting in another hash value, with decent bit > * mixing. > * > * Similar to boost's hash_combine(). > */ > static inline uint32 > hash_combine(uint32 a, uint32 b) > { > a ^= b + 0x9e3779b9 + (a << 6) + (a >> 2); > return a; > } > > and then hash everything. Hmm. I'm not sure I understand. I know what hash_combine is for but what do you mean when you say they key should just be a dsa_pointer? What's wrong with providing the key size, whole entry size, compare function and hash function like this? > +/* > + * Make sure that RecordCacheArray is large enough to store 'typmod'. > + */ > +static void > +ensure_record_cache_typmod_slot_exists(int32 typmod) > +{ > + if (RecordCacheArray == NULL) > + { > + RecordCacheArray = (TupleDesc *) > + MemoryContextAllocZero(CacheMemoryContext, 64 * sizeof(TupleDesc)); > + RecordCacheArrayLen = 64; > + } > + > + if (typmod >= RecordCacheArrayLen) > + { > + int32 newlen = RecordCacheArrayLen * 2; > + > + while (typmod >= newlen) > + newlen *= 2; > + > + RecordCacheArray = (TupleDesc *) repalloc(RecordCacheArray, > + newlen * sizeof(TupleDesc)); > + memset(RecordCacheArray + RecordCacheArrayLen, 0, > + (newlen - RecordCacheArrayLen) * sizeof(TupleDesc *)); > + RecordCacheArrayLen = newlen; > + } > +} > > Do we really want to keep this? Could just have an equivalent dynahash > for the non-parallel case? Hmm. Well the plain old array makes a lot of sense in the non-parallel case, since we allocate typmods starting from zero. What don't you like about it? The reason for using an array for backend-local lookup (aside from "that's how it is already") is that it's actually the best data structure for the job; the reason for using a hash table in the shared case is that it gives you locking and coordinates growth for free. (For the OID index it has to be a hash table in both cases.) > /* > * lookup_rowtype_tupdesc_internal --- internal routine to lookup a rowtype > @@ -1229,15 +1347,49 @@ lookup_rowtype_tupdesc_internal(Oid type_id, int32 typmod, bool noError) > /* > * It's a transient record type, so look in our record-type table. > */ > - if (typmod < 0 || typmod >= NextRecordTypmod) > + if (typmod >= 0) > { > - if (!noError) > - ereport(ERROR, > - (errcode(ERRCODE_WRONG_OBJECT_TYPE), > - errmsg("record type has not been registered"))); > - return NULL; > + /* It is already in our local cache? */ > + if (typmod < RecordCacheArrayLen && > + RecordCacheArray[typmod] != NULL) > + return RecordCacheArray[typmod]; > + > + /* Are we attached to a SharedRecordTypmodRegistry? */ > + if (CurrentSharedRecordTypmodRegistry.shared != NULL) > > Why do we want to do lookups in both? I don't think it's a good idea to > have a chance that you could have the same typmod in both the local > registry (because it'd been created before the shared one) and in the > shared (because it was created in a worker). Ah, that's for caching > purposes? If so, see my above point that we shouldn't have a serialized > version of typdesc (yesyes, constraints will be a bit ugly). Right, that's what I've now done. It's basically a write-through cache: we'll try to find it in the backend local structures and then fall back to the shared one. But if we find it in shared memory, we'll just copy the pointer it into our local data structures. In the last version I'd build a new TupleDesc from the serialized form, but now there is no serialized form, just TupleDesc objects which are now shmem-friendly (except for constraints, which do not survive the matter transfer into shmem; see TupleDescCopy). > + /* > + * While we still hold the atts_index entry locked, add this to > + * typmod_index. That's important because we don't want anyone to be able > + * to find a typmod via the former that can't yet be looked up in the > + * latter. > + */ > + typmod_index_entry = > + dht_find_or_insert(CurrentSharedRecordTypmodRegistry.typmod_index, > + &typmod, &found); > + if (found) > + elog(ERROR, "cannot create duplicate shared record typmod"); > + typmod_index_entry->typmod = typmod; > + typmod_index_entry->serialized_tupdesc = serialized_dp; > + dht_release(CurrentSharedRecordTypmodRegistry.typmod_index, > + typmod_index_entry); > > What if we fail to allocate memory for the entry in typmod_index? Well, I was careful to make sure that it was only pushed onto the list in the atts_index entry until after we'd successfully allocated entries in both indexes, so there was no way to exit from this function leaving a TupleDesc in one index but not the other. In other words, it might have created an atts_index entry but it'd have an empty list. But yeah, on reflection we shouldn't leak shared_dp in that case. In this version I added PG_CATCH() to dsa_free() it and PG_RETHROW(). More testing and review needed. -- Thomas Munro http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Вложения
On Fri, Aug 11, 2017 at 4:39 AM, Thomas Munro <thomas.munro@enterprisedb.com> wrote: > OK. Now it's ds_hash_table.{c,h}, where "ds" stands for "dynamic > shared". Better? If we were to do other data structures in DSA > memory they could follow that style: ds_red_black_tree.c, ds_vector.c, > ds_deque.c etc and their identifier prefix would be drbt_, dv_, dd_ > etc. > > Do you want to see a separate patch to rename dsa.c? Got a better > name? You could have spoken up earlier :-) It does sound like a bit > like the thing from crypto or perhaps a scary secret government > department. I doubt that we really want to have accessor functions with names like dynamic_shared_hash_table_insert or ds_hash_table_insert. Long names are fine, even desirable, for APIs that aren't too widely used, because they're relatively self-documenting, but a 30-character function name gets annoying in a hurry if you have to call it very often, and this is intended to be reusable for other things that want a dynamic shared memory hash table. I think we should (a) pick some reasonably short prefix for all the function names, like dht or dsht or ds_hash, but not ds_hash_table or dynamic_shared_hash_table and (b) also use that prefix as the name for the .c and .h files. Right now, we've got a situation where the most widely-used hash table implementation uses dynahash.c for the code, hsearch.h for the interface, and "hash" as the prefix for the names, and that's really hard to remember. I think having a consistent naming scheme throughout would be a lot better. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
On 2017-08-11 11:14:44 -0400, Robert Haas wrote: > On Fri, Aug 11, 2017 at 4:39 AM, Thomas Munro > <thomas.munro@enterprisedb.com> wrote: > > OK. Now it's ds_hash_table.{c,h}, where "ds" stands for "dynamic > > shared". Better? If we were to do other data structures in DSA > > memory they could follow that style: ds_red_black_tree.c, ds_vector.c, > > ds_deque.c etc and their identifier prefix would be drbt_, dv_, dd_ > > etc. > > > > Do you want to see a separate patch to rename dsa.c? Got a better > > name? You could have spoken up earlier :-) It does sound like a bit > > like the thing from crypto or perhaps a scary secret government > > department. I, and I bet a lot of other people, kind of missed dsa being merged for a while... > I doubt that we really want to have accessor functions with names like > dynamic_shared_hash_table_insert or ds_hash_table_insert. Long names > are fine, even desirable, for APIs that aren't too widely used, > because they're relatively self-documenting, but a 30-character > function name gets annoying in a hurry if you have to call it very > often, and this is intended to be reusable for other things that want > a dynamic shared memory hash table. I think we should (a) pick some > reasonably short prefix for all the function names, like dht or dsht > or ds_hash, but not ds_hash_table or dynamic_shared_hash_table and (b) > also use that prefix as the name for the .c and .h files. Yea, I agree with this. Something dsmhash_{insert,...}... seems like it'd kinda work without being too ambiguous like dht imo is, while still being reasonably short. > Right now, we've got a situation where the most widely-used hash table > implementation uses dynahash.c for the code, hsearch.h for the > interface, and "hash" as the prefix for the names, and that's really > hard to remember. I think having a consistent naming scheme > throughout would be a lot better. Yea, that situation still occasionally confuses me, a good 10 years after starting to look at pg... There's even a a dynahash.h, except it's useless. And dynahash.c doesn't even include hsearch.h directly (included via shmem.h)! Personally I'd actually in favor of moving hsearch.h stuff into dynahash.h and leave hsearch as a wrapper. - Andres
Hi, On 2017-08-11 20:39:13 +1200, Thomas Munro wrote: > Please find attached a new patch series. I apologise in advance for > 0001 and note that the patchset now weighs in at ~75kB compressed. > Here are my in-line replies to your two reviews: Replying to a few points here, then I'll do a pass through your your submission... > On Tue, Jul 25, 2017 at 10:09 PM, Andres Freund <andres@anarazel.de> wrote: > > It does concern me that we're growing yet another somewhat different > > hashtable implementation. Yet I don't quite see how we could avoid > > it. dynahash relies on proper pointers, simplehash doesn't do locking > > (and shouldn't) and also relies on pointers, although to a much lesser > > degree. All the open coded tables aren't a good match either. So I > > don't quite see an alternative, but I'd love one. > > Yeah, I agree. To deal with data structures with different pointer > types, locking policy, inlined hash/eq functions etc, perhaps there is > a way we could eventually do 'policy based design' using the kind of > macro trickery you started where we generate N different hash table > variations but only have to maintain source code for one chaining hash > table implementation? Or perl scripts that effectively behave as a > cfront^H^H^H nevermind. I'm not planning to investigate that for this > cycle. Whaaa, what have I done!!!! But more seriously, I'm doubtful it's worth going there. > > + * level. However, when a resize operation begins, all partition locks must > > + * be acquired simultaneously for a brief period. This is only expected to > > + * happen a small number of times until a stable size is found, since growth is > > + * geometric. > > > > I'm a bit doubtful that we need partitioning at this point, and that it > > doesn't actually *degrade* performance for your typmod case. > > Yeah, partitioning not needed for this case, but this is supposed to > be more generally useful. I thought about making the number of > partitions a construction parameter, but it doesn't really hurt does > it? Well, using multiple locks and such certainly isn't free. An exclusively owned cacheline mutex is nearly an order of magnitude faster than one that's currently shared, not to speak of modified. Also it does increase the size overhead, which might end up happening for a few other cases. > > + * Resizing is done incrementally so that no individual insert operation pays > > + * for the potentially large cost of splitting all buckets. > > > > I'm not sure this is a reasonable tradeoff for the use-case suggested so > > far, it doesn't exactly make things simpler. We're not going to grow > > much. > > Yeah, designed to be more generally useful. Are you saying you would > prefer to see the DHT patch split into an initial submission that does > the simplest thing possible, so that the unlucky guy who causes the > hash table to grow has to do all the work of moving buckets to a > bigger hash table? Then we could move the more complicated > incremental growth stuff to a later patch. Well, most of the potential usecases for dsmhash I've heard about so far, don't actually benefit much from incremental growth. In nearly all the implementations I've seen incremental move ends up requiring more total cycles than doing it at once, and for parallelism type usecases the stall isn't really an issue. So yes, I think this is something worth considering. If we were to actually use DHT for shared caches or such, this'd be different, but that seems darned far off. > This is complicated, and in the category that I would normally want a > stack of heavy unit tests for. If you don't feel like making > decisions about this now, perhaps iteration (and incremental resize?) > could be removed, leaving only the most primitive get/put hash table > facilities -- just enough for this purpose? Then a later patch could > add them back, with a set of really convincing unit tests... I'm inclined to go for that, yes. > > +/* > > + * Detach from a hash table. This frees backend-local resources associated > > + * with the hash table, but the hash table will continue to exist until it is > > + * either explicitly destroyed (by a backend that is still attached to it), or > > + * the area that backs it is returned to the operating system. > > + */ > > +void > > +dht_detach(dht_hash_table *hash_table) > > +{ > > + /* The hash table may have been destroyed. Just free local memory. */ > > + pfree(hash_table); > > +} > > > > Somewhat inclined to add debugging refcount - seems like bugs around > > that might be annoying to find. Maybe also add an assert ensuring that > > no locks are held? > > Added assert that not locks are held. > > In an earlier version I had reference counts. Then I realised that it > wasn't really helping anything. The state of being 'attached' to a > dht_hash_table isn't really the same as holding a heavyweight resource > like a DSM segment or a file which is backed by kernel resources. > 'Attaching' is just something you have to do to get a backend-local > palloc()-ated object required to interact with the hash table, and > since it's just a bit of memory there is no strict requirement to > detach from it, if you're happy to let MemoryContext do that for you. > To put it in GC terms, there is no important finalizer here. Here I > am making the same distinction that we make between stuff managed by > resowner.c (files etc) and stuff managed by MemoryContext (memory); in > the former case it's an elog()-gable offence not to close things > explicitly in non-error paths, but in the latter you're free to do > that, or pfree earlier. If in future we create more things that can > live in DSA memory, I'd like them to be similarly free-and-easy. Make > sense? I don't quite follow. You're saying that just because there could be local bugs (which'd easily be found via the mcxt/aset debugging stuff and/or valgrind) making sure about the shared resources still being there isn't useful? I don't quite find that convincing... > > +/* > > + * Look up an entry, given a key. Returns a pointer to an entry if one can be > > + * found with the given key. Returns NULL if the key is not found. If a > > + * non-NULL value is returned, the entry is locked and must be released by > > + * calling dht_release. If an error is raised before dht_release is called, > > + * the lock will be released automatically, but the caller must take care to > > + * ensure that the entry is not left corrupted. The lock mode is either > > + * shared or exclusive depending on 'exclusive'. > > > > This API seems a bit fragile. > > Do you mean "... the caller must take care to ensure that the entry is > not left corrupted"? Yes. > This is the same as anything protected by LWLocks including shared > buffers. If you error out, locks are released and you had better not > have left things in a bad state. I guess this comment is really just > about what C++ people call "basic exception safety". Kind. Although it's not impossible to make this bit less error prone. E.g. by zeroing the entry before returning. Now that I think about it, it's possibly also worthwhile to note that any iterators and such are invalid after errors (given that ->locked is going to be wrong)? > > diff --git a/src/backend/access/common/tupdesc.c b/src/backend/access/common/tupdesc.c > > index 9fd7b4e019b..97c0125a4ba 100644 > > --- a/src/backend/access/common/tupdesc.c > > +++ b/src/backend/access/common/tupdesc.c > > @@ -337,17 +337,75 @@ DecrTupleDescRefCount(TupleDesc tupdesc) > > { > > Assert(tupdesc->tdrefcount > 0); > > > > - ResourceOwnerForgetTupleDesc(CurrentResourceOwner, tupdesc); > > + if (CurrentResourceOwner != NULL) > > + ResourceOwnerForgetTupleDesc(CurrentResourceOwner, tupdesc); > > if (--tupdesc->tdrefcount == 0) > > FreeTupleDesc(tupdesc); > > } > > > > What's this about? CurrentResourceOwner should always be valid here, no? > > If so, why did that change? I don't think it's good to detach this from > > the resowner infrastructure... > > The reason is that I install a detach hook > shared_record_typmod_registry_detach() in worker processes to clear > out their typmod registry. It runs at a time when there is no > CurrentResourceOwner. It's a theoretical concern only today, because > workers are not reused. If a workers lingered in a waiting room and > then attached to a new session DSM from a different leader, then it > needs to remember nothing of the previous leader's typmods. Hm. I'm not sure I like adhoc code like this. Wouldn't it be better to have a 'per worker' rather than 'per transaction" resowner for things like this? Otherwise we end up with various datastructures to keep track of things. > > /* > > - * Magic numbers for parallel state sharing. Higher-level code should use > > - * smaller values, leaving these very large ones for use by this module. > > + * Magic numbers for per-context parallel state sharing. Higher-level code > > + * should use smaller values, leaving these very large ones for use by this > > + * module. > > */ > > #define PARALLEL_KEY_FIXED UINT64CONST(0xFFFFFFFFFFFF0001) > > #define PARALLEL_KEY_ERROR_QUEUE UINT64CONST(0xFFFFFFFFFFFF0002) > > @@ -63,6 +74,16 @@ > > #define PARALLEL_KEY_ACTIVE_SNAPSHOT UINT64CONST(0xFFFFFFFFFFFF0007) > > #define PARALLEL_KEY_TRANSACTION_STATE UINT64CONST(0xFFFFFFFFFFFF0008) > > #define PARALLEL_KEY_ENTRYPOINT UINT64CONST(0xFFFFFFFFFFFF0009) > > +#define PARALLEL_KEY_SESSION_DSM UINT64CONST(0xFFFFFFFFFFFF000A) > > + > > +/* Magic number for per-session DSM TOC. */ > > +#define PARALLEL_SESSION_MAGIC 0xabb0fbc9 > > + > > +/* > > + * Magic numbers for parallel state sharing in the per-session DSM area. > > + */ > > +#define PARALLEL_KEY_SESSION_DSA UINT64CONST(0xFFFFFFFFFFFF0001) > > +#define PARALLEL_KEY_RECORD_TYPMOD_REGISTRY UINT64CONST(0xFFFFFFFFFFFF0002) > > > > Not this patch's fault, but this infrastructure really isn't great. We > > should really replace it with a shmem.h style infrastructure, using a > > dht hashtable as backing... > > Well, I am trying to use the established programming style. We > already have a per-query DSM with a TOC indexed by magic numbers (and > executor node IDs). I add a per-session DSM with a TOC indexed by a > different set of magic numbers. We could always come up with > something better and fix it in both places later? I guess so. I know Robert is a bit tired of me harping about this, but I really don't think this is great... > > +/* > > + * A flattened/serialized representation of a TupleDesc for use in shared > > + * memory. Can be converted to and from regular TupleDesc format. Doesn't > > + * support constraints and doesn't store the actual type OID, because this is > > + * only for use with RECORD types as created by CreateTupleDesc(). These are > > + * arranged into a linked list, in the hash table entry corresponding to the > > + * OIDs of the first 16 attributes, so we'd expect to get more than one entry > > + * in the list when named and other properties differ. > > + */ > > +typedef struct SerializedTupleDesc > > +{ > > + dsa_pointer next; /* next with the same same attribute OIDs */ > > + int natts; /* number of attributes in the tuple */ > > + int32 typmod; /* typmod for tuple type */ > > + bool hasoid; /* tuple has oid attribute in its header */ > > + > > + /* > > + * The attributes follow. We only ever access the first > > + * ATTRIBUTE_FIXED_PART_SIZE bytes of each element, like the code in > > + * tupdesc.c. > > + */ > > + FormData_pg_attribute attributes[FLEXIBLE_ARRAY_MEMBER]; > > +} SerializedTupleDesc; > > > > Not a fan of a separate tupledesc representation, that's just going to > > lead to divergence over time. I think we should rather change the normal > > tupledesc representation to be compatible with this, and 'just' have a > > wrapper struct for the parallel case (with next and such). > > OK. I killed this. Instead I flattened tupleDesc to make it usable > directly in shared memory as long as there are no constraints. There > is still a small wrapper SharedTupleDesc, but that's just to bolt a > 'next' pointer to them so we can chain together TupleDescs with the > same OIDs. Yep, that makes sense. > > +/* > > + * An entry in SharedRecordTypmodRegistry's attribute index. The key is the > > + * first REC_HASH_KEYS attribute OIDs. That means that collisions are > > + * possible, but that's OK because SerializedTupleDesc objects are arranged > > + * into a list. > > + */ > > > > +/* Parameters for SharedRecordTypmodRegistry's attributes hash table. */ > > +const static dht_parameters srtr_atts_index_params = { > > + sizeof(Oid) * REC_HASH_KEYS, > > + sizeof(SRTRAttsIndexEntry), > > + memcmp, > > + tag_hash, > > + LWTRANCHE_SHARED_RECORD_ATTS_INDEX > > +}; > > + > > +/* Parameters for SharedRecordTypmodRegistry's typmod hash table. */ > > +const static dht_parameters srtr_typmod_index_params = { > > + sizeof(uint32), > > + sizeof(SRTRTypmodIndexEntry), > > + memcmp, > > + tag_hash, > > + LWTRANCHE_SHARED_RECORD_TYPMOD_INDEX > > +}; > > + > > > > I'm very much not a fan of this representation. I know you copied the > > logic, but I think it's a bad idea. I think the key should just be a > > dsa_pointer, and then we can have a proper tag_hash that hashes the > > whole thing, and a proper comparator too. Just have > > > > /* > > * Combine two hash values, resulting in another hash value, with decent bit > > * mixing. > > * > > * Similar to boost's hash_combine(). > > */ > > static inline uint32 > > hash_combine(uint32 a, uint32 b) > > { > > a ^= b + 0x9e3779b9 + (a << 6) + (a >> 2); > > return a; > > } > > > > and then hash everything. > > Hmm. I'm not sure I understand. I know what hash_combine is for but > what do you mean when you say they key should just be a dsa_pointer? > What's wrong with providing the key size, whole entry size, compare > function and hash function like this? Well, right now the key is "sizeof(Oid) * REC_HASH_KEYS" which imo is fairly ugly. Both because it wastes space for narrow cases, and because it leads to conflicts for wide ones. By having a dsa_pointer as a key and custom hash/compare functions there's no need for that, you can just compute the hash based on all keys, and compare based on all keys. > > +/* > > + * Make sure that RecordCacheArray is large enough to store 'typmod'. > > + */ > > +static void > > +ensure_record_cache_typmod_slot_exists(int32 typmod) > > +{ > > + if (RecordCacheArray == NULL) > > + { > > + RecordCacheArray = (TupleDesc *) > > + MemoryContextAllocZero(CacheMemoryContext, 64 * sizeof(TupleDesc)); > > + RecordCacheArrayLen = 64; > > + } > > + > > + if (typmod >= RecordCacheArrayLen) > > + { > > + int32 newlen = RecordCacheArrayLen * 2; > > + > > + while (typmod >= newlen) > > + newlen *= 2; > > + > > + RecordCacheArray = (TupleDesc *) repalloc(RecordCacheArray, > > + newlen * sizeof(TupleDesc)); > > + memset(RecordCacheArray + RecordCacheArrayLen, 0, > > + (newlen - RecordCacheArrayLen) * sizeof(TupleDesc *)); > > + RecordCacheArrayLen = newlen; > > + } > > +} > > > > Do we really want to keep this? Could just have an equivalent dynahash > > for the non-parallel case? > > Hmm. Well the plain old array makes a lot of sense in the > non-parallel case, since we allocate typmods starting from zero. What > don't you like about it? The reason for using an array for > backend-local lookup (aside from "that's how it is already") is that > it's actually the best data structure for the job; the reason for > using a hash table in the shared case is that it gives you locking and > coordinates growth for free. (For the OID index it has to be a hash > table in both cases.) Well, that reason kinda vanished after the parallelism introduction, no? There's no guarantee at all anymore that it's gapless - it's perfectly possible that each worker ends up with a distinct set of ids. Greetings, Andres Freund
Thanks for your feedback. Here are two parts that jumped out at me. I'll address the other parts in a separate email. On Sat, Aug 12, 2017 at 1:55 PM, Andres Freund <andres@anarazel.de> wrote: >> This is complicated, and in the category that I would normally want a >> stack of heavy unit tests for. If you don't feel like making >> decisions about this now, perhaps iteration (and incremental resize?) >> could be removed, leaving only the most primitive get/put hash table >> facilities -- just enough for this purpose? Then a later patch could >> add them back, with a set of really convincing unit tests... > > I'm inclined to go for that, yes. I will make it so. >> > +/* >> > + * An entry in SharedRecordTypmodRegistry's attribute index. The key is the >> > + * first REC_HASH_KEYS attribute OIDs. That means that collisions are >> > + * possible, but that's OK because SerializedTupleDesc objects are arranged >> > + * into a list. >> > + */ >> > >> > +/* Parameters for SharedRecordTypmodRegistry's attributes hash table. */ >> > +const static dht_parameters srtr_atts_index_params = { >> > + sizeof(Oid) * REC_HASH_KEYS, >> > + sizeof(SRTRAttsIndexEntry), >> > + memcmp, >> > + tag_hash, >> > + LWTRANCHE_SHARED_RECORD_ATTS_INDEX >> > +}; >> > + >> > +/* Parameters for SharedRecordTypmodRegistry's typmod hash table. */ >> > +const static dht_parameters srtr_typmod_index_params = { >> > + sizeof(uint32), >> > + sizeof(SRTRTypmodIndexEntry), >> > + memcmp, >> > + tag_hash, >> > + LWTRANCHE_SHARED_RECORD_TYPMOD_INDEX >> > +}; >> > + >> > >> > I'm very much not a fan of this representation. I know you copied the >> > logic, but I think it's a bad idea. I think the key should just be a >> > dsa_pointer, and then we can have a proper tag_hash that hashes the >> > whole thing, and a proper comparator too. Just have >> > >> > /* >> > * Combine two hash values, resulting in another hash value, with decent bit >> > * mixing. >> > * >> > * Similar to boost's hash_combine(). >> > */ >> > static inline uint32 >> > hash_combine(uint32 a, uint32 b) >> > { >> > a ^= b + 0x9e3779b9 + (a << 6) + (a >> 2); >> > return a; >> > } >> > >> > and then hash everything. >> >> Hmm. I'm not sure I understand. I know what hash_combine is for but >> what do you mean when you say they key should just be a dsa_pointer? > >> What's wrong with providing the key size, whole entry size, compare >> function and hash function like this? > > Well, right now the key is "sizeof(Oid) * REC_HASH_KEYS" which imo is > fairly ugly. Both because it wastes space for narrow cases, and because > it leads to conflicts for wide ones. By having a dsa_pointer as a key > and custom hash/compare functions there's no need for that, you can just > compute the hash based on all keys, and compare based on all keys. Ah, that. Yeah, it is ugly, both in the pre-existing code and in my patch. Stepping back from this a bit more, the true key here not an array of Oid at all (whether fixed sized or variable). It's actually a whole TupleDesc, because this is really a TupleDesc intern pool: given a TupleDesc, please give me the canonical TupleDesc equal to this one. You might call it a hash set rather than a hash table (key->value associative). Ideally, we'd get rid of the ugly REC_HASH_KEYS-sized key and the ugly extra conflict chain, and tupdesc.c would have a hashTupleDesc() function that is compatible with equalTupleDescs(). Then the hash table entry would simply be a TupleDesc (that is, a pointer). There is an extra complication when we use DSA memory though: If you have a hash table (set) full of dsa_pointer to struct tupleDesc but want to be able to search it given a TupleDesc (= backend local pointer) then you have to do some extra work. I think that work is: the hash table entries should be a small struct that has a union { dsa_pointer, TupleDesc } and a discriminator field to say which it is, and the hash + eq functions should be wrappers that follow dsa_pointer if needed and then forward to hashTupleDesc() (a function that does hash_combine() over the Oids) and equalTupleDescs(). (That complication might not exist if tupleDesc were fixed size and could be directly in the hash table entry, but in the process of flattening it (= holding the attributes in it) I made it variable size, so we have to use a pointer to it in the hash table since both DynaHash and DHT work with fixed size entries). Thoughts? -- Thomas Munro http://www.enterprisedb.com
On Fri, Aug 11, 2017 at 9:55 PM, Andres Freund <andres@anarazel.de> wrote: > Well, most of the potential usecases for dsmhash I've heard about so > far, don't actually benefit much from incremental growth. In nearly all > the implementations I've seen incremental move ends up requiring more > total cycles than doing it at once, and for parallelism type usecases > the stall isn't really an issue. So yes, I think this is something > worth considering. If we were to actually use DHT for shared caches or > such, this'd be different, but that seems darned far off. I think it'd be pretty interesting to look at replacing parts of the stats collector machinery with something DHT-based. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
On 2017-08-12 22:52:57 -0400, Robert Haas wrote: > On Fri, Aug 11, 2017 at 9:55 PM, Andres Freund <andres@anarazel.de> wrote: > > Well, most of the potential usecases for dsmhash I've heard about so > > far, don't actually benefit much from incremental growth. In nearly all > > the implementations I've seen incremental move ends up requiring more > > total cycles than doing it at once, and for parallelism type usecases > > the stall isn't really an issue. So yes, I think this is something > > worth considering. If we were to actually use DHT for shared caches or > > such, this'd be different, but that seems darned far off. > > I think it'd be pretty interesting to look at replacing parts of the > stats collector machinery with something DHT-based. That seems to involve a lot more than this though, given that currently the stats collector data doesn't entirely have to be in memory. I've seen sites with a lot of databases with quite some per-database stats data. Don't think we can just require that to be in memory :( - Andres
On Sat, Aug 12, 2017 at 11:30 PM, Andres Freund <andres@anarazel.de> wrote: > That seems to involve a lot more than this though, given that currently > the stats collector data doesn't entirely have to be in memory. I've > seen sites with a lot of databases with quite some per-database stats > data. Don't think we can just require that to be in memory :( Hmm. I'm not sure it wouldn't end up being *less* memory. Don't we end up caching 1 copy of it per backend, at least for the database to which that backend is connected? Accessing a shared copy would avoid that sort of thing. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
Robert Haas <robertmhaas@gmail.com> writes: > On Sat, Aug 12, 2017 at 11:30 PM, Andres Freund <andres@anarazel.de> wrote: >> That seems to involve a lot more than this though, given that currently >> the stats collector data doesn't entirely have to be in memory. I've >> seen sites with a lot of databases with quite some per-database stats >> data. Don't think we can just require that to be in memory :( > Hmm. I'm not sure it wouldn't end up being *less* memory. Don't we > end up caching 1 copy of it per backend, at least for the database to > which that backend is connected? Accessing a shared copy would avoid > that sort of thing. Yeah ... the collector itself has got all that in memory anyway. We do need to think about synchronization issues if we make that memory globally available, but I find it hard to see how that would lead to more memory consumption overall than what happens now. regards, tom lane
Hi, On 2017-08-11 20:39:13 +1200, Thomas Munro wrote: > Please find attached a new patch series. Review for 0001: I think you made a few long lines even longer, like: @@ -1106,11 +1106,11 @@ pltcl_trigger_handler(PG_FUNCTION_ARGS, pltcl_call_state *call_state, Tcl_ListObjAppendElement(NULL,tcl_trigtup, Tcl_NewObj()); for (i = 0; i < tupdesc->natts; i++) { - if (tupdesc->attrs[i]->attisdropped) + if (TupleDescAttr(tupdesc, i)->attisdropped) Tcl_ListObjAppendElement(NULL, tcl_trigtup, Tcl_NewObj()); else Tcl_ListObjAppendElement(NULL, tcl_trigtup, - Tcl_NewStringObj(utf_e2u(NameStr(tupdesc->attrs[i]->attname)), -1)); + Tcl_NewStringObj(utf_e2u(NameStr(TupleDescAttr(tupdesc, i)->attname)), -1)); as it's not particularly pretty to access tupdesc->attrs[i] repeatedly, it'd be good if you instead had a local variable for the individual attribute. Similar: if (OidIsValid(get_base_element_type(TupleDescAttr(tupdesc, i)->atttypid))) sv = plperl_ref_from_pg_array(attr,TupleDescAttr(tupdesc, i)->atttypid); else if ((funcid = get_transform_fromsql(TupleDescAttr(tupdesc,i)->atttypid, current_call_data->prodesc->lang_oid, current_call_data->prodesc->trftypes))) sv = (SV *) DatumGetPointer(OidFunctionCall1(funcid, attr)); @@ -150,7 +148,7 @@ ValuesNext(ValuesScanState *node) */ values[resind] = MakeExpandedObjectReadOnly(values[resind], isnull[resind], - att[resind]->attlen); + TupleDescAttr(slot->tts_tupleDescriptor, resind)->attlen); @@ -158,9 +158,9 @@ convert_tuples_by_position(TupleDesc indesc, * must agree. */ if (attrMap[i]== 0 && - indesc->attrs[i]->attisdropped && - indesc->attrs[i]->attlen == outdesc->attrs[i]->attlen && - indesc->attrs[i]->attalign == outdesc->attrs[i]->attalign) + TupleDescAttr(indesc, i)->attisdropped && + TupleDescAttr(indesc, i)->attlen == TupleDescAttr(outdesc, i)->attlen && + TupleDescAttr(indesc, i)->attalign == TupleDescAttr(outdesc, i)->attalign) continue; I think you get the drift, there's more.... Otherwise this seems fairly boring... Review for 0002: @@ -71,17 +71,17 @@ typedef struct tupleConstrtypedef struct tupleDesc{ int natts; /* number ofattributes in the tuple */ - Form_pg_attribute *attrs; - /* attrs[N] is a pointer to the description of Attribute Number N+1 */ TupleConstr *constr; /* constraints,or NULL if none */ Oid tdtypeid; /* composite type ID for tuple type */ int32 tdtypmod; /* typmod for tuple type */ bool tdhasoid; /* tuple has oid attribute in its header */ int tdrefcount; /* reference count, or -1 if not counting */ + /* attrs[N] is the description of Attribute Number N+1 */ + FormData_pg_attribute attrs[FLEXIBLE_ARRAY_MEMBER];} *TupleDesc; sorry if I'm beating on my hobby horse, but if we're re-ordering anyway, can you move TupleConstr to the second-to-last? That a) seems more consistent but b) (hobby horse, sorry) avoids unnecessary alignment padding. @@ -734,13 +708,13 @@ BuildDescForRelation(List *schema) /* Override TupleDescInitEntry's settings as requested */ TupleDescInitEntryCollation(desc, attnum, attcollation); if (entry->storage) - desc->attrs[attnum - 1]->attstorage = entry->storage; + desc->attrs[attnum - 1].attstorage = entry->storage; /* Fill in additional stuff not handled by TupleDescInitEntry */ - desc->attrs[attnum - 1]->attnotnull = entry->is_not_null; + desc->attrs[attnum - 1].attnotnull = entry->is_not_null; has_not_null |= entry->is_not_null; - desc->attrs[attnum - 1]->attislocal = entry->is_local; - desc->attrs[attnum - 1]->attinhcount = entry->inhcount; + desc->attrs[attnum - 1].attislocal = entry->is_local; + desc->attrs[attnum - 1].attinhcount = entry->inhcount; This'd be a lot more readable if wed just stored desc->attrs[attnum - 1] in a local variable. Also think it'd be good if it just used TupleDescAttr() for that. Probably as part of previous commit. @@ -366,8 +340,8 @@ equalTupleDescs(TupleDesc tupdesc1, TupleDesc tupdesc2) for (i = 0; i < tupdesc1->natts; i++) { - Form_pg_attribute attr1 = tupdesc1->attrs[i]; - Form_pg_attribute attr2 = tupdesc2->attrs[i]; + Form_pg_attribute attr1 = &tupdesc1->attrs[i]; + Form_pg_attribute attr2 = &tupdesc2->attrs[i]; I'd convert all these as part of the previous commit. @@ -99,12 +72,9 @@ CreateTemplateTupleDesc(int natts, bool hasoid) /* * CreateTupleDesc - * This function allocates a new TupleDesc pointing to a given + * This function allocates a new TupleDesc by copying a given * Form_pg_attribute array. * - * Note: if the TupleDesc is ever freed, the Form_pg_attribute array - * will not be freed thereby. - * I'm leaning towards no, but you could argue that we should just change that remark to be about constr? @@ -51,39 +51,12 @@ CreateTemplateTupleDesc(int natts, bool hasoid) /* * Allocate enough memory for the tuple descriptor, including the - * attribute rows, and set up the attribute row pointers. - * - * Note: we assume that sizeof(struct tupleDesc) is a multiple of the - * struct pointer alignment requirement, and hence we don't need to insert - * alignment padding between the struct and the array of attribute row - * pointers. - * - * Note: Only the fixed part of pg_attribute rows is included in tuple - * descriptors, so we only need ATTRIBUTE_FIXED_PART_SIZE space per attr. - * That might need alignment padding, however. + * attribute rows. */ - attroffset = sizeof(struct tupleDesc) + natts * sizeof(Form_pg_attribute); - attroffset = MAXALIGN(attroffset); - stg = palloc(attroffset + natts * MAXALIGN(ATTRIBUTE_FIXED_PART_SIZE)); + attroffset = offsetof(struct tupleDesc, attrs); + stg = palloc0(attroffset + natts * sizeof(FormData_pg_attribute)); desc = (TupleDesc) stg; note that attroffset isn't used anymore after this... We have two mildly different places allocating a tupledesc struct for a number of elements. Seems sense to put them into an AllocTupleDesc()? Review of 0003: I'm not doing a too detailed review, given I think there's some changes in the pipeline. @@ -0,0 +1,124 @@ +/*------------------------------------------------------------------------- + * + * ds_hash_table.h + * Concurrent hash tables backed by dynamic shared memory areas. ... +/* + * The opaque type representing a hash table. While the struct is defined + * before, client code should consider it to be be an opaque and deal only in + * pointers to it. + */ +struct dht_hash_table; +typedef struct dht_hash_table dht_hash_table; "defined before"? +/* + * The opaque type used for iterator state. While the struct is actually + * defined below so it can be used on the stack, client code should deal only + * in pointers to it rather than accessing its members. + */ +struct dht_iterator; +typedef struct dht_iterator dht_iterator; s/used/allocated/? + +/* + * The set of parameters needed to create or attach to a hash table. The + * members tranche_id and tranche_name do not need to be initialized when + * attaching to an existing hash table. The functions do need to be supplied + * even when attaching because we can't safely share function pointers between + * backends in general. + */ +typedef struct +{ + size_t key_size; /* Size of the key (initial bytes of entry) */ + size_t entry_size; /* Total size of entry */ + dht_compare_function compare_function; /* Compare function */ + dht_hash_function hash_function; /* Hash function */ + int tranche_id; /* The tranche ID to use for locks. */ +} dht_parameters; Wonder if it'd make sense to say that key/entry sizes to be only minimums? That means we could increase them to be the proper aligned size? /** Unlock an entry which was locked by dht_find or dht_find_or_insert.*/ void dht_release(dht_hash_table *hash_table, void *entry) /** Release the most recently obtained lock. This can optionally be called in* between calls to dht_iterate_next to allowother processes to access the* same partition of the hash table.*/ void dht_iterate_release_lock(dht_iterator *iterator) I'd add lock to the first too. FWIW, I'd be perfectly fine with abbreviating iterate/iterator to "iter" or something. We already have that elsewhere and it's pretty clear. +/* + * Print out debugging information about the internal state of the hash table. + * No locks must be held by the caller. + */ +void Should specify where the information is printed. + * scan. (We don't actually expect them to have more than 1 item unless + * the hash function is of low quality.) That, uh, seems like an hasty remark. Even with a good hash function you're going to get collisions occasionally. Review of 0004: Ignoring aspects related to REC_HASH_KEYS and related discussion, since we're already discussing that in another email. +static int32 +find_or_allocate_shared_record_typmod(TupleDesc tupdesc) +{ + /* + * While we still hold the atts_index entry locked, add this to + * typmod_index. That's important because we don't want anyone to be able + * to find a typmod via the former that can't yet be looked up in the + * latter. + */ + PG_TRY(); + { + typmod_index_entry = + dht_find_or_insert(CurrentSharedRecordTypmodRegistry.typmod_index, + &typmod, &found); + if (found) + elog(ERROR, "cannot create duplicate shared record typmod"); + } + PG_CATCH(); + { + /* + * If we failed to allocate or elog()ed, we have to be careful not to + * leak the shared memory. Note that we might have created a new + * atts_index entry above, but we haven't put anything in it yet. + */ + dsa_free(CurrentSharedRecordTypmodRegistry.area, shared_dp); + PG_RE_THROW(); + } Not entirely related, but I do wonder if we don't need abetter solution to this. Something like dsa pointers that register appropriate memory context callbacks to get deleted in case of errors? Codewise this seems ok aside from the already discussed issues. But architecturally I'm still not sure I quite like the a bit ad-hoc manner session state is defined here. I think we much more should go towards a PGPROC like PGSESSION array, that PGPROCs reference. That'd also be preallocated in "normal" shmem. From there things like the handle for a dht typmod table could be referenced. I think we should slowly go towards a world where session state isn't in a lot of file local static variables. I don't know if this is the right moment to start doing so, but I think it's quite soon. Reviewing 0005: Yay! - Andres
On Mon, Aug 14, 2017 at 12:32 PM, Andres Freund <andres@anarazel.de> wrote: > Review for 0001: > > I think you made a few long lines even longer, like: > > @@ -1106,11 +1106,11 @@ pltcl_trigger_handler(PG_FUNCTION_ARGS, pltcl_call_state *call_state, > Tcl_ListObjAppendElement(NULL, tcl_trigtup, Tcl_NewObj()); > for (i = 0; i < tupdesc->natts; i++) > { > - if (tupdesc->attrs[i]->attisdropped) > + if (TupleDescAttr(tupdesc, i)->attisdropped) > Tcl_ListObjAppendElement(NULL, tcl_trigtup, Tcl_NewObj()); > else > Tcl_ListObjAppendElement(NULL, tcl_trigtup, > - Tcl_NewStringObj(utf_e2u(NameStr(tupdesc->attrs[i]->attname)),-1)); > + Tcl_NewStringObj(utf_e2u(NameStr(TupleDescAttr(tupdesc,i)->attname)), -1)); > > > as it's not particularly pretty to access tupdesc->attrs[i] repeatedly, > it'd be good if you instead had a local variable for the individual > attribute. Done. > Similar: > if (OidIsValid(get_base_element_type(TupleDescAttr(tupdesc, i)->atttypid))) > sv = plperl_ref_from_pg_array(attr, TupleDescAttr(tupdesc, i)->atttypid); > else if ((funcid = get_transform_fromsql(TupleDescAttr(tupdesc, i)->atttypid, current_call_data->prodesc->lang_oid,current_call_data->prodesc->trftypes))) > sv = (SV *) DatumGetPointer(OidFunctionCall1(funcid, attr)); Done. > @@ -150,7 +148,7 @@ ValuesNext(ValuesScanState *node) > */ > values[resind] = MakeExpandedObjectReadOnly(values[resind], > isnull[resind], > - att[resind]->attlen); > + TupleDescAttr(slot->tts_tupleDescriptor,resind)->attlen); > > @@ -158,9 +158,9 @@ convert_tuples_by_position(TupleDesc indesc, > * must agree. > */ > if (attrMap[i] == 0 && > - indesc->attrs[i]->attisdropped && > - indesc->attrs[i]->attlen == outdesc->attrs[i]->attlen && > - indesc->attrs[i]->attalign == outdesc->attrs[i]->attalign) > + TupleDescAttr(indesc, i)->attisdropped && > + TupleDescAttr(indesc, i)->attlen == TupleDescAttr(outdesc, i)->attlen && > + TupleDescAttr(indesc, i)->attalign == TupleDescAttr(outdesc, i)->attalign) > continue; Done. > I think you get the drift, there's more..../ Done in some more places too. > Review for 0002: > > @@ -71,17 +71,17 @@ typedef struct tupleConstr > typedef struct tupleDesc > { > int natts; /* number of attributes in the tuple */ > - Form_pg_attribute *attrs; > - /* attrs[N] is a pointer to the description of Attribute Number N+1 */ > TupleConstr *constr; /* constraints, or NULL if none */ > Oid tdtypeid; /* composite type ID for tuple type */ > int32 tdtypmod; /* typmod for tuple type */ > bool tdhasoid; /* tuple has oid attribute in its header */ > int tdrefcount; /* reference count, or -1 if not counting */ > + /* attrs[N] is the description of Attribute Number N+1 */ > + FormData_pg_attribute attrs[FLEXIBLE_ARRAY_MEMBER]; > } *TupleDesc; > > sorry if I'm beating on my hobby horse, but if we're re-ordering anyway, > can you move TupleConstr to the second-to-last? That a) seems more > consistent but b) (hobby horse, sorry) avoids unnecessary alignment > padding. Done. > @@ -734,13 +708,13 @@ BuildDescForRelation(List *schema) > /* Override TupleDescInitEntry's settings as requested */ > TupleDescInitEntryCollation(desc, attnum, attcollation); > if (entry->storage) > - desc->attrs[attnum - 1]->attstorage = entry->storage; > + desc->attrs[attnum - 1].attstorage = entry->storage; > > /* Fill in additional stuff not handled by TupleDescInitEntry */ > - desc->attrs[attnum - 1]->attnotnull = entry->is_not_null; > + desc->attrs[attnum - 1].attnotnull = entry->is_not_null; > has_not_null |= entry->is_not_null; > - desc->attrs[attnum - 1]->attislocal = entry->is_local; > - desc->attrs[attnum - 1]->attinhcount = entry->inhcount; > + desc->attrs[attnum - 1].attislocal = entry->is_local; > + desc->attrs[attnum - 1].attinhcount = entry->inhcount; > > This'd be a lot more readable if wed just stored desc->attrs[attnum - 1] > in a local variable. Also think it'd be good if it just used > TupleDescAttr() for that. Probably as part of previous commit. Done. > @@ -366,8 +340,8 @@ equalTupleDescs(TupleDesc tupdesc1, TupleDesc tupdesc2) > > for (i = 0; i < tupdesc1->natts; i++) > { > - Form_pg_attribute attr1 = tupdesc1->attrs[i]; > - Form_pg_attribute attr2 = tupdesc2->attrs[i]; > + Form_pg_attribute attr1 = &tupdesc1->attrs[i]; > + Form_pg_attribute attr2 = &tupdesc2->attrs[i]; > > I'd convert all these as part of the previous commit. Done. > @@ -99,12 +72,9 @@ CreateTemplateTupleDesc(int natts, bool hasoid) > > /* > * CreateTupleDesc > - * This function allocates a new TupleDesc pointing to a given > + * This function allocates a new TupleDesc by copying a given > * Form_pg_attribute array. > * > - * Note: if the TupleDesc is ever freed, the Form_pg_attribute array > - * will not be freed thereby. > - * > > I'm leaning towards no, but you could argue that we should just change > that remark to be about constr? I don't see why. > @@ -51,39 +51,12 @@ CreateTemplateTupleDesc(int natts, bool hasoid) > > /* > * Allocate enough memory for the tuple descriptor, including the > - * attribute rows, and set up the attribute row pointers. > - * > - * Note: we assume that sizeof(struct tupleDesc) is a multiple of the > - * struct pointer alignment requirement, and hence we don't need to insert > - * alignment padding between the struct and the array of attribute row > - * pointers. > - * > - * Note: Only the fixed part of pg_attribute rows is included in tuple > - * descriptors, so we only need ATTRIBUTE_FIXED_PART_SIZE space per attr. > - * That might need alignment padding, however. > + * attribute rows. > */ > - attroffset = sizeof(struct tupleDesc) + natts * sizeof(Form_pg_attribute); > - attroffset = MAXALIGN(attroffset); > - stg = palloc(attroffset + natts * MAXALIGN(ATTRIBUTE_FIXED_PART_SIZE)); > + attroffset = offsetof(struct tupleDesc, attrs); > + stg = palloc0(attroffset + natts * sizeof(FormData_pg_attribute)); > desc = (TupleDesc) stg; > > note that attroffset isn't used anymore after this... Tidied. > We have two mildly different places allocating a tupledesc struct for a > number of elements. Seems sense to put them into an AllocTupleDesc()? Yeah. CreateTemplateTupleDesc() is already suitable. I changed CreateTupleDesc() to call that instead of duplicating the allocation code. > Review of 0003: > > I'm not doing a too detailed review, given I think there's some changes > in the pipeline. Yep. In the new patch set the hash table formerly known as DHT is now in patch 0004 and I made the following changes based on your feedback: 1. Renamed it to "dshash". The files are named dshash.{c,h}, and the prefix on identifiers is dshash_. You suggested dsmhash, but the "m" didn't seem to make much sense. I considered dsahash, but dshash seemed better. Thoughts? 2. Ripped out the incremental resizing and iterator support for now, as discussed. I want to post patches to add those features when we have a use case but I can see that it's no slam dunk so I want to keep that stuff out of the dependency graph for parallel hash. 3. Added support for hash and compare functions with an extra argument for user data, a bit like qsort_arg_comparator. This is necessary for functions that need to be able to dereference a dsa_pointer stored in the entry, since they need the dsa_area. (I would normally call such an argument 'user_data' or 'context' or something but 'arg' seemed to be establish by qsort_arg.) > @@ -0,0 +1,124 @@ > +/*------------------------------------------------------------------------- > + * > + * ds_hash_table.h > + * Concurrent hash tables backed by dynamic shared memory areas. > > ... > > +/* > + * The opaque type representing a hash table. While the struct is defined > + * before, client code should consider it to be be an opaque and deal only in > + * pointers to it. > + */ > +struct dht_hash_table; > +typedef struct dht_hash_table dht_hash_table; > > "defined before"? Bleugh. Fixed. > +/* > + * The opaque type used for iterator state. While the struct is actually > + * defined below so it can be used on the stack, client code should deal only > + * in pointers to it rather than accessing its members. > + */ > +struct dht_iterator; > +typedef struct dht_iterator dht_iterator; > > s/used/allocated/? Removed for now, see above. > + > +/* > + * The set of parameters needed to create or attach to a hash table. The > + * members tranche_id and tranche_name do not need to be initialized when > + * attaching to an existing hash table. The functions do need to be supplied > + * even when attaching because we can't safely share function pointers between > + * backends in general. > + */ > +typedef struct > +{ > + size_t key_size; /* Size of the key (initial bytes of entry) */ > + size_t entry_size; /* Total size of entry */ > + dht_compare_function compare_function; /* Compare function */ > + dht_hash_function hash_function; /* Hash function */ > + int tranche_id; /* The tranche ID to use for locks. */ > +} dht_parameters; > > Wonder if it'd make sense to say that key/entry sizes to be only > minimums? That means we could increase them to be the proper aligned > size? I don't understand. You mean explicitly saying that there are overheads? Doesn't that go without saying? > /* > * Unlock an entry which was locked by dht_find or dht_find_or_insert. > */ > void > dht_release(dht_hash_table *hash_table, void *entry) > > /* > * Release the most recently obtained lock. This can optionally be called in > * between calls to dht_iterate_next to allow other processes to access the > * same partition of the hash table. > */ > void > dht_iterate_release_lock(dht_iterator *iterator) > > I'd add lock to the first too. Done. > FWIW, I'd be perfectly fine with abbreviating iterate/iterator to "iter" > or something. We already have that elsewhere and it's pretty clear. Will return to this question in a future submission that adds iterators. > +/* > + * Print out debugging information about the internal state of the hash table. > + * No locks must be held by the caller. > + */ > +void > > Should specify where the information is printed. Done. > + * scan. (We don't actually expect them to have more than 1 item unless > + * the hash function is of low quality.) > > That, uh, seems like an hasty remark. Even with a good hash function > you're going to get collisions occasionally. > > > Review of 0004: > > Ignoring aspects related to REC_HASH_KEYS and related discussion, since > we're already discussing that in another email. This version includes new refactoring patches 0003, 0004 to get rid of REC_HASH_KEYS by teaching the hash table how to use a TupleDesc as a key directly. Then the shared version does approximately the same thing, with a couple of extra hoops to jump thought. Thoughts? > +static int32 > +find_or_allocate_shared_record_typmod(TupleDesc tupdesc) > +{ > > + /* > + * While we still hold the atts_index entry locked, add this to > + * typmod_index. That's important because we don't want anyone to be able > + * to find a typmod via the former that can't yet be looked up in the > + * latter. > + */ > + PG_TRY(); > + { > + typmod_index_entry = > + dht_find_or_insert(CurrentSharedRecordTypmodRegistry.typmod_index, > + &typmod, &found); > + if (found) > + elog(ERROR, "cannot create duplicate shared record typmod"); > + } > + PG_CATCH(); > + { > + /* > + * If we failed to allocate or elog()ed, we have to be careful not to > + * leak the shared memory. Note that we might have created a new > + * atts_index entry above, but we haven't put anything in it yet. > + */ > + dsa_free(CurrentSharedRecordTypmodRegistry.area, shared_dp); > + PG_RE_THROW(); > + } > > Not entirely related, but I do wonder if we don't need abetter solution > to this. Something like dsa pointers that register appropriate memory > context callbacks to get deleted in case of errors? Huh, scope guards. I have had some ideas about some kind of destructor mechanism that might replace what we're doing with DSM detach hooks in various places and also work in containers like hash tables (ie entries could have destructors), but doing it with the stack is another level... > Codewise this seems ok aside from the already discussed issues. > > But architecturally I'm still not sure I quite like the a bit ad-hoc > manner session state is defined here. I think we much more should go > towards a PGPROC like PGSESSION array, that PGPROCs reference. That'd > also be preallocated in "normal" shmem. From there things like the > handle for a dht typmod table could be referenced. I think we should > slowly go towards a world where session state isn't in a lot of file > local static variables. I don't know if this is the right moment to > start doing so, but I think it's quite soon. No argument from me about that general idea. All our global state is an obstacle for testability, multi-threading, new CPU scheduling architectures etc. I had been trying to avoid getting too adventurous here, but here goes nothing... In this version there is an honest Session struct. There is still a single global variable -- CurrentSession -- which would I guess could be a candidate to become a thread-local variable from the future (or alternatively an argument to every function that needs session access). Is this better? Haven't tested this much yet but seems like better code layout to me. > Reviewing 0005: > > Yay! That's the kind of review I like! Thanks. I will also post some testing code soon. -- Thomas Munro http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Вложения
On Tue, Aug 15, 2017 at 5:44 PM, Thomas Munro <thomas.munro@enterprisedb.com> wrote: > On Mon, Aug 14, 2017 at 12:32 PM, Andres Freund <andres@anarazel.de> wrote: >> But architecturally I'm still not sure I quite like the a bit ad-hoc >> manner session state is defined here. I think we much more should go >> towards a PGPROC like PGSESSION array, that PGPROCs reference. That'd >> also be preallocated in "normal" shmem. From there things like the >> handle for a dht typmod table could be referenced. I think we should >> slowly go towards a world where session state isn't in a lot of file >> local static variables. I don't know if this is the right moment to >> start doing so, but I think it's quite soon. > > No argument from me about that general idea. All our global state is > an obstacle for testability, multi-threading, new CPU scheduling > architectures etc. I had been trying to avoid getting too adventurous > here, but here goes nothing... In this version there is an honest > Session struct. There is still a single global variable -- > CurrentSession -- which would I guess could be a candidate to become a > thread-local variable from the future (or alternatively an argument to > every function that needs session access). Is this better? Haven't > tested this much yet but seems like better code layout to me. > 0006-Introduce-a-shared-memory-record-typmod-registry.patch +/* + * A struct encapsulating some elements of a user's session. For now this + * manages state that applies to parallel query, but it principle it could + * include other things that are currently global variables. + */ +typedef struct Session +{ + dsm_segment *segment; /* The session-scoped DSM segment. */ + dsa_area *area; /* The session-scoped DSA area. */ + + /* State managed by typcache.c. */ + SharedRecordTypmodRegistry *typmod_registry; + dshash_table *record_table; /* Typmods indexed by tuple descriptor */ + dshash_table *typmod_table; /* Tuple descriptors indexed by typmod */ +} Session; Upon reflection, these members should probably be called shared_record_table etc. Presumably later refactoring would introduce (for example) local_record_table, which would replace the following variable in typcache.c: static HTAB *RecordCacheHash = NULL; ... and likewise for NextRecordTypmod and RecordCacheArray which together embody this session's local typmod registry and ability to make more. The idea here is eventually to move all state that is tried to a session into this structure, though I'm not proposing to do any more of that than is necessary as part of *this* patchset. For now I'm just looking for a decent place to put the minimal shared session state, but in a way that allows us "slowly [to] go towards a world where session state isn't in a lot of file local static variables" as you put it. There's a separate discussion to be had about whether things like assign_record_type_typmod() should take a Session pointer or access the global variable (and perhaps in future thread-local) CurrentSession, but the path of least resistance for now is, I think, as I have it. On another topic, I probably need to study and test some failure paths better. Thoughts? -- Thomas Munro http://www.enterprisedb.com
On 2017-08-15 17:44:55 +1200, Thomas Munro wrote: > > @@ -99,12 +72,9 @@ CreateTemplateTupleDesc(int natts, bool hasoid) > > > > /* > > * CreateTupleDesc > > - * This function allocates a new TupleDesc pointing to a given > > + * This function allocates a new TupleDesc by copying a given > > * Form_pg_attribute array. > > * > > - * Note: if the TupleDesc is ever freed, the Form_pg_attribute array > > - * will not be freed thereby. > > - * > > > > I'm leaning towards no, but you could argue that we should just change > > that remark to be about constr? > > I don't see why. Because for that the freeing bit is still true, ie. it's still separately allocated. > > Review of 0003: > > > > I'm not doing a too detailed review, given I think there's some changes > > in the pipeline. > > Yep. In the new patch set the hash table formerly known as DHT is now > in patch 0004 and I made the following changes based on your feedback: > > 1. Renamed it to "dshash". The files are named dshash.{c,h}, and the > prefix on identifiers is dshash_. You suggested dsmhash, but the "m" > didn't seem to make much sense. I considered dsahash, but dshash > seemed better. Thoughts? WFM. Just curious, why didn't m make sense? I was referring to dynamic shared memory hash - seems right. Whether there's an intermediary dsa layer or not... > 2. Ripped out the incremental resizing and iterator support for now, > as discussed. I want to post patches to add those features when we > have a use case but I can see that it's no slam dunk so I want to keep > that stuff out of the dependency graph for parallel hash. Cool. > 3. Added support for hash and compare functions with an extra > argument for user data, a bit like qsort_arg_comparator. This is > necessary for functions that need to be able to dereference a > dsa_pointer stored in the entry, since they need the dsa_area. (I > would normally call such an argument 'user_data' or 'context' or > something but 'arg' seemed to be establish by qsort_arg.) Good. > > +/* > > + * The set of parameters needed to create or attach to a hash table. The > > + * members tranche_id and tranche_name do not need to be initialized when > > + * attaching to an existing hash table. The functions do need to be supplied > > + * even when attaching because we can't safely share function pointers between > > + * backends in general. > > + */ > > +typedef struct > > +{ > > + size_t key_size; /* Size of the key (initial bytes of entry) */ > > + size_t entry_size; /* Total size of entry */ > > + dht_compare_function compare_function; /* Compare function */ > > + dht_hash_function hash_function; /* Hash function */ > > + int tranche_id; /* The tranche ID to use for locks. */ > > +} dht_parameters; > > > > Wonder if it'd make sense to say that key/entry sizes to be only > > minimums? That means we could increase them to be the proper aligned > > size? > > I don't understand. You mean explicitly saying that there are > overheads? Doesn't that go without saying? I was thinking that we could do the MAXALIGN style calculations once instead of repeatedly, by including them in the key and entry sizes. > > Ignoring aspects related to REC_HASH_KEYS and related discussion, since > > we're already discussing that in another email. > > This version includes new refactoring patches 0003, 0004 to get rid of > REC_HASH_KEYS by teaching the hash table how to use a TupleDesc as a > key directly. Then the shared version does approximately the same > thing, with a couple of extra hoops to jump thought. Thoughts? Will look. > > +static int32 > > +find_or_allocate_shared_record_typmod(TupleDesc tupdesc) > > +{ > > > > + /* > > + * While we still hold the atts_index entry locked, add this to > > + * typmod_index. That's important because we don't want anyone to be able > > + * to find a typmod via the former that can't yet be looked up in the > > + * latter. > > + */ > > + PG_TRY(); > > + { > > + typmod_index_entry = > > + dht_find_or_insert(CurrentSharedRecordTypmodRegistry.typmod_index, > > + &typmod, &found); > > + if (found) > > + elog(ERROR, "cannot create duplicate shared record typmod"); > > + } > > + PG_CATCH(); > > + { > > + /* > > + * If we failed to allocate or elog()ed, we have to be careful not to > > + * leak the shared memory. Note that we might have created a new > > + * atts_index entry above, but we haven't put anything in it yet. > > + */ > > + dsa_free(CurrentSharedRecordTypmodRegistry.area, shared_dp); > > + PG_RE_THROW(); > > + } > > > > Not entirely related, but I do wonder if we don't need abetter solution > > to this. Something like dsa pointers that register appropriate memory > > context callbacks to get deleted in case of errors? > > Huh, scope guards. I have had some ideas about some kind of > destructor mechanism that might replace what we're doing with DSM > detach hooks in various places and also work in containers like hash > tables (ie entries could have destructors), but doing it with the > stack is another level... Not sure what you mean with 'stack'? shared-record-typmods-v5.patchset/0004-Refactor-typcache.c-s-record-typmod-hash-table.patch + * hashTupleDesc + * Compute a hash value for a tuple descriptor. + * + * If two tuple descriptors would be considered equal by equalTupleDescs() + * then their hash value will be equal according to this function. + */ +uint32 +hashTupleDesc(TupleDesc desc) +{ + uint32 s = 0; + int i; + + for (i = 0; i < desc->natts; ++i) + s = hash_combine(s, hash_uint32(TupleDescAttr(desc, i)->atttypid)); + + return s; +} Hm, is it right not to include tdtypeid, tdtypmod, tdhasoid here? equalTupleDescs() does compare them... +/* + * Hash function for the hash table of RecordCacheEntry. + */ +static uint32 +record_type_typmod_hash(const void *data, size_t size) +{ + return hashTupleDesc(((RecordCacheEntry *) data)->tupdesc); +} + +/* + * Match function for the hash table of RecordCacheEntry. + */ +static int +record_type_typmod_compare(const void *a, const void *b, size_t size) +{ + return equalTupleDescs(((RecordCacheEntry *) a)->tupdesc, + ((RecordCacheEntry *) b)->tupdesc) ? 0 : 1; +} I'd rather have local vars for the casted params, but it's not important. MemSet(&ctl, 0, sizeof(ctl)); - ctl.keysize = REC_HASH_KEYS * sizeof(Oid); + ctl.keysize = 0; /* unused */ ctl.entrysize = sizeof(RecordCacheEntry); Hm, keysize 0? Is that right? Wouldn't it be more correct to have both of the same size, given dynahash includes the key size in the entry, and the pointer really is the key? Otherwise looks pretty good. shared-record-typmods-v5.patchset/0006-Introduce-a-shared-memory-record-typmod-registry.patch Hm, name & comment don't quite describe this accurately anymore. +/* + * A struct encapsulating some elements of a user's session. For now this + * manages state that applies to parallel query, but it principle it could + * include other things that are currently global variables. + */ +typedef struct Session +{ + dsm_segment *segment; /* The session-scoped DSM segment. */ + dsa_area *area; /* The session-scoped DSA area. */ + + /* State managed by typcache.c. */ + SharedRecordTypmodRegistry *typmod_registry; + dshash_table *record_table; /* Typmods indexed by tuple descriptor */ + dshash_table *typmod_table; /* Tuple descriptors indexed by typmod */ +} Session; Interesting. I was apparently thinking slightly differently. I'd have thought we'd have Session struct in statically allocated shared memory. Which'd then have dsa_handle, dshash_table_handle, ... members. +extern void EnsureCurrentSession(void); +extern void EnsureCurrentSession(void); duplicated. +/* + * We want to create a DSA area to store shared state that has the same extent + * as a session. So far, it's only used to hold the shared record type + * registry. We don't want it to have to create any DSM segments just yet in + * common cases, so we'll give it enough space to hold a very small + * SharedRecordTypmodRegistry. + */ +#define SESSION_DSA_SIZE 0x30000 Same "extent"? Maybe lifetime? + +/* + * Make sure that there is a CurrentSession. + */ +void EnsureCurrentSession(void) +{ linebreak. +{ + if (CurrentSession == NULL) + { + MemoryContext old_context = MemoryContextSwitchTo(TopMemoryContext); + + CurrentSession = palloc0(sizeof(Session)); + MemoryContextSwitchTo(old_context); + } +} Isn't MemoryContextAllocZero easier? Greetings, Andres Freund
On Tue, Aug 15, 2017 at 6:06 PM, Andres Freund <andres@anarazel.de> wrote: > Interesting. I was apparently thinking slightly differently. I'd have > thought we'd have Session struct in statically allocated shared > memory. Which'd then have dsa_handle, dshash_table_handle, ... members. Sounds an awful lot like what we're already doing with PGPROC. I am not sure that inventing a Session thing that should have 500 things in it but actually has the 3 that are relevant to this patch is really a step forward. In fact, it sounds like something that will just create confusion down the road. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
On 2017-08-15 20:30:16 -0400, Robert Haas wrote: > On Tue, Aug 15, 2017 at 6:06 PM, Andres Freund <andres@anarazel.de> wrote: > > Interesting. I was apparently thinking slightly differently. I'd have > > thought we'd have Session struct in statically allocated shared > > memory. Which'd then have dsa_handle, dshash_table_handle, ... members. > > Sounds an awful lot like what we're already doing with PGPROC. Except it'd be shared between leader and workers. So no, not really. Greetings, Andres Freund
Will respond to the actionable code review points separately with a new patch set, but first: On Wed, Aug 16, 2017 at 10:06 AM, Andres Freund <andres@anarazel.de> wrote: > On 2017-08-15 17:44:55 +1200, Thomas Munro wrote: >> > @@ -99,12 +72,9 @@ CreateTemplateTupleDesc(int natts, bool hasoid) >> > >> > /* >> > * CreateTupleDesc >> > - * This function allocates a new TupleDesc pointing to a given >> > + * This function allocates a new TupleDesc by copying a given >> > * Form_pg_attribute array. >> > * >> > - * Note: if the TupleDesc is ever freed, the Form_pg_attribute array >> > - * will not be freed thereby. >> > - * >> > >> > I'm leaning towards no, but you could argue that we should just change >> > that remark to be about constr? >> >> I don't see why. > > Because for that the freeing bit is still true, ie. it's still > separately allocated. It's true of struct tupleDesc in general but not true of objects returned by this function in respect of the arguments to the function. In master, that comment is a useful warning that the object will hold onto but never free the attrs array you pass in. The same doesn't apply to constr so I don't think we need to say anything. >> > Review of 0003: >> > >> > I'm not doing a too detailed review, given I think there's some changes >> > in the pipeline. >> >> Yep. In the new patch set the hash table formerly known as DHT is now >> in patch 0004 and I made the following changes based on your feedback: >> >> 1. Renamed it to "dshash". The files are named dshash.{c,h}, and the >> prefix on identifiers is dshash_. You suggested dsmhash, but the "m" >> didn't seem to make much sense. I considered dsahash, but dshash >> seemed better. Thoughts? > > WFM. Just curious, why didn't m make sense? I was referring to dynamic > shared memory hash - seems right. Whether there's an intermediary dsa > layer or not... I think of DSA as a defining characteristic that dshash exists to work with (it's baked into dshash's API), but DSM as an implementation detail which dshash doesn't directly depend on. Therefore I don't like the "m". I speculate that in future we might have build modes where DSA doesn't use DSM anyway: it could use native pointers and maybe even a different allocator in a build that either uses threads or non-portable tricks to carve out a huge amount of virtual address space so that it can map memory in at the same location in each backend. In that universe DSA would still be providing the service of grouping allocations together into a scope for "rip cord" cleanup (possibly by forwarding to MemoryContext stuff) but otherwise compile away to nearly nothing. >> > +static int32 >> > +find_or_allocate_shared_record_typmod(TupleDesc tupdesc) >> > +{ >> > >> > + /* >> > + * While we still hold the atts_index entry locked, add this to >> > + * typmod_index. That's important because we don't want anyone to be able >> > + * to find a typmod via the former that can't yet be looked up in the >> > + * latter. >> > + */ >> > + PG_TRY(); >> > + { >> > + typmod_index_entry = >> > + dht_find_or_insert(CurrentSharedRecordTypmodRegistry.typmod_index, >> > + &typmod, &found); >> > + if (found) >> > + elog(ERROR, "cannot create duplicate shared record typmod"); >> > + } >> > + PG_CATCH(); >> > + { >> > + /* >> > + * If we failed to allocate or elog()ed, we have to be careful not to >> > + * leak the shared memory. Note that we might have created a new >> > + * atts_index entry above, but we haven't put anything in it yet. >> > + */ >> > + dsa_free(CurrentSharedRecordTypmodRegistry.area, shared_dp); >> > + PG_RE_THROW(); >> > + } >> > >> > Not entirely related, but I do wonder if we don't need abetter solution >> > to this. Something like dsa pointers that register appropriate memory >> > context callbacks to get deleted in case of errors? >> >> Huh, scope guards. I have had some ideas about some kind of >> destructor mechanism that might replace what we're doing with DSM >> detach hooks in various places and also work in containers like hash >> tables (ie entries could have destructors), but doing it with the >> stack is another level... > > Not sure what you mean with 'stack'? I probably read too much into your words. I was imagining something conceptually like the following, since the "appropriate memory context" in the code above is actually a stack frame: dsa_pointer p = ...; ON_ERROR_SCOPE_EXIT(dsa_free, area, p); /* yeah, I know, no variadic macros */ elog(ERROR, "boo"); /* this causes p to be freed */ The point being that if the caller of this function catches the error then ITS on-error-cleanup stack mustn't run, but this one's must. Hence requirement for awareness of stack. I'm not sure it's actually any easier to use this than the existing try/catch macros and I'm not proposing it, but I thought perhaps you were. > +/* > + * A struct encapsulating some elements of a user's session. For now this > + * manages state that applies to parallel query, but it principle it could > + * include other things that are currently global variables. > + */ > +typedef struct Session > +{ > + dsm_segment *segment; /* The session-scoped DSM segment. */ > + dsa_area *area; /* The session-scoped DSA area. */ > + > + /* State managed by typcache.c. */ > + SharedRecordTypmodRegistry *typmod_registry; > + dshash_table *record_table; /* Typmods indexed by tuple descriptor */ > + dshash_table *typmod_table; /* Tuple descriptors indexed by typmod */ > +} Session; > > > Interesting. I was apparently thinking slightly differently. I'd have > thought we'd have Session struct in statically allocated shared > memory. Which'd then have dsa_handle, dshash_table_handle, ... members. A session needs (1) some backend-private state to hold the addresses of stuff in this process's memory map and (2) some shared state worth pointing to. My patch introduces both of those things, but doesn't need to make the shared state part 'discoverable'. Workers get their hands on it by receiving it explicitly from a leader. I think that you're right about a cluster-wide PGSESSION array being useful if we divorce session from processes completely and write some kind of scheduler. But for the purposes of this patch set we don't seem to need to any decisions about that. Leaders passing DSM handles over to workers seems to be enough for now. Does this make sense? -- Thomas Munro http://www.enterprisedb.com
On Tue, Aug 15, 2017 at 8:34 PM, Andres Freund <andres@anarazel.de> wrote: > On 2017-08-15 20:30:16 -0400, Robert Haas wrote: >> On Tue, Aug 15, 2017 at 6:06 PM, Andres Freund <andres@anarazel.de> wrote: >> > Interesting. I was apparently thinking slightly differently. I'd have >> > thought we'd have Session struct in statically allocated shared >> > memory. Which'd then have dsa_handle, dshash_table_handle, ... members. >> >> Sounds an awful lot like what we're already doing with PGPROC. > > Except it'd be shared between leader and workers. So no, not really. There's precedent for using it that way, though - cf. group locking. And in practice you're going to need an array of the same length as the procarray. It's maybe not quite the same thing, but it smells pretty similar. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
Hi, Pushing 0001, 0002 now. - rebased after conflicts - fixed a significant number of too long lines - removed a number of now superflous linebreaks I think it'd be a good idea to backpatch the addition of TupleDescAttr(tupledesc, n) to make future backpatching easier. What do others think? Thomas, prepare yourself for some hate from extension and fork authors / maintainers ;) Regards, Andres
On Mon, Aug 21, 2017 at 6:17 AM, Andres Freund <andres@anarazel.de> wrote: > Pushing 0001, 0002 now. > > - rebased after conflicts > - fixed a significant number of too long lines > - removed a number of now superflous linebreaks Thanks! Please find attached a rebased version of the rest of the patch set. > Thomas, prepare yourself for some hate from extension and fork authors / > maintainers ;) /me hides The attached version also fixes a couple of small details you complained about last week: On Wed, Aug 16, 2017 at 10:06 AM, Andres Freund <andres@anarazel.de> wrote: >> > + size_t key_size; /* Size of the key (initial bytes of entry) */ >> > + size_t entry_size; /* Total size of entry */ >> > >> > Wonder if it'd make sense to say that key/entry sizes to be only >> > minimums? That means we could increase them to be the proper aligned >> > size? >> >> I don't understand. You mean explicitly saying that there are >> overheads? Doesn't that go without saying? > > I was thinking that we could do the MAXALIGN style calculations once > instead of repeatedly, by including them in the key and entry sizes. I must be missing something -- where do we do it repeatedly? The only place we use MAXALIGN is a compile-type constant expression (see expansion of macros ENTRY_FROM_ITEM and ITEM_FROM_ENTRY, and also in one place AXALIGN(sizeof(dshash_table_item))). > shared-record-typmods-v5.patchset/0004-Refactor-typcache.c-s-record-typmod-hash-table.patch > > + * hashTupleDesc > + * Compute a hash value for a tuple descriptor. > + * > + * If two tuple descriptors would be considered equal by equalTupleDescs() > + * then their hash value will be equal according to this function. > + */ > +uint32 > +hashTupleDesc(TupleDesc desc) > +{ > + uint32 s = 0; > + int i; > + > + for (i = 0; i < desc->natts; ++i) > + s = hash_combine(s, hash_uint32(TupleDescAttr(desc, i)->atttypid)); > + > + return s; > +} > > Hm, is it right not to include tdtypeid, tdtypmod, tdhasoid here? > equalTupleDescs() does compare them... OK, now adding natts (just for consistency), tdtypeid and tdhasoid to be exactly like equalTupleDescs(). Note that tdtypmod is deliberately *not* included. > + return hashTupleDesc(((RecordCacheEntry *) data)->tupdesc); > ... > + return equalTupleDescs(((RecordCacheEntry *) a)->tupdesc, > + ((RecordCacheEntry *) b)- > > I'd rather have local vars for the casted params, but it's not > important. Done. > MemSet(&ctl, 0, sizeof(ctl)); > - ctl.keysize = REC_HASH_KEYS * sizeof(Oid); > + ctl.keysize = 0; /* unused */ > ctl.entrysize = sizeof(RecordCacheEntry); > > Hm, keysize 0? Is that right? Wouldn't it be more correct to have both > of the same size, given dynahash includes the key size in the entry, and > the pointer really is the key? Done. > shared-record-typmods-v5.patchset/0006-Introduce-a-shared-memory-record-typmod-registry.patch > > Hm, name & comment don't quite describe this accurately anymore. Updated commit message. > +extern void EnsureCurrentSession(void); > +extern void EnsureCurrentSession(void); > > duplicated. Fixed. > +/* > + * We want to create a DSA area to store shared state that has the same extent > + * as a session. So far, it's only used to hold the shared record type > + * registry. We don't want it to have to create any DSM segments just yet in > + * common cases, so we'll give it enough space to hold a very small > + * SharedRecordTypmodRegistry. > + */ > +#define SESSION_DSA_SIZE 0x30000 > > Same "extent"? Maybe lifetime? Done. > + > +/* > + * Make sure that there is a CurrentSession. > + */ > +void EnsureCurrentSession(void) > +{ > > linebreak. Fixed. > +{ > + if (CurrentSession == NULL) > + { > + MemoryContext old_context = MemoryContextSwitchTo(TopMemoryContext); > + > + CurrentSession = palloc0(sizeof(Session)); > + MemoryContextSwitchTo(old_context); > + } > +} > > Isn't MemoryContextAllocZero easier? Done. I also stopped saying "const TupleDesc" in a few places, which was a thinko (I wanted pointer to const tupldeDesc, not const pointer to tupleDesc...), and made sure that the shmem TupleDescs always have tdtypmod actually set. So as I understand it the remaining issues (aside from any undiscovered bugs...) are: 1. Do we like "Session", "CurrentSession" etc? Robert seems to be suggesting that this is likely to get in the way when we try to tackle this area more thoroughly. Andres is suggesting that this is a good time to take steps in this direction. 2. Andres didn't like what I did to DecrTupleDescRefCount, namely allowing to run when there is no ResourceOwner. I now see that this is probably an indication of a different problem; even if there were a worker ResourceOwner as he suggested (or perhaps a session-scoped one, which a worker would reset before being reused), it wouldn't be the one that was active when the TupleDesc was created. I think I have failed to understand the contracts here and will think/read about it some more. -- Thomas Munro http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Вложения
On Mon, Aug 21, 2017 at 6:17 AM, Andres Freund <andres@anarazel.de> wrote: > I think it'd be a good idea to backpatch the addition of > TupleDescAttr(tupledesc, n) to make future backpatching easier. What do > others think? +1 That would also provide a way for extension developers to be able to write code that compiles against PG11 and also earlier releases without having to do ugly conditional macros stuff. -- Thomas Munro http://www.enterprisedb.com
On Mon, Aug 21, 2017 at 10:18 AM, Thomas Munro <thomas.munro@enterprisedb.com> wrote: > On Mon, Aug 21, 2017 at 6:17 AM, Andres Freund <andres@anarazel.de> wrote: >> I think it'd be a good idea to backpatch the addition of >> TupleDescAttr(tupledesc, n) to make future backpatching easier. What do >> others think? > > +1 > > That would also provide a way for extension developers to be able to > write code that compiles against PG11 and also earlier releases > without having to do ugly conditional macros stuff. Updating only tupdesc.h is harmless, so no real objection to your argument. -- Michael
On 2017-08-21 11:02:52 +1200, Thomas Munro wrote: > On Mon, Aug 21, 2017 at 6:17 AM, Andres Freund <andres@anarazel.de> wrote: > > Pushing 0001, 0002 now. > > > > - rebased after conflicts > > - fixed a significant number of too long lines > > - removed a number of now superflous linebreaks > > Thanks! Please find attached a rebased version of the rest of the patch set. Pushed 0001, 0002. Looking at later patches. Greetings, Andres Freund
On 2017-08-22 16:41:23 -0700, Andres Freund wrote: > On 2017-08-21 11:02:52 +1200, Thomas Munro wrote: > > On Mon, Aug 21, 2017 at 6:17 AM, Andres Freund <andres@anarazel.de> wrote: > > > Pushing 0001, 0002 now. > > > > > > - rebased after conflicts > > > - fixed a significant number of too long lines > > > - removed a number of now superflous linebreaks > > > > Thanks! Please find attached a rebased version of the rest of the patch set. > > Pushed 0001, 0002. Looking at later patches. Committing 0003. This'll probably need further adjustment, but I think it's good to make progress here. Changes: - pgindent'ed after adding the necessary typedefs to typedefs.list - replaced INT64CONST w UINT64CONST - moved count assertion in delete_item to before decrementing - as count is unsigned, it'd just wrap around on underflownot triggering the assertion. - documented and asserted resize is called without partition lock held - removed reference to iterator in dshash_find comments - removed stray references to dshash_release (rather than dshash_release_lock) - reworded dshash_find_or_insert reference to dshash_find to also mention error handling. Notes for possible followup commits of the dshash API: - nontrivial portions of dsahash are essentially critical sections lest dynamic shared memory is leaked. Should we, shortterm, introduce actual critical section markers to make that more obvious? Should we, longer term, make this more failsafe/ easier to use, by extending/emulating memory contexts for dsa memory? - I'm very unconvinced of supporting both {compare,hash}_arg_function and the non-arg version. Why not solely support the_arg_ version, but add the size argument? On all relevant platforms that should still be register arg callable, and thebranch isn't free either. - might be worthwhile to try to reduce duplication between delete_item_from_bucket, delete_key_from_bucket, delete_item dshash_delete_key. For later commits in the series: - Afaict the whole shared tupledesc stuff, as tqueue.c before, is entirely untested. This baffles me. See also [1]. I canforce the code to be reached with force_parallel_mode=regress/1, but this absolutely really totally needs to be reachedby the default tests. Robert? - gcc wants static before const (0004). - Afaict GetSessionDsmHandle() uses the current rather than TopMemoryContext. Try running the regression tests under force_parallel_mode- crashes immediately for me without fixing that. - SharedRecordTypmodRegistryInit() is called from GetSessionDsmHandle() which calls EnsureCurrentSession(), but SharedRecordTypmodRegistryInit()does so again - sprinkling those around liberally seems like it could hide bugs. Regards, Andres [1] https://coverage.postgresql.org/src/backend/executor/tqueue.c.gcov.html
On Wed, Aug 23, 2017 at 5:46 PM, Andres Freund <andres@anarazel.de> wrote: > Committing 0003. This'll probably need further adjustment, but I think > it's good to make progress here. Thanks! > Changes: > - pgindent'ed after adding the necessary typedefs to typedefs.list > - replaced INT64CONST w UINT64CONST > - moved count assertion in delete_item to before decrementing - as count > is unsigned, it'd just wrap around on underflow not triggering the assertion. > - documented and asserted resize is called without partition lock held > - removed reference to iterator in dshash_find comments > - removed stray references to dshash_release (rather than dshash_release_lock) > - reworded dshash_find_or_insert reference to dshash_find to also > mention error handling. Doh. Thanks. > Notes for possible followup commits of the dshash API: > - nontrivial portions of dsahash are essentially critical sections lest > dynamic shared memory is leaked. Should we, short term, introduce > actual critical section markers to make that more obvious? Should we, > longer term, make this more failsafe / easier to use, by > extending/emulating memory contexts for dsa memory? Hmm. I will look into this. > - I'm very unconvinced of supporting both {compare,hash}_arg_function > and the non-arg version. Why not solely support the _arg_ version, but > add the size argument? On all relevant platforms that should still be > register arg callable, and the branch isn't free either. Well, the idea was that both versions were compatible with existing functions: one with DynaHash's hash and compare functions and the other with qsort_arg's compare function type. In the attached version I've done as you suggested in 0001. Since I guess many users will finish up wanting raw memory compare and hash I've provided dshash_memcmp() and dshash_memhash(). Thoughts? Since there is no attempt to be compatible with anything else, I was slightly tempted to make equal functions return true for a match, rather than the memcmp-style return value but figured it was still better to be consistent. > - might be worthwhile to try to reduce duplication between > delete_item_from_bucket, delete_key_from_bucket, delete_item > dshash_delete_key. Yeah. I will try this and send a separate refactoring patch. > For later commits in the series: > - Afaict the whole shared tupledesc stuff, as tqueue.c before, is > entirely untested. This baffles me. See also [1]. I can force the code > to be reached with force_parallel_mode=regress/1, but this absolutely > really totally needs to be reached by the default tests. Robert? A fair point. 0002 is a simple patch to push some blessed records through a TupleQueue in select_parallel.sql. It doesn't do ranges and arrays (special cases in the tqueue.c code that 0004 rips out), but for exercising the new shared code I believe this is enough. If you apply just 0002 and 0004 then this test fails with a strange confused record decoding error as expected. > - gcc wants static before const (0004). Fixed. > - Afaict GetSessionDsmHandle() uses the current rather than > TopMemoryContext. Try running the regression tests under > force_parallel_mode - crashes immediately for me without fixing that. Gah, right. Fixed. > - SharedRecordTypmodRegistryInit() is called from GetSessionDsmHandle() > which calls EnsureCurrentSession(), but > SharedRecordTypmodRegistryInit() does so again - sprinkling those > around liberally seems like it could hide bugs. Yeah. Will look into this. -- Thomas Munro http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Вложения
On Wed, Aug 23, 2017 at 11:58 PM, Thomas Munro <thomas.munro@enterprisedb.com> wrote: > On Wed, Aug 23, 2017 at 5:46 PM, Andres Freund <andres@anarazel.de> wrote: >> - Afaict GetSessionDsmHandle() uses the current rather than >> TopMemoryContext. Try running the regression tests under >> force_parallel_mode - crashes immediately for me without fixing that. > > Gah, right. Fixed. That version missed an early return case where dsm_create failed. Here's a version that restores the caller's memory context in that case too. -- Thomas Munro http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Вложения
On Wed, Aug 23, 2017 at 1:46 AM, Andres Freund <andres@anarazel.de> wrote: > For later commits in the series: > - Afaict the whole shared tupledesc stuff, as tqueue.c before, is > entirely untested. This baffles me. See also [1]. I can force the code > to be reached with force_parallel_mode=regress/1, but this absolutely > really totally needs to be reached by the default tests. Robert? force_parallel_mode=regress is a good way of testing this because it keeps the leader from doing the work, which would likely dodge any bugs that happened to exist. If you want to test something in the regular regression tests, using force_parallel_mode=on is probably a good way to do it. Also note that there are 3 buildfarm members that test with force_parallel_mode=regress on a regular basis, so it's not like there is no automated coverage of this area. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
On 2017-08-23 09:45:38 -0400, Robert Haas wrote: > On Wed, Aug 23, 2017 at 1:46 AM, Andres Freund <andres@anarazel.de> wrote: > > For later commits in the series: > > - Afaict the whole shared tupledesc stuff, as tqueue.c before, is > > entirely untested. This baffles me. See also [1]. I can force the code > > to be reached with force_parallel_mode=regress/1, but this absolutely > > really totally needs to be reached by the default tests. Robert? > > force_parallel_mode=regress is a good way of testing this because it > keeps the leader from doing the work, which would likely dodge any > bugs that happened to exist. If you want to test something in the > regular regression tests, using force_parallel_mode=on is probably a > good way to do it. > > Also note that there are 3 buildfarm members that test with > force_parallel_mode=regress on a regular basis, so it's not like there > is no automated coverage of this area. I don't think that's sufficient. make, and especially check-world, should have a decent coverage of the code locally. Without having to know about options like force_parallel_mode=regress. As e.g. evidenced by the fact that Thomas's latest version crashed if you ran the tests that way. If there's a few lines that aren't covered by the plain tests, and more than a few node + parallelism combinations, I'm not bothered much. But this is (soon hopefully was) a fairly complicated piece of infrastructure - that should be exercised. If necessary that can just be a BEGIN; SET LOCAL force_parallel_mode=on; query with blessed descs;COMMIT or whatnot - it's not like we need something hugely complicated here. Greetings, Andres Freund
On Wed, Aug 23, 2017 at 12:42 PM, Andres Freund <andres@anarazel.de> wrote: > I don't think that's sufficient. make, and especially check-world, > should have a decent coverage of the code locally. Without having to > know about options like force_parallel_mode=regress. As e.g. evidenced > by the fact that Thomas's latest version crashed if you ran the tests > that way. If there's a few lines that aren't covered by the plain > tests, and more than a few node + parallelism combinations, I'm not > bothered much. But this is (soon hopefully was) a fairly complicated > piece of infrastructure - that should be exercised. If necessary that > can just be a BEGIN; SET LOCAL force_parallel_mode=on; query with > blessed descs;COMMIT or whatnot - it's not like we need something hugely > complicated here. Yeah, we've been bitten before by changes that seemed OK when run without force_parallel_mode but misbehaved with that option, so it would be nice to improve things. Now, I'm not totally convinced that just adding a test around blessed tupledescs is really going to help very much - that option exercises a lot of code, and this is only one relatively small bit of it. But I'm certainly not objecting to the idea. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
On Wed, Aug 23, 2017 at 11:58 PM, Thomas Munro <thomas.munro@enterprisedb.com> wrote: > On Wed, Aug 23, 2017 at 5:46 PM, Andres Freund <andres@anarazel.de> wrote: >> Notes for possible followup commits of the dshash API: >> - nontrivial portions of dsahash are essentially critical sections lest >> dynamic shared memory is leaked. Should we, short term, introduce >> actual critical section markers to make that more obvious? Should we, >> longer term, make this more failsafe / easier to use, by >> extending/emulating memory contexts for dsa memory? > > Hmm. I will look into this. Yeah, dshash_create() leaks the control object if the later allocation of the initial hash table array raises an error. I think that should be fixed -- please see 0001 in the new patch set attached. The other two places where shared memory is allocated are resize() and insert_into_bucket(), and both of those seem exception-safe to me: if dsa_allocate() elogs then nothing is changed, and the code after that point is no-throw. Am I missing something? >> - SharedRecordTypmodRegistryInit() is called from GetSessionDsmHandle() >> which calls EnsureCurrentSession(), but >> SharedRecordTypmodRegistryInit() does so again - sprinkling those >> around liberally seems like it could hide bugs. > > Yeah. Will look into this. One idea is to run InitializeSession() in InitPostgres() instead, so that CurrentSession is initialized at startup, but initially empty. See attached. (I realised that that terminology is a bit like a large volume called FRENCH CUISINE which turns out to have just one recipe for an omelette in it, but you have to start somewhere...) Better ideas? -- Thomas Munro http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Вложения
On 2017-08-21 11:02:52 +1200, Thomas Munro wrote: > 2. Andres didn't like what I did to DecrTupleDescRefCount, namely > allowing to run when there is no ResourceOwner. I now see that this > is probably an indication of a different problem; even if there were a > worker ResourceOwner as he suggested (or perhaps a session-scoped one, > which a worker would reset before being reused), it wouldn't be the > one that was active when the TupleDesc was created. I think I have > failed to understand the contracts here and will think/read about it > some more. Maybe I'm missing something, but isn't the issue here that using DecrTupleDescRefCount() simply is wrong, because we're not actually necessarily tracking the TupleDesc via the resowner mechanism? If you look at the code, in the case it's a previously unknown tupledesc it's registered with: entDesc = CreateTupleDescCopy(tupDesc); .../* mark it as a reference-counted tupdesc */entDesc->tdrefcount = 1; ...RecordCacheArray[newtypmod] = entDesc; ... Note that there's no PinTupleDesc(), IncrTupleDescRefCount() or ResourceOwnerRememberTupleDesc() managing the reference from the array. Nor was there one before. We have other code managing TupleDesc lifetimes similarly, and look at how they're freeing it: /* Delete tupdesc if we have it */ if (typentry->tupDesc != NULL) { /* *Release our refcount, and free the tupdesc if none remain. * (Can't use DecrTupleDescRefCount because this referenceis not * logged in current resource owner.) */ Assert(typentry->tupDesc->tdrefcount > 0); if (--typentry->tupDesc->tdrefcount == 0) FreeTupleDesc(typentry->tupDesc); typentry->tupDesc= NULL; } This also made me think about how we're managing the lookup from the shared array: /* * Our local array can now point directly to the TupleDesc * in sharedmemory. */ RecordCacheArray[typmod] = tupdesc; Uhm. Isn't that highly highly problematic? E.g. tdrefcount manipulations which are done by all lookups (cf. lookup_rowtype_tupdesc()) would in that case manipulate shared memory in a concurrency unsafe manner. Greetings, Andres Freund
Thanks for the review and commits so far. Here's a rebased, debugged and pgindented version of the remaining patches. I ran pgindent with --list-of-typedefs="SharedRecordTableKey,SharedRecordTableEntry,SharedTypmodTableEntry,SharedRecordTypmodRegistry,Session" to fix some weirdness around these new typenames. While rebasing the 0002 patch (removal of tqueue.c's remapping logic), I modified the interface of the newly added ExecParallelCreateReaders() function from commit 51daa7bd because it no longer has any reason to take a TupleDesc. On Fri, Aug 25, 2017 at 1:46 PM, Andres Freund <andres@anarazel.de> wrote: > On 2017-08-21 11:02:52 +1200, Thomas Munro wrote: >> 2. Andres didn't like what I did to DecrTupleDescRefCount, namely >> allowing to run when there is no ResourceOwner. I now see that this >> is probably an indication of a different problem; even if there were a >> worker ResourceOwner as he suggested (or perhaps a session-scoped one, >> which a worker would reset before being reused), it wouldn't be the >> one that was active when the TupleDesc was created. I think I have >> failed to understand the contracts here and will think/read about it >> some more. > > Maybe I'm missing something, but isn't the issue here that using > DecrTupleDescRefCount() simply is wrong, because we're not actually > necessarily tracking the TupleDesc via the resowner mechanism? Yeah. Thanks. > If you look at the code, in the case it's a previously unknown tupledesc > it's registered with: > > entDesc = CreateTupleDescCopy(tupDesc); > ... > /* mark it as a reference-counted tupdesc */ > entDesc->tdrefcount = 1; > ... > RecordCacheArray[newtypmod] = entDesc; > ... > > Note that there's no PinTupleDesc(), IncrTupleDescRefCount() or > ResourceOwnerRememberTupleDesc() managing the reference from the > array. Nor was there one before. > > We have other code managing TupleDesc lifetimes similarly, and look at > how they're freeing it: > /* Delete tupdesc if we have it */ > if (typentry->tupDesc != NULL) > { > /* > * Release our refcount, and free the tupdesc if none remain. > * (Can't use DecrTupleDescRefCount because this reference is not > * logged in current resource owner.) > */ > Assert(typentry->tupDesc->tdrefcount > 0); > if (--typentry->tupDesc->tdrefcount == 0) > FreeTupleDesc(typentry->tupDesc); > typentry->tupDesc = NULL; > } Right. I have changed shared_record_typmod_registry_worker_detach() to be more like that, with an explanation. > This also made me think about how we're managing the lookup from the > shared array: > > /* > * Our local array can now point directly to the TupleDesc > * in shared memory. > */ > RecordCacheArray[typmod] = tupdesc; > > Uhm. Isn't that highly highly problematic? E.g. tdrefcount manipulations > which are done by all lookups (cf. lookup_rowtype_tupdesc()) would in > that case manipulate shared memory in a concurrency unsafe manner. No. See this change, in that and similar code paths: - IncrTupleDescRefCount(tupDesc); + PinTupleDesc(tupDesc); The difference between IncrTupleDescRefCount() and PinTupleDesc() is that the latter recognises non-refcounted tuple descriptors (tdrefcount == -1) and does nothing. Shared tuple descriptors are not reference counted (see TupleDescCopy() which initialises dst->tdrefcount to -1). It was for foolish symmetry that I was trying to use ReleaseTupleDesc() in shared_record_typmod_registry_detach() before, since it also knows about non-refcounted tuple descriptors, but that's not appropriate: it calls DecrTupleDescRefCount() which assumes that we're using resource owners. We're not. To summarise the object lifetime management situation created by this patch: shared TupleDesc objects accumulate in per-session DSM memory until eventually the session ends and the DSM memory goes away. A bit like CacheMemoryContext: there is no retail cleanup of shared TupleDesc objects. BUT: the DSM detach callback is used to clear out backend-local pointers to that stuff (and any non-shared reference counted TupleDesc objects that might be found), in anticipation of being able to reuse a worker process one day (which will involve attaching to a new session, so we mustn't retain any traces of the previous session in our local state). Maybe I'm trying to be a little too clairvoyant there... I improved the cleanup code: now it frees RecordCacheArray and RecordCacheHash and reinstalls NULL pointers. Also it deals with errors in GetSessionDsmHandle() better. I renamed the members of Session to include a "shared_" prefix, which seems a bit clearer. I refactored it so that it never makes needless local copies of TupleDesc objects (previously assign_record_type_typmod() would create an extra local copy and cache that, which was wasteful). That actually makes much of the discussion above moot: on detach, a worker should now ONLY find shared non-refcounted TupleDesc objects in the local caches, so the FreeTupleDesc() case is unreachable... The leader on the other hand can finish up with a mixture of local and shared TupleDesc objects in its cache, if it had some before it ran a parallel query. Its detach hook doesn't try to free those so it doesn't matter. -- Thomas Munro http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Вложения
Hi, On 2017-09-04 18:14:39 +1200, Thomas Munro wrote: > Thanks for the review and commits so far. Here's a rebased, debugged > and pgindented version of the remaining patches. I've pushed this with minor modifications: - added typedefs to typedefs.list - re-pgindented, there were some missing reindents in headers - added a very brief intro into session.c, moved some content repeated in various places to the header - some of them werebound to become out-of-date due to future uses of the facility. - moved NULL setting in detach hook directly after the respective resource deallocation, for the not really probable caseof it being reinvoked due to an error in a later dealloc function Two remarks: - I'm not sure I like the order in which things are added to the typemod hashes, I wonder if some more careful organizationcould get rid of the races. Doesn't seem critical, but would be a bit nicer. - I'm not yet quite happy with the Session facility. I think it'd be nicer if we'd a cleaner split between the shared memorynotion of a session and the local memory version of it. The shared memory version would live in a ~max_connectionssized array, referenced from PGPROC. In a lot of cases it'd completely obsolete the need for a shm_toc, becauseyou could just store handles etc in there. The local memory version then would just store local pointers etc intothat. But I think we can get there incrementally. It's very nice to push commits that have stats like6 files changed, 27 insertions(+), 1110 deletions(-) even if it essentially has been paid forward by a lot of previous work ;) Thanks for the work on this! Regards, Andres -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
On Fri, Sep 15, 2017 at 3:03 PM, Andres Freund <andres@anarazel.de> wrote: > On 2017-09-04 18:14:39 +1200, Thomas Munro wrote: >> Thanks for the review and commits so far. Here's a rebased, debugged >> and pgindented version of the remaining patches. > > I've pushed this with minor modifications: Thank you! > - added typedefs to typedefs.list Should I do this manually with future patches? > - re-pgindented, there were some missing reindents in headers > - added a very brief intro into session.c, moved some content repeated > in various places to the header - some of them were bound to become > out-of-date due to future uses of the facility. > - moved NULL setting in detach hook directly after the respective > resource deallocation, for the not really probable case of it being > reinvoked due to an error in a later dealloc function > > Two remarks: > - I'm not sure I like the order in which things are added to the typemod > hashes, I wonder if some more careful organization could get rid of > the races. Doesn't seem critical, but would be a bit nicer. I will have a think about whether I can improve that. In an earlier version I did things in a different order and had different problems. The main hazard to worry about here is that you can't let any typmod number escape into shmem where it might be read by others (for example a concurrent session that wants a typmod for a TupleDesc that happens to match) until the typmod number is resolvable back to a TupleDesc (meaning you can look it up in shared_typmod_table). Not wasting/leaking memory in various failure cases is a secondary (but obviously important) concern. > - I'm not yet quite happy with the Session facility. I think it'd be > nicer if we'd a cleaner split between the shared memory notion of a > session and the local memory version of it. The shared memory version > would live in a ~max_connections sized array, referenced from > PGPROC. In a lot of cases it'd completely obsolete the need for a > shm_toc, because you could just store handles etc in there. The local > memory version then would just store local pointers etc into that. > > But I think we can get there incrementally. +1 to all of the above. I fully expect this to get changed around quite a lot. I'll keep an eye out for problem reports. -- Thomas Munro http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Thomas Munro <thomas.munro@enterprisedb.com> writes: > On Fri, Sep 15, 2017 at 3:03 PM, Andres Freund <andres@anarazel.de> wrote: >> - added typedefs to typedefs.list > Should I do this manually with future patches? FWIW, I'm not on board with that. I think the version of typedefs.list in the tree should reflect the last official pgindent run. There's also a problem that it only works well if *every* committer faithfully updates typedefs.list, which isn't going to happen. For local pgindent'ing, I pull down https://buildfarm.postgresql.org/cgi-bin/typedefs.pl and then add any typedefs created by the patch I'm working on to that. But I don't put the result into the commit. Maybe we need a bit better documentation and/or tool support for using an unofficial typedef list. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
On 2017-09-14 23:29:05 -0400, Tom Lane wrote: > Thomas Munro <thomas.munro@enterprisedb.com> writes: > > On Fri, Sep 15, 2017 at 3:03 PM, Andres Freund <andres@anarazel.de> wrote: > >> - added typedefs to typedefs.list > > > Should I do this manually with future patches? I think there's sort of a circuit split on that one. Robert and I do regularly, most others don't. > FWIW, I'm not on board with that. I think the version of typedefs.list > in the tree should reflect the last official pgindent run. Why? I see pretty much no upside to that. You can't reindent anyway, due to unindented changes. You can get the used typedefs.list trivially from git. > There's also a problem that it only works well if *every* committer > faithfully updates typedefs.list, which isn't going to happen. > > For local pgindent'ing, I pull down > > https://buildfarm.postgresql.org/cgi-bin/typedefs.pl > > and then add any typedefs created by the patch I'm working on to that. > But I don't put the result into the commit. Maybe we need a bit better > documentation and/or tool support for using an unofficial typedef list. That's a mighty manual process - I want to be able to reindent files, especially new ones where it's still reasonably possible, without having to download files, then move changes out of the way, so I can rebase, ... Greetings, Andres Freund -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Andres Freund <andres@anarazel.de> writes: > On 2017-09-14 23:29:05 -0400, Tom Lane wrote: >> FWIW, I'm not on board with that. I think the version of typedefs.list >> in the tree should reflect the last official pgindent run. > Why? I see pretty much no upside to that. You can't reindent anyway, due > to unindented changes. You can get the used typedefs.list trivially from > git. Perhaps, but the real problem is still this: >> There's also a problem that it only works well if *every* committer >> faithfully updates typedefs.list, which isn't going to happen. We can't even get everybody to pgindent patches before commit, let alone update typedefs.list. So sooner or later your process is going to need to involve getting a current list from the buildfarm. >> For local pgindent'ing, I pull down >> https://buildfarm.postgresql.org/cgi-bin/typedefs.pl > That's a mighty manual process - I want to be able to reindent files, > especially new ones where it's still reasonably possible, without having > to download files, then move changes out of the way, so I can rebase, Well, that just shows you don't know how to use it. You can tell pgindent to use an out-of-tree copy of typedefs.list. I have the curl fetch and using the out-of-tree list all nicely scripted ;-) There might be something to be said for removing the typedefs list from git altogether, and adjusting the standard wrapper script to pull it from the buildfarm into a .gitignore'd location if there's not a copy there already. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
On 2017-09-15 15:39:49 -0400, Tom Lane wrote: > Andres Freund <andres@anarazel.de> writes: > > On 2017-09-14 23:29:05 -0400, Tom Lane wrote: > >> FWIW, I'm not on board with that. I think the version of typedefs.list > >> in the tree should reflect the last official pgindent run. > > > Why? I see pretty much no upside to that. You can't reindent anyway, due > > to unindented changes. You can get the used typedefs.list trivially from > > git. > > Perhaps, but the real problem is still this: > > >> There's also a problem that it only works well if *every* committer > >> faithfully updates typedefs.list, which isn't going to happen. > > We can't even get everybody to pgindent patches before commit, let alone > update typedefs.list. Well, that's partially because right now it's really painful to do so, and we've not tried to push people to do so. You essentially have to: 1) Pull down a new typedefs.list (how many people know where from?) 2) Add new typedefs that have been added in the commit-to-be 3) Run pgindent only on the changed files, because there's bound to be thousands of unrelated reindents 4) Revert reindents in changed files that are unrelated to the commit. 1) is undocumented 2) is painful (add option to automatically generate?), 3) is painful (add commandline tool?) 4) is painful. So it's not particularly surprising that many don't bother. > >> For local pgindent'ing, I pull down > >> https://buildfarm.postgresql.org/cgi-bin/typedefs.pl > > > That's a mighty manual process - I want to be able to reindent files, > > especially new ones where it's still reasonably possible, without having > > to download files, then move changes out of the way, so I can rebase, > > Well, that just shows you don't know how to use it. You can tell pgindent > to use an out-of-tree copy of typedefs.list. I have the curl fetch and > using the out-of-tree list all nicely scripted ;-) Not sure how that invalidates my statement. If you have to script it locally, and still have to add typedefs manually, that's still plenty stuff every committer (and better even, ever contributor!) has to learn. > There might be something to be said for removing the typedefs list > from git altogether, and adjusting the standard wrapper script to pull > it from the buildfarm into a .gitignore'd location if there's not a > copy there already. I wonder if we could add a command that pulls down an up2date list *and* regenerates a list for the local tree with the local settings. And then runs pgindent with the combined list - in most cases that'd result in a properly indented tree. The number of commits with platform specific changes that the author/committer doesn't compile/run isn't that high. Greetings, Andres Freund -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers