Re: logical decoding bug when mapped relation with toast contents is rewritten repeatedly

Hi, On 09/14/2018 04:10 AM, Andres Freund wrote: > Hi, > > (Tomas, CCing you because you IIRC mentioned encountered an issue like > this) > I might have mentioned an issue with this symptom recently, but that turned out to be already fixed by da10d6a8a9 (before the minor version with that fix

Re: Code of Conduct plan

On Fri, Sep 14, 2018 at 3:37 PM, Joshua D. Drake wrote: > On 09/14/2018 07:14 AM, Dave Page wrote: > > > > On Fri, Sep 14, 2018 at 3:08 PM, Joshua D. Drake > wrote: > >> On 09/14/2018 01:31 AM, Chris Travers wrote: >> >> >> I apologize for the glacial slowness with which this has all been

Re: Code of Conduct plan

On Fri, Sep 14, 2018 at 3:41 PM, James Keener wrote: > > Community is people who joined it > > We're not a "community." We're people using email to get help with or > discuss technical aspects of PostgreSQL. The types of discussions that > would normally be held within a "community" would be

Re: Code of Conduct plan

> > Yes, I believe so. Isn't that what "To that end, we have established this Code > of Conduct for community interaction and participation in the project’s > work and the community at large." basically says? > No? What's the "community at large"? To me that sounds like "all interactions" whether

Re: Code of Conduct plan

On Fri, Sep 14, 2018 at 3:55 PM, James Keener wrote: > > > Yes. They can. The people who make the majority of the contributions to >> the software can decide what happens, because without them there is no >> software. If you want to spend 20 years of your life >> > > So everyone who moderates

Re: Code of Conduct plan

On 09/14/2018 07:51 AM, Dave Page wrote: If that business is publicly bringing the project into disrepute, or harassing other community members and they approach us about it, then it becomes our business. If it's unrelated to PostgreSQL, then it's your personal business and not

Re: Code of Conduct plan

On Fri, Sep 14, 2018 at 4:14 PM Dave Page wrote: > > > On Fri, Sep 14, 2018 at 3:08 PM, Joshua D. Drake > wrote: > >> On 09/14/2018 01:31 AM, Chris Travers wrote: >> >> >> I apologize for the glacial slowness with which this has all been moving. >>> The core team has now agreed to some

Re: Code of Conduct plan

I hesitate to exacerbate what is a society-wide debate that is being worked out across organizations across the spectrum, but if I may provide a thought for consideration. The framing and language of the Code of Conduct, as written and proposed, includes a large number of checkpoints to protect

Re: Code of Conduct plan

On Fri, 14 Sep 2018 at 15:10, James Keener wrote: > I understand the concern, however, if you look at how attacks happen > >> it is frequently through other sites. Specifically under/poorly >> moderated sites. For specific examples, people who have issues with >> people on Quora will frequently

Re: Code of Conduct plan

On 09/14/2018 06:59 AM, Robert Eckhardt wrote: I really have to object to this addition: "This Code is meant to cover all interaction between community members, whether or not it takes place within postgresql.org infrastructure, so long as there is not another Code of

Re: Code of Conduct plan

On Fri, Sep 14, 2018 at 3:08 PM, Joshua D. Drake wrote: > On 09/14/2018 01:31 AM, Chris Travers wrote: > > > I apologize for the glacial slowness with which this has all been moving. >> The core team has now agreed to some revisions to the draft CoC based on >> the comments in this thread; see

Re: Code of Conduct plan

On 09/14/2018 07:14 AM, Dave Page wrote: On Fri, Sep 14, 2018 at 3:08 PM, Joshua D. Drake > wrote: On 09/14/2018 01:31 AM, Chris Travers wrote: I apologize for the glacial slowness with which this has all been moving. The core team

Re: Code of Conduct plan

On Fri, Sep 14, 2018 at 3:43 PM, Joshua D. Drake wrote: > On 09/14/2018 07:36 AM, Dave Page wrote: > > > > On Fri, Sep 14, 2018 at 3:21 PM, James Keener wrote: > >> >> Now, you may say that (2) would be rejected by the committee, but I would counter that it's still a stain on me and

Re: Code of Conduct plan

> To many of us, we absolutely are a community. Remember, there are people > here who have been around for 20+ years, of which many have become close > friends, having started working on PostgreSQL as a hobby. We have always > seen the project as a community of like-minded technologists, and

Re: Code of Conduct plan

Yes. They can. The people who make the majority of the contributions to the > software can decide what happens, because without them there is no > software. If you want to spend 20 years of your life > So everyone who moderates this group and that will be part of the CoC committee will have had

Table renaming does not propagate to views

Hi Hackers - It appears only the oid of the relations used in a view are captured in the view definition, not the relations' name itself. The effect this has is that relation renaming does not propagate to views. I would like to assert that they should. The user has stated their intention in

Re: Code of Conduct plan

Greetings, * Joshua D. Drake (j...@commandprompt.com) wrote: > I think this is a complicated issue. On the one hand, postgresql.org has no > business telling people how to act outside of postgresql.org. Full stop. This is exactly what this CoC points out- yes, PG.Org absolutely can and should

Re: Table renaming does not propagate to views

Jordan Deitch writes: > It appears only the oid of the relations used in a view are captured in the > view definition, not the relations' name itself. The effect this has is that > relation renaming does not propagate to views. I would like to assert that > they should. > The user has stated

Re: Code of Conduct plan

> Community is people who joined it We're not a "community." We're people using email to get help with or discuss technical aspects of PostgreSQL. The types of discussions that would normally be held within a "community" would be entirely off-topic here. We should be professional to each other

Re: when set track_commit_timestamp on, database system abort startup

On 2018-Sep-15, Masahiko Sawada wrote: > On Fri, Sep 14, 2018 at 4:27 PM, 李海龙 wrote: > > When I enable the parameter track_commit_timestamp in postgresql.conf of a > > Base Backup (making a Base Backup from a standby and the > > track_commit_timestamp is off on it), > > In addition to the

Re: pgsql: Improve autovacuum logging for aggressive and anti-wraparound ru

On 2018-Sep-13, Michael Paquier wrote: > Improve autovacuum logging for aggressive and anti-wraparound runs > > A log message was being generated when log_min_duration is reached for > autovacuum on a given relation to indicate if it was an aggressive run, > and missed the point of mentioning if

Re: Code of Conduct plan

On 09/14/2018 01:31 AM, Chris Travers wrote: I apologize for the glacial slowness with which this has all been moving. The core team has now agreed to some revisions to the draft CoC based on the comments in this thread; see

Fwd: Code of Conduct plan

I didn't realize they had replied personally to me. -- Forwarded message -- From: James Keener Date: Fri, Sep 14, 2018 at 10:43 AM Subject: Re: Code of Conduct plan To: Dave Page If that business is publicly bringing the project into disrepute, or > harassing other community

Re: Cache lookup errors with functions manipulation object addresses

On 2018-Sep-14, Michael Paquier wrote: > On Fri, Sep 14, 2018 at 11:22:12AM +0900, Michael Paquier wrote: > > Attached are rebased versions. This has been around for some time, so I > > am planning to move on with this patch set pretty soon as that's mainly > > cleanup for getObjectIdentity as

Re: Cache lookup errors with functions manipulation object addresses

On 2018-Sep-14, Alvaro Herrera wrote: > I haven't looked at 0003 yet. It's strange that pg_identify_object returns empty type in only some cases (as seen in the regression test output) ... and this one definitely does not make sense: +SELECT * FROM pg_identify_object('pg_class'::regclass,

Re: Code of Conduct plan

On Fri, Sep 14, 2018 at 3:57 PM, James Keener wrote: > > >> Yes, I believe so. Isn't that what "To that end, we have established >> this Code of Conduct for community interaction and participation in the >> project’s work and the community at large." basically says? >> > > No? What's the

Re: Code of Conduct plan

> > And if you believe strongly that a given statement you may have made is > not objectionable...you should be willing to defend it in an adjudication > investigation. So because someone doesn't like what I say in a venue 100% separate from postgres, I have to subject myself, and waste my

Re: Code of Conduct plan

On 09/14/2018 07:36 AM, Dave Page wrote: On Fri, Sep 14, 2018 at 3:21 PM, James Keener > wrote: Now, you may say that (2) would be rejected by the committee, but I would counter that it's still a stain on me and something that

Re: Code of Conduct plan

I understand the concern, however, if you look at how attacks happen > it is frequently through other sites. Specifically under/poorly > moderated sites. For specific examples, people who have issues with > people on Quora will frequently go after them on Facebook and Twitter. > > these aren't a

Re: Code of Conduct plan

On Fri, Sep 14, 2018 at 3:13 PM, Adrian Klaver wrote: > On 9/14/18 6:59 AM, Robert Eckhardt wrote: > >> On Fri, Sep 14, 2018 at 9:41 AM, Adrian Klaver >> wrote: >> >>> On 9/14/18 1:31 AM, Chris Travers wrote: >>> >> > I really have to object to this addition: "This Code is meant to

Re: Code of Conduct plan

On Fri, Sep 14, 2018 at 3:10 PM, James Keener wrote: > I understand the concern, however, if you look at how attacks happen > >> it is frequently through other sites. Specifically under/poorly >> moderated sites. For specific examples, people who have issues with >> people on Quora will

Re: Code of Conduct plan

On 9/14/18 7:19 AM, Dave Page wrote: No one is tracking anything as part of the CoC. That's nothing but a straw man argument. Not buying it or the below is null and void: "This Code is meant to cover all interaction between community members, whether or not it takes place within

Re: Code of Conduct plan

> On 14. Sep 2018, at 16:17, Dave Page wrote: > > > The lists are just one of many different ways people in this community > interact. I could only heavily +1 this. I can get from where comes the idea that community is only what happens just on postgresql.org or just on some other channel

Re: Code of Conduct plan

On 9/14/18 6:59 AM, Robert Eckhardt wrote: On Fri, Sep 14, 2018 at 9:41 AM, Adrian Klaver wrote: On 9/14/18 1:31 AM, Chris Travers wrote: I really have to object to this addition: "This Code is meant to cover all interaction between community members, whether or not it takes place within

Re: Code of Conduct plan

> Now, you may say that (2) would be rejected by the committee, but I would >> counter that it's still a stain on me and something that will forever >> appear >> along side my name in search results and that the amount of time and >> stress it'd take me to defend myself would make my voluntarily

Re: Code of Conduct plan

On Fri, Sep 14, 2018 at 3:21 PM, James Keener wrote: > > Now, you may say that (2) would be rejected by the committee, but I would >>> counter that it's still a stain on me and something that will forever >>> appear >>> along side my name in search results and that the amount of time and >>>

Re: Code of Conduct plan

On Fri, Sep 14, 2018 at 3:28 PM, Adrian Klaver wrote: > On 9/14/18 7:19 AM, Dave Page wrote: > >> >> >> > >> No one is tracking anything as part of the CoC. That's nothing but a >> straw man argument. >> > > Not buying it or the below is null and void: > > "This Code is meant to cover all

Re: when set track_commit_timestamp on, database system abort startup

On Fri, Sep 14, 2018 at 4:27 PM, 李海龙 wrote: > > HI, Dear pgsql-hackers > > > The details are as follows: > > > Environment: > > OS:CentOS 6.7 (Final), Linux 3.18.48-11.el6.x86_64 x86_64, 64-bit > > > PostgreSQL: > > postgres=# select version(); >

ssl tests README and certs

in src/test/ssl the README suggest that the Makefile can be used to recreate the ssl directory, however there are no rules to create *_ca.crt|key. Am I missing something ? Dave Cramer

Re: Code of Conduct plan

> On 14. Sep 2018, at 16:31, Ilya Kosmodemiansky wrote: > > > > > I could only heavily +1 this. I can get I can’t get of course, sorry for typo > from where comes the idea that community is only what happens just on > postgresql.org or just on some other channel community uses. > .

Re: Code of Conduct plan

Greetings, * Adrian Klaver (adrian.kla...@aklaver.com) wrote: > On 9/14/18 1:31 AM, Chris Travers wrote: > >On Wed, Sep 12, 2018 at 10:53 PM Tom Lane >> wrote: > > > >I wrote: > > > Stephen Frost mailto:sfr...@snowman.net>> > >writes: > > >> We seem to

Re: Code of Conduct plan

On Fri, Sep 14, 2018 at 7:19 AM, Joshua D. Drake wrote: > Sure and that is unfortunate but isn't it up to the individual to deal with > it through appropriate channels for whatever platform they are on? All of > these platforms are: > > 1. Voluntary to use > 2. Have their own Terms of Use and

Re: Delta Materialized View Refreshes?

Hi Jeremy, Could you apply something similar using triggers? One question would be how PG would identify changes to existing rows - using the replication facilities to essentially replicate into the view? This would be quite tricky I reckon. Otherwise a change to the underlying table may not

Re: pg_dump test instability

On 13/09/2018 23:03, Tom Lane wrote: > Attached updated patch does it like that and makes the cosmetic > adjustments you suggested. I also went ahead and did the renaming > of par_prev/par_next/par_list_xxx that I'd suggested upthread. > I think this is committable ... Yes, this looks good to

Logical replication to partitioned subscriber

Are there any plans to support logical replication to a table which is only partitioned on the subscriber? We are very interested in such a feature for a couple use cases. We are using logical replication for archiving data and we only want it partitioned on the archive server, and we want it to

Re: Should contrib modules install .h files?

On 01/08/2018 00:34, Peter Eisentraut wrote: > On 23/07/2018 18:32, Andrew Gierth wrote: >>> "Tom" == Tom Lane writes: >> >> Tom> As I said before, I think that we should change the existing >> Tom> contrib modules to be coded likewise, all using a single -I switch >> Tom> that points at

Re: Should contrib modules install .h files?

> "Peter" == Peter Eisentraut writes: >> But I think there are some fundamentally incompatible goals here >> with regard to how the final -I options are supposed to look. Peter> Was this ever resolved? There are open questions about plperl and plpython, which currently don't install

Re: Code of Conduct plan

On Fri, Sep 14, 2018 at 11:10 AM, Dave Page wrote: > That wording has been in the published draft for 18 months, and noone > objected to it that I'm aware of. There will always be people who don't like > some of the wording, much as there are often people who disagree with the > way a patch to

Re: Consistent segfault in complex query

Andrew Gierth writes: > If it helps, here is a patch that adds isolation tests to > eval-plan-qual.spec for two test cases (one with CTE, one without). > I've verified that these reproduce the crash, and that they run > successfully with your patch. I can't currently see any more specific > code

Re: Code of Conduct plan

Robert Haas writes: > It's not clear to me that there IS a general consensus here. It looks > to me like the unelected core team got together and decided to impose > a vaguely-worded code of conduct on a vaguely-defined group of people > covering not only their work on PostgreSQL but also their

Delta Materialized View Refreshes?

To me the biggest disadvantage of using a materialized view instead of a table delta load for an ETL process, for example, is that the materialized view is very inefficient in terms of write overhead, for of course it rewrites the whole set of data in the table, meaning heap, indexes, WAL and

Re: Delta Materialized View Refreshes?

> > > Could you apply something similar using triggers? > One question would be how PG would identify changes to existing rows - > using the replication facilities to essentially replicate into the view? > This would be quite tricky I reckon. Otherwise a change to the underlying > table may not

Re: Code of Conduct plan

On Fri, 14 Sep 2018, 15:55 James Keener, wrote: > > > Yes. They can. The people who make the majority of the contributions to >> the software can decide what happens, because without them there is no >> software. If you want to spend 20 years of your life >> > > So everyone who moderates this

Re: cache lookup failed for constraint when alter table referred by partition table

Thanks Rajkumar, Tom, Justin -- pushed fix. -- Álvaro Herrerahttps://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Re: Code of Conduct plan

On 09/14/2018 07:41 AM, James Keener wrote: > Community is people who joined it We're not a "community." I do not think you are going to get very many people on board with that argument. As anyone who knows me will attest I am one of the most contrarian members of this community but I still

Re: stat() on Windows might cause error if target file is larger than 4GB

On Thu, Sep 13, 2018 at 10:05 PM, Michael Paquier wrote: > On Thu, Sep 13, 2018 at 02:23:47PM -0400, Robert Haas wrote: >> This, to me, seems way too clever. Replacing 'struct stat' with >> something else everywhere in the code is more churn, but far less >> likely to have surprising

Re: [PATCH] get rid of StdRdOptions, use individual binary reloptions representation for each relation kind instead

Hi! I've rebased the patch against recent master. I've imported changes from 857f9c36 commit. BTW this commit shows why do this patch is important: 857f9c36 adds new option for b-tree indexes. But thanks to the StdRdOptions this option will exist for no practical use in all heaps that has just

Re: Delta Materialized View Refreshes?

On Fri, 14 Sep 2018 at 16:26, Jeremy Finzel wrote: > >> Could you apply something similar using triggers? >> One question would be how PG would identify changes to existing rows - >> using the replication facilities to essentially replicate into the view? >> This would be quite tricky I reckon.

Re: Defaulting to jit=on/off for v11

On Fri, Sep 14, 2018 at 3:32 PM, Tom Lane wrote: > I'd go with #2, personally. It does seem that the costing needs work, > but it's not clear to me that we know what to change, so it's kinda > late to propose #3 for v11. +1. I also favor option #2. -- Peter Geoghegan

Re: move PartitionDispatchData definition to execPartition.c

On 2018-Jul-04, Amit Langote wrote: > Hi. > > I think we may have simply forgotten to do $subject in the following commit. We did. Pushed now, thanks. -- Álvaro Herrerahttps://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Re: stat() on Windows might cause error if target file is larger than 4GB

Robert Haas writes: > I do not think that using #define to play clever tricks like this can > reasonably be classified as non-invasive. Non-invasive doesn't mean > it touches a small number of lines; it means it's unlikely to break > stuff. Otherwise, > #define continue break > would qualify as

Re: pg_dump test instability

Peter Eisentraut writes: > On 13/09/2018 23:03, Tom Lane wrote: >> Attached updated patch does it like that and makes the cosmetic >> adjustments you suggested. I also went ahead and did the renaming >> of par_prev/par_next/par_list_xxx that I'd suggested upthread. >> I think this is

Defaulting to jit=on/off for v11

Hi, I kind of thought I'd sent out this mail Friday morning, but apparently I forgot to hit send, before accidentally releasing my laptop's battery while running :/ We'd agreed a while ago, when JIT compilation landed, to decide close to the release whether JIT compilation should be enabled or

Re: Defaulting to jit=on/off for v11

On 9/14/18 6:32 PM, Tom Lane wrote: > Andres Freund writes: >> I can see basically three sensible routes to go for v11 (before we >> improve further): > >> 1) Leave it enabled, as currently. > >> 2) Disable it by default in v11, leave it enabled in master. > >> 3) Increase the costs

