Re: [HACKERS] [COMMITTERS] pgsql: Use gender-neutral language in documentation

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. The term feminazi has zero business in this

Re: [HACKERS] Rework the way multixact truncations work

On Tue, Sep 22, 2015 at 9:20 AM, Andres Freund wrote: > On 2015-09-21 16:36:03 +0200, Andres Freund wrote: >> Agreed. I'll update the patch. > > Here's updated patches against master. These include the "legacy" > truncation support. There's no meaningful functional differences

Re: [HACKERS] Parallel Seq Scan

On Fri, Sep 18, 2015 at 5:31 PM, Amit Kapila wrote: > > On Thu, Sep 17, 2015 at 4:44 PM, Robert Haas wrote: > > > > I haven't studied the planner logic in enough detail yet to have a > > clear opinion on this. But what I do think is that this is a

Re: [HACKERS] hot_standby_feedback default and docs

On 9/16/15 5:52 PM, Simon Riggs wrote: > IMHO the default is the best one at the current time. > See recovery_min_apply_delay. The applications of recovery_min_apply_delay are likely to be varied and specific, so there might not be a general answer to this, but wouldn't you want

Re: [HACKERS] [COMMITTERS] pgsql: Use gender-neutral language in documentation

On 2015-09-22 20:33, Andrew Dunstan wrote: now some reactionaries and misogynists are fighting to maintain that somewhat latter day rule. That's almost as offensive a qualification as 'feminazi', don't you agree? And it rather makes the gender-avoidance sound as a political-correctness

Re: [HACKERS] TABLESAMPLE patch is really in pretty sad shape

On 9/19/15 10:46 AM, Tom Lane wrote: > Peter Eisentraut writes: >> On 7/23/15 6:39 PM, Tom Lane wrote: >>> + 2202HEERRCODE_INVALID_TABLESAMPLE_ARGUMENT >>>invalid_tablesample_argument >>> + 2202GEERRCODE_INVALID_TABLESAMPLE_REPEAT

Re: [HACKERS] [COMMITTERS] pgsql: Use gender-neutral language in documentation

On 09/22/2015 01:43 PM, Mark Dilger wrote: On Sep 22, 2015, at 6:09 AM, Andrew Dunstan wrote: You are fighting a losing battle. Think of they/them/their/theirs as being indefinitely gendered third person singular pronouns, as well as being third person plural pronouns.

Re: [HACKERS] Rework the way multixact truncations work

On Tue, Sep 22, 2015 at 1:57 PM, Andres Freund wrote: > On 2015-09-22 13:38:58 -0400, Robert Haas wrote: >> Regarding 0003, I'm still very much not convinced that it's a good >> idea to apply this to 9.3 and 9.4. This patch changes the way we do >> truncation in those older

Re: [HACKERS] Calculage avg. width when operator = is missing

On 09/22/2015 12:16 PM, Shulgin, Oleksandr wrote: Hi Hackers, I've recently stumbled upon a problem with table bloat estimation in case there are columns of type JSON. The quick bloat estimation queries use sum over pg_statistic.stawidth of table's columns, but in case of JSON the

Re: [HACKERS] Calculage avg. width when operator = is missing

On Sep 22, 2015 8:58 PM, "Andrew Dunstan" wrote: > > > > On 09/22/2015 12:16 PM, Shulgin, Oleksandr wrote: >> >> Hi Hackers, >> >> I've recently stumbled upon a problem with table bloat estimation in case there are columns of type JSON. >> >> The quick bloat estimation

Re: [HACKERS] [COMMITTERS] pgsql: Use gender-neutral language in documentation

On Tue, Sep 22, 2015 at 2:33 PM, Andrew Dunstan wrote: > Good point. In the 18th and 19th centuries it was deemed by some grammarians > to be incorrect for some reason, (and yet Thackeray still used it in Vanity > Fair, for instance) and now some reactionaries and misogynists

Re: [HACKERS] [COMMITTERS] pgsql: Use gender-neutral language in documentation

Hello, - environment variable); any user can make such a change for his session. + environment variable); any user can make such a change for the session. Or + environment variable); any user can make such a change for the connected session. - allowed to change his

