[COMMITTERS] pgsql: Include policies based on ACLs needed
Include policies based on ACLs needed When considering which policies should be included, rather than look at individual bits of the query (eg: if a RETURNING clause exists, or if a WHERE clause exists which is referencing the table, or if it's a FOR SHARE/UPDATE query), consider any case where we've determined the user needs SELECT rights on the relation while doing an UPDATE or DELETE to be a case where we apply SELECT policies, and any case where we've deteremind that the user needs UPDATE rights on the relation while doing a SELECT to be a case where we apply UPDATE policies. This simplifies the logic and addresses concerns that a user could use UPDATE or DELETE with a WHERE clauses to determine if rows exist, or they could use SELECT .. FOR UPDATE to lock rows which they are not actually allowed to modify through UPDATE policies. Use list_append_unique() to avoid adding the same quals multiple times, as, on balance, the cost of checking when adding the quals will almost always be cheaper than keeping them and doing busywork for each tuple during execution. Back-patch to 9.5 where RLS was added. Branch -- master Details --- http://git.postgresql.org/pg/commitdiff/7d8db3e8f37aec9d252353904e77381a18a2fa9f Modified Files -- src/backend/rewrite/rowsecurity.c | 108 - src/test/regress/expected/rowsecurity.out | 60 2 files changed, 101 insertions(+), 67 deletions(-) -- Sent via pgsql-committers mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: Include policies based on ACLs needed
Include policies based on ACLs needed When considering which policies should be included, rather than look at individual bits of the query (eg: if a RETURNING clause exists, or if a WHERE clause exists which is referencing the table, or if it's a FOR SHARE/UPDATE query), consider any case where we've determined the user needs SELECT rights on the relation while doing an UPDATE or DELETE to be a case where we apply SELECT policies, and any case where we've deteremind that the user needs UPDATE rights on the relation while doing a SELECT to be a case where we apply UPDATE policies. This simplifies the logic and addresses concerns that a user could use UPDATE or DELETE with a WHERE clauses to determine if rows exist, or they could use SELECT .. FOR UPDATE to lock rows which they are not actually allowed to modify through UPDATE policies. Use list_append_unique() to avoid adding the same quals multiple times, as, on balance, the cost of checking when adding the quals will almost always be cheaper than keeping them and doing busywork for each tuple during execution. Back-patch to 9.5 where RLS was added. Branch -- REL9_5_STABLE Details --- http://git.postgresql.org/pg/commitdiff/75096c458aa8e27160112cc20a18fec3a111e4b0 Modified Files -- src/backend/rewrite/rowsecurity.c | 108 - src/test/regress/expected/rowsecurity.out | 60 2 files changed, 101 insertions(+), 67 deletions(-) -- Sent via pgsql-committers mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: Don't dump core when destroying an unused ParallelContext.
Don't dump core when destroying an unused ParallelContext. If a transaction or subtransaction creates a ParallelContext but ends without calling InitializeParallelDSM, the previous code would seg fault. Fix that. Branch -- master Details --- http://git.postgresql.org/pg/commitdiff/227d57f3587d7d2a7d0792011f5ac952ba763681 Modified Files -- src/backend/access/transam/parallel.c | 17 ++--- 1 file changed, 10 insertions(+), 7 deletions(-) -- Sent via pgsql-committers mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: Don't dump core when destroying an unused ParallelContext.
Don't dump core when destroying an unused ParallelContext. If a transaction or subtransaction creates a ParallelContext but ends without calling InitializeParallelDSM, the previous code would seg fault. Fix that. Branch -- REL9_5_STABLE Details --- http://git.postgresql.org/pg/commitdiff/91d97f03ca2a9ed56b322b69dde0392db835f722 Modified Files -- src/backend/access/transam/parallel.c | 17 ++--- 1 file changed, 10 insertions(+), 7 deletions(-) -- Sent via pgsql-committers mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: Add a Gather executor node.
Add a Gather executor node. A Gather executor node runs any number of copies of a plan in an equal number of workers and merges all of the results into a single tuple stream. It can also run the plan itself, if the workers are unavailable or haven't started up yet. It is intended to work with the Partial Seq Scan node which will be added in future commits. It could also be used to implement parallel query of a different sort by itself, without help from Partial Seq Scan, if the single_copy mode is used. In that mode, a worker executes the plan, and the parallel leader does not, merely collecting the worker's results. So, a Gather node could be inserted into a plan to split the execution of that plan across two processes. Nested Gather nodes aren't currently supported, but we might want to add support for that in the future. There's nothing in the planner to actually generate Gather nodes yet, so it's not quite time to break out the champagne. But we're getting close. Amit Kapila. Some designs suggestions were provided by me, and I also reviewed the patch. Single-copy mode, documentation, and other minor changes also by me. Branch -- master Details --- http://git.postgresql.org/pg/commitdiff/3bd909b220930f21d6e15833a17947be749e7fde Modified Files -- doc/src/sgml/config.sgml | 46 src/backend/commands/explain.c| 19 ++ src/backend/executor/Makefile |4 +- src/backend/executor/execAmi.c|8 + src/backend/executor/execMain.c |3 + src/backend/executor/execParallel.c | 14 +- src/backend/executor/execProcnode.c | 46 src/backend/executor/nodeGather.c | 299 + src/backend/nodes/copyfuncs.c | 25 +++ src/backend/nodes/outfuncs.c | 14 ++ src/backend/optimizer/path/costsize.c | 38 src/backend/optimizer/plan/createplan.c | 57 + src/backend/optimizer/plan/setrefs.c |1 + src/backend/optimizer/plan/subselect.c|1 + src/backend/optimizer/util/pathnode.c | 26 +++ src/backend/utils/misc/guc.c | 30 +++ src/backend/utils/misc/postgresql.conf.sample |3 + src/include/executor/executor.h |1 + src/include/executor/nodeGather.h | 25 +++ src/include/nodes/execnodes.h | 16 ++ src/include/nodes/nodes.h |3 + src/include/nodes/plannodes.h | 11 + src/include/nodes/relation.h | 13 ++ src/include/optimizer/cost.h |7 + src/include/optimizer/pathnode.h |3 + src/tools/pgindent/typedefs.list |4 + 26 files changed, 709 insertions(+), 8 deletions(-) -- Sent via pgsql-committers mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: Improve LISTEN startup time when there are many unread notificat
Improve LISTEN startup time when there are many unread notifications. If some existing listener is far behind, incoming new listener sessions would start from that session's read pointer and then need to advance over many already-committed notification messages, which they have no interest in. This was expensive in itself and also thrashed the pg_notify SLRU buffers a lot more than necessary. We can improve matters considerably in typical scenarios, without much added cost, by starting from the furthest-ahead read pointer, not the furthest-behind one. We do have to consider only sessions in our own database when doing this, which requires an extra field in the data structure, but that's a pretty small cost. Back-patch to 9.0 where the current LISTEN/NOTIFY logic was introduced. Matt Newell, slightly adjusted by me Branch -- REL9_3_STABLE Details --- http://git.postgresql.org/pg/commitdiff/aad86c518d7b3b97c14872258c02551b443536f0 Modified Files -- src/backend/commands/async.c | 50 +- 1 file changed, 45 insertions(+), 5 deletions(-) -- Sent via pgsql-committers mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: Improve LISTEN startup time when there are many unread notificat
Improve LISTEN startup time when there are many unread notifications. If some existing listener is far behind, incoming new listener sessions would start from that session's read pointer and then need to advance over many already-committed notification messages, which they have no interest in. This was expensive in itself and also thrashed the pg_notify SLRU buffers a lot more than necessary. We can improve matters considerably in typical scenarios, without much added cost, by starting from the furthest-ahead read pointer, not the furthest-behind one. We do have to consider only sessions in our own database when doing this, which requires an extra field in the data structure, but that's a pretty small cost. Back-patch to 9.0 where the current LISTEN/NOTIFY logic was introduced. Matt Newell, slightly adjusted by me Branch -- master Details --- http://git.postgresql.org/pg/commitdiff/07e4d03fb476587bd943b4ba7d51bf0bb559a631 Modified Files -- src/backend/commands/async.c | 49 +- 1 file changed, 44 insertions(+), 5 deletions(-) -- Sent via pgsql-committers mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: Improve LISTEN startup time when there are many unread notificat
Improve LISTEN startup time when there are many unread notifications. If some existing listener is far behind, incoming new listener sessions would start from that session's read pointer and then need to advance over many already-committed notification messages, which they have no interest in. This was expensive in itself and also thrashed the pg_notify SLRU buffers a lot more than necessary. We can improve matters considerably in typical scenarios, without much added cost, by starting from the furthest-ahead read pointer, not the furthest-behind one. We do have to consider only sessions in our own database when doing this, which requires an extra field in the data structure, but that's a pretty small cost. Back-patch to 9.0 where the current LISTEN/NOTIFY logic was introduced. Matt Newell, slightly adjusted by me Branch -- REL9_4_STABLE Details --- http://git.postgresql.org/pg/commitdiff/03f9b63e24ea6a40afbf518a281e9fca134e999c Modified Files -- src/backend/commands/async.c | 50 +- 1 file changed, 45 insertions(+), 5 deletions(-) -- Sent via pgsql-committers mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: Improve LISTEN startup time when there are many unread notificat
Improve LISTEN startup time when there are many unread notifications. If some existing listener is far behind, incoming new listener sessions would start from that session's read pointer and then need to advance over many already-committed notification messages, which they have no interest in. This was expensive in itself and also thrashed the pg_notify SLRU buffers a lot more than necessary. We can improve matters considerably in typical scenarios, without much added cost, by starting from the furthest-ahead read pointer, not the furthest-behind one. We do have to consider only sessions in our own database when doing this, which requires an extra field in the data structure, but that's a pretty small cost. Back-patch to 9.0 where the current LISTEN/NOTIFY logic was introduced. Matt Newell, slightly adjusted by me Branch -- REL9_5_STABLE Details --- http://git.postgresql.org/pg/commitdiff/8c8a834b14712de5252858aebbd4c5900c105c78 Modified Files -- src/backend/commands/async.c | 50 +- 1 file changed, 45 insertions(+), 5 deletions(-) -- Sent via pgsql-committers mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: Improve LISTEN startup time when there are many unread notificat
Improve LISTEN startup time when there are many unread notifications. If some existing listener is far behind, incoming new listener sessions would start from that session's read pointer and then need to advance over many already-committed notification messages, which they have no interest in. This was expensive in itself and also thrashed the pg_notify SLRU buffers a lot more than necessary. We can improve matters considerably in typical scenarios, without much added cost, by starting from the furthest-ahead read pointer, not the furthest-behind one. We do have to consider only sessions in our own database when doing this, which requires an extra field in the data structure, but that's a pretty small cost. Back-patch to 9.0 where the current LISTEN/NOTIFY logic was introduced. Matt Newell, slightly adjusted by me Branch -- REL9_0_STABLE Details --- http://git.postgresql.org/pg/commitdiff/2d4336cf85c13354b3da7acef4df06b74275 Modified Files -- src/backend/commands/async.c | 50 +- 1 file changed, 45 insertions(+), 5 deletions(-) -- Sent via pgsql-committers mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: Improve LISTEN startup time when there are many unread notificat
Improve LISTEN startup time when there are many unread notifications. If some existing listener is far behind, incoming new listener sessions would start from that session's read pointer and then need to advance over many already-committed notification messages, which they have no interest in. This was expensive in itself and also thrashed the pg_notify SLRU buffers a lot more than necessary. We can improve matters considerably in typical scenarios, without much added cost, by starting from the furthest-ahead read pointer, not the furthest-behind one. We do have to consider only sessions in our own database when doing this, which requires an extra field in the data structure, but that's a pretty small cost. Back-patch to 9.0 where the current LISTEN/NOTIFY logic was introduced. Matt Newell, slightly adjusted by me Branch -- REL9_1_STABLE Details --- http://git.postgresql.org/pg/commitdiff/2bbe8a6847a0b449a96b29a1e2d3ed7b9a55ef37 Modified Files -- src/backend/commands/async.c | 50 +- 1 file changed, 45 insertions(+), 5 deletions(-) -- Sent via pgsql-committers mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: Fix errors in commit a04bb65f70dafdf462e0478ad19e6de56df89bfc.
Fix errors in commit a04bb65f70dafdf462e0478ad19e6de56df89bfc. Not a lot of commentary needed here really. Branch -- master Details --- http://git.postgresql.org/pg/commitdiff/5884b92a841d83ceadb986843892d57c68ea32cd Modified Files -- src/backend/commands/async.c |2 +- src/test/isolation/isolation_schedule |1 + 2 files changed, 2 insertions(+), 1 deletion(-) -- Sent via pgsql-committers mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: Improve LISTEN startup time when there are many unread notificat
Improve LISTEN startup time when there are many unread notifications. If some existing listener is far behind, incoming new listener sessions would start from that session's read pointer and then need to advance over many already-committed notification messages, which they have no interest in. This was expensive in itself and also thrashed the pg_notify SLRU buffers a lot more than necessary. We can improve matters considerably in typical scenarios, without much added cost, by starting from the furthest-ahead read pointer, not the furthest-behind one. We do have to consider only sessions in our own database when doing this, which requires an extra field in the data structure, but that's a pretty small cost. Back-patch to 9.0 where the current LISTEN/NOTIFY logic was introduced. Matt Newell, slightly adjusted by me Branch -- REL9_2_STABLE Details --- http://git.postgresql.org/pg/commitdiff/e4c00750af916cf001725dbb034b198eed8eee0c Modified Files -- src/backend/commands/async.c | 50 +- 1 file changed, 45 insertions(+), 5 deletions(-) -- Sent via pgsql-committers mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