Re: Logical replication to partitioned subscriber

On 2018-Sep-14, Jeremy Finzel wrote: > Are there any plans to support logical replication to a table which is only > partitioned on the subscriber? We are very interested in such a feature > for a couple use cases. We are using logical replication for archiving > data and we only want it

Re: move PartitionDispatchData definition to execPartition.c

Alvaro Herrera writes: > On 2018-Jul-04, Amit Langote wrote: >> I think we may have simply forgotten to do $subject in the following commit. > We did. Pushed now, thanks. Erm, shouldn't that have been done in HEAD as well as v11? regards, tom lane

Re: Defaulting to jit=on/off for v11

Andres Freund writes: > I can see basically three sensible routes to go for v11 (before we > improve further): > 1) Leave it enabled, as currently. > 2) Disable it by default in v11, leave it enabled in master. > 3) Increase the costs substantially, so it triggers in far fewer >cases.

Re: hot_standby_feedback vs excludeVacuum and snapshots

At Sat, 4 Aug 2018 14:09:18 +1200, Thomas Munro wrote in > On Mon, Jul 9, 2018 at 6:51 AM, Noah Misch wrote: > > On Fri, Jul 06, 2018 at 04:32:56PM +0100, Simon Riggs wrote: > >> On 6 July 2018 at 03:30, Thomas Munro > >> wrote: > >> > On Thu, Jul 5, 2018 at 8:27 AM, Noah Misch wrote: > >>

