Re: Indicate anti-wraparound autovacuum in log_autovacuum_min_duration

[Sergei Kornilov]

> Thanks Sergei for the new version, pushed.
Thank you!

regards, Sergei

Re: Problem while setting the fpw with SIGHUP

[Michael Paquier]

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 first problem.  I am going to send
another patch which is able to take care of concurrent updates of
Insert->fullPageWrites for the checkpointer and the startup process
to fix the original issue reported by Dilip Kumar, so as we are able to
close definitely the loop on this thread. 
--
Michael


signature.asc
Description: PGP signature

Re: Problem while setting the fpw with SIGHUP

[Michael Paquier]

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 finally coming back to this patch set, and that's one of the first
> things I am going to help moving on for this CF.  And this bit from the
> last patch series is not acceptable as there are some parameters which
> are used by the startup process which can be reloaded.  One of them is
> wal_retrieve_retry_interval for tuning when fetching WAL at recovery.

So, I have been working on this problem again and I have reviewed the
thread, and there have been many things discussed in the last couple of
months:
1) We do not want to initialize XLogInsert stuff unconditionally for all
processes at the moment recovery begins, but we just want to initialize
it once WAL write is open for business.
2) Both the checkpointer and the startup process can call
UpdateFullPageWrites() which can cause Insert->fullPageWrites to get
incorrect values.
3) We do not want a palloc() in a critical section because of
RecoveryinProgress being called.

And the root issue here is 2), because the checkpointer tries to update
Insert->fullPageWrites but it does not need to do so until recovery has
been finished.  So in order to fix the original issue I am proposing a
simple fix: let's make sure that the checkpointer does not update
Insert->fullPageWrites until recovery finishes, and let's have the
startup process do the first update once it finishes recovery and
inserts by itself the XLOG_PARAMETER_CHANGE.  This way the order of
events is purely sequential and we don't need to worry about having the
checkpointer and the startup process eat on each other's plate because
the checkpointer would only try to work on updating the shared memory
value of full_page_writes once SharedRecoveryInProgress is switched to
true, and that happens after the startup process does its initial call
to UpdateFullPageWrites().  I have improved as well all the comments
around to make clear the behavior wanted.

Thoughts?
--
Michael
diff --git a/src/backend/access/transam/xlog.c b/src/backend/access/transam/xlog.c
index 3025d0badb..69912e6a22 100644
--- a/src/backend/access/transam/xlog.c
+++ b/src/backend/access/transam/xlog.c
@@ -7719,6 +7719,11 @@ StartupXLOG(void)
 	 * Update full_page_writes in shared memory and write an XLOG_FPW_CHANGE
 	 * record before resource manager writes cleanup WAL records or checkpoint
 	 * record is written.
+	 *
+	 * It is safe to check the shared full_page_writes without the lock,
+	 * because there is no concurrently running process able to update it.
+	 * The only other process able to update full_page_writes is the
+	 * checkpointer, still it is unable to do so until recovery finishes.
 	 */
 	Insert->fullPageWrites = lastFullPageWrites;
 	LocalSetXLogInsertAllowed();
@@ -9693,14 +9698,27 @@ XLogReportParameters(void)
  * Update full_page_writes in shared memory, and write an
  * XLOG_FPW_CHANGE record if necessary.
  *