Re: [HACKERS] [COMMITTERS] pgsql: Use gender-neutral language in documentation

On Tue, Sep 22, 2015 at 11:59:21AM -0400, Robert Haas wrote: > On Tue, Sep 22, 2015 at 11:00 AM, Andrew Dunstan wrote: > >> Happily for me, I can continue to write documents in a grammatically > >> correct way, and no-one will read them and think I'm a grammar-nazi (or > >>

Re: [HACKERS] Rework the way multixact truncations work

On 2015-09-22 13:38:58 -0400, Robert Haas wrote: > Regarding 0003, I'm still very much not convinced that it's a good > idea to apply this to 9.3 and 9.4. This patch changes the way we do > truncation in those older releases; instead of happening at a > restartpoint, it happens when

Re: [HACKERS] Rework the way multixact truncations work

Robert Haas wrote: > Regarding 0003, I'm still very much not convinced that it's a good > idea to apply this to 9.3 and 9.4. This patch changes the way we do > truncation in those older releases; instead of happening at a > restartpoint, it happens when oldestMultiXid advances. I admit that I >

Re: [HACKERS] [COMMITTERS] pgsql: Use gender-neutral language in documentation

On 2015-09-22 19:25, Garick Hamlin wrote: Constructs like 'he or she' exclude people. This remains difficult for me to follow but with all the native speakers being in favor of this change I for one retract my objections. thanks, Erik Rijkers -- Sent via pgsql-hackers mailing list

Re: [HACKERS] 9.5: Can't connect with PGSSLMODE=require on Windows

On Tue, Sep 22, 2015 at 11:23 AM, Andrew Dunstan wrote: > "git bisect" is your friend. Yeah, but finding someone who has a working Windows build environment and a lot of time to run this down is my enemy. We're trying, but if anyone else has a clue, that would be much

Re: [HACKERS] [COMMITTERS] pgsql: Use gender-neutral language in documentation

On Tue, Sep 22, 2015 at 7:11 AM, Andrew Dunstan wrote: > You can think that if you like, but it's not even remotely true. It's a > deliberate choice to use a new, perfectly reasonable and now widely accepted > style of which you disapprove, but it's not lazy. It never

Re: [HACKERS] [COMMITTERS] pgsql: Use gender-neutral language in documentation

> On Sep 22, 2015, at 6:09 AM, Andrew Dunstan wrote: > > You are fighting a losing battle. Think of they/them/their/theirs as being > indefinitely gendered third person singular pronouns, as well as being third > person plural pronouns. Yes it's a relatively new usage,

Re: [HACKERS] planstate_tree_walker oversight CustomScan