Re: Loaded footgun open_datasync on Windows

Michael Paquier wrote: > On Thu, Sep 13, 2018 at 03:55:20PM +0200, Laurenz Albe wrote: > > Attached is the new, improved version of the patch. > > Thanks, finally pushed. I have made sure that recovery TAP tests, > upgrade tests and bin/ tests are working properly. Thanks for being interested

Re: Problem while setting the fpw with SIGHUP

On Thu, Sep 13, 2018 at 04:38:30PM +0530, Amit Kapila wrote: > So, the problem started appearing after some rearrangement of code in > both the above-mentioned commits. I verified that this problem > doesn't exist in versions <=9.4, so backpatch-through 9.5. Thanks Amit for taking care of this

Re: Loaded footgun open_datasync on Windows

On Fri, Sep 14, 2018 at 08:43:18AM +0200, Laurenz Albe wrote: > Thanks for being interested and doing the work. No problem. I have a sort of Windows-label stuck on me for ages, and those random buildfarm failures are annoying with TAP tests on Windows. > If it turns out not to break anything,

when set track_commit_timestamp on, database system abort startup

HI, Dear pgsql-hackers The details are as follows: Environment: OS:CentOS 6.7 (Final), Linux 3.18.48-11.el6.x86_64 x86_64, 64-bit PostgreSQL: postgres=# select version(); version

