Re: [COMMITTERS] pgsql: Mark pg_start_backup and pg_stop_backup as parallel-restricted.
On 3/6/17 12:48 PM, Robert Haas wrote: Mark pg_start_backup and pg_stop_backup as parallel-restricted. They depend on backend-private state that will not be synchronized by the parallel machinery, so they should not be marked parallel-safe. This issue also exists in 9.6, but we obviously can't do anything about 9.6 clusters that already exist. Possibly this could be back-patched so that future 9.6 clusters would come out OK, or possibly we should back-patch some other fix, but that would need more discussion. I think it would be worth back-patching the catalog fix for future 9.6 clusters as a start. Parallelism is off by default in 9.6 so that mitigates some of the problem. I don't have any regression tests that cover backups when parallelism is enabled in 9.6, but I'm willing to do that and see if this is a realistic issue or not. -- -David da...@pgmasters.net -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
Re: [HACKERS] Re: [COMMITTERS] pgsql: Avoid extra locks in GetSnapshotData if old_snapshot_threshold
On 4/16/16 4:44 PM, Noah Misch wrote: > The key judgment to finalize here is whether it's okay to release this feature > given its current effect[1], when enabled, on performance. That is more > controversial than the potential ~2% regression for old_snapshot_threshold=-1. > Alvaro[2] and Robert[3] are okay releasing that way, and Andres[4] is not. If > anyone else wants to weigh in, now is the time. I'm in favor of releasing the feature even with the performance regression when enabled. First, there are use cases where a feature like this is absolutely critical. Second, I don't think it will improve and become performant without exposure to a wider audience. I think it's entirely within the PostgreSQL philosophy to release a feature that has warts and doesn't perform as well as we'd like as long as it is stable and does not corrupt data. In my opinion this feature meets these criteria and it is an important capability to add to PostgreSQL. -- -David da...@pgmasters.net -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
Re: [HACKERS] [COMMITTERS] pgsql: Use gender-neutral language in documentation
On 9/22/15 11:00 AM, Andrew Dunstan wrote: On 09/22/2015 10:29 AM, Geoff Winkless wrote: That's your opinion; my opinion remains otherwise. It's not "perfectly reasonable" to abuse the plural because some 1960s feminazis either misunderstood or didn't like the fact that (because of history) in English the gender-neutral singular happens to also be the male singular. Wow, 1960s feminazis, eh? I originally thought you were just a narrow minded, pedantic and antiquated grammarian. Now I realize that's the least of your troubles. Please take your misogyny elsewhere. I hear the Rabid Puppies have openings. I think conversations like this are a part of why we have trouble attracting new contributors (of any gender) to the community. -- -David da...@pgmasters.net -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
Re: [COMMITTERS] pgsql: Add pg_audit, an auditing extension
On 5/15/15 3:44 PM, Stephen Frost wrote: > * Fujii Masao (masao.fu...@gmail.com) wrote: >> CREATE EXTENSION pg_audit failed with the following error message >> when shared_preload_libraries and pg_audit.log are set to pg_audit and >> ddl, respectively. >> >> =# create extension pg_audit ; >> ERROR: pg_event_trigger_ddl_commands() can only be called in an event >> trigger function >> CONTEXT: SQL statement "SELECT UPPER(object_type), object_identity >> FROM pg_event_trigger_ddl_commands()" > Interesting. I'm very curious about this error and if it impacts other > extensions which use event triggers. I'll look into it. I'm looking into this. There's definitely something strange going on here, but not sure it's in pg_audit. >> The categories of some SQL commands are different between log_statement and >> pg_audit. For example, REINDEX is treated as DDL in pg_audit, but not in >> log_statement. That's confusing. We should use the same "category-mapping" >> rule as much as possible. > David, Simon and I have all considered this at different times and my > recollection is that we all felt that it made sense as DDL because > CLUSTER is DDL (which is actually noted in the comments). However, you > bring up a good point that classifying it as DDL makes it different from > what the core system does and it'd probably be good to be consistent. > > The question here really is- is that the right classification for > REINDEX to have in core? If so, shouldn't CLUSTER have the same? > Probably a discussion to have on -hackers rather than here. I'll go > ahead and change it to match what core does. Then, if core changes to > make it DDL, pg_audit will automatically pick that up and also treat it > as DDL. I admit I was influenced by this comment in core: case T_ReindexStmt: lev = LOGSTMT_ALL;/* should this be DDL? */ break; and the fact that CLUSTER is DDL. I'm not married to REINDEX as DDL, though. I'm happy to make it consistent with core. If it changes in core, it would also change in pg_audit. -- - David Steele da...@pgmasters.net signature.asc Description: OpenPGP digital signature