On Mon, Sep 21, 2015 at 9:54 AM, Kouhei Kaigai wrote: > The planstate_tree_walker() oversight custom_ps of CustomScanState; > that should be a list of underlying PlanState object if any. > > ExplainPreScanNode() treated ForeignScan and CustomScan in special > way (it is

Re: [HACKERS] Parallel Seq Scan

On Tue, Sep 22, 2015 at 9:18 PM, Amit Kapila wrote: > PlannedStmt is needed because we are passing the same from master > to worker for execution and the reason was that Executor interfaces > expect it. I thought we were passing the Plan and then the worker was

Re: [HACKERS] Parallel Seq Scan

On Tue, Sep 22, 2015 at 9:12 PM, Kouhei Kaigai wrote: > Oh... I did exactly duplicated job a few days before. > > https://github.com/kaigai/sepgsql/blob/readfuncs/src/backend/nodes/readfuncs.c Please post the patch here, and clarify that it is under the PostgreSQL

Re: [HACKERS] a funnel by any other name

On Tue, Sep 22, 2015 at 10:34 AM, Simon Riggs wrote: > Robert, thanks for asking. We'll be stuck with these words for some time, > user visible via EXPLAIN so this is important. I agree, thanks for taking an interest. > The main operations are the 3 mentioned by Nicolas:

Re: [HACKERS] planstate_tree_walker oversight CustomScan

On Tue, Sep 22, 2015 at 9:30 PM, Kouhei Kaigai wrote: > The latest ExplainPreScanNode is sufficient. Regardless of scanrelid > (even if it is zero), fs_relids and custom_relids shall be set properly > to introduce which relations are represented by this ForeignScan and >

Re: [HACKERS] Less than ideal error reporting in pg_stat_statements

On Tue, Sep 22, 2015 at 6:55 PM, Alvaro Herrera wrote: > So if I have multiple queries like > > SELECT foo FROM bar WHERE baz IN (a, b) > SELECT foo FROM bar WHERE baz IN (a, b, c) > > they are not normalized down to the same? That seems odd. Yes, although in practice

Re: [HACKERS] a funnel by any other name

Robert Haas wrote: > On Tue, Sep 22, 2015 at 10:34 AM, Simon Riggs wrote: > > For 1, Gather makes most sense. > > Yeah, I'm leaning that way myself. Amit argued for "Parallel Gather" > but I think that's overkill. There can't be a non-parallel gather, > and long names

Re: [HACKERS] Parallel Seq Scan

> On Tue, Sep 22, 2015 at 9:12 PM, Kouhei Kaigai wrote: > > Oh... I did exactly duplicated job a few days before. > > > https://github.com/kaigai/sepgsql/blob/readfuncs/src/backend/nodes/readfuncs > .c > > Please post the patch here, and clarify that it is under the

[HACKERS] unclear about row-level security USING vs. CHECK

I'm testing the new row-level security feature. I'm not clear on the difference between the USING and CHECK clauses in the CREATE POLICY statement. The documentation says: """ A policy grants the ability to SELECT, INSERT, UPDATE, or DELETE rows which match the relevant policy expression.

Re: [HACKERS] Less than ideal error reporting in pg_stat_statements

On Tue, Sep 22, 2015 at 5:01 PM, Peter Geoghegan wrote: > My guess is that this very large query involved a very large number of > constants, possibly contained inside an " IN ( )". Slight variants of > the same query, that a human would probably consider to be equivalent > have

Re: [HACKERS] Parallel Seq Scan

On Wed, Sep 23, 2015 at 5:42 AM, Robert Haas wrote: > > On Tue, Sep 22, 2015 at 3:21 PM, Amit Kapila wrote: > > readAttrNumberCols uses sizeof(Oid) instead of sizeof(AttrNumber). > > I still don't understand why we need to handle PlanInvalItem.

Re: [HACKERS] unclear about row-level security USING vs. CHECK

Hello Peter > I'm testing the new row-level security feature. I'm not clear on the > difference between the USING and CHECK clauses in the CREATE POLICY > statement. > > The documentation says: > > """ > A policy grants the ability to SELECT, INSERT, UPDATE, or DELETE rows > which match the

Re: [HACKERS] Parallel Seq Scan

> > On Thu, Sep 17, 2015 at 4:44 PM, Robert Haas wrote: > > > > > > I haven't studied the planner logic in enough detail yet to have a > > > clear opinion on this. But what I do think is that this is a very > > > good reason why we should bite the bullet and add

Re: [HACKERS] planstate_tree_walker oversight CustomScan

> -Original Message- > From: pgsql-hackers-ow...@postgresql.org > [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Robert Haas > Sent: Wednesday, September 23, 2015 10:15 AM > To: Kaigai Kouhei(海外 浩平) > Cc: pgsql-hackers@postgresql.org > Subject: Re: [HACKERS] planstate_tree_walker

Re: [HACKERS] Less than ideal error reporting in pg_stat_statements

Peter Geoghegan wrote: > My guess is that this very large query involved a very large number of > constants, possibly contained inside an " IN ( )". Slight variants of > the same query, that a human would probably consider to be equivalent > have caused artificial pressure on garbage collection.

Re: [HACKERS] [COMMITTERS] pgsql: Use gender-neutral language in documentation

On 22 September 2015 at 15:11, Robert Haas wrote: > > On Tue, Sep 22, 2015 at 2:33 PM, Andrew Dunstan wrote: > > Good point. In the 18th and 19th centuries it was deemed by some grammarians > > to be incorrect for some reason, (and yet Thackeray still

Re: [HACKERS] [COMMITTERS] pgsql: Use gender-neutral language in documentation

On 22 September 2015 at 21:22, David Steele wrote: > I think conversations like this are a part of why we have trouble > attracting new contributors (of any gender) to the community. > ​It's very clear that my use of the word (which I shan't make the mistake of repeating!)

Re: [HACKERS] [COMMITTERS] pgsql: Use gender-neutral language in documentation

> I think conversations like this are a part of why we have trouble attracting > new contributors (of any gender) to the community. +1 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] [COMMITTERS] pgsql: Use gender-neutral language in documentation

On 23/09/15 08:17, Christopher Browne wrote: [...] "The user should do [something]; he or she or it, or the cis/trans/asexual personage or connection used by a web application, whether written in C, Java, Perl, PHP, running on Windows or Unix or ..." as the increasing inclusions heads to some

Re: [HACKERS] Calculage avg. width when operator = is missing

Tom Lane wrote: > Should we consider this HEAD-only, or a back-patchable bug fix? > Or perhaps compromise on HEAD + 9.5? It looks like a bug to me, but I think it might destabilize approved execution plans(*), so it may not be such a great idea to back patch branches that are already released.

Re: [HACKERS] One question about security label command

On 09/15/2015 11:36 AM, Joe Conway wrote: > On 09/13/2015 10:29 AM, Kouhei Kaigai wrote: >> The attached one is the regression test fixup in v9.2. >> As we applied to the v9.3 or later, it replaces unconfined_t domain >> by the self defined sepgsql_regtest_superuser_t. > Thanks -- I'll look

Re: [HACKERS] Calculage avg. width when operator = is missing

Shulgin, Oleksandr wrote: > On Sep 22, 2015 8:58 PM, "Andrew Dunstan" wrote: > > Yes, "/revenons/ à /nos moutons/." You can set up text based comparison > > ops fairly easily for json - you just need to be aware of the limitations. > > See

Re: [HACKERS] Calculage avg. width when operator = is missing

Alvaro Herrera writes: > In any case I think your patch is a good starting point. The comments seemed to need some wordsmithing, but I think this is probably basically a good idea; we've had similar complaints before about some other equality-less datatypes, such as

[HACKERS] Less than ideal error reporting in pg_stat_statements

A client was getting some hard to diagnose out of memory errors. What made this especially confusing was that there was no context reported at all, other than the (enormous) statement that triggered the error. At first I thought the lack of context indicated a palloc had failed during

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)