Re: Problem while setting the fpw with SIGHUP

On Thu, Sep 06, 2018 at 04:37:28PM -0700, Michael Paquier wrote: > /* > * Properly accept or ignore signals the postmaster might send us. > */ > - pqsignal(SIGHUP, StartupProcSigHupHandler); /* reload config file */ > + pqsignal(SIGHUP, SIG_IGN); /* ignore reload config */ > > I am

Re: Code of Conduct plan

On Wed, Sep 12, 2018 at 10:53 PM Tom Lane wrote: > I wrote: > > Stephen Frost writes: > >> We seem to be a bit past that timeline... Do we have any update on when > >> this will be moving forward? > >> Or did I miss something? > > > Nope, you didn't. Folks have been on holiday which made it

Re: Changing the setting of wal_sender_timeout per standby

On Thu, Sep 13, 2018 at 12:32 PM, Michael Paquier wrote: > On Thu, Sep 13, 2018 at 01:14:12AM +, Tsunakawa, Takayuki wrote: >> Some customer wants to change the setting per standby, i.e., a shorter >> timeout for a standby in the same region to enable faster detection >> failure and failover,

Re: Code of Conduct plan

I find a lot of neo-con/trumpian political stances moronic, short-sighted, and anti-intellectual and therefore consider them offensive, an affront on my way of life, and a stain on my country. 1) Can I report anyone holding such views and discussing them on a 3rd party forum? 2) Could I be