- * Note: this function assumes there is no other process running
- * concurrently that could update it.
+ * Note: this can be called from the checkpointer, or the startup process
+ * at the end of recovery.  One could think that this routine should be
+ * careful with its lock handling, however this is a no-op for the
+ * checkpointer until the startup process marks the end of recovery,
+ * so only one of them can do the work of this routine at once.
  */
 void
 UpdateFullPageWrites(void)
 {
 	XLogCtlInsert *Insert = &XLogCtl->Insert;
 
+	/*
+	 * Check if recovery is still in progress before entering this critical
+	 * section, as some memory allocation could happen at the end of
+	 * recovery.  There is nothing to do for a system still in recovery.
+	 * Note that we need to process things here at the end of recovery for
+	 * the startup process, which is why this checks after InRecovery.
+	 */
+	if (RecoveryInProgress() && !InRecovery)
+		return;
+
 	/*
 	 * Do nothing if full_page_writes has not been changed.
 	 *
@@ -9731,7 +9749,7 @@ UpdateFullPageWrites(void)
 	 * Write an XLOG_FPW_CHANGE record. This allows us to keep track of
 	 * full_page_writes during archive recovery, if required.
 	 */
-	if (XLogStandbyInfoActive() && !RecoveryInProgress())
+	if (XLogStandbyInfoActive())
 	{
 		XLogBeginInsert();
 		XLogRegisterData((char *) (&fullPageWrites), sizeof(bool));


signature.asc
Description: PGP signature

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
-
 PostgreSQL 10.5 on x86_64-pc-linux-gnu, compiled by gcc (GCC) 4.4.7 20120313 
(Red Hat 4.4.7-16), 64-bit
(1 row)

postgres=# show wal_level ;
 wal_level
---
 replica
(1 row)


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),

the database system aborted startup.


The log is：

[2018-09-14 14:38:30.723 CST 8433 5b9b5766.20f1 1  0]LOG:  database system 
was interrupted while in recovery at log time 2018-09-12 07:00:05 CST
[2018-09-14 14:38:30.723 CST 8433 5b9b5766.20f1 2  0]HINT:  If this has 
occurred more than once some data might be corrupted and you might need to 
choose an earlier recovery target.
[2018-09-14 14:38:30.817 CST 8433 5b9b5766.20f1 3  0]LOG:  redo starts at 
1C45/6FC0A230
[2018-09-14 14:38:31.215 CST 8433 5b9b5766.20f1 4  0]FATAL:  could not 
access status of transaction 3003911820
[2018-09-14 14:38:31.215 CST 8433 5b9b5766.20f1 5  0]DETAIL:  Could not 
read from file "pg_commit_ts/6FEE" at offset 557056: Success.
[2018-09-14 14:38:31.215 CST 8433 5b9b5766.20f1 6  0]CONTEXT:  WAL redo at 
1C45/7844DC60 for Transaction/COMMIT: 2018-09-12 07:00:16.629145+08
[2018-09-14 14:38:31.228 CST 8431 5b9b5766.20ef 6  0]LOG:  startup process 
(PID 8433) exited with exit code 1
[2018-09-14 14:38:31.228 CST 8431 5b9b5766.20ef 7  0]LOG:  aborting startup 
due to startup process failure
[2018-09-14 14:38:31.341 CST 8431 5b9b5766.20ef 8  0]LOG:  database system 
is shut down



I have no choice but I enable the parameter track_commit_timestamp off, the 
database system is starting up successfully!


The log is：

[2018-09-14 14:41:38.887 CST 10210 5b9b5822.27e2 1  0]LOG:  database system 
was interrupted while in recovery at 2018-09-14 14:41:21 CST
[2018-09-14 14:41:38.887 CST 10210 5b9b5822.27e2 2  0]HINT:  This probably 
means that some data is corrupted and you will have to use the last backup for 
recovery.
[2018-09-14 14:41:38.977 CST 10210 5b9b5822.27e2 3  0]LOG:  database system 
was not properly shut down; automatic recovery in progress
[2018-09-14 14:41:38.979 CST 10210 5b9b5822.27e2 4  0]LOG:  redo starts at 
1C45/6FC0A230
[[unknown] [unknown] [unknown] [local] 2018-09-14 14:41:43.794 CST 10284 
5b9b5827.282c 1  0]LOG:  connection received: host=[local]
[postgres template1 [unknown] [local] 2018-09-14 14:41:43.794 CST 10284 
5b9b5827.282c 2  0]FATAL:  the database system is starting up
..
..
[2018-09-14 14:47:03.486 CST 10210 5b9b5822.27e2 5  0]LOG:  redo done at 
1C63/FF683C98
[2018-09-14 14:47:03.486 CST 10210 5b9b5822.27e2 6  0]LOG:  last completed 
transaction was at log time 2018-09-12 13:02:56.737147+08
[2018-09-14 14:47:03.491 CST 10210 5b9b5822.27e2 7  0]LOG:  checkpoint 
starting: end-of-recovery immediate
[[unknown] [unknown] [unknown] [local] 2018-09-14 14:47:43.940 CST 13383 
5b9b598f.3447 1  0]LOG:  connection received: host=[local]
[postgres template1 [unknown] [local] 2018-09-14 14:47:43.940 CST 13383 
5b9b598f.3447 2  0]FATAL:  the database system is starting up
[2018-09-14 14:48:06.651 CST 10210 5b9b5822.27e2 8  0]LOG:  checkpoint 
complete: wrote 1871378 buffers (89.2%); 0 WAL file(s) added, 0 removed, 0 
recycled; write=57.447 s, sync=5.683 s, total=63.160 s; sync files=1366, 
longest=0.648 s, average=0.004 s; distance=128192471 kB, estimate=128192471 kB
[2018-09-14 14:48:09.932 CST 10208 5b9b5822.27e0 6  0]LOG:  database system 
is ready to accept connections
[[unknown] [unknown] [unknown] [local] 2018-09-14 14:48:31.916 CST 13682 
5b9b59bf.3572 1  0]LOG:  connection received: host=[local]
[postgres template1 [unknown] [local] 2018-09-14 14:48:31.917 CST 13682 
5b9b59bf.3572 2 3/1 0]LOG:  connection authorized: user=postgres 
database=template1
[postgres template1 [unknown] [local] 2018-09-14 14:48:31.944 CST 13682 
5b9b59bf.3572 3  0]LOG:  disconnection: session time: 0:00:00.027 user=postgres 
database=template1 host=[local]


Has anyone entered this and please help me.

--
Qunar PostgreSQL DBA hailong.li


<>

Re: Loaded footgun open_datasync on Windows

[Michael Paquier]

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, would you consider backpatching?
> On the one hand it fixes a bug, on the other hand it affects all
> frontend executables...

Yeah, for this reason I would not do a backpatch.  I have a very hard
time to believe that any frontend tools on Windows developed by anybody
rely on files to be opened only by a single process, still if they do
they would be surprised to see a change of behavior after a minor
update in case they rely on the concurrency limitations.

> I wonder why nobody noticed the problem in pg_test_fsync earlier.
> Is it that people running Windows care less if their storage is
> reliable?

likely so.
--
Michael


signature.asc
Description: PGP signature

Re: Code of Conduct plan

[Chris Travers]

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 hard to keep
> > forward progress going, particularly with respect to selecting the
> initial
> > committee members.  Now that Magnus is back on shore, I hope we can
> > wrap it up quickly --- say by the end of August.
>
> 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
>
> https://wiki.postgresql.org/wiki/Code_of_Conduct
>
> (That's the updated text, but you can use the diff tool on the page
> history tab to see the changes from the previous draft.)
>

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 takes precedence (such as a
conference's Code of Conduct)."

That covers things like public twitter messages over live political
controversies which might not be personally directed.   At least if one is
going to go that route, one ought to *also* include a safe harbor for
non-personally-directed discussions of philosophy, social issues, and
politics.  Otherwise, I think this is asking for trouble.  See, for
example, what happened with Opalgate and how this could be seen to
encourage use of this to silence political controversies unrelated to
PostgreSQL.

>
> I think we are about ready to announce the initial membership of the
> CoC committee, as well, but that should be a separate post.
>
> regards, tom lane
>
>

-- 
Best Wishes,
Chris Travers

Efficito:  Hosted Accounting and ERP.  Robust and Flexible.  No vendor
lock-in.
http://www.efficito.com/learn_more

Re: Changing the setting of wal_sender_timeout per standby

[Masahiko Sawada]

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, and a longer timeout for a standby in the remote
>> region (for disaster recovery) to avoid mis-judging its health.
>
> This argument is sensible.
>
>> The current PGC_HUP allows to change the setting by editing
>> postgresql.conf or ALTER SYSTEM and then sending SIGHUP to a specific
>> walsender.  But that's not easy to use.  The user has to do it upon
>> every switchover and failover.
>>
>> With PGC_BACKEND, the user would be able to tune the timeout as follows:
>>
>> [recovery.conf]
>> primary_conninfo = '... options=''-c wal_sender_timeout=6'' ...'
>>
>> With PGC_USERSET, the user would be able to use different user
>> accounts for each standby, and tune the setting as follows:
>>
>> ALTER USER repluser_remote SET wal_sender_timeout = 6;
>
> It seems to me that switching to PGC_BACKENDwould cover already all the
> use-cases you are mentioning, as at the end one would just want to
> adjust the WAL sender timeout on a connection basis depending on the
> geographical location of the receiver and the latency between primary
> and standby.

+1 for PGC_BACKEND. It looks enough for most use cases.

Regards,

--
Masahiko Sawada
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center

Re: Code of Conduct plan

[Chris Travers]

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 postgresql.org infrastructure, so
> long
> > as there is not another Code of Conduct that takes precedence (such as a
> > conference's Code of Conduct)."
> >
> > That covers things like public twitter messages over live political
> > controversies which might not be personally directed.   At least if one
> is
> > going to go that route, one ought to *also* include a safe harbor for
> > non-personally-directed discussions of philosophy, social issues, and
> > politics.  Otherwise, I think this is asking for trouble.  See, for
> example,
> > what happened with Opalgate and how this could be seen to encourage use
> of
> > this to silence political controversies unrelated to PostgreSQL.
>
> I think, this point has nothing to do with _correct_ discussions or
> public tweets.
>
> If one community member tweets publicly and in a way which abuses
> other community members, it is obvious CoC violation. It is hard to
> imagine healthy community if someone interacts with others  correctly
> on the list or at a conference because the CoC stops him doing things
> which he will do on private capacity to the same people when CoC
> doesnt apply.
>
> If someone reports CoC violation just because other community member's
> _correct_ public tweet or whatsoever  expressed different
> political/philosophical/religious views, this is a quite different
> story. I suppose CoC committee and/or Core team in this case should
> explain the reporter the purpose of CoC rather than automatically
> enforce it.
>

So first, I think what the clause is trying to do is address cases where
harassment targeting a particular community member takes place outside the
infrastructure and frankly ensuring that the code of conduct applies in
these cases is important and something I agree with.

However, let's look at problem cases:

"I am enough of a Marxist to see gender as a qualitative relationship to
biological reproduction and maybe economic production too."

I can totally imagine someone arguing that such a tweet might be abusive,
and certainly not "correct."

Or consider:

"The effort to push GLBT rights on family-business economies is nothing
more than an effort at corporate neocolonialism."

Which would make the problem more clear.  Whether or not a comment like
that occurring outside postgresql.org infrastructure would be considered
"correct" or "abusive" is ultimately a political decision and something
which, once that fight is picked, has no reasonable solution in an
international and cross-cultural product (where issues like sexuality,
economics, and how gender and individualism intersect will vary
dramatically across members around the world).  There are people who will
assume that both of the above statements are personally offensive and
attacks on the basis of gender identity even if they are critiques of
political agendas severable from that.  Worse, the sense of attack
themselves could be seen as attacks on culture or religions of other
participants.

Now neither of these comments would be tolerated as viewpoints expressed on
PostgreSQL.org email lists because they are off-topic, but once one expands
the code of conduct in this way they become fair game.  Given the way
culture war issues are shaping up particularly in the US, I think one has
to be very careful not to set an expectation that this applies to literally
everything that anyone does anywhere.

So maybe something more like:

"Conduct that occurs outside the postgresql.org infrastructure is not
automatically excluded from enforcement of this code of conduct.  In
particular if other parties are unable to act, and if it is, on balance, in
the interest of the global community to apply the code of conduct, then the
code of conduct shall apply."

>
> > --
> > Best Wishes,
> > Chris Travers
> >
> > Efficito:  Hosted Accounting and ERP.  Robust and Flexible.  No vendor
> > lock-in.
> > http://www.efficito.com/learn_more
>


-- 
Best Wishes,
Chris Travers

Efficito:  Hosted Accounting and ERP.  Robust and Flexible.  No vendor
lock-in.
http://www.efficito.com/learn_more

Re: Connection slots reserved for replication

[Masahiko Sawada]

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 case if all non-reserved connection slots are busy, replica fails to open
> a new connection and start streaming from the primary. Such behavior is very
> bad if you want to run postgresql HA clusters

Yeah, that's also bad if we want to use pg_baseback in the situation.

>
> Initially, replication connections required superuser privileges (in 9.0)
> and therefore they were deliberately excluded from
> superuser_reserved_connections. Basically that means it has never been
> possible to reserve come connection slots for replication connections.
>
> Later (9.1) it became possible to create a user with REPLICATION and
> NOSUPERUSER options, but comment in the postinit.c still tells that
> superuser is required.
>
> Now I think now it is a time to go further, and we should make it possible
> to reserve some connection slots for replication in a manner similar to
> superuser connections.
>

+1

> How should it work:
> 1. If we know that we got the replication connection, we just should make
> sure that there are at least superuser_reserved_connections free connection
> slots are available.
> 2. If we know that this is neither superuser nor replication connection, we
> should check that there are at least (superuser_reserved_connections +
> NumWalSenders() - max_wal_senders) connection slots are available.

You wanted to mean (superuser_reserved_connections + max_wal_senders -
NumWalSenders()) in the second point?

>
> And the last question how to control the number of reserved slots for
> replication. There are two options:
> 1. We can introduce a new GUC for that: replication_reserved_connections
> 2. Or we can just use the value of max_wal_senders
>
> Personally, I more like the second option.
>

One argrable point of the second option could be that it breaks
backward compatibility of the parameter configurations. That is, the
existing systems need to re-configure the max_connections. So it might
be better to take the first option with
replication_reservd_connections = 0 by default.

Regards,

--
Masahiko Sawada
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center

Re: Problem while setting the fpw with SIGHUP

[Amit Kapila]

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 */
> > +   pqsignal(SIGHUP, SIG_IGN);  /* ignore reload config */
> >
> > I am finally coming back to this patch set, and that's one of the first
> > things I am going to help moving on for this CF.  And this bit from the
> > last patch series is not acceptable as there are some parameters which
> > are used by the startup process which can be reloaded.  One of them is
> > wal_retrieve_retry_interval for tuning when fetching WAL at recovery.
>
> So, I have been working on this problem again and I have reviewed the
> thread, and there have been many things discussed in the last couple of
> months:
> 1) We do not want to initialize XLogInsert stuff unconditionally for all
> processes at the moment recovery begins, but we just want to initialize
> it once WAL write is open for business.
> 2) Both the checkpointer and the startup process can call
> UpdateFullPageWrites() which can cause Insert->fullPageWrites to get
> incorrect values.

Can you share the steps to reproduce this problem?

> 3) We do not want a palloc() in a critical section because of
> RecoveryinProgress being called.
>
> And the root issue here is 2), because the checkpointer tries to update
> Insert->fullPageWrites but it does not need to do so until recovery has
> been finished.  So in order to fix the original issue I am proposing a
> simple fix: let's make sure that the checkpointer does not update
> Insert->fullPageWrites until recovery finishes, and let's have the
> startup process do the first update once it finishes recovery and
> inserts by itself the XLOG_PARAMETER_CHANGE.  This way the order of
> events is purely sequential and we don't need to worry about having the
> checkpointer and the startup process eat on each other's plate because
> the checkpointer would only try to work on updating the shared memory
> value of full_page_writes once SharedRecoveryInProgress is switched to
> true, and that happens after the startup process does its initial call
> to UpdateFullPageWrites().  I have improved as well all the comments
> around to make clear the behavior wanted.
>
> Thoughts?
>

 UpdateFullPageWrites(void)
 {
  XLogCtlInsert *Insert = &XLogCtl->Insert;
+ /*
+ * Check if recovery is still in progress before entering this critical
+ * section, as some memory allocation could happen at the end of
+ * recovery.  There is nothing to do for a system still in recovery.
+ * Note that we need to process things here at the end of recovery for
+ * the startup process, which is why this checks after InRecovery.
+ */
+ if (RecoveryInProgress() && !InRecovery)
+ return;
+

On a regular startup when there is no recovery, it won't allow us to
log the WAL record (XLOG_FPW_CHANGE) which can happen without above
change.  You can check that by setting full_page_writes=off and start
the system.

-- 
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com

Re: Code of Conduct plan

[Ilya Kosmodemiansky]

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 takes precedence (such as a
> conference's Code of Conduct)."
>
> That covers things like public twitter messages over live political
> controversies which might not be personally directed.   At least if one is
> going to go that route, one ought to *also* include a safe harbor for
> non-personally-directed discussions of philosophy, social issues, and
> politics.  Otherwise, I think this is asking for trouble.  See, for example,
> what happened with Opalgate and how this could be seen to encourage use of
> this to silence political controversies unrelated to PostgreSQL.

I think, this point has nothing to do with _correct_ discussions or
public tweets.

If one community member tweets publicly and in a way which abuses
other community members, it is obvious CoC violation. It is hard to
imagine healthy community if someone interacts with others  correctly
on the list or at a conference because the CoC stops him doing things
which he will do on private capacity to the same people when CoC
doesnt apply.

If someone reports CoC violation just because other community member's
_correct_ public tweet or whatsoever  expressed different
political/philosophical/religious views, this is a quite different
story. I suppose CoC committee and/or Core team in this case should
explain the reporter the purpose of CoC rather than automatically
enforce it.

> --
> Best Wishes,
> Chris Travers
>
> Efficito:  Hosted Accounting and ERP.  Robust and Flexible.  No vendor
> lock-in.
> http://www.efficito.com/learn_more

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

[Thomas Munro]

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 entirely possible to get make check-world passing on a Mac.
Maybe post the problem you're seeing to a new thread?

> ...

> In the past it had been suggested we do PG_TRY(); and PG_CATCH(), but given 
> that it is not consistent whether we can raise an error or whether we MUST 
> raise an error, I don't see how this approach can work.  As far as I can see, 
> we MUST raise an error in the appropriate spot if and only if elevel is set 
> to a sufficient level.

Yeah, your way looks a bit nicer than something involving PG_TRY().

> Is there any feedback on this approach before I add it to the next commitfest?

Please go ahead and add it.  Being a bug fix, we'll commit it sooner
than the open commitfest anyway, but it's useful to have it in there.

+ if (errno == EINTR && elevel >= ERROR)
+ CHECK_FOR_INTERRUPTS();

I think we might as well just CHECK_FOR_INTERRUPTS() unconditionally.
In this branch elevel is always ERROR as you noted, and the code
around there is confusing enough already.

+ } while (rc == EINTR && !(ProcDiePending || QueryCancelPending));

There seems to be a precedent for checking QueryCancelPending directly
to break out of a loop in regcomp.c and syncrep.c.  So this seems OK.
Hmm, I wonder if there should be an INTERRUPT_PENDING() macro that
hides those details, but allows you to break out of a loop and then do
some cleanup before CHECK_FOR_INTERRUPT().

-- 
Thomas Munro
http://www.enterprisedb.com

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

[Amit Khandekar]

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 think we better show per-worker jit info also. The current patch
>>> does not show that. I think it would be easy to continue on the patch
>>> to show per-worker info also. Under the Gather node, we can show
>>> per-worker jit counters. I think this would be useful too, besides the
>>> cumulative figures in the leader process. Comments ?
>>
>> Yes, I think that'd be good.
> Ok. Will continue on the patch.
>
>> I think we either should print the stats at
>> the top level as $leader_value, $combined_worker_value, $total_value or
>> just have the $combined_worker_value at the level where we print other
>> stats from the worker, too.
>
> Yes, I think we can follow and be consistent with whatever way in
> which the other worker stats are printed. Will check.
>
> Note: Since there can be a multiple separate Gather plans under a plan
> tree, I think we can show this info for each Gather plan.

The attached patch shows per-worker information, besides the
cumulative figure in the end of plan. Attached is the complete output
of an aggregate parallel query on tenk1 table (created using the
regression tests). You can see that the per-worker figures are under
each of the Gather plans.


We can show combined values of all the workers under a Gather plan as
one single value, but I guess if we just show per-worker values, we
don't have to additionally show combined value. Comments ?
Also, I have kept the the per-worker info only for verbose=true.

The Gather plan's leader value is not shown. We also don't show
leader-specific values when we show the usual per-worker
instrumentation values. So I think we are consistent. Actually it is a
bit tedious to collect only leader-specific values. And I don't think
it is worth trying for it. For worker, I am not collecting
per-plan-node info, because we want to show total worker figures, and
not per-plan-node figures. For the normal instrumentations, we want to
show per-node info. For leader-specific instrumentation, we would need
to store per-(Gather-)plan info.

Need to finalize the indentation and the other explain formats. One
option is to keep the per-worker JIT info in a single line, like how
we print the normal per-worker instrumentation :
Worker 1: actual time=20.971..35.975 rows=39991 loops=1


Below is a snippet :

 Aggregate  (cost=18656.00..18656.01 rows=1 width=8) (actual
time=593.917..593.917 rows=1 loops=1)
   Output: count(*)
   ->  Hash Join  (cost=10718.00..18456.00 rows=8 width=0) (actual
time=496.650..593.883 rows=16 loops=1)
 Inner Unique: true
 Hash Cond: ((a.unique1 = b.unique1) AND (a.two =
(row_number() OVER (?
 ->  Gather  (cost=0.00..5918.00 rows=16 width=8) (actual
time=192.319..223.384 rows=16 loops=1)
   Output: a.unique1, a.two
   Workers Planned: 4
   Workers Launched: 4
   Jit for Worker : 0
 Functions: 2
 Generation Time: 0.273 ms
 Inlining: true
 Inlining Time: 43.686 ms
 Optimization: true
 Optimization Time: 10.788 ms
 Emission Time: 8.438 ms
   Jit for Worker : 1
 Functions: 2
 Generation Time: 0.293 ms
 Inlining: true
 Inlining Time: 72.587 ms
 Optimization: true
 Optimization Time: 10.386 ms
 Emission Time: 8.115 ms
..
..
..
 Planning Time: 0.548 ms
 Jit:
   Functions: 40
   Generation Time: 3.892 ms
   Inlining: true
   Inlining Time: 409.397 ms
   Optimization: true
   Optimization Time: 174.708 ms
   Emission Time: 91.785 ms
 Execution Time: 610.262 ms
(98 rows)


>
>>
>>
>>>  /*
>>> + * Add up the workers' JIT instrumentation from dynamic shared memory.
>>> + */
>>> +static void
>>> +ExecParallelRetrieveJitInstrumentation(PlanState *planstate,
>>> +
>>> SharedJitInstrumentation *shared_jit)
>>> +{
>>> + int n;
>>> + JitContext *jit = planstate->state->es_jit;
>>> +
>>> + /* If the leader hasn't yet created a jit context, allocate one now. 
>>> */
>>> + if (!jit)
>>> + {
>>> + planstate->state->es_jit = jit =
>>> + jit_create_context(planstate->state->es_jit_flags);
>>> + }
>>
>> Wouldn't it be better to move the jit instrumentation to outside of the
>> context, to avoid having to do this?  Or just cope with not having
>> instrumentation for the leader in this case?  We'd kinda need to deal
>> with failure to create one anyway?
>
> Yeah, I think taking out the i

Re: Code of Conduct plan

[Damir Colak]

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 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 hard to keep
> > forward progress going, particularly with respect to selecting the initial
> > committee members.  Now that Magnus is back on shore, I hope we can
> > wrap it up quickly --- say by the end of August.
> 
> 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
> 
> https://wiki.postgresql.org/wiki/Code_of_Conduct 
> 
> 
> (That's the updated text, but you can use the diff tool on the page
> history tab to see the changes from the previous draft.)
> 
> 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 takes 
> precedence (such as a conference's Code of Conduct)."
> 
> That covers things like public twitter messages over live political 
> controversies which might not be personally directed.   At least if one is 
> going to go that route, one ought to *also* include a safe harbor for 
> non-personally-directed discussions of philosophy, social issues, and 
> politics.  Otherwise, I think this is asking for trouble.  See, for example, 
> what happened with Opalgate and how this could be seen to encourage use of 
> this to silence political controversies unrelated to PostgreSQL.
> 
> I think we are about ready to announce the initial membership of the
> CoC committee, as well, but that should be a separate post.
> 
> regards, tom lane
> 
> 
> 
> -- 
> Best Wishes,
> Chris Travers
> 
> Efficito:  Hosted Accounting and ERP.  Robust and Flexible.  No vendor 
> lock-in.
> http://www.efficito.com/learn_more 

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

[Brad DeJong]

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

[Daniel Gustafsson]

> 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 capitalized as "Sort nodes” to match the rest of the comment.

cheers ./daniel

Re: hostorder and failover_timeout for libpq

[Surafel Temesgen]

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 host to connect to
+will be randomly picked from the list. It allows load balacing between
+several cluster nodes.
I Can’t think of use case where randomly picking a node rather than in
user specified order can load balance the cluster better. Can you
explain the purpose of this feature more? And in the code I can’t see
a mechanism for preventing picking one host multiple time
By the way patch doesn’t apply cleanly I think it need a rebase
http://cfbot.cputube.org/patch_19_1631.log

Regards
Surafel

Re: Code of Conduct plan

[James Keener]

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 reported for saying the above on a 3rd party forum? 

Obviously the pg mailing list isn't a place for such discussion, but is being a 
member of this community a deal with the devil to give up my right to free 
speech elsewhere?

Jim

On September 14, 2018 6:10:47 AM EDT, Chris Travers  
wrote:
>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 postgresql.org infrastructure,
>so
>> long
>> > as there is not another Code of Conduct that takes precedence (such
>as a
>> > conference's Code of Conduct)."
>> >
>> > That covers things like public twitter messages over live political
>> > controversies which might not be personally directed.   At least if
>one
>> is
>> > going to go that route, one ought to *also* include a safe harbor
>for
>> > non-personally-directed discussions of philosophy, social issues,
>and
>> > politics.  Otherwise, I think this is asking for trouble.  See, for
>> example,
>> > what happened with Opalgate and how this could be seen to encourage
>use
>> of
>> > this to silence political controversies unrelated to PostgreSQL.
>>
>> I think, this point has nothing to do with _correct_ discussions or
>> public tweets.
>>
>> If one community member tweets publicly and in a way which abuses
>> other community members, it is obvious CoC violation. It is hard to
>> imagine healthy community if someone interacts with others  correctly
>> on the list or at a conference because the CoC stops him doing things
>> which he will do on private capacity to the same people when CoC
>> doesnt apply.
>>
>> If someone reports CoC violation just because other community
>member's
>> _correct_ public tweet or whatsoever  expressed different
>> political/philosophical/religious views, this is a quite different
>> story. I suppose CoC committee and/or Core team in this case should
>> explain the reporter the purpose of CoC rather than automatically
>> enforce it.
>>
>
>So first, I think what the clause is trying to do is address cases
>where
>harassment targeting a particular community member takes place outside
>the
>infrastructure and frankly ensuring that the code of conduct applies in
>these cases is important and something I agree with.
>
>However, let's look at problem cases:
>
>"I am enough of a Marxist to see gender as a qualitative relationship
>to
>biological reproduction and maybe economic production too."
>
>I can totally imagine someone arguing that such a tweet might be
>abusive,
>and certainly not "correct."
>
>Or consider:
>
>"The effort to push GLBT rights on family-business economies is nothing
>more than an effort at corporate neocolonialism."
>
>Which would make the problem more clear.  Whether or not a comment like
>that occurring outside postgresql.org infrastructure would be
>considered
>"correct" or "abusive" is ultimately a political decision and something
>which, once that fight is picked, has no reasonable solution in an
>international and cross-cultural product (where issues like sexuality,
>economics, and how gender and individualism intersect will vary
>dramatically across members around the world).  There are people who
>will
>assume that both of the above statements are personally offensive and
>attacks on the basis of gender identity even if they are critiques of
>political agendas severable from that.  Worse, the sense of attack
>themselves could be seen as attacks on culture or religions of other
>participants.
>
>Now neither of these comments would be tolerated as viewpoints
>expressed on
>PostgreSQL.org email lists because they are off-topic, but once one
>expands
>the code of conduct in this way they become fair game.  Given the way
>culture war issues are shaping up particularly in the US, I think one
>has
>to be very careful not to set an expectation that this applies to
>literally
>everything that anyone does anywhere.
>
>So maybe something more like:
>
>"Conduct that occurs outside the postgresql.org infrastructure is not
>automatically excluded from enforcement of this code of conduct.  In
>particular if other parties are unable to act, and if it is, on
>balance, in
>the interest of the global community to apply the code of conduct, then
>the
>code of conduct shall apply."
>
>>
>> > --
>> > Best Wishes,
>> > Chris Travers
>> >
>> > Efficito:  Hosted Accounting and ERP.  Robust and Flexible.  No
>vendor
>> > lock-in.
>> > http://www.efficito.com/learn_more
>>
>
>
>-- 
>Best Wishes,
>Chris Travers
>
>Efficito:  Hosted Accounting and ERP.  Rob

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

[Etsuro Fujita]

(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 simple relation but I didn't find that
actually happens.


Yeah, currently, postgres_fdw and file_fdw don't use that list for
simple foreign table scans, but it could be used to improve the
efficiency for those scans, as explained in fdwhandler.sgml:

...

I'll put more consideration on using fdw_scan_tlist in the
documented way.


Done. postgres_fdw now generates full fdw_scan_tlist (as
documented) for foreign relations with junk columns having a
small change in core side. However it is far less invasive than
the previous version and I believe that it dones't harm
maybe-existing use of fdw_scan_tlist on non-join rels (that is,
in the case of a subset of relation columns).


Yeah, changes to the core by the new version is really small, which is 
great, but I'm not sure it's a good idea to modify the catalog info on 
the target table on the fly:


@@ -126,8 +173,18 @@ get_relation_info(PlannerInfo *root, Oid 
relationObjectId,\

 bool inhparent,
(errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
 errmsg("cannot access temporary or unlogged relations 
during r\

ecovery")));

+   max_attrnum = RelationGetNumberOfAttributes(relation);
+
+   /* Foreign table may have exanded this relation with junk columns */
+   if (root->simple_rte_array[varno]->relkind == RELKIND_FOREIGN_TABLE)
+   {
+   AttrNumber maxattno = max_varattno(root->parse->targetList, varno);
+   if (max_attrnum < maxattno)
+   max_attrnum = maxattno;
+   }
+
rel->min_attr = FirstLowInvalidHeapAttributeNumber + 1;
-   rel->max_attr = RelationGetNumberOfAttributes(relation);
+   rel->max_attr = max_attrnum;
rel->reltablespace = RelationGetForm(relation)->reltablespace;

This breaks the fundamental assumption that rel->max_attr is equal to 
RelationGetNumberOfAttributes of that table.  My concern is: this change 
would probably be a wart, so it would be bug-prone in future versions.


Another thing on the new version:

@@ -1575,6 +1632,19 @@ build_physical_tlist(PlannerInfo *root, 
RelOptInfo *rel)

relation = heap_open(rte->relid, NoLock);

numattrs = RelationGetNumberOfAttributes(relation);
+
+   /*
+* Foreign tables may have expanded with some junk columns. Punt
+* in the case.
+*/
+   if (numattrs < rel->max_attr)
+   {
+   Assert(root->simple_rte_array[rel->relid]->relkind ==
+  RELKIND_FOREIGN_TABLE);
+   heap_close(relation, NoLock);
+   break;
+   }

I think this would disable the optimization on projection in foreign 
scans, causing performance regression.



One arguable behavior change is about wholrow vars. Currently it
refferes local tuple with all columns but it is explicitly
fetched as ROW() after this patch applied. This could be fixed
but not just now.

Part of 0004-:
-  Output: f1, ''::text, ctid, rem1.*
-  Remote SQL: SELECT f1, f2, ctid FROM public.loc1 FOR UPDATE
+  Output: f1, ''::text, tableoid, ctid, rem1.*
+  Remote SQL: SELECT f1, tableoid, ctid, ROW(f1, f2) FROM public.loc1 FOR 
UPDATE


That would be also performance regression.  If we go in this direction, 
that should be fixed.



Since this uses fdw_scan_tlist so it is theoretically
back-patchable back to 9.6.


IIRC, the fdw_scan_tlist stuff was introduced in PG9.5 as part of join 
pushdown infrastructure, so I think your patch can be back-patched to 
PG9.5, but I don't think that's enough; IIRC, this issue was introduced 
in PG9.3, so a solution for this should be back-patch-able to PG9.3, I 
think.



Please find the attached three files.


Thanks for the patches!


0001-Add-test-for-postgres_fdw-foreign-parition-update.patch

  This should fail for unpatched postgres_fdw. (Just for demonstration)


+CREATE TABLE p1 (a int, b int);
+CREATE TABLE c1 (LIKE p1) INHERITS (p1);
+CREATE TABLE c2 (LIKE p1) INHERITS (p1);
+CREATE FOREIGN TABLE fp1 (a int, b int)
+ SERVER loopback OPTIONS (table_name 'p1');
+INSERT INTO c1 VALUES (0, 1);
+INSERT INTO c2 VALUES (1, 1);
+SELECT tableoid::int - (SELECT min(tableoid) FROM fp1)::int AS 
toiddiff, ctid, * FROM fp1;


Does it make sense to evaluate toiddiff?  I think that should always be 0.


0003-Fix-of-foreign-update-bug-of-PgFDW.patch

  Fix of postgres_fdw for this problem.


Sorry, I have not looked at it closely yet, but before that I'd like to 
discuss the direction we go in.  I'm not convinced that your approach is 
the right direction, so as promised, I wrote a patch using the 
Param-based approach, and compared the two approaches.  Attached is a 
WIP patch for that, which includes the 0003 patch.  I don't think there 
would be any 

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

[Arthur Zakirov]

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
> > completing with FROM DEFAULT or TO after it, instead of a list of
> > tablespaces.
> 
> And just after hitting send, I noticed I'd typed ALTER TABLE instead of
> ALTER DATABASE, including in the commit message :(
> 
> Fixed patch attached.

The patch seems reasonable. It fixes the lack of tab completion for
ALTER DATABASE ... SET TABLESPACE ... .

There is no need to patch the documentation and regression tests.

Marked as Ready for Commiter.

-- 
Arthur Zakirov
Postgres Professional: http://www.postgrespro.com
Russian Postgres Company

Re: Code of Conduct plan

[Martin Mueller]

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 reminding offenders that 
they’ve crossed a line marked by common decency or common courtesy. I think a 
list manager should have the right to expel repeat offenders. I doubt whether 
‘proceduralizing’ offences against common decency or common courtesy makes it 
easier to police what is always a tricky boundary.

It is possible to spend a lot of time and energy designing bureaucratic 
solution that in the end does little good.  My grandchildren were taught that 
“please and thank you sound so nice  manners are important, be polite” sung 
to the tune of Frère Jacques. They don’t always remember it,  but a longer poem 
wouldn’t help.


From: James Keener 
Date: Friday, September 14, 2018 at 7:52 AM
To: "pgsql-gene...@lists.postgresql.org" , 
Chris Travers , "i...@dataegret.com" 

Cc: Tom Lane , Stephen Frost , 
"pgsql-generallists.postgresql.org" , 
"pgsql-hackers@lists.postgresql.org" , 
"pgsql-advoc...@lists.postgresql.org" 
Subject: 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 reported for saying the above on a 3rd party forum?

Obviously the pg mailing list isn't a place for such discussion, but is being a 
member of this community a deal with the devil to give up my right to free 
speech elsewhere?

Jim
On September 14, 2018 6:10:47 AM EDT, Chris Travers  
wrote:

On Fri, Sep 14, 2018 at 11:45 AM Ilya Kosmodemiansky 
mailto:i...@dataegret.com>> wrote:
On Fri, Sep 14, 2018 at 10:31 AM, Chris Travers 
mailto:chris.trav...@gmail.com>> 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 takes precedence (such as a
> conference's Code of Conduct)."
>
> That covers things like public twitter messages over live political
> controversies which might not be personally directed.   At least if one is
> going to go that route, one ought to *also* include a safe harbor for
> non-personally-directed discussions of philosophy, social issues, and
> politics.  Otherwise, I think this is asking for trouble.  See, for example,
> what happened with Opalgate and how this could be seen to encourage use of
> this to silence political controversies unrelated to PostgreSQL.

I think, this point has nothing to do with _correct_ discussions or
public tweets.

If one community member tweets publicly and in a way which abuses
other community members, it is obvious CoC violation. It is hard to
imagine healthy community if someone interacts with others  correctly
on the list or at a conference because the CoC stops him doing things
which he will do on private capacity to the same people when CoC
doesnt apply.

If someone reports CoC violation just because other community member's
_correct_ public tweet or whatsoever  expressed different
political/philosophical/religious views, this is a quite different
story. I suppose CoC committee and/or Core team in this case should
explain the reporter the purpose of CoC rather than automatically
enforce it.

So first, I think what the clause is trying to do is address cases where 
harassment targeting a particular community member takes place outside the 
infrastructure and frankly ensuring that the code of conduct applies in these 
cases is important and something I agree with.

However, let's look at problem cases:

"I am enough of a Marxist to see gender as a qualitative relationship to 
biological reproduction and maybe economic production too."

I can totally imagine someone arguing that such a tweet might be abusive, and 
certainly not "correct."

Or consider:

"The effort to push GLBT rights on family-business economies is nothing more 
than an effort at corporate neocolonialism."

Which would make the problem more clear.  Whether or not a comment like that 
occurring outside 
postgresql.org
 infrastructure wou

Re: Code of Conduct plan

[Adrian Klaver]

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 will be moving forward?
 >> Or did I miss something?

 > Nope, you didn't.  Folks have been on holiday which made it hard
to keep
 > forward progress going, particularly with respect to selecting
the initial
 > committee members.  Now that Magnus is back on shore, I hope we can
 > wrap it up quickly --- say by the end of August.

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

https://wiki.postgresql.org/wiki/Code_of_Conduct

(That's the updated text, but you can use the diff tool on the page
history tab to see the changes from the previous draft.)


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 takes precedence (such as a conference's Code of 
Conduct)."


I second that objection. It is not in PGDG's remit to cure the world, 
for whatever form of cure you ascribe to. This is especially true as 
'community member' has no strict definition.




That covers things like public twitter messages over live political 
controversies which might not be personally directed.   At least if one 
is going to go that route, one ought to *also* include a safe harbor for 
non-personally-directed discussions of philosophy, social issues, and 
politics.  Otherwise, I think this is asking for trouble.  See, for 
example, what happened with Opalgate and how this could be seen to 
encourage use of this to silence political controversies unrelated to 
PostgreSQL.



I think we are about ready to announce the initial membership of the
CoC committee, as well, but that should be a separate post.

                         regards, tom lane



--
Best Wishes,
Chris Travers

Efficito:  Hosted Accounting and ERP.  Robust and Flexible.  No vendor 
lock-in.

http://www.efficito.com/learn_more



--
Adrian Klaver
adrian.kla...@aklaver.com

Re: Code of Conduct plan

[Robert Eckhardt]

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 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 hard
>> to keep
>>  > forward progress going, particularly with respect to selecting
>> the initial
>>  > committee members.  Now that Magnus is back on shore, I hope we can
>>  > wrap it up quickly --- say by the end of August.
>>
>> 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
>>
>> https://wiki.postgresql.org/wiki/Code_of_Conduct
>>
>> (That's the updated text, but you can use the diff tool on the page
>> history tab to see the changes from the previous draft.)
>>
>>
>> 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 takes
>> precedence (such as a conference's Code of Conduct)."
>
>
> I second that objection. It is not in PGDG's remit to cure the world, for
> whatever form of cure you ascribe to. This is especially true as 'community
> member' has no strict definition.

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 solution looking for a problem. If we just want to look
at the clusterfuck that is happening in the reddis community right now
we can see conversations spilling onto twitter and into ad hominem
vitriol.

My $0.02
-- Rob Eckhardt

>
>
>>
>> That covers things like public twitter messages over live political
>> controversies which might not be personally directed.   At least if one is
>> going to go that route, one ought to *also* include a safe harbor for
>> non-personally-directed discussions of philosophy, social issues, and
>> politics.  Otherwise, I think this is asking for trouble.  See, for example,
>> what happened with Opalgate and how this could be seen to encourage use of
>> this to silence political controversies unrelated to PostgreSQL.
>>
>>
>> I think we are about ready to announce the initial membership of the
>> CoC committee, as well, but that should be a separate post.
>>
>>  regards, tom lane
>>
>>
>>
>> --
>> Best Wishes,
>> Chris Travers
>>
>> Efficito:  Hosted Accounting and ERP.  Robust and Flexible.  No vendor
>> lock-in.
>> http://www.efficito.com/learn_more
>
>
>
> --
> Adrian Klaver
> adrian.kla...@aklaver.com
>

Re: Code of Conduct plan

[Joshua D. Drake]

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

https://wiki.postgresql.org/wiki/Code_of_Conduct

(That's the updated text, but you can use the diff tool on the page
history tab to see the changes from the previous draft.)


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 takes precedence (such as a conference's 
Code of Conduct)."


That covers things like public twitter messages over live political 
controversies which might not be personally directed.   At least if 
one is going to go that route, one ought to *also* include a safe 
harbor for non-personally-directed discussions of philosophy, social 
issues, and politics.  Otherwise, I think this is asking for trouble.  
See, for example, what happened with Opalgate and how this could be 
seen to encourage use of this to silence political controversies 
unrelated to PostgreSQL.


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.


On the other hand if you are (note: contributor, not community member 
which is different) contributor to PostgreSQL, your actions speak about 
PostgreSQL. So I am not sure what a good plan of action here would be.


One area where this is going to cause a lot of issues is within the 
social constructs of the micro-communities. Are we going to ban Chinese 
members because their government is anti Christian and anti Muslim? Are 
we going to ban members of countries that are not as progressive 
thinking about LGBT rights? Are we going to tell evangelical Christians 
or devout Muslims that they are unwelcome because they are against Gay 
marriage? Are we going to ban Atheists because they think Christians are 
fools?


I think the answer would be, "no" unless they post an opinion... Is that 
really what our community is becoming, thought police?


There was a time when Open Source was about code and community. It is 
clear that it is becoming about authority and politics.


I am the individual that initiated this whole process many moons ago 
with the intent that we have a simple, "be excellent to each other" code 
of conduct. What we have now (although much better than previous drafts) 
is still an over reach.


tl;dr; The willingness of people to think they are right is only 
exceeded by their willingness to oppress those they don't agree with.



JD
--

Command Prompt, Inc. || http://the.postgres.company/ || @cmdpromptinc
***  A fault and talent of mine is to tell it exactly how it is.  ***
PostgreSQL centered full stack support, consulting and development.
Advocate: @amplifypostgres || Learn: https://postgresconf.org
* Unless otherwise stated, opinions are my own.   *

Re: Code of Conduct plan

[James Keener]

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 solution looking for a problem. If we just want to look
> at the clusterfuck that is happening in the reddis community right now
> we can see conversations spilling onto twitter and into ad hominem
> vitriol.
>

You haven't established that this is both 1) the PG mailing list's problem
and that 2) this can't and won't be used to retaliate against those holding
unpopular viewpoints but aren't specifically harassing anyone.

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 leaving
the community, which would be seen as an admission of guilt, my only
option.

People are shitheads. People are assholes. We're not agreeing to join
some organization and sign an ethics clause when signing up for the mailing
list.  The current moderators can already remove bad actors from the list.
How they act outside of the list is non of this list's concern.

Conferences are free to hold their own CoC because you explicitly agree to
it when you purchase a ticket, and it's governing interactions at the
conference
(or should only be governing actions at the conference.)

Jim

Re: Code of Conduct plan

[Adrian Klaver]

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 postgresql.org 
infrastructure, so long as there is not another Code of Conduct that takes
precedence (such as a conference's Code of Conduct)."



I second that objection. It is not in PGDG's remit to cure the world, for
whatever form of cure you ascribe to. This is especially true as 'community
member' has no strict definition.


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 solution looking for a problem. If we just want to look
at the clusterfuck that is happening in the reddis community right now
we can see conversations spilling onto twitter and into ad hominem
vitriol.


Ask yourself, if this was a government agency tracking your speech 
across platforms would you be as approving? Personally I find the whole 
thing creepy.




My $0.02
-- Rob Eckhardt




Adrian Klaver
adrian.kla...@aklaver.com






--
Adrian Klaver
adrian.kla...@aklaver.com

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

[Tomas Vondra]

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 got released).

> I just spent quite a while debugging an issue where running logical
> decoding yielded a:
> ERROR:  could not map filenode "base/$X/$Y" to relation OID
> error.
> 
> After discarding like 30 different theories, I have found the cause:
> 

Yeah. These issues are not exactly trivial to investigate ;-)

> During rewrites (i.e. VACUUM FULL / CLUSTER) of a mapped relation with a
> toast table with actual live toasted tuples (pg_proc in my case and
> henceforth) heap inserts with the toast data happen into the new toast
> relation, triggered by:
> 
> static void
> raw_heap_insert(RewriteState state, HeapTuple tup)
> ...
>   /*
>* If the new tuple is too big for storage or contains already toasted
>* out-of-line attributes from some other relation, invoke the toaster.
>*
>* Note: below this point, heaptup is the data we actually intend to 
> store
>* into the relation; tup is the caller's original untoasted data.
>*/
>   if (state->rs_new_rel->rd_rel->relkind == RELKIND_TOASTVALUE)
>   {
>   /* toast table entries should never be recursively toasted */
>   Assert(!HeapTupleHasExternal(tup));
>   heaptup = tup;
>   }
>   else if (HeapTupleHasExternal(tup) || tup->t_len > 
> TOAST_TUPLE_THRESHOLD)
>   heaptup = toast_insert_or_update(state->rs_new_rel, tup, NULL,
>   
>  HEAP_INSERT_SKIP_FSM |
>   
>  (state->rs_use_wal ?
>   
>   0 : HEAP_INSERT_SKIP_WAL));
>   else
>   heaptup = tup;
> 
> 
> At that point the new toast relation does *NOT* appear to be a system
> catalog, it's just appears as an "independent" table.  Therefore we do
> not trigger, in heap_insert():
> 

Hmm, can't we change that? Recognizing the new TOAST table as a catalog
would fix the issue, no?

> /*
>  * RelationIsLogicallyLogged
>  *True if we need to log enough information to extract the data 
> from the
>  *WAL stream.
>  *
>  * We don't log information for unlogged tables (since they don't WAL log
>  * anyway) and for system tables (their content is hard to make sense of, and
>  * it would complicate decoding slightly for little gain). Note that we *do*
>  * log information for user defined catalog tables since they presumably are
>  * interesting to the user...
>  */
> #define RelationIsLogicallyLogged(relation) \
>   (XLogLogicalInfoActive() && \
>RelationNeedsWAL(relation) && \
>!IsCatalogRelation(relation))
> 
>   /*
>* For logical decoding, we need the tuple even if we're doing 
> a full
>* page write, so make sure it's included even if we take a 
> full-page
>* image. (XXX We could alternatively store a pointer into the 
> FPW).
>*/
>   if (RelationIsLogicallyLogged(relation))
>   {
>   xlrec.flags |= XLH_INSERT_CONTAINS_NEW_TUPLE;
>   bufflags |= REGBUF_KEEP_DATA;
>   }
> 
> i.e. the inserted toast tuple will be marked as
> XLH_INSERT_CONTAINS_NEW_TUPLE - which it shouldn't, because it's a
> system table. Which we currently do not allow do be logically decoded.
> 
> That normally ends up being harmless, because ReorderBufferCommit() has the
> following check:
>   if 
> (!RelationIsLogicallyLogged(relation))
>   goto change_done;
> 
> but to reach that check, we first have to map the relfilenode from the
> WAL to the corresponding OID:
>   reloid = 
> RelidByRelfilenode(change->data.tp.relnode.spcNode,
>   
> change->data.tp.relnode.relNode);
> 
> That works correctly if there's only one rewrite - the relmapper
> contains the data for the new toast table.  But if there's been *two*
> consecutive rewrites, the relmapper *does not* contain the intermediary
> relfilenode of pg_proc.  There's no such problem for non-mapped tables,
> because historic snapshots allow us to access the relevant data, but the
> relmapper isn't mvcc.
> 
> Therefore the catalog-rewrite escape hatch of:
>   /*
>* Catalog tuple without data, emitted 
> while catalog was
>* in the process of

Re: Code of Conduct plan

[Geoff Winkless]

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 go after them on Facebook and Twitter.
>>
>> these aren't a solution looking for a problem. If we just want to look
>> at the clusterfuck that is happening in the reddis community right now
>> we can see conversations spilling onto twitter and into ad hominem
>> vitriol.
>>
>
> You haven't established that this is both 1) the PG mailing list's problem
> and that 2) this can't and won't be used to retaliate against those holding
> unpopular viewpoints but aren't specifically harassing anyone.
>

This argument (whether or not PostgreSQL should have a CoC) was hashed out
pretty heavily a year ago. In my opinion it wasn't really clear that any
one side or another won the argument but the people who matter came down on
the side of having one. It's pretty unlikely that re-running these
arguments is going to make those people change their minds.

Certainly posting obscenities to these open forums isn't going to do it,
however strongly you might feel about it.

Geoff

Re: Code of Conduct plan

[Dave Page]

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 frequently go after them on Facebook and Twitter.
>>
>> these aren't a solution looking for a problem. If we just want to look
>> at the clusterfuck that is happening in the reddis community right now
>> we can see conversations spilling onto twitter and into ad hominem
>> vitriol.
>>
>
> You haven't established that this is both 1) the PG mailing list's problem
> and that 2) this can't and won't be used to retaliate against those holding
> unpopular viewpoints but aren't specifically harassing anyone.
>
> 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 leaving
> the community, which would be seen as an admission of guilt, my only
> option.
>

If you had read the policy, you would know that wouldn't happen as reports
and details of reports are to be kept confidential.


>
> People are shitheads. People are assholes. We're not agreeing to join
> some organization and sign an ethics clause when signing up for the mailing
> list.  The current moderators can already remove bad actors from the list.
> How they act outside of the list is non of this list's concern.
>

The lists are just one of many different ways people in this community
interact.

-- 
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

Re: Code of Conduct plan

[Dave Page]

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 cover all interaction between community members,
 whether or not it takes place within postgresql.org <
 http://postgresql.org>
 infrastructure, so long as there is not another Code of Conduct that
 takes
 precedence (such as a conference's Code of Conduct)."

>>>
>>>
>>> I second that objection. It is not in PGDG's remit to cure the world, for
>>> whatever form of cure you ascribe to. This is especially true as
>>> 'community
>>> member' has no strict definition.
>>>
>>
>> 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 solution looking for a problem. If we just want to look
>> at the clusterfuck that is happening in the reddis community right now
>> we can see conversations spilling onto twitter and into ad hominem
>> vitriol.
>>
>
> Ask yourself, if this was a government agency tracking your speech across
> platforms would you be as approving? Personally I find the whole thing
> creepy.


No one is tracking anything as part of the CoC. That's nothing but a straw
man argument.

-- 
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

Re: Code of Conduct plan

[James Keener]

> 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 leaving
>> the community, which would be seen as an admission of guilt, my only
>> option.
>>
>
> If you had read the policy, you would know that wouldn't happen as reports
> and details of reports are to be kept confidential.
>

That doesn't mean I won't be strung along and it doesn't mean that the
attacker can't release those details. Remember, I'm worried
about politically motivated attacks, and attacks meant to silence opposing
viewpoints, not legitimate instances of harassment.


>
>
>>
>> People are shitheads. People are assholes. We're not agreeing to join
>> some organization and sign an ethics clause when signing up for the
>> mailing
>> list.  The current moderators can already remove bad actors from the list.
>> How they act outside of the list is non of this list's concern.
>>
>
> The lists are just one of many different ways people in this community
> interact.
>

So? We interact with people outside of specific groups all the time. Baring
specific
agreements to the contrary, why should any one group claim responsibility
of my
personal business?

Jim

Re: Code of Conduct plan

[Adrian Klaver]

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 postgresql.org infrastructure, so 
long as there is not another Code of Conduct that takes precedence (such 
as a conference's Code of Conduct)."


Not sure how the above can be enforced without someone reporting on what 
is said outside the 'postgresql.org infrastructure'?


At any rate, whether I like it or not the CoC is here to stay. I just 
feel a dissenting opinion is important to the conversation.




--
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



--
Adrian Klaver
adrian.kla...@aklaver.com

Re: Code of Conduct plan

[Ilya Kosmodemiansky]

> 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 community uses. Community is people who joined it and CoC supposed to 
apply even if people use analogue telephones. This is about communication, not 
about communication channels. 


> 
> -- 
> Dave Page
> Blog: http://pgsnake.blogspot.com
> Twitter: @pgsnake
> 
> EnterpriseDB UK: http://www.enterprisedb.com
> The Enterprise PostgreSQL Company

Re: Code of Conduct plan

[Dave Page]

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
>>> stress it'd take me to defend myself would make my voluntarily leaving
>>> the community, which would be seen as an admission of guilt, my only
>>> option.
>>>
>>
>> If you had read the policy, you would know that wouldn't happen as
>> reports and details of reports are to be kept confidential.
>>
>
> That doesn't mean I won't be strung along and it doesn't mean that the
> attacker can't release those details. Remember, I'm worried
> about politically motivated attacks, and attacks meant to silence opposing
> viewpoints, not legitimate instances of harassment.
>

Sure, but an attacker can do that now. Having the CoC doesn't change
anything there, though it does give us a framework to deal with it.


>
>
>>
>>
>>>
>>> People are shitheads. People are assholes. We're not agreeing to join
>>> some organization and sign an ethics clause when signing up for the
>>> mailing
>>> list.  The current moderators can already remove bad actors from the
>>> list.
>>> How they act outside of the list is non of this list's concern.
>>>
>>
>> The lists are just one of many different ways people in this community
>> interact.
>>
>
> So? We interact with people outside of specific groups all the time.
> Baring specific
> agreements to the contrary, why should any one group claim responsibility
> of my
> personal business?
>

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
something the project would get involved in.

-- 
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

Re: Code of Conduct plan

[Dave Page]

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
>>
>> https://wiki.postgresql.org/wiki/Code_of_Conduct
>>
>> (That's the updated text, but you can use the diff tool on the page
>> history tab to see the changes from the previous draft.)
>>
>
> 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 takes precedence (such as
> a conference's Code of Conduct)."
>
> That covers things like public twitter messages over live political
> controversies which might not be personally directed.   At least if one is
> going to go that route, one ought to *also* include a safe harbor for
> non-personally-directed discussions of philosophy, social issues, and
> politics.  Otherwise, I think this is asking for trouble.  See, for
> example, what happened with Opalgate and how this could be seen to
> encourage use of this to silence political controversies unrelated to
> PostgreSQL.
>
>
> 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.
>

I'm going to regret jumping in here, but...

I disagree. If a community member decides to join forums for other software
and then strongly promotes PostgreSQL to the point that they become abusive
or offensive to people making other software choices, then they are clearly
bringing the project into disrepute and we should have every right to
sanction them by preventing them participating in our project in whatever
ways are deemed appropriate.

-- 
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

Re: Code of Conduct plan

[Joshua D. Drake]

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 has now agreed to some revisions to the draft
CoC based on
the comments in this thread; see

https://wiki.postgresql.org/wiki/Code_of_Conduct


(That's the updated text, but you can use the diff tool on
the page
history tab to see the changes from the previous draft.)


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 takes precedence (such as a
conference's Code of Conduct)."

That covers things like public twitter messages over live
political controversies which might not be personally directed.  
At least if one is going to go that route, one ought to *also*
include a safe harbor for non-personally-directed discussions of
philosophy, social issues, and politics. Otherwise, I think this
is asking for trouble.  See, for example, what happened with
Opalgate and how this could be seen to encourage use of this to
silence political controversies unrelated to PostgreSQL.


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.


I'm going to regret jumping in here, but...

I disagree. If a community member decides to join forums for other 
software and then strongly promotes PostgreSQL to the point that they 
become abusive or offensive to people making other software choices, 
then they are clearly bringing the project into disrepute and we 
should have every right to sanction them by preventing them 
participating in our project in whatever ways are deemed appropriate.


We all know that PostgreSQL is the only database we should use and 
anybody using a different one just hasn't been enlightened yet. :P


I think we need to define community member. I absolutely see your point 
of the individual is a contributor but community member is rather 
ethereal in this context don't you think?


JD

--
Command Prompt, Inc. || http://the.postgres.company/ || @cmdpromptinc
***  A fault and talent of mine is to tell it exactly how it is.  ***
PostgreSQL centered full stack support, consulting and development.
Advocate: @amplifypostgres || Learn: https://postgresconf.org
* Unless otherwise stated, opinions are my own.   *

Re: Code of Conduct plan

[James Keener]

> 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 here; we don't need to be
buddies. There is a clear difference between "professionalism" and
"community". A document governing interactions on this list is within the
right of the moderation, but leaking into the "real world" is an
abomination and perversion of what this group is.

My church group is 100% within their right to kick me out of teaching
Sunday School if I were to have an affair. Teaching Sunday School is an act
taking place as part of a community of people with a shared belief and
culture. My job would 100% not be within their right to fire me for having
an affair, as it's not a community, but a professional environment and my
personal life is just that: personal. (Baring an ethics clauses signed when
joining, I guess?)

Jim


On Fri, Sep 14, 2018 at 10:31 AM, Ilya Kosmodemiansky 
wrote:

>
>
> 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 community uses. Community is people who joined it and CoC
> supposed to apply even if people use analogue telephones. This is about
> communication, not about communication channels.
>
>
>
> --
> Dave Page
> Blog: http://pgsnake.blogspot.com
> Twitter: @pgsnake
>
> EnterpriseDB UK: http://www.enterprisedb.com
> The Enterprise PostgreSQL Company
>
>

Re: Code of Conduct plan

[Dave Page]

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 moving.
>>> The core team has now agreed to some revisions to the draft CoC based on
>>> the comments in this thread; see
>>>
>>> https://wiki.postgresql.org/wiki/Code_of_Conduct
>>>
>>> (That's the updated text, but you can use the diff tool on the page
>>> history tab to see the changes from the previous draft.)
>>>
>>
>> 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 takes precedence (such as
>> a conference's Code of Conduct)."
>>
>> That covers things like public twitter messages over live political
>> controversies which might not be personally directed.   At least if one is
>> going to go that route, one ought to *also* include a safe harbor for
>> non-personally-directed discussions of philosophy, social issues, and
>> politics.  Otherwise, I think this is asking for trouble.  See, for
>> example, what happened with Opalgate and how this could be seen to
>> encourage use of this to silence political controversies unrelated to
>> PostgreSQL.
>>
>>
>> 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.
>>
>
> I'm going to regret jumping in here, but...
>
> I disagree. If a community member decides to join forums for other
> software and then strongly promotes PostgreSQL to the point that they
> become abusive or offensive to people making other software choices, then
> they are clearly bringing the project into disrepute and we should have
> every right to sanction them by preventing them participating in our
> project in whatever ways are deemed appropriate.
>
>
> We all know that PostgreSQL is the only database we should use and anybody
> using a different one just hasn't been enlightened yet. :P
>
> I think we need to define community member. I absolutely see your point of
> the individual is a contributor but community member is rather ethereal in
> this context don't you think?
>

There are some fuzzy edges I guess (e.g. Slack), but in my mind it's always
been anyone who participates in any of the projects communications channels.


-- 
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

Fwd: Code of Conduct plan

[James Keener]

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 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
> something the project would get involved in.
>
>
And yet, none of that is made clear or establish or even hinted at in the
current CoC. Also, may I refer you to https://github.com/opal/opal/
issues/941 as a scenario in which an outside conversation can leak in and
become the business of the group?

Jim

Re: Code of Conduct plan

[Dave Page]

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 entirely off-topic
> here.  We should be professional to each other here; we don't need to be
> buddies. There is a clear difference between "professionalism" and
> "community". A document governing interactions on this list is within the
> right of the moderation, but leaking into the "real world" is an
> abomination and perversion of what this group is.
>

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 welcome
others that wish to join, whether just to ask a single question or to hang
around for the next 20 years. I do see your viewpoint, but I would counter
that coming here for help (for example) is quite different from calling
tech support at a vendor.


>
> My church group is 100% within their right to kick me out of teaching
> Sunday School if I were to have an affair. Teaching Sunday School is an act
> taking place as part of a community of people with a shared belief and
> culture. My job would 100% not be within their right to fire me for having
> an affair, as it's not a community, but a professional environment and my
> personal life is just that: personal. (Baring an ethics clauses signed when
> joining, I guess?)
>

> Jim
>
>
> On Fri, Sep 14, 2018 at 10:31 AM, Ilya Kosmodemiansky 
> wrote:
>
>>
>>
>> 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 community uses. Community is people who joined it and CoC
>> supposed to apply even if people use analogue telephones. This is about
>> communication, not about communication channels.
>>
>>
>>
>> --
>> Dave Page
>> Blog: http://pgsnake.blogspot.com
>> Twitter: @pgsnake
>>
>> EnterpriseDB UK: http://www.enterprisedb.com
>> The Enterprise PostgreSQL Company
>>
>>
>


-- 
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

Re: Code of Conduct plan

[Dave Page]

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 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 leaving
 the community, which would be seen as an admission of guilt, my only
 option.

>>>
>>> If you had read the policy, you would know that wouldn't happen as
>>> reports and details of reports are to be kept confidential.
>>>
>>
>> That doesn't mean I won't be strung along and it doesn't mean that the
>> attacker can't release those details. Remember, I'm worried
>> about politically motivated attacks, and attacks meant to silence
>> opposing viewpoints, not legitimate instances of harassment.
>>
>
> Sure, but an attacker can do that now. Having the CoC doesn't change
> anything there, though it does give us a framework to deal with it.
>
>
>>
>>
>>>
>>>

 People are shitheads. People are assholes. We're not agreeing to join
 some organization and sign an ethics clause when signing up for the
 mailing
 list.  The current moderators can already remove bad actors from the
 list.
 How they act outside of the list is non of this list's concern.

>>>
>>> The lists are just one of many different ways people in this community
>>> interact.
>>>
>>
>> So? We interact with people outside of specific groups all the time.
>> Baring specific
>> agreements to the contrary, why should any one group claim responsibility
>> of my
>> personal business?
>>
>
> 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
> something the project would get involved in.
>
>
> O.k. so this isn't clear (at least to me) within the CoC. I want to make
> sure I understand. You are saying that if a community member posts on
> Twitter that they believe gays are going to hell, reporting that to the CoC
> committee would result in a non-violation UNLESS they referenced postgresql
> within the post?
>

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?

-- 
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

Re: Code of Conduct plan

[James Keener]

> 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 welcome
> others that wish to join, whether just to ask a single question or to hang
> around for the next 20 years. I do see your viewpoint, but I would counter
> that coming here for help (for example) is quite different from calling
> tech support at a vendor.
>

I fail to see how that makes everyone here part of a community anymore than
I'm part of the "community" of regulars at a bar I walk into for the first
time.

As I said, the rules can and should apply within the list, but applying
them outside the list is odd and wreaks of authoritarianism.

Jim

Re: Code of Conduct plan

[James Keener]

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 to have dedicated their life of pg?

Sure, they own the servers, they make the rules. I get it. I'm not entirely
opposed to it, even if I think it's silly to ram something down the rest of
the groups throats.

Jim

PS: Also, what's with the personal replies? If you don't want to say what
you want to the whole group, I don't really have an interest in talking to
you personally.

Re: Code of Conduct plan

[James Keener]

>
> 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 or not they're about postgres.

Jim

Re: Cache lookup errors with functions manipulation object addresses

[Alvaro Herrera]

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 it triggers elog("cache lookup") or
> > such for undefined objects.  Patch 0001 extends FDW and server routines
> > so as it is possible to skip missing entries, without breaking
> > compatibility.  Patch 0002 adds a missing_ok flag when doing
> > subscription and publication lookups.
> > 
> > Any objections?
> 
> And I forgot to attach the patches..

Patches 0001 and 0002 look OK to me now, on a cursory glance.

I haven't looked at 0003 yet.

-- 
Álvaro Herrerahttps://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Re: Code of Conduct plan

[Dave Page]

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 this group and that will be part of the CoC
> committee will have had to have dedicated their life of pg?
>
> Sure, they own the servers, they make the rules. I get it. I'm not
> entirely opposed to it, even if I think it's silly to ram something down
> the rest of the groups throats.
>
> Jim
>
> PS: Also, what's with the personal replies? If you don't want to say what
> you want to the whole group, I don't really have an interest in talking to
> you personally.
>

I've had one off-list personal reply in this thread... from you :-p

-- 
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

Re: Cache lookup errors with functions manipulation object addresses

[Alvaro Herrera]

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, 'pg_class'::regclass, 
-8); -- no column for relation
+ type |   schema   |   name   |  identity   
+--++--+-
+ table column | pg_catalog | pg_class | pg_catalog.pg_class
+(1 row)

-- 
Álvaro Herrerahttps://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Re: Code of Conduct plan

[Joshua D. Drake]

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 something the project would get involved in.


O.k. so this isn't clear (at least to me) within the CoC. I want
to make sure I understand. You are saying that if a community
member posts on Twitter that they believe gays are going to hell,
reporting that to the CoC committee would result in a
non-violation UNLESS they referenced postgresql within the post?


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?


Honestly, no. At least not to me especially when you consider the 
sentence right after that, "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 takes precedence (such as a conference's Code of Conduct)."


Based on your clarification, I am feeling better but the language 
doesn't read that way to me.


I wish this was easier but have we considered that all channels that we 
would be concerned with already have CoC's and therefore our CoC is 
fairly powerless? Sure they call them Terms of Use but that's what they 
are, Code of Conducts.


Thanks,

JD

--

Command Prompt, Inc. || http://the.postgres.company/ || @cmdpromptinc
***  A fault and talent of mine is to tell it exactly how it is.  ***
PostgreSQL centered full stack support, consulting and development.
Advocate: @amplifypostgres || Learn: https://postgresconf.org
* Unless otherwise stated, opinions are my own.   *

Re: Code of Conduct plan

[Dave Page]

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 "community at large"? To me that sounds like "all
> interactions" whether or not they're about postgres.
>

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 the code is written. Sooner or later though, the general
consensus prevails and we have to move on, otherwise nothing will ever get
completed.

-- 
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

Re: Code of Conduct plan

[James Keener]

>
> 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 time, defending actions
in this (and potentially other groups who would also adopt overly broad
CoC) group.

One of the biggest drivers of plea-bargains for innocent people in the US
justice system is the expense of having to defend yourself. I find that to
be a travesty; why are we duplicating that at a smaller level?

Jim

Re: when set track_commit_timestamp on, database system abort startup

[Masahiko Sawada]

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();
>  version
> -
>  PostgreSQL 10.5 on x86_64-pc-linux-gnu, compiled by gcc (GCC) 4.4.7
> 20120313 (Red Hat 4.4.7-16), 64-bit
> (1 row)
>
> postgres=# show wal_level ;
>  wal_level
> ---
>  replica
> (1 row)
>
>
> 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 above operation, I've reproduced this issue by
replaying a commit WAL record that sets the timestamp to a new page
during the crash recovery (or from restart).

It seems to me that the cause of this is that we could not extend
commitTs page since the COMMIT_TS_ZEROPAGE WAL wasn't generated at the
standby server whose track_commit_timestamp is off. So during
replaying the commit WAL record the startup process fails since the
corresponding commitTs page doesn't exist.

To fix that maybe we can disable commitTs if
controlFile->track_commit_timestamp == false and the
track_commit_timestamp == true even in crash recovery.

Regards,

--
Masahiko Sawada
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center

Re: Code of Conduct plan

[Chris Travers]

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 revisions to the draft CoC based on
>>> the comments in this thread; see
>>>
>>> https://wiki.postgresql.org/wiki/Code_of_Conduct
>>>
>>> (That's the updated text, but you can use the diff tool on the page
>>> history tab to see the changes from the previous draft.)
>>>
>>
>> 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 takes precedence (such as
>> a conference's Code of Conduct)."
>>
>> That covers things like public twitter messages over live political
>> controversies which might not be personally directed.   At least if one is
>> going to go that route, one ought to *also* include a safe harbor for
>> non-personally-directed discussions of philosophy, social issues, and
>> politics.  Otherwise, I think this is asking for trouble.  See, for
>> example, what happened with Opalgate and how this could be seen to
>> encourage use of this to silence political controversies unrelated to
>> PostgreSQL.
>>
>>
>> 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.
>>
>
> I'm going to regret jumping in here, but...
>
> I disagree. If a community member decides to join forums for other
> software and then strongly promotes PostgreSQL to the point that they
> become abusive or offensive to people making other software choices, then
> they are clearly bringing the project into disrepute and we should have
> every right to sanction them by preventing them participating in our
> project in whatever ways are deemed appropriate.
>

 Actually, the easier case here is not being abusive to MySQL users, as the
code of conduct really doesn't clearly cover that anyway.  The easier case
is where two people have a feud and one person carries on a harassment
campaign over various forms of social media.  The current problem is:

1.  The current code of conduct is not clear as to whether terms of
service/community standards of, say, Reddit, supersede or not, and
2.  The community has to act (even if it is includes behavior at a
conference which has its own code of conduct)

So I think the addition is both over inclusive and under inclusive.   It is
over inclusive because it invites a certain group of (mostly American)
people to pick fights (not saying this is all Americans).  And it is under
inclusive because there are cases where the code of conduct *should* be
employed when behavior includes behavior at events which might have their
own codes of conduct.

On the other side, consider someone carrying on a low-grade harassment
campaign against another community member at a series of conferences where
each conference may not amount to a real actionable concern but where the
pattern as a whole might.  There's the under inclusive bit.

So I don't like this clause because I think it invites problems and doesn't
solve issues.
-- 
Best Wishes,
Chris Travers

Efficito:  Hosted Accounting and ERP.  Robust and Flexible.  No vendor
lock-in.
http://www.efficito.com/learn_more

Re: when set track_commit_timestamp on, database system abort startup

[Alvaro Herrera]

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 above operation, I've reproduced this issue by
> replaying a commit WAL record that sets the timestamp to a new page
> during the crash recovery (or from restart).
> 
> It seems to me that the cause of this is that we could not extend
> commitTs page since the COMMIT_TS_ZEROPAGE WAL wasn't generated at the
> standby server whose track_commit_timestamp is off. So during
> replaying the commit WAL record the startup process fails since the
> corresponding commitTs page doesn't exist.

Hmm, wow.  I wonder if it's possible to detect the config difference
early enough that the zeropage WAL records are emitted, instead.  But
even this might not work, since some transactions need to have their
commitTS in pages that will not have been zeroed anyway, because the
page threshold was crossed in the old primary.

> To fix that maybe we can disable commitTs if
> controlFile->track_commit_timestamp == false and the
> track_commit_timestamp == true even in crash recovery.

Hmm, so keep it off while crash recovery runs, and once it's out of that
then enable it automatically?  That might work -- by definition we don't
care about the commit TSs of the transaction replayed during crash
recovery, since they were executed in the primary that didn't have
commitTS enable anyway.

It seems like the first thing we need is TAP cases that reproduce these
two crash scenarios.

-- 
Álvaro Herrerahttps://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

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

[Alvaro Herrera]

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 it is doing an anti-wrapround
> run.  The log message generated is improved so as one, both or no extra
> details are added depending on the option set.

Hmm, can a for-wraparound vacuum really not be aggressive?  I think one
of those four cases is really dead code.

-- 
Álvaro Herrerahttps://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

ssl tests README and certs

[Dave Cramer]

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

Table renaming does not propagate to views

[Jordan Deitch]

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 the view to reference a particular 
relation by name, not by oid, and so materializing the oid is defective 
behavior.

The following procedure demonstrates:

---
begin;
create table public.test (id varchar(255));
insert into public.test(id) values ('12/12/2009');


create table public.test_new (id varchar(50));
insert into public.test_new(id) select * from test;

create view public.test_v as select count(*) from test;

select * from public.test_v; <-- returns 1

alter table public.test rename to test_depricated;
alter table public.test_new rename to test;

insert into public.test(id) values ('12/12/2010');


select * from public.test_v; <-- (erroneously) returns 1


rollback;
---

Thanks!


-- 
Jordan Deitch
https://id.rsa.pub/

Re: Code of Conduct plan

[Stephen Frost]

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 consider the behavior of individuals as a whole, regardless of
where, when it comes to deciding if it's appropriate for that individual
to continue to be a member of this community.  The CoC isn't about
everyone in the world, nor is it trying to address the actions of
individuals who are not members of this community, but it's definitely
about more than just actions seen on these mailing lists.

> On the other hand if you are (note: contributor, not community member which
> is different) contributor to PostgreSQL, your actions speak about
> PostgreSQL. So I am not sure what a good plan of action here would be.

The line being drawn here isn't terribly clear and I don't know that
it's really useful to try and draw a line.  There's a limit to what PGDG
is able to do from a technical perspective, but anything which is able
to be done within PGDG should be done to distance the community and
project, to the fullest extent possible, from inappropriate behavior.
That could be someone causing problems on IRC or on the mailing lists or
somewhere else, even if that individual isn't listed as a contributor or
involved in the project in other ways.  Naturally, there are different
levels and that's why there's a CoC committee to consider what's fair
and reasonable and at least part of that will probably take into
consideration an individual's role in the community.

> There was a time when Open Source was about code and community. It is clear
> that it is becoming about authority and politics.

This isn't actually anything new, to be clear, this is simply a
definition and documentation to provide clarity and a seperate committee
which Core is delegating out responsibility to.

Thanks,

Stephen


signature.asc
Description: PGP signature

Re: Code of Conduct plan

[Evan Macbeth]

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 those accused of
violations of the code of conduct: Confidentiality, the Good Faith clause
that actually puts risk on those who report behavior under the code, a
scaling of consequences that is weighted *heavily* towards providing second
and third chances to those who may be accused of violating the code.

In the examples that have been raised in this discussion, it would seem to
me to be unreasonable for an investigation to result in a finding that the
code had been violated to the extent that any kind of public consequence
would be warranted. Indeed, were the examples cited to be adjudicated under
this code, I am confident we as a community would discover the code to be
working as designed, rather than the opposite.

If the objection is to the possibility of being reported at all for your
own behavior that you believe is not in violation, that's a different
matter. But if that is the concern, than the objection is not to *this*
code of conduct but to ANY code of conduct, because any code of conduct is
inherently going to introduce risk of being reported for everyone. 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. If you are not willing to defend it in an adjudication
investigation, then you are tacitly (at least) acknowledging the statement
was not in keeping withe standards represented by the code.

This code of conduct as written, in my opinion, merely holds every member
of our community responsible for owning our words and behavior, and the
consequences thereof. I believe that we are adult enough to be willing to
take responsibility for ourselves.

Just my $0.02.

Evan Macbeth


On Fri, Sep 14, 2018 at 8:50 AM, James Keener  wrote:

> 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 reported for saying the above on a 3rd party forum?
>
> Obviously the pg mailing list isn't a place for such discussion, but is
> being a member of this community a deal with the devil to give up my right
> to free speech elsewhere?
>
> Jim
>
>
> On September 14, 2018 6:10:47 AM EDT, Chris Travers <
> chris.trav...@gmail.com> wrote:
>>
>>
>>
>> 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 postgresql.org infrastructure,
>>> so long
>>> > as there is not another Code of Conduct that takes precedence (such as
>>> a
>>> > conference's Code of Conduct)."
>>> >
>>> > That covers things like public twitter messages over live political
>>> > controversies which might not be personally directed.   At least if
>>> one is
>>> > going to go that route, one ought to *also* include a safe harbor for
>>> > non-personally-directed discussions of philosophy, social issues, and
>>> > politics.  Otherwise, I think this is asking for trouble.  See, for
>>> example,
>>> > what happened with Opalgate and how this could be seen to encourage
>>> use of
>>> > this to silence political controversies unrelated to PostgreSQL.
>>>
>>> I think, this point has nothing to do with _correct_ discussions or
>>> public tweets.
>>>
>>> If one community member tweets publicly and in a way which abuses
>>> other community members, it is obvious CoC violation. It is hard to
>>> imagine healthy community if someone interacts with others  correctly
>>> on the list or at a conference because the CoC stops him doing things
>>> which he will do on private capacity to the same people when CoC
>>> doesnt apply.
>>>
>>> If someone reports CoC violation just because other community member's
>>> _correct_ public tweet or whatsoever  expressed different
>>> political/philosophical/religious views, this is a quite different
>>> story. I suppose CoC committee and/or Core team in this case should
>>> explain the reporter the purpose of CoC rather than automatically
>>> enforce it.
>>>
>>
>> So first, I think what the clause is trying to do is address cases where
>> harassment targeting a particular community member takes place outside the
>> infrastructure and frankly ensuring that the code of conduct applies in
>> these cases is important and something I agree with.
>>
>> However, let's look at problem cases:
>>
>> "I am enough of a Marxist to see gender as a qualitative

Re: Code of Conduct plan

[Joshua D. Drake]

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
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 leaving
the community, which would be seen as an admission of
guilt, my only
option.


If you had read the policy, you would know that wouldn't
happen as reports and details of reports are to be kept
confidential.


That doesn't mean I won't be strung along and it doesn't mean that
the attacker can't release those details. Remember, I'm worried
about politically motivated attacks, and attacks meant to silence
opposing viewpoints, not legitimate instances of harassment.


Sure, but an attacker can do that now. Having the CoC doesn't change 
anything there, though it does give us a framework to deal with it.



People are shitheads. People are assholes. We're not
agreeing to join
some organization and sign an ethics clause when signing
up for the mailing
list.  The current moderators can already remove bad
actors from the list.
How they act outside of the list is non of this list's
concern.


The lists are just one of many different ways people in this
community interact.


So? We interact with people outside of specific groups all the
time. Baring specific
agreements to the contrary, why should any one group claim
responsibility of my
personal business?


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 something the project would get involved in.


O.k. so this isn't clear (at least to me) within the CoC. I want to make 
sure I understand. You are saying that if a community member posts on 
Twitter that they believe gays are going to hell, reporting that to the 
CoC committee would result in a non-violation UNLESS they referenced 
postgresql within the post?


JD


--
Command Prompt, Inc. || http://the.postgres.company/ || @cmdpromptinc
***  A fault and talent of mine is to tell it exactly how it is.  ***
PostgreSQL centered full stack support, consulting and development.
Advocate: @amplifypostgres || Learn: https://postgresconf.org
* Unless otherwise stated, opinions are my own.   *

Re: Code of Conduct plan

[Ilya Kosmodemiansky]

> 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.



> . 
> 
> 
>> 
>> -- 
>> Dave Page
>> Blog: http://pgsnake.blogspot.com
>> Twitter: @pgsnake
>> 
>> EnterpriseDB UK: http://www.enterprisedb.com
>> The Enterprise PostgreSQL Company

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

[Andrew Gierth]

 >> Here's what I have queued up to push.

 Daniel> LGTM, thanks!

Committed.

Many thanks for the contribution, and thanks to the reviewers for their
work.

-- 
Andrew (irc:RhodiumToad)

Re: Code of Conduct plan

[Stephen Frost]

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 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 hard
> >to keep
> > > forward progress going, particularly with respect to selecting
> >the initial
> > > committee members.  Now that Magnus is back on shore, I hope we can
> > > wrap it up quickly --- say by the end of August.
> >
> >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
> >
> >https://wiki.postgresql.org/wiki/Code_of_Conduct
> >
> >(That's the updated text, but you can use the diff tool on the page
> >history tab to see the changes from the previous draft.)
> >
> >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 takes precedence (such as a conference's Code of
> >Conduct)."

I was wondering about that myself and rather had an objection to
implying that this CoC doesn't apply when there's a CoC set up for some
event.  The CoC for an event is typically going to be thinking about
things from the event's timeline (which is on the order of days),
whereas something which happened at an event reflects on the community
and should also be addressed at that level.

> I second that objection. It is not in PGDG's remit to cure the world, for
> whatever form of cure you ascribe to. This is especially true as 'community
> member' has no strict definition.

The goal of this CoC isn't to cure the world, it's to define what's
acceptable behavior to continue to be a member of this community, to
participate in this community through the mailing lists, IRC, etc, and
to be seen as a representative of the community/project.

We certainly have both the right and the remit to define who we want to
have in our community and to represent this community and project to
other communities, projects, organizations, and to people in general.
This CoC is about making it clear what's acceptable and what isn't and
making it clear to everyone, including other communities, that we take
conduct seriously and have a mechanism for dealing with issues that's
fair and reasonable.

Thanks!

Stephen


signature.asc
Description: PGP signature

Re: Code of Conduct plan

[Dave Page]

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 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 takes precedence (such as
> a conference's Code of Conduct)."
>
> Not sure how the above can be enforced without someone reporting on what
> is said outside the 'postgresql.org infrastructure'?
>
> At any rate, whether I like it or not the CoC is here to stay. I just feel
> a dissenting opinion is important to the conversation.


I can report someone who steal my wallet to the police. That doesn't mean I
track pick-pockets activity.

-- 
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

Re: Table renaming does not propagate to views

[Tom Lane]

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 their intention in the view to reference a particular 
> relation by name, not by oid, and so materializing the oid is defective 
> behavior.

[ shrug... ]  There's a considerably larger body of people who think
the current behavior is correct; moreover, we've got a couple decades
of backwards compatibility to consider.  I think your odds of convincing
us to change this are nil.

Unfortunately, since the SQL standard lacks any renaming functionality,
it's hard to settle this sort of thing by appealing to outside authority.
However, if they did add RENAME, I bet that they'd make it work as we have
it, because otherwise the standard's notions of dependency and cascaded
drops make no sense.  If we did things as you suggest, then in the
interval between the two renames, what does the view mean?

create view public.test_v as select count(*) from test;
alter table public.test rename to test_depricated;

select * from public.test_v;-- what should happen here?

alter table public.test_new rename to test;

It's pretty clear from the spec's definition of DROP that they don't
intend to allow you to take away any referenced table of a view while
still having the view in existence.  With the reference-by-OID behavior,
RENAME doesn't create an issue for that, but with reference-by-name it
would.

Perhaps you can get the behavior you want by executing dynamic SQL
instead of using a view.

regards, tom lane

Re: Code of Conduct plan

[Joshua D. Drake]

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 Conduct that takes
precedence (such as a conference's Code of Conduct)."


I second that objection. It is not in PGDG's remit to cure the world, for
whatever form of cure you ascribe to. This is especially true as 'community
member' has no strict definition.

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.


Yes but are we to be the School Principal for the world?


these aren't a solution looking for a problem. If we just want to look
at the clusterfuck that is happening in the reddis community right now
we can see conversations spilling onto twitter and into ad hominem
vitriol.


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 complaint departments
3. If it is abuse there are laws

I agree that within Postgresql.org we must have a professional code of 
conduct but the idea that an arbitrary committee appointed by an 
unelected board can decide the fate of a community member based on 
actions outside of the community is a bit authoritarian don't you think?


JD

--
Command Prompt, Inc. || http://the.postgres.company/ || @cmdpromptinc
***  A fault and talent of mine is to tell it exactly how it is.  ***
PostgreSQL centered full stack support, consulting and development.
Advocate: @amplifypostgres || Learn: https://postgresconf.org
* Unless otherwise stated, opinions are my own.   *

Re: Code of Conduct plan

[Peter Geoghegan]

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 complaint departments
> 3. If it is abuse there are laws
>
> I agree that within Postgresql.org we must have a professional code of
> conduct but the idea that an arbitrary committee appointed by an unelected
> board can decide the fate of a community member based on actions outside of
> the community is a bit authoritarian don't you think?

The choice of the committee members is hardly arbitrary. Having
committee members be appointed by core is more or less consistent with
how the community has always dealt with disciplinary issues. The
criteria used by core were discussed quite openly. While the risk that
the committee will yield their power in an "authoritarian" way seems
very small, it cannot be ruled out entirely. In fact, it hasn't been
ruled out by the draft CoC itself.

No CoC can possibly provide for every conceivable situation. Somebody
has to interpret the rules, and it has to be possible to impose
sanctions when the CoC is violated -- otherwise, what's the point?
There are several checks and balances in place, and I for one have
confidence in the process as outlined. It's imperfect, but quite a lot
better than either the status quo, or a platitude about inclusivity.

-- 
Peter Geoghegan

Re: Code of Conduct plan

[Geoff Winkless]

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 group and that will be part of the CoC
> committee will have had to have dedicated their life of pg?
>

No. The core developers get to decide the policy and who is best to enforce
it. It seems fair that the people who have contributed so much get to
decide what goes on in their name.

>
> Sure, they own the servers, they make the rules. I get it. I'm not
> entirely opposed to it, even if I think it's silly to ram something down
> the rest of the groups throats.
>

I agree with you. I'm just fed up with rerunning the same argument every 3
months every time a new CoC update comes out.

PS: Also, what's with the personal replies? If you don't want to say what
> you want to the whole group, I don't really have an interest in talking to
> you personally.
>

Sorry what? I replied offlist to your offlist reply to my onlist post,
since I assumed you had decided (correctly) that this was hardly the sort
of discussion that we should be clogging up other people's mailboxes with.

Geoff

>

Re: Should contrib modules install .h files?

[Peter Eisentraut]

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 SRCDIR/contrib. That'd help give people the right
>>  Tom> coding model to follow.
>>
>> I don't see that playing nicely with PGXS?
> 
> I'm also not on board that my random third-party extension now has to
> refer to its own header files as "subdirectory/headerfile.h".  Which
> will mess up existing extensions that have header files in their tree.
> 
> Or at least I'm not totally sure what the exact proposal and real-world
> implications are, with regard to existing extensions with one or more
> header files.
> 
> By all means, let's make it easier for large or small extensions to
> manage their header files with PGXS.  But let's separate what PGXS can
> and should do from what the extension's own file layout is.
> 
> But I think there are some fundamentally incompatible goals here with
> regard to how the final -I options are supposed to look.

Was this ever resolved?

Seems necessary to resolve for PG11.

-- 
Peter Eisentraut  http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

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

[Alvaro Herrera]

Thanks Rajkumar, Tom, Justin -- pushed fix.

-- 
Álvaro Herrerahttps://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Re: Should contrib modules install .h files?

[Andrew Gierth]

> "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 what's needed for out-of-tree transforms. See the
subthread under this message:

https://www.postgresql.org/message-id/87o9ej8bgl.fsf%40news-spur.riddles.org.uk

Fixing contrib/hstore_plperl etc. to work as examples of how to do
things would obviously first require fixing plperl and plpython, and
while I'm happy to do that I do need feedback first regarding the
plpython headers (I do not use python myself) and the other issues I
mentioned in the message that contains a draft patch.

-- 
Andrew (irc:RhodiumToad)

Re: Code of Conduct plan

[Joshua D. Drake]

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 agree that it is a 
community.


JD


--
Command Prompt, Inc. || http://the.postgres.company/ || @cmdpromptinc
***  A fault and talent of mine is to tell it exactly how it is.  ***
PostgreSQL centered full stack support, consulting and development.
Advocate: @amplifypostgres || Learn: https://postgresconf.org
* Unless otherwise stated, opinions are my own.   *

Re: Code of Conduct plan

[Robert Haas]

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 the code is written. Sooner or later though, the general
> consensus prevails and we have to move on, otherwise nothing will ever get
> completed.

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 entire life.
It is not difficult to imagine that someone's private life might
include "behavior that may bring the PostgreSQL project into
disrepute."

However, I also don't think it matters very much.  The Code of Conduct
Committee is going to consist of small number of people -- at least
four, perhaps a few more.  But there are hundreds of people involved
on the PostgreSQL mailing lists, maybe thousands.  If the Code of
Conduct Committee, or the core team, believes that it can impose on a
very large group of people, all of whom are volunteers, some set of
rules with which they don't agree, it's probably going to find out
pretty quickly that it is mistaken.  If people from that large group
get banned for behavior which is perceived by other members of that
large group to be legitimate, then there will be a ferocious backlash.
Nobody wants to see people who are willing to contribute driven away
from the project, and anyone we drive away without a really good
reason will find some other project that welcomes their participation.
So the only thing that the Code of Conduct Committee is likely to be
able to do in practice is admonish people to be nicer (which is
probably a good thing) and punish really egregious conduct, especially
when committed by people who aren't involved enough that their absence
will be keenly felt.

In practice, therefore, democracy is going to win out.  That's both
good and bad.  It's good because nobody wants a CoC witch-hunt, and
it's bad because there's probably some behavior which legitimately
deserves censure and will escape it.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

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

[Nikolay Shaplov]

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 any option set to non-default
value, and in indexes that use StdRdOptions (and also has any option set)
And there will be more. StdRdOptions is long outdated solution and it needs to
be replaced.


--
Do code for fun.diff --git a/src/backend/access/common/reloptions.c b/src/backend/access/common/reloptions.c
index db84da0..e7e2392 100644
--- a/src/backend/access/common/reloptions.c
+++ b/src/backend/access/common/reloptions.c
@@ -22,7 +22,7 @@
 #include "access/htup_details.h"
 #include "access/nbtree.h"
 #include "access/reloptions.h"
-#include "access/spgist.h"
+#include "access/spgist_private.h"
 #include "access/tuptoaster.h"
 #include "catalog/pg_type.h"
 #include "commands/defrem.h"
@@ -46,9 +46,8 @@
  * upper and lower bounds (if applicable); for strings, consider a validation
  * routine.
  * (ii) add a record below (or use add__reloption).
- * (iii) add it to the appropriate options struct (perhaps StdRdOptions)
- * (iv) add it to the appropriate handling routine (perhaps
- * default_reloptions)
+ * (iii) add it to the appropriate options struct
+ * (iv) add it to the appropriate handling routine
  * (v) make sure the lock level is set correctly for that operation
  * (vi) don't forget to document the option
  *
@@ -1004,7 +1003,7 @@ extractRelOptions(HeapTuple tuple, TupleDesc tupdesc,
 		case RELKIND_TOASTVALUE:
 		case RELKIND_MATVIEW:
 		case RELKIND_PARTITIONED_TABLE:
-			options = heap_reloptions(classForm->relkind, datum, false);
+			options = relation_reloptions(classForm->relkind, datum, false);
 			break;
 		case RELKIND_VIEW:
 			options = view_reloptions(datum, false);
@@ -1337,63 +1336,133 @@ fillRelOptions(void *rdopts, Size basesize,


 /*
- * Option parser for anything that uses StdRdOptions.
+ * Option parsing definition for autovacuum. Used in toast and heap options.
+ */
+
+#define AUTOVACUUM_RELOPTIONS(OFFSET)\
+		{"autovacuum_enabled", RELOPT_TYPE_BOOL, \
+		OFFSET + offsetof(AutoVacOpts, enabled)},\
+		{"autovacuum_vacuum_threshold", RELOPT_TYPE_INT, \
+		OFFSET + offsetof(AutoVacOpts, vacuum_threshold)},   \
+		{"autovacuum_analyze_threshold", RELOPT_TYPE_INT,\
+		OFFSET + offsetof(AutoVacOpts, analyze_threshold)},  \
+		{"autovacuum_vacuum_cost_delay", RELOPT_TYPE_INT,\
+		OFFSET + offsetof(AutoVacOpts, vacuum_cost_delay)},  \
+		{"autovacuum_vacuum_cost_limit", RELOPT_TYPE_INT,\
+		OFFSET + offsetof(AutoVacOpts, vacuum_cost_limit)},  \
+		{"autovacuum_freeze_min_age", RELOPT_TYPE_INT,   \
+		OFFSET + offsetof(AutoVacOpts, freeze_min_age)}, \
+		{"autovacuum_freeze_max_age", RELOPT_TYPE_INT,   \
+		OFFSET + offsetof(AutoVacOpts, freeze_max_age)}, \
+		{"autovacuum_freeze_table_age", RELOPT_TYPE_INT, \
+		OFFSET + offsetof(AutoVacOpts, freeze_table_age)},   \
+		{"autovacuum_multixact_freeze_min_age", RELOPT_TYPE_INT, \
+		OFFSET + offsetof(AutoVacOpts, multixact_freeze_min_age)},   \
+		{"autovacuum_multixact_freeze_max_age", RELOPT_TYPE_INT, \
+		OFFSET + offsetof(AutoVacOpts, multixact_freeze_max_age)},   \
+		{"autovacuum_multixact_freeze_table_age", RELOPT_TYPE_INT,   \
+		OFFSET + offsetof(AutoVacOpts, multixact_freeze_table_age)}, \
+		{"log_autovacuum_min_duration", RELOPT_TYPE_INT, \
+		OFFSET + offsetof(AutoVacOpts, log_min_duration)},   \
+		{"autovacuum_vacuum_scale_factor", RELOPT_TYPE_REAL, \
+		OFFSET + offsetof(AutoVacOpts, vacuum_scale_factor)},\
+		{"autovacuum_analyze_scale_factor", RELOPT_TYPE_REAL,\
+		OFFSET + offsetof(AutoVacOpts, analyze_scale_factor)}
+
+/*
+ * Option parser for heap
  */
 bytea *
-default_reloptions(Datum reloptions, bool validate, relopt_kind kind)
+heap_reloptions(Datum reloptions, bool validate)
 {
 	relopt_value *options;
-	StdRdOptions *rdopts;
+	HeapRelOptions *rdopts;
 	int			numoptions;
 	static const relopt_parse_elt tab[] = {
-		{"fillfactor", RELOPT_TYPE_INT, offsetof(StdRdOptions, fillfactor)},
-		{"autovacuum_enabled", RELOPT_TYPE_BOOL,
-		offsetof(StdRdOptions, autovacuum) + offsetof(AutoVacOpts, enabled)},
-		{"autovacuum_vacuum_threshold", RELOPT_TYPE_INT,
-		offsetof(StdRdOptions, autovacuum) + offsetof(AutoVacOpts, vacuum_threshold)},
-		{"autovacuum_analyze_threshold", RELOPT_TYPE_INT,
-		offsetof(StdRdOptions, autovacuum) + offsetof(AutoVacOpts, analyze_threshold)},
-		{"autovacuum_vacuum_cost_delay", RELOPT_TYPE_INT,
-		offsetof(StdRdOptions, autovacuum) + offsetof(AutoVacOpts, vacuum_cost_delay)},
-		{"autovacuum_vacuum_cost_limit", RELOPT_TYPE_INT,
-	

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

[Robert Haas]

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 consequences down the road.  Or so I would
>> think, anyway.
>
> I don't have the mind set to work on that today (enough Windows-ism for
> the day), but I would rather use the clever solution because, as far as
> I know, we want a back-patchable solution so things should not be
> invasive.

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 non-invasive.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

Delta Materialized View Refreshes?

[Jeremy Finzel]

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
everything that goes with it.

Couldn't this be coded to only update changed records?  As an example, we
have a materialized view definition that holds summarized data on customer
records, and it only changes when new customers are added.  It would be so
nice to only write that change.

I recognize that it may take longer, but for our environment as I'm sure is
true of many others, we are often much more excited about reducing write
churn than read churn.

If in fact it could be option, I am curious if we could leverage the work
being done on the merge functionality to do a "merge" from the materialized
view definition into the actual persistent object.

If people really like the current functionality, then at least it could be
an option like REFRESH MATERIALIZED VIEW DELTA or something - I dunno I am
more interested in just having the feature!

Many thanks for any thoughts on this subject.
Jeremy

Logical replication to partitioned subscriber

[Jeremy Finzel]

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 just work transparently with logical replication.

Another use case is to convert a huge OLTP database table to be
partitioned, and as opposed to writing a script, use logical replication to
replicate to a destination replica which has the partitioning work done
online, then swap nodes.

We are using pglogical, but I see from the docs that the same limitations
apply even in pg11's built-in logical replication.

Thanks!
Jeremy

Re: Delta Materialized View Refreshes?

[Jordan Deitch]

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 
propagate correctly to the MV. 


-- 
Jordan Deitch
https://id.rsa.pub/

Re: Consistent segfault in complex query

[Tom Lane]

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 paths to probe in these tests.

Thanks!  I incorporated these into the attached proposed patches.

The main difference from what I had yesterday is that I rewrote
ExecEvalParamExecParams to my satisfaction.  The crucial thing I didn't
like about it was that it hard-wired use of the GetPerTupleExprContext
econtext for initplan evaluation.  That seemed like it risked memory
leaks in case of repeated initplan evaluation for a single top-level
output tuple.  I've since convinced myself that it's basically impossible
to leak memory in ExecSetParamPlan right now (cf comments below), but
that doesn't seem like an assumption to bake into an API when it isn't
even buying us anything to do so.

The attached is split into two parts because 0001 will need to go all
the way back, whereas 0002 only applies to HEAD and v11.  I don't
plan to make them separate commits though.

A quick test says that back-patching 0001 might be slightly painful;
a lot of the hunks don't apply.  I've not looked at why not.

regards, tom lane

diff --git a/src/backend/executor/execMain.c b/src/backend/executor/execMain.c
index c583e02..0074014 100644
*** a/src/backend/executor/execMain.c
--- b/src/backend/executor/execMain.c
***
*** 46,51 
--- 46,52 
  #include "commands/matview.h"
  #include "commands/trigger.h"
  #include "executor/execdebug.h"
+ #include "executor/nodeSubplan.h"
  #include "foreign/fdwapi.h"
  #include "mb/pg_wchar.h"
  #include "miscadmin.h"
*** EvalPlanQualBegin(EPQState *epqstate, ES
*** 3078,3083 
--- 3079,3092 
  		{
  			int			i;
  
+ 			/*
+ 			 * Force evaluation of any InitPlan outputs that could be needed
+ 			 * by the subplan, just in case they got reset since
+ 			 * EvalPlanQualStart (see comments therein).
+ 			 */
+ 			ExecSetParamPlanMulti(planstate->plan->extParam,
+   GetPerTupleExprContext(parentestate));
+ 
  			i = list_length(parentestate->es_plannedstmt->paramExecTypes);
  
  			while (--i >= 0)
*** EvalPlanQualStart(EPQState *epqstate, ES
*** 3170,3178 
--- 3179,3210 
  	{
  		int			i;
  
+ 		/*
+ 		 * Force evaluation of any InitPlan outputs that could be needed by
+ 		 * the subplan.  (With more complexity, maybe we could postpone this
+ 		 * till the subplan actually demands them, but it doesn't seem worth
+ 		 * the trouble; this is a corner case already, since usually the
+ 		 * InitPlans would have been evaluated before reaching EvalPlanQual.)
+ 		 *
+ 		 * This will not touch output params of InitPlans that occur somewhere
+ 		 * within the subplan tree, only those that are attached to the
+ 		 * ModifyTable node or above it and are referenced within the subplan.
+ 		 * That's OK though, because the planner would only attach such
+ 		 * InitPlans to a lower-level SubqueryScan node, and EPQ execution
+ 		 * will not descend into a SubqueryScan.
+ 		 *
+ 		 * The EState's per-output-tuple econtext is sufficiently short-lived
+ 		 * for this, since it should get reset before there is any chance of
+ 		 * doing EvalPlanQual again.
+ 		 */
+ 		ExecSetParamPlanMulti(planTree->extParam,
+ 			  GetPerTupleExprContext(parentestate));
+ 
+ 		/* now make the internal param workspace ... */
  		i = list_length(parentestate->es_plannedstmt->paramExecTypes);
  		estate->es_param_exec_vals = (ParamExecData *)
  			palloc0(i * sizeof(ParamExecData));
+ 		/* ... and copy down all values, whether really needed or not */
  		while (--i >= 0)
  		{
  			/* copy value if any, but not execPlan link */
diff --git a/src/backend/executor/nodeSubplan.c b/src/backend/executor/nodeSubplan.c
index 6b37075..63de981 100644
*** a/src/backend/executor/nodeSubplan.c
--- b/src/backend/executor/nodeSubplan.c
*** ExecInitSubPlan(SubPlan *subplan, PlanSt
*** 1009,1014 
--- 1009,1025 
   * of initplans: we don't run the subplan until/unless we need its output.
   * Note that this routine MUST clear the execPlan fields of the plan's
   * output parameters after evaluating them!
+  *
+  * The results of this function are stored in the EState associated with the
+  * ExprContext (particularly, its ecxt_param_exec_vals); any pass-by-ref
+  * result Datums are allocated in the EState's per-query memory.  The passed
+  * econtext can be any ExprContext belonging to that EState; which one is
+  * important only to the extent that the ExprContext's per-tuple memory
+  * context is used to evaluate any parameters passed down to the subplan.
+  * (Thus in principle, the shorter-lived the ExprContext the better, since
+  * that data isn't needed after we return.  In practice, because initplan
+  * parameters are never more complex th

Re: pg_dump test instability

[Peter Eisentraut]

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 me.

-- 
Peter Eisentraut  http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Re: Code of Conduct plan

[Tom Lane]

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 entire life.

There's been quite a lot of input, from quite a lot of people, dating
back at least as far as a well-attended session at PGCon 2016.  I find
it quite upsetting to hear accusations that core is imposing this out
of nowhere.  From my perspective, we're responding to a real need
voiced by other people, not so much by us.

> However, I also don't think it matters very much.

Yeah, this.  The PG community is mostly nice people, AFAICT.  I'll be
astonished (and worried) if the CoC committee finds much to do.  We're
implementing this mostly to make newcomers to the project feel that
it's a safe space.

It's also worth reminding people that this is v1.0 of the CoC document.
We plan to revisit it in a year or so, and thereafter as needed, to
improve anything that's causing problems or not working well.

regards, tom lane

Re: Delta Materialized View Refreshes?

[Jeremy Finzel]

>
>
> 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 propagate correctly to the MV.
>

That's not what I had in mind.  I only mean when REFRESH MATERIALIZED VIEW
is run, it gathers the results of the view in memory, then instead of
essentially "wiping and reloading" the table, it would only write the
differences.  So if 90% of the rows would be the same as before the
refresh, we only update 10% of the rows.

This would also mean materialized views could get bloated just like tables.

Thanks,
Jeremy

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

[Tom Lane]

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 non-invasive.

This argument would hold more water if it weren't that "stat" is already
a macro in our Windows port:

#ifndef UNSAFE_STAT_OK
extern int  pgwin32_safestat(const char *path, struct stat *buf);
#define stat(a,b) pgwin32_safestat(a,b)
#endif

Admittedly, a macro with params will fire in fewer places than one
without, but claiming that the current situation is entirely surprise-free
seems wrong.

I also think that you're underestimating the value of continuing to spell
"struct stat" in the standard way.  People know what that is, if they've
done any Unix programming before, whereas "pg_struct_stat" requires some
learning.

More, I can just about guarantee that even if we make the substitution
today, new occurrences of "struct stat" will sneak in via patches, because
not everybody will remember this PG-ism all the time.  Yeah, probably the
buildfarm will find those mistakes, but maybe not quickly or reliably ---
I think it'd only show up as a warning not an error, which isn't going to
be something we'd notice easily.

So I'm not buying that "#define stat" is so evil it should be rejected
out of hand.  It may be that it doesn't work for some reason, but we
should at least test it.

regards, tom lane

Re: Delta Materialized View Refreshes?

[Isaac Morland]

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. Otherwise a change to the underlying
>> table may not propagate correctly to the MV.
>>
>
> That's not what I had in mind.  I only mean when REFRESH MATERIALIZED VIEW
> is run, it gathers the results of the view in memory, then instead of
> essentially "wiping and reloading" the table, it would only write the
> differences.  So if 90% of the rows would be the same as before the
> refresh, we only update 10% of the rows.
>

On a related note, I've mused about allowing a WHERE clause on REFRESH
MATERIALIZED VIEW. To start with, I imagine limiting it to refer to the
columns of a primary key (which implies that primary key constraints would
have to be allowed). As long as this is done, I think it's pretty clear
what the semantics would have to be, at least as to the new view contents:
the equivalent of DELETE with the WHERE clause, followed by INSERT of the
view expression with the same WHERE clause applied.

Re: Logical replication to partitioned subscriber

[Alvaro Herrera]

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 partitioned on the archive server, and we want it
> to just work transparently with logical replication.
> 
> Another use case is to convert a huge OLTP database table to be
> partitioned, and as opposed to writing a script, use logical replication to
> replicate to a destination replica which has the partitioning work done
> online, then swap nodes.
> 
> We are using pglogical, but I see from the docs that the same limitations
> apply even in pg11's built-in logical replication.

As I understand, in pglogical you can set pglogical.use_spi and it
Should Work(tm).

As for built-in replication, I'm afraid there's a small patch required
to make it work, and nobody wrote it for pg11.

-- 
Álvaro Herrerahttps://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Re: pg_dump test instability

[Tom Lane]

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 committable ...

> Yes, this looks good to me.

Pushed, thanks for reviewing.

regards, tom lane

Defaulting to jit=on/off for v11

[Andres Freund]

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 disabled by
default. It seems the time for that has come.


I think there's several angles to this:

* Enabling by default will give far greater exposure, making it much
  more likely that we'll fix bugs earlier, meaning fewer people will be
  caught later when they already thought everything should be perfectly
  stable.  We'll want to enable the feature by default at some point, so
  that'd be good way to get there fast.

* There's a number of cases where JIT compilation triggers over-eagerly:
  In particular when costs are widely off (e.g. in the regression tests
  due to an un-analyzed table), or when the majority of the cost is
  incurred from things like enable_*=off.  That can cause slowdowns.  If
  we had caching of JITed code, that'd not be that bad, but we don't.

* There's a substantial risk that the JIT feature has bugs - it was
  largely written by a single person (i.e. me), nontrivial and there
  definitely have been features that have been more widely reviewed.

* Disabling it by default will prevent people from "automatically"
  benefiting.


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. Those would be too high for cases that want to benefit fully,
   but would reduce the risk - although it also probably makes it
   harder to easily hit problematic cases.


I personally can see reasons to go with either of these, and don't have
a real preference myself.


Comments?


Greetings,

Andres Freund

Re: Defaulting to jit=on/off for v11

[Tom Lane]

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. Those would be too high for cases that want to benefit fully,
>but would reduce the risk - although it also probably makes it
>harder to easily hit problematic cases.

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.

regards, tom lane

Re: move PartitionDispatchData definition to execPartition.c

[Alvaro Herrera]

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: Defaulting to jit=on/off for v11

[Jonathan S. Katz]

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 substantially, so it triggers in far fewer
>>cases. Those would be too high for cases that want to benefit fully,
>>but would reduce the risk - although it also probably makes it
>>harder to easily hit problematic cases.
> 
> 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.

First, I'm going to say I'm a huge fan of this feature and I'm excited
for the ongoing work.

From doing some testing, I hit a substantial performance loss on a query
that would be considered part of the critical path of a system. I'm sure
getting the costing right would help, but also that query did contain
expressions that could benefit from JIT compilation. My concern would be
 that other apps have queries that would make them start to under perform.

The nice thing is you can enable jit on a per query basis if needed -
more work for the user, but I think safer in the first release than
having it on by default.

+1 to option #2.

Jonathan



signature.asc
Description: OpenPGP digital signature

Re: Defaulting to jit=on/off for v11

[Peter Geoghegan]

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

[Tom Lane]

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