Re: [HACKERS] Support for N synchronous standby servers - take 2

>On 07/16/15, Robert Haas wrote: >     >>> * Developers will immediately understand the format >> >>I doubt it.  I think any format that we pick will have to be carefully >>documented.  People may know what JSON looks like in general, but they >>will not immediately know what bells and whistles

Re: [HACKERS] PATCH: use foreign keys to improve join estimates v1

On 20 August 2015 at 13:49, Tomas Vondra wrote: > attached is a significantly reworked patch for using the foreign keys in > selectivity estimation. > Thanks for working a new patch, I'm starting to look at it again now: Here's my thoughts so far: + /* + * TODO

Re: [HACKERS] Less than ideal error reporting in pg_stat_statements

On 23 September 2015 at 10:16, Jim Nasby wrote: > > Attached patch fixes, though I'm not sure if %lld is portable or not. > > I think you could probably use INT64_FORMAT, and cast the stat.st_size to int64 too. There's an example in FileRead() in fd.c Regards David

Re: [HACKERS] Rework the way multixact truncations work

On Tue, Sep 22, 2015 at 7:45 PM, Andres Freund wrote: > On 2015-09-23 01:24:31 +0200, Andres Freund wrote: >> I think we put at least three layers on bandaid on this issue since >> 9.3.2, and each layer made things more complicated. > > 2a9b01928f193f529b885ac577051c4fd00bd427

Re: [HACKERS] Rework the way multixact truncations work

On 2015-09-22 20:14:11 -0400, Robert Haas wrote: > I'm not disagreeing with any of that. I'm just disagreeing with you > on the likelihood that we're going to make things better vs. making > them worse. But, really, I've said everything I have to say about > this. You have a commit bit. I'm

Re: [HACKERS] Less than ideal error reporting in pg_stat_statements

David Rowley writes: > On 23 September 2015 at 10:16, Jim Nasby wrote: >>> Attached patch fixes, though I'm not sure if %lld is portable or not. It is not. > I think you could probably use INT64_FORMAT, Not in a message you expect to be

Re: [HACKERS] Rework the way multixact truncations work

On 2015-09-23 01:24:31 +0200, Andres Freund wrote: > I think we put at least three layers on bandaid on this issue since > 9.3.2, and each layer made things more complicated. 2a9b01928f193f529b885ac577051c4fd00bd427 - Cope with possible failure of the oldest MultiXact to exist.

Re: [HACKERS] Less than ideal error reporting in pg_stat_statements

On Tue, Sep 22, 2015 at 3:16 PM, Jim Nasby wrote: > At first I thought the lack of context indicated a palloc had failed during > ereport() (since we apparently just toss the previous error when that > happens), but it turns out there's some error reporting in >

Re: [HACKERS] Rework the way multixact truncations work

On 2015-09-22 14:52:49 -0400, Robert Haas wrote: > 1. It would be possible to write a patch that included ONLY the > changes needed to make that happen, and did nothing else. It would be > largely a subset of this. If we want to change 9.3 and 9.4, I > recommend we do that first, and then come

Re: [HACKERS] Parallel Seq Scan

On Tue, Sep 22, 2015 at 3:21 PM, Amit Kapila wrote: > Attached patch (read_funcs_v1.patch) contains support for all the plan > and other nodes (like SubPlan which could be required for worker) except > CustomScan node. It looks like you need to update the top-of-file

Re: [HACKERS] Less than ideal error reporting in pg_stat_statements

On 9/22/15 5:58 PM, Peter Geoghegan wrote: On Tue, Sep 22, 2015 at 3:16 PM, Jim Nasby wrote: At first I thought the lack of context indicated a palloc had failed during ereport() (since we apparently just toss the previous error when that happens), but it turns out

Re: [HACKERS] Less than ideal error reporting in pg_stat_statements

Peter Geoghegan writes: > I'm not opposed to this basic idea, but I think the message should be > reworded, and that the presence of two separate ereport() call sites > like the above is totally unnecessary. The existing MaxAllocSize check > is just defensive; no user-visible

Re: [HACKERS] Less than ideal error reporting in pg_stat_statements

On Tue, Sep 22, 2015 at 4:40 PM, Tom Lane wrote: > I wonder whether the real problem here is failure to truncate statement > texts to something sane. Do we really need to record the whole text of > multi-megabyte statements? Especially if doing so could render the entire >

Re: [HACKERS] [COMMITTERS] pgsql: Use gender-neutral language in documentation

On Tue, Sep 22, 2015 at 11:00 AM, Andrew Dunstan wrote: >> Happily for me, I can continue to write documents in a grammatically >> correct way, and no-one will read them and think I'm a grammar-nazi (or >> obstinate, or old-fashioned or whatever) because unless they're

Re: [HACKERS] Improving test coverage of extensions with pg_dump

Euler Taveira wrote: > On 17-09-2015 14:21, Michael Paquier wrote: > >pg_dump relies on attnum to define the column ordering, so one > >possibility would be to do things more consistently at backend level. We discussed this in some other thread, not long ago. I looked briefly in the archives but

[HACKERS] Calculage avg. width when operator = is missing

Hi Hackers, I've recently stumbled upon a problem with table bloat estimation in case there are columns of type JSON. The quick bloat estimation queries use sum over pg_statistic.stawidth of table's columns, but in case of JSON the corresponding entry is never created by the ANALYZE command due

Re: [HACKERS] [COMMITTERS] pgsql: Use gender-neutral language in documentation

On 22 September 2015 at 09:28, Albe Laurenz wrote: > Peter Geoghegan wrote: > > On Mon, Sep 21, 2015 at 9:32 PM, Erik Rijkers wrote: > >> I think this compulsive 'he'-avoiding is making the text worse. > >> > >> > >> - environment variable); any

Re: [HACKERS] [PATCH] Refactoring of LWLock tranches

On Tue, 15 Sep 2015 14:39:51 -0400 Robert Haas wrote: > On Tue, Sep 15, 2015 at 12:44 PM, Ildus Kurbangaliev > wrote: > > On Mon, 14 Sep 2015 06:32:22 -0400 > > Robert Haas wrote: > > > >> On Sun, Sep 13, 2015 at 5:05

Re: [HACKERS] [COMMITTERS] pgsql: Use gender-neutral language in documentation

Peter Geoghegan wrote: > On Mon, Sep 21, 2015 at 9:32 PM, Erik Rijkers wrote: >> I think this compulsive 'he'-avoiding is making the text worse. >> >> >> - environment variable); any user can make such a change for his >> session. >> + environment variable); any user

Re: [HACKERS] LW_SHARED_MASK macro

On 2015-09-21 21:36:15 +0200, Andres Freund wrote: > On 2015-09-21 22:34:46 +0300, Alexander Korotkov wrote: > > Great. BTW, are you going to commit this? > > Yes, will do so tomorrow. And done. Thanks for noticing. Andres -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)

Re: [HACKERS] [COMMITTERS] pgsql: Use gender-neutral language in documentation

On 22 September 2015 at 14:09, Andrew Dunstan wrote: > You are fighting a losing battle. Think of they/them/their/theirs as being > indefinitely gendered third person singular pronouns, as well as being > third person plural pronouns. Yes it's a relatively new usage, but I

[HACKERS] 9.5: Can't connect with PGSSLMODE=require on Windows

Hi, With 9.5 alpha 2 on Windows 8 (64-bit), trying to require SSL results in a blocking error: pg_hba.conf: hostssl postgres postgres 0.0.0.0/0 trust postgresql.conf: ssl=on C:\Program Files\PostgreSQL\9.5\bin>SET PGSSLMODE=require C:\Program Files\PostgreSQL\9.5\bin>psql.exe -p 5432

Re: [HACKERS] Obsolete use of volatile in walsender.c, walreceiver.c, walreceiverfuncs.c?

Hi, On 2015-09-17 16:32:17 +1200, Thomas Munro wrote: > In walsender.c, walreceiver.c, walreceiverfuncs.c there are several > places where volatile qualifiers are used apparently only to prevent > reordering around spinlock operations. My understanding is that if > potential load/store

Re: [HACKERS] [COMMITTERS] pgsql: Use gender-neutral language in documentation

On 22/09/15 21:33, Geoff Winkless wrote: On 22 September 2015 at 09:28, Albe Laurenz >wrote: Peter Geoghegan wrote: > On Mon, Sep 21, 2015 at 9:32 PM, Erik Rijkers > wrote: >> I

Re: [HACKERS] [COMMITTERS] pgsql: Use gender-neutral language in documentation

On Tue, 22 Sep 2015 11:17:54 +0100 Geoff Winkless wrote: > On 22 September 2015 at 10:52, Gavin Flower > wrote: > > > On 22/09/15 21:33, Geoff Winkless wrote: > >> ?? > >> Without wanting to get into a grammar war, ?I'm not so sure I agree

Re: [HACKERS] [COMMITTERS] pgsql: Use gender-neutral language in documentation

On 22 September 2015 at 10:52, Gavin Flower wrote: > On 22/09/15 21:33, Geoff Winkless wrote: > >> ​​ >> Without wanting to get into a grammar war, ​I'm not so sure I agree that >> it "condones" it. Dictionaries reflect the current state of usage, they >> don't act

Re: [HACKERS] [COMMITTERS] pgsql: Use gender-neutral language in documentation

Hello all, I'm a non-native speaker and to my shame not very good in english at all. So just my 2c on the topic: "Users can make such a change for their individual sessions" is for me perfectly understandable. "any user can make such a change for their session" is for me a mixture of a

Re: [HACKERS] [COMMITTERS] pgsql: Use gender-neutral language in documentation

On 22/09/15 22:17, Geoff Winkless wrote: On 22 September 2015 at 10:52, Gavin Flower >wrote: On 22/09/15 21:33, Geoff Winkless wrote: ​ ​ Without wanting to get into a grammar war, ​I'm not so sure I

Re: [HACKERS] [COMMITTERS] pgsql: Use gender-neutral language in documentation

On 09/22/2015 10:29 AM, Geoff Winkless wrote: Oh, good! We're actually going to have this argument? Even though I said I don't care what you do? On 22 September 2015 at 15:11, Andrew Dunstan > wrote: On 09/22/2015 09:25 AM, Geoff

Re: [HACKERS] a funnel by any other name

On 17 September 2015 at 05:07, Nicolas Barbier wrote: > 2015-09-17 Robert Haas : > > > 1. Exchange Bushy > > 2. Exchange Inter-Operator (this is what's currently implemented) > > 3. Exchange Replicate > > 4. Exchange Merge > > 5. Interchange > >

Re: [HACKERS] row_security GUC, BYPASSRLS

* Noah Misch (n...@leadboat.com) wrote: > On Mon, Sep 21, 2015 at 09:30:15AM -0400, Stephen Frost wrote: > > * Noah Misch (n...@leadboat.com) wrote: > > > Right now, if a BYPASSRLS user creates a SECURITY DEFINER function, any > > > caller > > > can change that function's behavior by toggling the

Re: [HACKERS] [COMMITTERS] pgsql: Use gender-neutral language in documentation

On 09/22/2015 09:25 AM, Geoff Winkless wrote: If someone sends me a document that uses "their" in a singular usage, I will think that person is lazy. That will continue to be the case, whether people tell me that it's accepted usage or not. You can think that if you like, but it's not

Re: [HACKERS] COPY planning

* Tom Lane (t...@sss.pgh.pa.us) wrote: > Alvaro Herrera writes: > > I noticed that COPY calls planner() (this was introduced in 85188ab88). > > I think it should be calling pg_plan_query() instead. > > +1 --- AFAICS, this is the *only* place that is going directly to >

Re: [HACKERS] Rework the way multixact truncations work

On 2015-07-02 11:52:04 -0400, Robert Haas wrote: > On Mon, Jun 29, 2015 at 3:48 PM, Andres Freund wrote: > > New version attached. > > 0002 looks good, but the commit message should perhaps mention the > comment fix. Or commit that separately. I'm inclined to backpatch the

Re: [HACKERS] [COMMITTERS] pgsql: Use gender-neutral language in documentation

On 09/22/2015 06:17 AM, Geoff Winkless wrote: On 22 September 2015 at 10:52, Gavin Flower >wrote: On 22/09/15 21:33, Geoff Winkless wrote: ​ ​ Without wanting to get into a grammar war, ​I'm not so

Re: [HACKERS] [COMMITTERS] pgsql: Use gender-neutral language in documentation

On 09/22/2015 12:32 AM, Erik Rijkers wrote: - might not be the same as the database user he needs to connect as. + might not be the same as the database user that is to be connect as. It is not an improvement. I would like to see this change rolled back. I agree this is awkward.

Re: [HACKERS] [COMMITTERS] pgsql: Use gender-neutral language in documentation

Oh, good! We're actually going to have this argument? Even though I said I don't care what you do? On 22 September 2015 at 15:11, Andrew Dunstan wrote: > On 09/22/2015 09:25 AM, Geoff Winkless wrote: > >> If someone sends me a document that uses "their" in a singular

Re: [HACKERS] 9.5: Can't connect with PGSSLMODE=require on Windows

On Tue, Sep 22, 2015 at 9:54 AM, Thom Brown wrote: > Hi, > > With 9.5 alpha 2 on Windows 8 (64-bit), trying to require SSL results > in a blocking error: > > pg_hba.conf: > hostssl postgres postgres 0.0.0.0/0 trust > > postgresql.conf: > ssl=on > > > C:\Program

Re: [HACKERS] 9.5: Can't connect with PGSSLMODE=require on Windows

On 09/22/2015 10:57 AM, Robert Haas wrote: On Tue, Sep 22, 2015 at 9:54 AM, Thom Brown wrote: Hi, With 9.5 alpha 2 on Windows 8 (64-bit), trying to require SSL results in a blocking error: pg_hba.conf: hostssl postgres postgres 0.0.0.0/0 trust postgresql.conf:

Re: [HACKERS] [PROPOSAL] VACUUM Progress Checker.

Hello, Please find attached patch with bugs reported by Thom and Sawada-san solved. >* The progress of vacuum by autovacuum seems not to be displayed. The progress is stored in shared variables during autovacuum. I guess the reason they are not visible is that the entries are deleted as soon as