Re: Problem while updating a foreign table pointing to a partitioned table on foreign server

(2018/08/24 16:58), Kyotaro HORIGUCHI wrote: At Tue, 21 Aug 2018 11:01:32 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI wrote in<20180821.110132.261184472.horiguchi.kyot...@lab.ntt.co.jp> You wrote: Several places seems to be assuming that fdw_scan_tlist may be used foreign scan on

Re: Re[3]: doc - improve description of default privileges

On 2018-09-12 Tom Lane wrote ... > The reviewer does that, indicating signoff. Thanks. I have now changed the status to "Ready for Committer".

Re: Avoid extra Sort nodes between WindowAggs when sorting can be reused

> On 13 Sep 2018, at 19:50, Andrew Gierth wrote: > > Here's what I have queued up to push. LGTM, thanks! > + * framing clauses differ), then all peer rows must be presented in the > + * same order in all of them. If we allowed multiple sort nodes for such Should probably be

Re: hostorder and failover_timeout for libpq

Hey , Here are a few comment. + Here's a typo: ="libpq-connect-falover-timeout" + {"failover_timeout", NULL, NULL, NULL, + "Failover Timeout", "", 10, Word is separated by hyphen in internalPQconninfoOption lable as a surrounding code +If the value is random, the

Re: Problem while setting the fpw with SIGHUP

On Fri, Sep 14, 2018 at 12:57 PM Michael Paquier wrote: > > On Thu, Sep 06, 2018 at 04:37:28PM -0700, Michael Paquier wrote: > > /* > > * Properly accept or ignore signals the postmaster might send us. > > */ > > - pqsignal(SIGHUP, StartupProcSigHupHandler); /* reload config file */ > > +

Re: [PATCH] Fix for infinite signal loop in parallel scan

On Sat, Sep 8, 2018 at 3:57 AM Chris Travers wrote: > Attached is the patch we are fully testing at Adjust. Thanks! > I have run make check on Linux and MacOS, and make check-world on Linux > (check-world fails on MacOS on all versions and all branches due to ecpg > failures). FWIW it's

Re: Query is over 2x slower with jit=on

On 11 September 2018 at 14:50, Amit Khandekar wrote: > On 10 September 2018 at 21:39, Andres Freund wrote: >> Hi, >> >> On 2018-09-10 15:42:55 +0530, Amit Khandekar wrote: >>> Attached is a patch that accumulates the per-worker jit counters into >>> the leader process. >> >> Thanks! >> >> >>> I

Re: Code of Conduct plan

Please take me off this list. > On Sep 14, 2018, at 05:31, Chris Travers wrote: > > > > On Wed, Sep 12, 2018 at 10:53 PM Tom Lane > wrote: > I wrote: > > Stephen Frost mailto:sfr...@snowman.net>> writes: > >> We seem to be a bit past that timeline... Do we have

Re: Code of Conduct plan

On Fri, Sep 14, 2018 at 11:45 AM Ilya Kosmodemiansky wrote: > On Fri, Sep 14, 2018 at 10:31 AM, Chris Travers > wrote: > > I really have to object to this addition: > > "This Code is meant to cover all interaction between community members, > > whether or not it takes place within

Re: Connection slots reserved for replication

On Wed, Aug 1, 2018 at 9:30 PM, Alexander Kukushkin wrote: > Hello hackers, > > at the moment it is possible to reserve some amount of connection slots for > superusers and this behavior is controlled by superuser_reserved_connections > configuration parameter with the default value = 3. > > In

Re: Code of Conduct plan

On Fri, Sep 14, 2018 at 10:31 AM, Chris Travers wrote: > I really have to object to this addition: > "This Code is meant to cover all interaction between community members, > whether or not it takes place within postgresql.org infrastructure, so long > as there is not another Code of Conduct that

Re: [PATCH] Tab completion for ALTER DATABASE … SET TABLESPACE

On Thu, Aug 30, 2018 at 05:54:23PM +0100, Dagfinn Ilmari Mannsåker wrote: > ilm...@ilmari.org (Dagfinn Ilmari Mannsåker) writes: > > Hi hackers, > > > > I just noticed that psql's tab completion for ALTER TABLE … SET > > TABLESPACE was treating it as any other configuration parameter and > >

Re: Code of Conduct plan

I have followed this list for a couple of years, have benefited several times from quick and helpful advice, and wonder whether all this code of conduct stuff is a solution in search of a problem. Or, if there is a problem now and then, whether an elaborate code does a better job than

Re: Code of Conduct plan

On 9/14/18 1:31 AM, Chris Travers wrote: On Wed, Sep 12, 2018 at 10:53 PM Tom Lane > wrote: I wrote: > Stephen Frost mailto:sfr...@snowman.net>> writes: >> We seem to be a bit past that timeline...  Do we have any update on when >> this

Re: Code of Conduct plan

On Fri, Sep 14, 2018 at 9:41 AM, Adrian Klaver wrote: > On 9/14/18 1:31 AM, Chris Travers wrote: >> >> >> >> On Wed, Sep 12, 2018 at 10:53 PM Tom Lane > > wrote: >> >> I wrote: >> > Stephen Frost mailto:sfr...@snowman.net>> >> writes: >> >> We seem to