Re: [HACKERS] Re: In-core regression tests for replication, cascading, archiving, PITR, etc.

[Amir Rohan]

On 10/07/2015 09:27 AM, Michael Paquier wrote:
> On Wed, Oct 7, 2015 at 7:51 AM, Michael Paquier
>  wrote:
>> On Wed, Oct 7, 2015 at 7:43 AM, Michael Paquier
>>  wrote:
>>> On Wed, Oct 7, 2015 at 5:58 AM, Robert Haas wrote:
 On Sat, Oct 3, 2015 at 7:38 AM, Michael Paquier wrote:
 It seems that these days 'make check' creates a directory in /tmp
 called /tmp/pg_regress-RANDOMSTUFF.  Listening on TCP ports is
 disabled, and the socket goes inside this directory with a name like
 .s.PGSQL.PORT.  You can connect with psql -h
 /tmp/pg_regress-RANDOMSTUFF -p PORT, but not over TCP.  This basically
 removes the risk of TCP port number collisions, as well as the risk of
 your temporary instance being hijacked by a malicious user on the same
 machine.
>>>
>>> Right, that's for example /var/folders/ on OSX, and this is defined
>>> once per test run via $tempdir_short. PGHOST is set to that as well.
>>
>> Er, mistake here. That's actually once per standard_initdb, except
>> that all the tests I have included in my patch run it just once to
>> create a master node. It seems that it would be wiser to set one
>> socket dir per node then, remove the port assignment stuff, and use
>> tempdir_short as a key to define a node as well as in the connection
>> string to this node. I'll update the patch later today...
> 
> So, my conclusion regarding multiple calls of make_master is that we
> should not allow to do it. On Unix/Linux we could have a separate unix
> socket directory for each node, but not on Windows where
> listen_addresses is set to look after 127.0.0.1. On Unix/Linux, PGHOST
> is set by the master node to a tempdir once and for all. Hence, to
> make the code more consistent, I think that we should keep the port
> lookup machinery here. An updated patch is attached.
> 

If parallel tests are supported, get_free_port is still racy even
with last_port_found because it's:
1) process-local.
2) even if it were shared, there's the race window between the
available-check and the listen() I mentioned upthread.

If parallel tests are explicitly disallowed, a comment to that
effect (and a note on things known to break) might help someone
down the road.

Also, the removal of poll_query_until from pg_rewind looks suspiciously
like a copy-paste gone bad. Pardon if I'm missing something.

Amir



-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Re: In-core regression tests for replication, cascading, archiving, PITR, etc.

[Michael Paquier]

On Wed, Oct 7, 2015 at 4:16 PM, Amir Rohan  wrote:
> On 10/07/2015 09:27 AM, Michael Paquier wrote:
>> On Wed, Oct 7, 2015 at 7:51 AM, Michael Paquier
>>  wrote:
>>> On Wed, Oct 7, 2015 at 7:43 AM, Michael Paquier
>>>  wrote:
 On Wed, Oct 7, 2015 at 5:58 AM, Robert Haas wrote:
> On Sat, Oct 3, 2015 at 7:38 AM, Michael Paquier wrote:
> It seems that these days 'make check' creates a directory in /tmp
> called /tmp/pg_regress-RANDOMSTUFF.  Listening on TCP ports is
> disabled, and the socket goes inside this directory with a name like
> .s.PGSQL.PORT.  You can connect with psql -h
> /tmp/pg_regress-RANDOMSTUFF -p PORT, but not over TCP.  This basically
> removes the risk of TCP port number collisions, as well as the risk of
> your temporary instance being hijacked by a malicious user on the same
> machine.

 Right, that's for example /var/folders/ on OSX, and this is defined
 once per test run via $tempdir_short. PGHOST is set to that as well.
>>>
>>> Er, mistake here. That's actually once per standard_initdb, except
>>> that all the tests I have included in my patch run it just once to
>>> create a master node. It seems that it would be wiser to set one
>>> socket dir per node then, remove the port assignment stuff, and use
>>> tempdir_short as a key to define a node as well as in the connection
>>> string to this node. I'll update the patch later today...
>>
>> So, my conclusion regarding multiple calls of make_master is that we
>> should not allow to do it. On Unix/Linux we could have a separate unix
>> socket directory for each node, but not on Windows where
>> listen_addresses is set to look after 127.0.0.1. On Unix/Linux, PGHOST
>> is set by the master node to a tempdir once and for all. Hence, to
>> make the code more consistent, I think that we should keep the port
>> lookup machinery here. An updated patch is attached.
>>
> If parallel tests are supported, get_free_port is still racy even
> with last_port_found because it's:
> 1) process-local.
> 2) even if it were shared, there's the race window between the
> available-check and the listen() I mentioned upthread.
>
> If parallel tests are explicitly disallowed, a comment to that
> effect (and a note on things known to break) might help someone
> down the road.

Actually, no, port lookup will not map and parallel tests would work
fine thinking more about it, each set of tests uses its own PGHOST to
a private unix socket directory so even if multiple tests use the same
port number they won't interact with each other because they connect
to different socket paths. MinGW is a problem though, and an existing
one in the perl test scripts, I recall that it can use make -j and
that's on Windows where PGHOST is mapping to 127.0.0.1 only.

> Also, the removal of poll_query_until from pg_rewind looks suspiciously
> like a copy-paste gone bad. Pardon if I'm missing something.

Perhaps. Do you have a suggestion regarding that? It seems to me that
this is more useful in TestLib.pm as-is.
-- 
Michael


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Re: In-core regression tests for replication, cascading, archiving, PITR, etc.

[Craig Ringer]

On 25 September 2015 at 14:29, Michael Paquier
 wrote:

> I also arrived at the conclusion that it would be
> better to place the new package file in src/test/perl instead of
> src/test/recovery to allow any users of the TAP tests to have it in their
> PERL5LIB path and to be able to call the new routines to create and
> manipulate nodes.

While it's Python not Perl, you might find it interesting that support
for the replication protocol is being added to psycopg2, the Python
driver for PostgreSQL. I've been reviewing the patch at
https://github.com/psycopg/psycopg2/pull/322 .

I'm using it to write protocol validation for a logical decoding
plugin at the moment, so that the decoding plugin's output can be
validated in a consistent way for easily controlled inputs.

Perhaps it's worth teaching DBD::Pg to do this? Or adopting psycopg2
for some optional protocol tests...

-- 
 Craig Ringer   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] pg_ctl/pg_rewind tests vs. slow AIX buildfarm members

[Michael Paquier]

On Sat, Sep 26, 2015 at 9:12 AM, Tom Lane wrote:
> So the attached modified patch adjusts the PID-match logic and some
> comments, but is otherwise what I posted before.  I believe that this
> might actually work on Windows, but I have no way to test it.  Someone
> please try that?  (Don't forget to test the service-start path, too.)

If "pg_ctl start" is invoked directly from a command prompt, it works.
Now, if I run "pg_ctl start" within a script (in an msysgit
environment for example), pg_ctl fails, complaining that
postmaster.pid already exists. The TAP tests get broken as well,
attached are the log files of the run, and here is an interested bit:
# Running: pg_ctl start -D
C:\Users\ioltas\git\postgres\src\bin\pg_ctl\tmp_testor2K/data -w
waiting for server to start... stopped waiting
not ok 12 - pg_ctl start -w
#   Failed test 'pg_ctl start -w'
#   at C:/Users/ioltas/git/postgres/src/test/perl/TestLib.pm line 282.
# Running: pg_ctl start -D
C:\Users\ioltas\git\postgres\src\bin\pg_ctl\tmp_testor2K/data -w
waiting for server to start...FATAL:  lock file "postmaster.pid" already exists
HINT:  Is another postmaster (PID 4040) running in data directory
"C:/Users/ioltas/git/postgres/src/bin/pg_ctl/tmp_testor2K/data"?
LOG:  database system was shut down at 2015-10-06 23:58:02 PDT
LOG:  MultiXact member wraparound protections are now enabled
FATAL:  the database system is starting up
LOG:  database system is ready to accept connections
LOG:  autovacuum launcher started
 stopped waiting
Registering a service to the SCM works, but the service registered
refuses to start.
Regards,
-- 
Michael


regress_log_001_start_stop
Description: Binary data


regress_log_002_status
Description: Binary data

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Foreign join pushdown vs EvalPlanQual

[Kyotaro HORIGUCHI]

Hello,

At Wed, 7 Oct 2015 00:24:57 -0400, Robert Haas  wrote in 

> On Wed, Oct 7, 2015 at 12:10 AM, Kyotaro HORIGUCHI
>  wrote:
> >> IIUC, I think that if ROW_MARK_COPY is in use, the descriptor would
> >> have 6 columns: those 4, plus a whole-row var for ft1 and another
> >> whole-row bar for ft2.  Maybe I'm missing something, though.
> >
> > You're right. The result tuple for the Robert's example has 6
> > attributes in the order of [ft1.a, ft1.b, (ft1.a, ft1.b), ft2.a...]
> >
> > But the point of the discussion is in another point. The problem
> > is when such joins are joined with another local table. For such
> > case, the whole-row reference for the intermediate foreign-join
> > would lose the targets in top-level tuple.
> 
> Really?  Would that mean that ROW_MARK_COPY is totally broken?  I bet it's 
> not.

The semantics of ROW_MARK_COPY is the tuple should hold whole-row
*value* as in resjunk column. I should misunderstood "whole row
*reference*" by confising planner and executor behaviors. I
understood the new story as adding to a tuple a reference to
itself. If it is wrong and the correct story is having additional
whole-row *value* in the whole joined tuple including resjunks
passed from the underlying tuples, it should work.

> >> > 4, plus a whole-row reference for ROW_MARK_COPY.  If we know what
> >> > values we're going to store in columns 1..4, couldn't we just form
> >> > them into a tuple to populate column 5? We don't actually need to be
> >> > able to fetch such a tuple from the remote side because we can just
> >> > construct it.  I think.
> >>
> >> I also was thinking whether we could replace one of the whole-row vars
> >> with a whole-row var that represents the scan slot of the
> >> ForeignScanState node.
> >
> > I suppose it requires additional resjunk to be added on joinrel
> > creation, which is what Kaigai-san said as overkill. But I'm
> > interedted in what it looks.
> 
> I think it rather requires *replacing* two resjunk columns by one new
> one.  The whole-row references for the individual foreign tables are
> only there to support EvalPlanQual; if we instead have a column to
> populate the foreign scan's slot directly, then we can use that column
> for that purpose directly and there's no remaining use for the
> whole-row vars on the baserels.

It is what I had in mind. Target lists for joinrels cannot be
built straight-forward way as it is.

regards,

-- 
Kyotaro Horiguchi
NTT Open Source Software Center



-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

[HACKERS] [PATCH] Documentation bug in 9.5/ master - pg_replication_origin_session_setup

[Pallavi Sontakke]

Hi All,

There appears to be a typo error in documentation of this function. Actual
function is 'pg_replication_origin_session_setup' while documentation has
it as 'pg_replication_origin_setup_session'.

Please find patch for 9.5 and master attached.

Thanks,
Pallavi
diff --git a/doc/src/sgml/func.sgml b/doc/src/sgml/func.sgml
index 262f5ee..48af3ec 100644
--- a/doc/src/sgml/func.sgml
+++ b/doc/src/sgml/func.sgml
@@ -17411,7 +17411,7 @@ postgres=# SELECT * FROM pg_xlogfile_name_offset(pg_stop_backup());
 
  pg_replication_origin_session_setup
 
-pg_replication_origin_setup_session(node_name text)
+pg_replication_origin_session_setup(node_name text)


 void
diff --git a/doc/src/sgml/func.sgml b/doc/src/sgml/func.sgml
index 897ed64..e0503c1 100644
--- a/doc/src/sgml/func.sgml
+++ b/doc/src/sgml/func.sgml
@@ -17436,7 +17436,7 @@ postgres=# SELECT * FROM pg_xlogfile_name_offset(pg_stop_backup());
 
  pg_replication_origin_session_setup
 
-pg_replication_origin_setup_session(node_name text)
+pg_replication_origin_session_setup(node_name text)


 void

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Foreign join pushdown vs EvalPlanQual

[Etsuro Fujita]

On 2015/10/07 15:06, Kyotaro HORIGUCHI wrote:

At Wed, 7 Oct 2015 00:24:57 -0400, Robert Haas  wrote

I think it rather requires *replacing* two resjunk columns by one new
one.  The whole-row references for the individual foreign tables are
only there to support EvalPlanQual; if we instead have a column to
populate the foreign scan's slot directly, then we can use that column
for that purpose directly and there's no remaining use for the
whole-row vars on the baserels.



It is what I had in mind.


OK  I'll investigate this further.

Best regards,
Etsuro Fujita



--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Re: In-core regression tests for replication, cascading, archiving, PITR, etc.

[Michael Paquier]

On Wed, Oct 7, 2015 at 7:51 AM, Michael Paquier
 wrote:
> On Wed, Oct 7, 2015 at 7:43 AM, Michael Paquier
>  wrote:
>> On Wed, Oct 7, 2015 at 5:58 AM, Robert Haas wrote:
>>> On Sat, Oct 3, 2015 at 7:38 AM, Michael Paquier wrote:
>>> It seems that these days 'make check' creates a directory in /tmp
>>> called /tmp/pg_regress-RANDOMSTUFF.  Listening on TCP ports is
>>> disabled, and the socket goes inside this directory with a name like
>>> .s.PGSQL.PORT.  You can connect with psql -h
>>> /tmp/pg_regress-RANDOMSTUFF -p PORT, but not over TCP.  This basically
>>> removes the risk of TCP port number collisions, as well as the risk of
>>> your temporary instance being hijacked by a malicious user on the same
>>> machine.
>>
>> Right, that's for example /var/folders/ on OSX, and this is defined
>> once per test run via $tempdir_short. PGHOST is set to that as well.
>
> Er, mistake here. That's actually once per standard_initdb, except
> that all the tests I have included in my patch run it just once to
> create a master node. It seems that it would be wiser to set one
> socket dir per node then, remove the port assignment stuff, and use
> tempdir_short as a key to define a node as well as in the connection
> string to this node. I'll update the patch later today...

So, my conclusion regarding multiple calls of make_master is that we
should not allow to do it. On Unix/Linux we could have a separate unix
socket directory for each node, but not on Windows where
listen_addresses is set to look after 127.0.0.1. On Unix/Linux, PGHOST
is set by the master node to a tempdir once and for all. Hence, to
make the code more consistent, I think that we should keep the port
lookup machinery here. An updated patch is attached.
-- 
Michael
diff --git a/src/bin/pg_rewind/RewindTest.pm b/src/bin/pg_rewind/RewindTest.pm
index a4c1737..ea219d7 100644
--- a/src/bin/pg_rewind/RewindTest.pm
+++ b/src/bin/pg_rewind/RewindTest.pm
@@ -125,38 +125,6 @@ sub check_query
 	}
 }
 
-# Run a query once a second, until it returns 't' (i.e. SQL boolean true).
-sub poll_query_until
-{
-	my ($query, $connstr) = @_;
-
-	my $max_attempts = 30;
-	my $attempts = 0;
-	my ($stdout, $stderr);
-
-	while ($attempts < $max_attempts)
-	{
-		my $cmd = [ 'psql', '-At', '-c', "$query", '-d', "$connstr" ];
-		my $result = run $cmd, '>', \$stdout, '2>', \$stderr;
-
-		chomp($stdout);
-		$stdout =~ s/\r//g if $Config{osname} eq 'msys';
-		if ($stdout eq "t")
-		{
-			return 1;
-		}
-
-		# Wait a second before retrying.
-		sleep 1;
-		$attempts++;
-	}
-
-	# The query result didn't change in 30 seconds. Give up. Print the stderr
-	# from the last attempt, hopefully that's useful for debugging.
-	diag $stderr;
-	return 0;
-}
-
 sub append_to_file
 {
 	my ($filename, $str) = @_;
diff --git a/src/test/Makefile b/src/test/Makefile
index b713c2c..d6e51eb 100644
--- a/src/test/Makefile
+++ b/src/test/Makefile
@@ -17,7 +17,7 @@ SUBDIRS = regress isolation modules
 # We don't build or execute examples/, locale/, or thread/ by default,
 # but we do want "make clean" etc to recurse into them.  Likewise for ssl/,
 # because the SSL test suite is not secure to run on a multi-user system.
-ALWAYS_SUBDIRS = examples locale thread ssl
+ALWAYS_SUBDIRS = examples locale thread ssl recovery
 
 # We want to recurse to all subdirs for all standard targets, except that
 # installcheck and install should not recurse into the subdirectory "modules".
diff --git a/src/test/perl/RecoveryTest.pm b/src/test/perl/RecoveryTest.pm
new file mode 100644
index 000..cbd2441
--- /dev/null
+++ b/src/test/perl/RecoveryTest.pm
@@ -0,0 +1,410 @@
+package RecoveryTest;
+
+# Set of common routines for recovery regression tests for a PostgreSQL
+# cluster. This includes global variables and methods that can be used
+# by the various set of tests present to set up cluster nodes and
+# configure them according to the test scenario wanted.
+#
+# Cluster nodes can be freely created using initdb or using the existing
+# base backup of another node, with minimum configuration done when the
+# node is created for the first time like having a proper port number.
+# It is then up to the test to decide what to do with the newly-created
+# node.
+#
+# Environment configuration of each node is available through a set
+# of global variables provided by this package, hashed depending on the
+# port number of a node:
+# - connstr_nodes connection string to connect to this node
+# - datadir_nodes to get the data folder of a given node
+# - archive_nodes for the location of the WAL archives of a node
+# - backup_nodes for the location of base backups of a node
+# - applname_nodes, application_name to use for a standby
+#
+# Nodes are identified by their port number, which should be unique
+# for each node of the cluster as it is run locally.
+
+use Cwd;
+use TestLib;
+use Test::More;
+
+use Archive::Tar;
+use IPC::Run qw(run start);
+
+use Exporter 'import';
+

Re: [HACKERS] Re: In-core regression tests for replication, cascading, archiving, PITR, etc.

[Amir Rohan]

On 10/07/2015 10:29 AM, Michael Paquier wrote:
> On Wed, Oct 7, 2015 at 4:16 PM, Amir Rohan  wrote:
>> On 10/07/2015 09:27 AM, Michael Paquier wrote:
>>> On Wed, Oct 7, 2015 at 7:51 AM, Michael Paquier
>>>  wrote:
 On Wed, Oct 7, 2015 at 7:43 AM, Michael Paquier
  wrote:
> On Wed, Oct 7, 2015 at 5:58 AM, Robert Haas wrote:
>> On Sat, Oct 3, 2015 at 7:38 AM, Michael Paquier wrote:
>> It seems that these days 'make check' creates a directory in /tmp
>> called /tmp/pg_regress-RANDOMSTUFF.  Listening on TCP ports is
>> disabled, and the socket goes inside this directory with a name like
>> .s.PGSQL.PORT.  You can connect with psql -h
>> /tmp/pg_regress-RANDOMSTUFF -p PORT, but not over TCP.  This basically
>> removes the risk of TCP port number collisions, as well as the risk of
>> your temporary instance being hijacked by a malicious user on the same
>> machine.
>
> Right, that's for example /var/folders/ on OSX, and this is defined
> once per test run via $tempdir_short. PGHOST is set to that as well.

 Er, mistake here. That's actually once per standard_initdb, except
 that all the tests I have included in my patch run it just once to
 create a master node. It seems that it would be wiser to set one
 socket dir per node then, remove the port assignment stuff, and use
 tempdir_short as a key to define a node as well as in the connection
 string to this node. I'll update the patch later today...
>>>
>>> So, my conclusion regarding multiple calls of make_master is that we
>>> should not allow to do it. On Unix/Linux we could have a separate unix
>>> socket directory for each node, but not on Windows where
>>> listen_addresses is set to look after 127.0.0.1. On Unix/Linux, PGHOST
>>> is set by the master node to a tempdir once and for all. Hence, to
>>> make the code more consistent, I think that we should keep the port
>>> lookup machinery here. An updated patch is attached.
>>>
>> If parallel tests are supported, get_free_port is still racy even
>> with last_port_found because it's:
>> 1) process-local.
>> 2) even if it were shared, there's the race window between the
>> available-check and the listen() I mentioned upthread.
>>
>> If parallel tests are explicitly disallowed, a comment to that
>> effect (and a note on things known to break) might help someone
>> down the road.
> 
> Actually, no, port lookup will not map and parallel tests would work
> fine thinking more about it, each set of tests uses its own PGHOST to
> a private unix socket directory so even if multiple tests use the same
> port number they won't interact with each other because they connect
> to different socket paths. MinGW is a problem though, and an existing
> one in the perl test scripts, I recall that it can use make -j and
> that's on Windows where PGHOST is mapping to 127.0.0.1 only.
> 

ah, the portnum is actually a real tcp port only on windows, and
the race is limited to that case as you say. Note that in the
tcp case, using psql to check is wrong:
$ nc -l 8001  # listen on 8001
$ psql -X -h lo -p 8001 postgres < /dev/null psql: could not connect to
server: Connection refused
Is the server running on host "lo" (127.0.0.1) and accepting
TCP/IP connections on port 8001?

The port isn't free, but psql is really only checking if pg is there
and reports that the port is available. That's a fairly mild issue, though.

>> Also, the removal of poll_query_until from pg_rewind looks suspiciously
>> like a copy-paste gone bad. Pardon if I'm missing something.
> 
> Perhaps. Do you have a suggestion regarding that? It seems to me that
> this is more useful in TestLib.pm as-is.
> 

My mistake, the patch only shows some internal function being deleted
but RewindTest.pm (obviously) imports TestLib. You're right, TestLib is
a better place for it.




-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] RLS bug in expanding security quals

[Stephen Frost]

Haribabu,

* Haribabu Kommi (kommi.harib...@gmail.com) wrote:
> During the testing of multi-tenancy feature from system catalog views, that
> is described in [1], found a problem in executing "user_privileges" view
> from information_schema. The following is the minimal test sql that
> reproduces the problem.

Interesting, thanks.

> >From further analysis, I found that the same issue can happen with user
> tables also. Attached
> rls_failure.sql file has test steps to reproduce the issue.

Just to make sure we're on the same page, this results in this assertion
being tripped:

TRAP: FailedAssertion("!(var->varattno <= rel->max_attr)", File:
"/home/sfrost/git/pg/dev/postgresql/src/backend/optimizer/path/costsize.c",
Line: 4152)

Due to var->varattno being 1 and rel->max_attr being 0.

> The problem is, while expanding security quals in
> function expand_security_quals, the relation
> u_grantor and test_tbl are to be expanded as they are the relations which
> have security quals.
> 
> Following is the debug information of parse->rtable that shows the details
> of each RangeTblEntry.
> 
> $69 = {type = T_Alias, aliasname = 0x19bd870 "u_grantor", colnames =
> 0x19bd890}
> (gdb) p *((RangeTblEntry
> *)parse->rtable->head->next->next->next->data.ptr_value)->eref
> $70 = {type = T_Alias, aliasname = 0x19bffc8 "grantee", colnames =
> 0x19bffe0}
> (gdb) p *((RangeTblEntry
> *)parse->rtable->head->next->next->next->next->data.ptr_value)->eref
> $71 = {type = T_Alias, aliasname = 0x19c3a60 "*SELECT* 1", colnames =
> 0x19c3a80}
> (gdb) p *((RangeTblEntry
> *)parse->rtable->head->next->next->next->next->next->data.ptr_value)->eref
> $72 = {type = T_Alias, aliasname = 0x19c40d8 "*SELECT* 2", colnames =
> 0x19c40f8}
> (gdb) p *((RangeTblEntry
> *)parse->rtable->head->next->next->next->next->next->next->data.ptr_value)->eref
> $73 = {type = T_Alias, aliasname = 0x19c4648 "test_tbl", colnames =
> 0x19c4668}
> 
> 
> In expand_security_qual function, the security_barrier_replace_vars
> function is called to prepare the context.targetlist. But this function
> doesn't generate targetlist for test_tbl RangeTblEntry. Because of this
> reason, while accessing the targetlist, it fails and throws an error.
> 
> In case if the policy is changed to below other than specified in the
> rls_failure.sql
> 
> create policy test_tbl_policy on test_tbl for select using(true);
> 
> the query execution passes, because in expand_security_quals function,
> the rangeTableEntry_used function returns false for test_tbl entry, thus it
> avoids expanding the security qual.

Interesting.

> Any ideas how to handle this problem?

It's quite late here, but I'll take a look at this in more depth
tomorrow.

Based on what the Assert's testing, I took an educated guess and tried
running without the UNION ALL, which appeared to work correctly.

Thanks!

Stephen


signature.asc
Description: Digital signature

Re: [HACKERS] cash_mul_int8 / cash_div_int8

[Michael Paquier]

On Thu, Oct 8, 2015 at 12:11 AM, Kohei KaiGai  wrote:
> Also, cash_pl, cash_mi, cash_mul_int4 and so on... does not have overflow 
> checks
> like as int8pl has.
>
> Of course, most of people don't need to worry about 64bit overflow for
> money... :-).

If you are using Zimbabwean dollar that's an issue:
https://en.wikipedia.org/wiki/Zimbabwean_dollar#Hyperinflation
-- 
Michael


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] PATCH: index-only scans with partial indexes

[Kyotaro HORIGUCHI]

Hello,

> The attached patch applies on the latest v5 patch and will
> address above issues. (And modifies expected files, which are the
> manifestation of this improovement).

As you see, it is a quite bad choice. Ugly and unreadable and
fragile.

The cause of this seeming mismatch would be the place to hold
indexrinfos. It is determined only by baserestrictinfo and
indpred. Any other components are not involved. So IndexClauseSet
is found not to be the best place after all, I suppose.

Instead, I came to think that the better place is
IndexOptInfo. Partial indexes are examined in check_partial_index
and it seems to be the most proper place to check this so far.

Thougts?

regards,


At Tue, 06 Oct 2015 15:12:02 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI 
 wrote in 
<20151006.151202.58051959.horiguchi.kyot...@lab.ntt.co.jp>
> Hello,
> 
> At Thu, 01 Oct 2015 01:36:51 +0200, Tomas Vondra 
>  wrote in <560c7213.3010...@2ndquadrant.com>
> > > Good point. I think we may simply point indexrinfos to the existing
> > > list
> > > of restrictions in that case - we don't need to copy it. So no
> > > additional memory / CPU consumption, and it should make the code
> > > working
> > > with it a bit simpler.
> > 
> > Attached is v5 of the patch improving the comments (rephrasing, moving
> > before function etc.).
> 
> Looks good (for me).
> 
> > I also attempted to fix the issue with empty list for non-partial
> > indexes by simply setting it to rel->baserestrictinfo in
> > match_restriction_clauses_to_index (for non-partial indexes),
> 
> Although it is not the cause of these errors (or any errors on
> regress), build_paths_for_OR (which doesn't seem to be called in
> regression tests) doesn't set indexrinfos
> properly. match_clauses_to_index can commonize(?) the process in
> return for additional list copy and concat.  The attached diff is
> doing in the latter method. Avoiding the copies will make the
> code a bit complicated.
> 
> But anyway regtests doesn't say whether it is sane or not:( (TODO)
> 
> > but that
> > results in a bunch of
> > 
> >ERROR:  variable not found in subplan target list
> > 
> > during "make installcheck". I can't quite wrap my head around why.
> 
> During considerartion on parameterized joins in
> get_join_index_paths, caluseset fed to get_index_paths is
> generated from given join (j|e)clausesets. So completing the
> clauseset with necessary restrictinfo from rcaluseset fixes the
> problem.
> 
> The attached patch applies on the latest v5 patch and will
> address above issues. (And modifies expected files, which are the
> manifestation of this improovement).

-- 
Kyotaro Horiguchi
NTT Open Source Software Center
>From 9801a9e83a108cead33c843021d604fc8b5defcc Mon Sep 17 00:00:00 2001
From: Kyotaro Horiguchi 
Date: Wed, 30 Sep 2015 09:04:36 +0900
Subject: [PATCH] Use IndexOptInfo to store index rinfos.

Instead of IndexClauseSet, this patch stores rinfos excluding clauses
implied by index predicates (indexrinfos) into IndexOptInfo. The
reason to do there is that the indexrinfos are determined only by base
restrictinfos on parent relation and index predicates. IndexClauseSet
is used several places irrelevant to such things.
---
 src/backend/optimizer/path/costsize.c|  5 ++-
 src/backend/optimizer/path/indxpath.c| 66 +++-
 src/backend/optimizer/util/pathnode.c|  1 +
 src/include/nodes/relation.h |  7 
 src/test/regress/expected/aggregates.out |  8 +---
 5 files changed, 69 insertions(+), 18 deletions(-)

diff --git a/src/backend/optimizer/path/costsize.c b/src/backend/optimizer/path/costsize.c
index 1b61fd9..ce042ac 100644
--- a/src/backend/optimizer/path/costsize.c
+++ b/src/backend/optimizer/path/costsize.c
@@ -88,6 +88,7 @@
 #include "optimizer/placeholder.h"
 #include "optimizer/plancat.h"
 #include "optimizer/planmain.h"
+#include "optimizer/predtest.h"
 #include "optimizer/restrictinfo.h"
 #include "parser/parsetree.h"
 #include "utils/lsyscache.h"
@@ -383,7 +384,7 @@ cost_index(IndexPath *path, PlannerInfo *root, double loop_count)
 		path->path.rows = path->path.param_info->ppi_rows;
 		/* qpquals come from the rel's restriction clauses and ppi_clauses */
 		qpquals = list_concat(
-	   extract_nonindex_conditions(baserel->baserestrictinfo,
+	   extract_nonindex_conditions(path->indexrinfos,
    path->indexquals),
 			  extract_nonindex_conditions(path->path.param_info->ppi_clauses,
 		  path->indexquals));
@@ -392,7 +393,7 @@ cost_index(IndexPath *path, PlannerInfo *root, double loop_count)
 	{
 		path->path.rows = baserel->rows;
 		/* qpquals come from just the rel's restriction clauses */
-		qpquals = extract_nonindex_conditions(baserel->baserestrictinfo,
+		qpquals = extract_nonindex_conditions(path->indexrinfos,
 			  path->indexquals);
 	}
 
diff --git 

Re: [HACKERS] More work on SortSupport for text - strcoll() and strxfrm() caching

[Peter Geoghegan]

On Tue, Oct 6, 2015 at 1:16 PM, Robert Haas  wrote:
> If you would care to revise the patch accordingly, I will commit it
> (barring objections from others, of course).

Here is a revision of 0001-*, with both BSWAP32() and BSWAP64() in a
new header, src/port/pg_bswap.h.

No revisions were required to any other patch in the patch series to
make this work, and so I only include a revised 0001-*.

-- 
Peter Geoghegan
From f671bbccc1eb2a7ecb5c64925630a5593f888a9d Mon Sep 17 00:00:00 2001
From: Peter Geoghegan 
Date: Mon, 29 Jun 2015 23:53:05 -0400
Subject: [PATCH 1/4] Provide for unsigned comparisons of abbreviated keys

Add ABBREV_STRING_UINT() macro to allow string-like types to represent
abbreviated keys as unsigned integers.  ABBREV_STRING_UINT() will use
the new BSWAP64() byte swapping macro (also introduced in this commit)
on 64-bit little-endian platforms, or the existing BSWAP32() macro on
32-bit platforms.

In future commits, certain types with abbreviation support will call
ABBREV_STRING_UINT() to perform a final conversion process on their
string-like abbreviated keys.  This makes it safe and portable to
implement the abbreviated key comparator as a simple 3-way unsigned
integer comparator, which must also be changed.  By using an
exceptionally cheap abbreviated comparator, a significant boost in sort
performance can be seen for these types on at least some platforms.
---
 config/c-compiler.m4| 18 ++
 configure   | 24 +++
 configure.in|  1 +
 src/include/pg_config.h.in  |  3 +++
 src/include/pg_config.h.win32   |  3 +++
 src/include/port/pg_bswap.h | 46 +++
 src/include/port/pg_crc32c.h| 12 ++
 src/include/utils/sortsupport.h | 53 +
 8 files changed, 150 insertions(+), 10 deletions(-)
 create mode 100644 src/include/port/pg_bswap.h

diff --git a/config/c-compiler.m4 b/config/c-compiler.m4
index 9feec0c..550d034 100644
--- a/config/c-compiler.m4
+++ b/config/c-compiler.m4
@@ -214,6 +214,24 @@ fi])# PGAC_C_BUILTIN_BSWAP32
 
 
 
+# PGAC_C_BUILTIN_BSWAP64
+# -
+# Check if the C compiler understands __builtin_bswap64(),
+# and define HAVE__BUILTIN_BSWAP64 if so.
+AC_DEFUN([PGAC_C_BUILTIN_BSWAP64],
+[AC_CACHE_CHECK(for __builtin_bswap64, pgac_cv__builtin_bswap64,
+[AC_COMPILE_IFELSE([AC_LANG_SOURCE(
+[static unsigned long int x = __builtin_bswap64(0xaabbccddeeff0011);]
+)],
+[pgac_cv__builtin_bswap64=yes],
+[pgac_cv__builtin_bswap64=no])])
+if test x"$pgac_cv__builtin_bswap64" = xyes ; then
+AC_DEFINE(HAVE__BUILTIN_BSWAP64, 1,
+  [Define to 1 if your compiler understands __builtin_bswap64.])
+fi])# PGAC_C_BUILTIN_BSWAP64
+
+
+
 # PGAC_C_BUILTIN_CONSTANT_P
 # -
 # Check if the C compiler understands __builtin_constant_p(),
diff --git a/configure b/configure
index 99ef10f..b771a83 100755
--- a/configure
+++ b/configure
@@ -11259,6 +11259,30 @@ if test x"$pgac_cv__builtin_bswap32" = xyes ; then
 $as_echo "#define HAVE__BUILTIN_BSWAP32 1" >>confdefs.h
 
 fi
+{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for __builtin_bswap64" >&5
+$as_echo_n "checking for __builtin_bswap64... " >&6; }
+if ${pgac_cv__builtin_bswap64+:} false; then :
+  $as_echo_n "(cached) " >&6
+else
+  cat confdefs.h - <<_ACEOF >conftest.$ac_ext
+/* end confdefs.h.  */
+static unsigned long int x = __builtin_bswap64(0xaabbccddeeff0011);
+
+_ACEOF
+if ac_fn_c_try_compile "$LINENO"; then :
+  pgac_cv__builtin_bswap64=yes
+else
+  pgac_cv__builtin_bswap64=no
+fi
+rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext
+fi
+{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $pgac_cv__builtin_bswap64" >&5
+$as_echo "$pgac_cv__builtin_bswap64" >&6; }
+if test x"$pgac_cv__builtin_bswap64" = xyes ; then
+
+$as_echo "#define HAVE__BUILTIN_BSWAP64 1" >>confdefs.h
+
+fi
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for __builtin_constant_p" >&5
 $as_echo_n "checking for __builtin_constant_p... " >&6; }
 if ${pgac_cv__builtin_constant_p+:} false; then :
diff --git a/configure.in b/configure.in
index 4143451..b5868b0 100644
--- a/configure.in
+++ b/configure.in
@@ -1317,6 +1317,7 @@ PGAC_C_FUNCNAME_SUPPORT
 PGAC_C_STATIC_ASSERT
 PGAC_C_TYPES_COMPATIBLE
 PGAC_C_BUILTIN_BSWAP32
+PGAC_C_BUILTIN_BSWAP64
 PGAC_C_BUILTIN_CONSTANT_P
 PGAC_C_BUILTIN_UNREACHABLE
 PGAC_C_VA_ARGS
diff --git a/src/include/pg_config.h.in b/src/include/pg_config.h.in
index dda73a8..a20e0cd 100644
--- a/src/include/pg_config.h.in
+++ b/src/include/pg_config.h.in
@@ -660,6 +660,9 @@
 /* Define to 1 if your compiler understands __builtin_bswap32. */
 #undef HAVE__BUILTIN_BSWAP32
 
+/* Define to 1 if your compiler understands __builtin_bswap64. */
+#undef HAVE__BUILTIN_BSWAP64
+
 /* Define to 1 if your compiler understands __builtin_constant_p. */
 #undef HAVE__BUILTIN_CONSTANT_P
 
diff --git 

[HACKERS] RLS bug in expanding security quals

[Haribabu Kommi]

During the testing of multi-tenancy feature from system catalog views, that
is described in [1], found a problem in executing "user_privileges" view
from information_schema. The following is the minimal test sql that
reproduces the problem.

SELECT (u_grantor.rolname) AS grantor,  (grantee.rolname) AS grantee
  FROM  pg_authid u_grantor,

  ( SELECT pg_authid.oid,

  pg_authid.rolname

 FROM pg_authid

  UNION ALL

  SELECT (0)::oid AS oid,

   'PUBLIC'::name) grantee(oid, rolname)
WHERE
(grantee.rolname = 'PUBLIC'::name)

>From further analysis, I found that the same issue can happen with user
tables also. Attached
rls_failure.sql file has test steps to reproduce the issue.

The problem is, while expanding security quals in
function expand_security_quals, the relation
u_grantor and test_tbl are to be expanded as they are the relations which
have security quals.

Following is the debug information of parse->rtable that shows the details
of each RangeTblEntry.

$69 = {type = T_Alias, aliasname = 0x19bd870 "u_grantor", colnames =
0x19bd890}
(gdb) p *((RangeTblEntry
*)parse->rtable->head->next->next->next->data.ptr_value)->eref
$70 = {type = T_Alias, aliasname = 0x19bffc8 "grantee", colnames =
0x19bffe0}
(gdb) p *((RangeTblEntry
*)parse->rtable->head->next->next->next->next->data.ptr_value)->eref
$71 = {type = T_Alias, aliasname = 0x19c3a60 "*SELECT* 1", colnames =
0x19c3a80}
(gdb) p *((RangeTblEntry
*)parse->rtable->head->next->next->next->next->next->data.ptr_value)->eref
$72 = {type = T_Alias, aliasname = 0x19c40d8 "*SELECT* 2", colnames =
0x19c40f8}
(gdb) p *((RangeTblEntry
*)parse->rtable->head->next->next->next->next->next->next->data.ptr_value)->eref
$73 = {type = T_Alias, aliasname = 0x19c4648 "test_tbl", colnames =
0x19c4668}


In expand_security_qual function, the security_barrier_replace_vars
function is called to prepare the context.targetlist. But this function
doesn't generate targetlist for test_tbl RangeTblEntry. Because of this
reason, while accessing the targetlist, it fails and throws an error.

In case if the policy is changed to below other than specified in the
rls_failure.sql

create policy test_tbl_policy on test_tbl for select using(true);

the query execution passes, because in expand_security_quals function,
the rangeTableEntry_used function returns false for test_tbl entry, thus it
avoids expanding the security qual.

Any ideas how to handle this problem?

Regards,
Hari Babu
Fujitsu Australia

[1] -
http://www.postgresql.org/message-id/cajrrpgd2cf4hz_edpx+uqjv1ytkajs_wjdiwj7pzzuuqwou...@mail.gmail.com


rls_failure.sql
Description: Binary data

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] RLS bug in expanding security quals

[Haribabu Kommi]

On Thu, Oct 8, 2015 at 2:54 PM, Stephen Frost  wrote:
> Haribabu,
>
> * Haribabu Kommi (kommi.harib...@gmail.com) wrote:
>> During the testing of multi-tenancy feature from system catalog views, that
>> is described in [1], found a problem in executing "user_privileges" view
>> from information_schema. The following is the minimal test sql that
>> reproduces the problem.
>
> Interesting, thanks.
>
>> >From further analysis, I found that the same issue can happen with user
>> tables also. Attached
>> rls_failure.sql file has test steps to reproduce the issue.
>
> Just to make sure we're on the same page, this results in this assertion
> being tripped:
>
> TRAP: FailedAssertion("!(var->varattno <= rel->max_attr)", File:
> "/home/sfrost/git/pg/dev/postgresql/src/backend/optimizer/path/costsize.c",
> Line: 4152)
>
> Due to var->varattno being 1 and rel->max_attr being 0.

Yes, the same the assertion problem with assert build.

without assert build, query fails with the following error.

ERROR:  invalid attnum -2 for rangetable entry test_tbl


>> Any ideas how to handle this problem?
>
> It's quite late here, but I'll take a look at this in more depth
> tomorrow.
>
> Based on what the Assert's testing, I took an educated guess and tried
> running without the UNION ALL, which appeared to work correctly.

Yes, it works fine without UNION ALL.

And also if we change the table column datatype from name to char,
the "pull_up_subqueries" function doesn't pull the union all because of
datatype mismatch and it works fine even with row level security is enabled.

Regards,
Hari Babu
Fujitsu Australia


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Re: In-core regression tests for replication, cascading, archiving, PITR, etc.

[Michael Paquier]

On Wed, Oct 7, 2015 at 5:44 PM, Amir Rohan wrote:
> On 10/07/2015 10:29 AM, Michael Paquier wrote:
>> On Wed, Oct 7, 2015 at 4:16 PM, Amir Rohan wrote:
>>> Also, the removal of poll_query_until from pg_rewind looks suspiciously
>>> like a copy-paste gone bad. Pardon if I'm missing something.
>>
>> Perhaps. Do you have a suggestion regarding that? It seems to me that
>> this is more useful in TestLib.pm as-is.
>>
>
> My mistake, the patch only shows some internal function being deleted
> but RewindTest.pm (obviously) imports TestLib. You're right, TestLib is
> a better place for it.

OK. Here is a new patch version. I have removed the restriction
preventing to call make_master multiple times in the same script (one
may actually want to test some stuff related to logical decoding or
FDW for example, who knows...), forcing PGHOST to always use the same
value after it has been initialized. I have added a sanity check
though, it is not possible to create a node based on a base backup if
no master are defined. This looks like a cheap insurance... I also
refactored a bit the code, using the new init_node_info to fill in the
fields of a newly-initialized node, and I removed get_free_port,
init_node, init_node_from_backup, enable_restoring and
enable_streaming from the list of routines exposed to the users, those
can be used directly with make_master, make_warm_standby and
make_hot_standby. We could add them again if need be, somebody may
want to be able to get a free port, set up a node without those
generic routines, just that it does not seem necessary now.
Regards,
-- 
Michael
diff --git a/src/bin/pg_rewind/RewindTest.pm b/src/bin/pg_rewind/RewindTest.pm
index a4c1737..ea219d7 100644
--- a/src/bin/pg_rewind/RewindTest.pm
+++ b/src/bin/pg_rewind/RewindTest.pm
@@ -125,38 +125,6 @@ sub check_query
 	}
 }
 
-# Run a query once a second, until it returns 't' (i.e. SQL boolean true).
-sub poll_query_until
-{
-	my ($query, $connstr) = @_;
-
-	my $max_attempts = 30;
-	my $attempts = 0;
-	my ($stdout, $stderr);
-
-	while ($attempts < $max_attempts)
-	{
-		my $cmd = [ 'psql', '-At', '-c', "$query", '-d', "$connstr" ];
-		my $result = run $cmd, '>', \$stdout, '2>', \$stderr;
-
-		chomp($stdout);
-		$stdout =~ s/\r//g if $Config{osname} eq 'msys';
-		if ($stdout eq "t")
-		{
-			return 1;
-		}
-
-		# Wait a second before retrying.
-		sleep 1;
-		$attempts++;
-	}
-
-	# The query result didn't change in 30 seconds. Give up. Print the stderr
-	# from the last attempt, hopefully that's useful for debugging.
-	diag $stderr;
-	return 0;
-}
-
 sub append_to_file
 {
 	my ($filename, $str) = @_;
diff --git a/src/test/Makefile b/src/test/Makefile
index b713c2c..d6e51eb 100644
--- a/src/test/Makefile
+++ b/src/test/Makefile
@@ -17,7 +17,7 @@ SUBDIRS = regress isolation modules
 # We don't build or execute examples/, locale/, or thread/ by default,
 # but we do want "make clean" etc to recurse into them.  Likewise for ssl/,
 # because the SSL test suite is not secure to run on a multi-user system.
-ALWAYS_SUBDIRS = examples locale thread ssl
+ALWAYS_SUBDIRS = examples locale thread ssl recovery
 
 # We want to recurse to all subdirs for all standard targets, except that
 # installcheck and install should not recurse into the subdirectory "modules".
diff --git a/src/test/perl/RecoveryTest.pm b/src/test/perl/RecoveryTest.pm
new file mode 100644
index 000..baa4d31
--- /dev/null
+++ b/src/test/perl/RecoveryTest.pm
@@ -0,0 +1,412 @@
+package RecoveryTest;
+
+# Set of common routines for recovery regression tests for a PostgreSQL
+# cluster. This includes global variables and methods that can be used
+# by the various set of tests present to set up cluster nodes and
+# configure them according to the test scenario wanted.
+#
+# Cluster nodes can be freely created using initdb or using the existing
+# base backup of another node, with minimum configuration done when the
+# node is created for the first time like having a proper port number.
+# It is then up to the test to decide what to do with the newly-created
+# node.
+#
+# Environment configuration of each node is available through a set
+# of global variables provided by this package, hashed depending on the
+# port number of a node:
+# - connstr_nodes connection string to connect to this node
+# - datadir_nodes to get the data folder of a given node
+# - archive_nodes for the location of the WAL archives of a node
+# - backup_nodes for the location of base backups of a node
+# - applname_nodes, application_name to use for a standby
+#
+# Nodes are identified by their port number, which should be unique
+# for each node of the cluster as it is run locally.
+
+use Cwd;
+use TestLib;
+use Test::More;
+
+use Archive::Tar;
+use IPC::Run qw(run start);
+
+use Exporter 'import';
+
+our @EXPORT = qw(
+	%connstr_nodes
+	%datadir_nodes
+	%backup_nodes
+	%archive_nodes
+	%applname_nodes
+
+	append_to_file
+	backup_node
+	disable_node
+	dump_node_info
+	enable_archiving
+	enable_node
+	

Re: [HACKERS] bugs and bug tracking

[Craig Ringer]

On 7 October 2015 at 02:33, Nathan Wagner  wrote:

> I think even with a bug tracker the default "ignore" behavior can still
> be done.  In principle, we could even mark bugs as "unconfirmed" or
> "logged" or something right away and only mark them as new or open or
> something if they actually draw a reply.

IMO it'd need to be a reply with a keyword or something, because if
you look at the bug history, a whole lot of bugs get replies of "what
version is this anyway? And what exact steps did you take?". Then
trail off as the submitter doesn't respond, or sends more
unintelligible gibberish.

-- 
 Craig Ringer   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] btreecheck extension

[Bernd Helmle]

--On 16. Juni 2014 18:47:30 -0700 Peter Geoghegan  wrote:

> Attached prototype patch adds contrib extension, btreecheck. This
> extension provides SQL-callable functions for checking these
> conditions on nbtree indexes on live systems.

What's the current state of this module? I see you are interested in stress
testing, but i'm not sure how far this all is gone? 

This tool actually served a very good job during identifying index
corruption due to collation issues[1].

[1]


-- 
Thanks

Bernd


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] btreecheck extension

[Peter Geoghegan]

On Wed, Oct 7, 2015 at 2:59 AM, Bernd Helmle  wrote:
> What's the current state of this module? I see you are interested in stress
> testing, but i'm not sure how far this all is gone?
>
> This tool actually served a very good job during identifying index
> corruption due to collation issues[1].

I tweaked it a bit. I actually don't really know if I'll pick it up
anytime soon. I'm glad that it helped you, but the goals for the tool
need to be thrashed out a bit more. We should discuss it again.

-- 
Peter Geoghegan


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] bugs and bug tracking

[Craig Ringer]

On 6 October 2015 at 21:05, Nathan Wagner  wrote:

> A lot of the reports aren't bugs at all, but requests for help.  My
> guess is that the users either don't know where to ask or don't
> understand the difference between a bug and not knowing how to do what
> they want to do.  Perhaps a more thorough explaination on the submission
> form would be useful.

Based on experience elsewhere, not even "unless you are absolutely
certain this is a bug, post to pgsql-general" would work.

Unless there's a "post to pgsql-general" text box right there,
forum-like. Because that's the point IMO: it's easier to post to a web
form than think about mailing lists and subscriptions. You can't just
go "click, send". People are going to consistently ignore the fact
that it's a bug report form when there's no corresponding "ask a
question" web form.

I'm not really advocating a "send a question" web form though. More
like a link to Stack Overflow or something like that.


-- 
 Craig Ringer   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] pg_dump LOCK TABLE ONLY question

[Filip Rembiałkowski]

Oct 2 2015 01:19 "Michael Paquier"  wrote:
>
> On Thu, Oct 1, 2015 at 10:43 PM, Filip Rembiałkowski  <
filip.rembialkow...@gmail.com> wrote:
> > I just want to understand why there is LOCK TABLE not LOCK TABLE ONLY.
>
> It seems to me that you'd still want to use LOCK TABLE particularly if
> the dump is only done on a subset of tables, using --table for
> example.

Right. But please consider this use case, when I have to dunp only given
schema, nothing more and nothing less.

Is --schema option not just for that?

Locking child tables seems a bit counter-intuitive.

COPY does not touch child tables, also.

Re: [HACKERS] Small documentation fix in src/interfaces/ecpg/preproc/po/pt_BR.po

[Robert Haas]

On Tue, Oct 6, 2015 at 6:49 PM, Andreas 'ads' Scherbaum
 wrote:
> When working on a script, I stumbled over a mistake in the pt_BR.po
> translation for ecpg. Patch attached.

Translations are sync'd to the main repository from the translations
project - so I assume this needs to be submitted there, but I don't
know how.

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


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] pg_ctl/pg_rewind tests vs. slow AIX buildfarm members

[Tom Lane]

Michael Paquier  writes:
> On Sat, Sep 26, 2015 at 9:12 AM, Tom Lane wrote:
>> So the attached modified patch adjusts the PID-match logic and some
>> comments, but is otherwise what I posted before.  I believe that this
>> might actually work on Windows, but I have no way to test it.  Someone
>> please try that?  (Don't forget to test the service-start path, too.)

> If "pg_ctl start" is invoked directly from a command prompt, it works.
> Now, if I run "pg_ctl start" within a script (in an msysgit
> environment for example), pg_ctl fails, complaining that
> postmaster.pid already exists. The TAP tests get broken as well,

Hm, the TAP trace makes it look like the postmaster start does actually
work, but pg_ctl isn't correctly waiting for that to happen.  (The
complaint about "already exists" seems to be from the second start
attempt, and is exactly what to expect there.)  I could believe that
I'd fat-fingered the PID comparison logic in test_postmaster_connection,
but I don't understand how it would work from a command prompt but not
from a script.  Any ideas?

regards, tom lane


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Small documentation fix in src/interfaces/ecpg/preproc/po/pt_BR.po

[Bruce Momjian]

On Wed, Oct  7, 2015 at 08:00:43AM -0400, Robert Haas wrote:
> On Tue, Oct 6, 2015 at 6:49 PM, Andreas 'ads' Scherbaum
>  wrote:
> > When working on a script, I stumbled over a mistake in the pt_BR.po
> > translation for ecpg. Patch attached.
> 
> Translations are sync'd to the main repository from the translations
> project - so I assume this needs to be submitted there, but I don't
> know how.

I think the details are here:

https://wiki.postgresql.org/wiki/NLS

-- 
  Bruce Momjian  http://momjian.us
  EnterpriseDB http://enterprisedb.com

+ As you are, so once was I. As I am, so you will be. +
+ Roman grave inscription +


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] bugs and bug tracking

[Stephen Frost]

Magnus,

* Magnus Hagander (mag...@hagander.net) wrote:
> On Wed, Oct 7, 2015 at 4:40 PM, Stephen Frost  wrote:
> > * Nathan Wagner (nw...@hydaspes.if.org) wrote:
> > > I think I have suggested that there be a way to generate a bug id via
> > > email.  Presumably someone could just copy that email address to make a
> > > not-tracked discussion get a bug id.  If the system archived all the
> > > lists (not hard) it would be possible to pull the other emails from the
> > > thread into the bug (also not hard).  As for marking as 'not-a-bug'
> > > this can easily be done via whatever mechanism might be used.
> > > Something along the lines of:
> > >
> > > Bug Status: not a bug
> >
> > If we're providing control messages through email (which I absolutely
> > believe needs to be supported), I'd strongly prefer that they be easy to
> > write.  The above isn't.
> >
> > A good set of commands to support can be seen here:
> >
> > https://www.debian.org/Bugs/server-control
> >
> > The way debbugs currently works, which I like, is that you email
> > -d...@bugs.debian.org ( being the bug #) and that automatically
> > closes the bug and that email is sent to the bug reporter.  Generally,
> > this will be in a reply to an email which came from, or at least CC'd,
> > n...@bugs.debian.org, so changing the address to go to -done is quite
> > easy.
> 
> 
> If I understand that correct, it completely breaks the current workflow of
> "reply-all"? When I need to comment on a bug, isntead of hitting reply-all,
> i should send it to the @bugs address? Or are you saying in those cases you
> still hit reply-all but just edit the actual address?

This, imv anyway, is why I need to just set it up and show people how it
works.

reply-all works just fine, since you like to know *exactly* how it works
at a technical level, I just checked and the bug email address is
automatically included in the Reply-To: header rather than being CC'd
or From.  The bug submitter's email is also in the Reply-To.

Please understand that, at least in my experience, Debian's workflows
are *very* similar to ours.  They just hammered out these questions
about how to make it work over the past 15 years that we've been writing
a database. ;)

> (FWIW, I think editing the actual address is nowhere near as easy as just
> adding a Status:  to the message itself. It's likely easier to
> deal with on the *server* side, but it's definitely not easier for the
> user. Especially if you're in a MUA that doesn't let you easily edit a mail
> address (hello gmail! which is quite a few of our users..)

An email to control@ with

close 1234

*is* also supported, but the Debian folks prefer using -done since the
email to -done always goes to the submitter, whereas using 'close 1234'
means you have to make sure you also email the submitter.  That's
certainly possible, but if you weren't on the bug originally for
whatever reason then you have to go get the submitter's email address,
etc.

My MUA makes changing an email To: line really easy and since I'm one of
the users of that part of the system, I like it.

One thing that's important to understand is that this system (in
particular, the email interface) is *not* for our users (more
specifically, it's not for the individuals who submit bugs via the bug
form).

It's for *us*.

Thanks!

Stephen


signature.asc
Description: Digital signature

[HACKERS] cash_mul_int8 / cash_div_int8

[Kohei KaiGai]

I noticed cash_mul_int8 / cash_div_int8 are defined in cash.c,
however, pg_proc.h and pg_operator.h contains no relevant entries.

Is it just a careless oversight?

Thanks,
-- 
KaiGai Kohei 


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] pg_ctl/pg_rewind tests vs. slow AIX buildfarm members

[Tom Lane]

Michael Paquier  writes:
> On Sat, Sep 26, 2015 at 9:12 AM, Tom Lane wrote:
>> So the attached modified patch adjusts the PID-match logic and some
>> comments, but is otherwise what I posted before.  I believe that this
>> might actually work on Windows, but I have no way to test it.  Someone
>> please try that?  (Don't forget to test the service-start path, too.)

> If "pg_ctl start" is invoked directly from a command prompt, it works.
> Now, if I run "pg_ctl start" within a script (in an msysgit
> environment for example), pg_ctl fails, complaining that
> postmaster.pid already exists. The TAP tests get broken as well,

Reading that again, I think you mean that "pg_ctl start" works but you
didn't try "pg_ctl start -w" manually?  Because it's "-w" that's at
issue here, and the failing test cases are using that.

After studying the test logs more carefully, I think the behavior they're
showing is consistent with the idea that postmaster_is_alive() doesn't
work on the CMD shell process.  Which seems very likely now that I think
about it, because we're depending on an implementation of kill() that
is PG-specific.

So in fact this idea doesn't work :-(.

I think there is still room to salvage something without fully rewriting
the postmaster invocation logic to avoid using CMD, because it's still
true that checking whether the CMD process is still there should be as
good as checking the postmaster proper.  We just can't use kill() for it.
I'd be inclined to get rid of the use of kill() on Unix as well; as Noah
mentioned upthread, if we're using fork/exec we might as well pay
attention to waitpid's results instead.  On Windows, I imagine that the
thing to do is have start_postmaster() save aside the handle for the CMD
process, and then in test_postmaster_connection(), check the handle state
to see if the process is still running (I assume there's a way to do
that).

I can take care of the Unix side of that, but as before, somebody else
would need to code and test the Windows side.  It's probably just a few
lines of code to add ... any volunteers?

regards, tom lane


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] bugs and bug tracking

[Magnus Hagander]

On Wed, Oct 7, 2015 at 4:56 PM, Stephen Frost  wrote:

>
> * Magnus Hagander (mag...@hagander.net) wrote:
> > On Wed, Oct 7, 2015 at 4:40 PM, Stephen Frost 
> wrote:
> > > * Nathan Wagner (nw...@hydaspes.if.org) wrote:
> > > > I think I have suggested that there be a way to generate a bug id via
> > > > email.  Presumably someone could just copy that email address to
> make a
> > > > not-tracked discussion get a bug id.  If the system archived all the
> > > > lists (not hard) it would be possible to pull the other emails from
> the
> > > > thread into the bug (also not hard).  As for marking as 'not-a-bug'
> > > > this can easily be done via whatever mechanism might be used.
> > > > Something along the lines of:
> > > >
> > > > Bug Status: not a bug
> > >
> > > If we're providing control messages through email (which I absolutely
> > > believe needs to be supported), I'd strongly prefer that they be easy
> to
> > > write.  The above isn't.
> > >
> > > A good set of commands to support can be seen here:
> > >
> > > https://www.debian.org/Bugs/server-control
> > >
> > > The way debbugs currently works, which I like, is that you email
> > > -d...@bugs.debian.org ( being the bug #) and that
> automatically
> > > closes the bug and that email is sent to the bug reporter.  Generally,
> > > this will be in a reply to an email which came from, or at least CC'd,
> > > n...@bugs.debian.org, so changing the address to go to -done is quite
> > > easy.
> >
> >
> > If I understand that correct, it completely breaks the current workflow
> of
> > "reply-all"? When I need to comment on a bug, isntead of hitting
> reply-all,
> > i should send it to the @bugs address? Or are you saying in those cases
> you
> > still hit reply-all but just edit the actual address?
>
> This, imv anyway, is why I need to just set it up and show people how it
> works.
>

Yes. Agreed.



> reply-all works just fine, since you like to know *exactly* how it works
> at a technical level, I just checked and the bug email address is
> automatically included in the Reply-To: header rather than being CC'd
> or From.  The bug submitter's email is also in the Reply-To.
>

Well, to play the devils advocate here - we explicitly *don't* set reply-to
headers on our mailinglists, and have done many rounds of bikeshedding as
to why :P



> Please understand that, at least in my experience, Debian's workflows
> are *very* similar to ours.  They just hammered out these questions
> about how to make it work over the past 15 years that we've been writing
> a database. ;)
>


Yeah, and they're just getting around to the database side now eh? :)


>
> > (FWIW, I think editing the actual address is nowhere near as easy as just
> > adding a Status:  to the message itself. It's likely easier to
> > deal with on the *server* side, but it's definitely not easier for the
> > user. Especially if you're in a MUA that doesn't let you easily edit a
> mail
> > address (hello gmail! which is quite a few of our users..)
>
> An email to control@ with


> close 1234
>


What I'd want is to just hit Reply-All, and add a keyword something like
"bug: closed" to the email, and that's it.



> My MUA makes changing an email To: line really easy and since I'm one of
> the users of that part of the system, I like it.


I know it does :) I use it for other things, but the majority of our
mailinglist users don't..



> One thing that's important to understand is that this system (in
> particular, the email interface) is *not* for our users (more
> specifically, it's not for the individuals who submit bugs via the bug
> form).

It's not for our end users, at least those parts, I agree.

But it's for all our developers, not just committers.

-- 
 Magnus Hagander
 Me: http://www.hagander.net/
 Work: http://www.redpill-linpro.com/

Re: [HACKERS] cash_mul_int8 / cash_div_int8

[Kohei KaiGai]

Also, cash_pl, cash_mi, cash_mul_int4 and so on... does not have overflow checks
like as int8pl has.

Of course, most of people don't need to worry about 64bit overflow for
money... :-).

2015-10-08 0:03 GMT+09:00 Kohei KaiGai :
> I noticed cash_mul_int8 / cash_div_int8 are defined in cash.c,
> however, pg_proc.h and pg_operator.h contains no relevant entries.
>
> Is it just a careless oversight?
>
> Thanks,
> --
> KaiGai Kohei 



-- 
KaiGai Kohei 


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Small documentation fix in src/interfaces/ecpg/preproc/po/pt_BR.po

[Euler Taveira]

On 06-10-2015 19:49, Andreas 'ads' Scherbaum wrote:

When working on a script, I stumbled over a mistake in the pt_BR.po
translation for ecpg. Patch attached.

I've already fixed it in the translation git. It'll be available only in 
the next set of releases.



--
   Euler Taveira   Timbira - http://www.timbira.com.br/
   PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento


--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] bugs and bug tracking

[Stephen Frost]

* Nathan Wagner (nw...@hydaspes.if.org) wrote:
> I think I have suggested that there be a way to generate a bug id via
> email.  Presumably someone could just copy that email address to make a
> not-tracked discussion get a bug id.  If the system archived all the
> lists (not hard) it would be possible to pull the other emails from the
> thread into the bug (also not hard).  As for marking as 'not-a-bug'
> this can easily be done via whatever mechanism might be used.
> Something along the lines of:
> 
> Bug Status: not a bug

If we're providing control messages through email (which I absolutely
believe needs to be supported), I'd strongly prefer that they be easy to
write.  The above isn't.

A good set of commands to support can be seen here:

https://www.debian.org/Bugs/server-control

The way debbugs currently works, which I like, is that you email
-d...@bugs.debian.org ( being the bug #) and that automatically
closes the bug and that email is sent to the bug reporter.  Generally,
this will be in a reply to an email which came from, or at least CC'd,
n...@bugs.debian.org, so changing the address to go to -done is quite
easy.

An example would go something like:

Initial email:

---
From: 1...@bugs.postgresql.org
[...]
PG should do X
---

Reply email:

---
From: sfr...@snowman.net
To: 1234-d...@bugs.postgresql.org, cont...@bugs.postgresql.org

tag 1234 wontfix
thanks

Blah, blah, this is why we don't consider this a bug
---

Currently with debbugs (afaik, I can double-check with Don though), to
actually add tags you have to email control@, which will read and
process commands up until it finds a "thanks" or similar end-command.
Since the email is going to control@, you have to specify which bug
you're adding the tag to.

Here's an example of how the system is used:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=100132

Using control@, etc, avoids having to figure out if a given email sent
to n...@bugs.postgresq.org has commands in it or not (all emails to
control@ are assumed to have commands).

Thanks!

Stephen


signature.asc
Description: Digital signature

Re: [HACKERS] cash_mul_int8 / cash_div_int8

[Tom Lane]

Kohei KaiGai  writes:
> I noticed cash_mul_int8 / cash_div_int8 are defined in cash.c,
> however, pg_proc.h and pg_operator.h contains no relevant entries.

> Is it just a careless oversight?

Hm.  I'd be inclined to fix that by removing the dead code, since
it's evidently useless.  For that matter, I doubt we need the int2
and flt4 variants; might as well depend on automatic promotions.

regards, tom lane


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] bugs and bug tracking

[Magnus Hagander]

On Wed, Oct 7, 2015 at 4:40 PM, Stephen Frost  wrote:

> * Nathan Wagner (nw...@hydaspes.if.org) wrote:
> > I think I have suggested that there be a way to generate a bug id via
> > email.  Presumably someone could just copy that email address to make a
> > not-tracked discussion get a bug id.  If the system archived all the
> > lists (not hard) it would be possible to pull the other emails from the
> > thread into the bug (also not hard).  As for marking as 'not-a-bug'
> > this can easily be done via whatever mechanism might be used.
> > Something along the lines of:
> >
> > Bug Status: not a bug
>
> If we're providing control messages through email (which I absolutely
> believe needs to be supported), I'd strongly prefer that they be easy to
> write.  The above isn't.
>
> A good set of commands to support can be seen here:
>
> https://www.debian.org/Bugs/server-control
>
> The way debbugs currently works, which I like, is that you email
> -d...@bugs.debian.org ( being the bug #) and that automatically
> closes the bug and that email is sent to the bug reporter.  Generally,
> this will be in a reply to an email which came from, or at least CC'd,
> n...@bugs.debian.org, so changing the address to go to -done is quite
> easy.
>


If I understand that correct, it completely breaks the current workflow of
"reply-all"? When I need to comment on a bug, isntead of hitting reply-all,
i should send it to the @bugs address? Or are you saying in those cases you
still hit reply-all but just edit the actual address?

(FWIW, I think editing the actual address is nowhere near as easy as just
adding a Status:  to the message itself. It's likely easier to
deal with on the *server* side, but it's definitely not easier for the
user. Especially if you're in a MUA that doesn't let you easily edit a mail
address (hello gmail! which is quite a few of our users..)



An example would go something like:
>
> Initial email:
>
> ---
> From: 1...@bugs.postgresql.org
> [...]
> PG should do X
> ---
>
> Reply email:
>
> ---
> From: sfr...@snowman.net
> To: 1234-d...@bugs.postgresql.org, cont...@bugs.postgresql.org
>
> tag 1234 wontfix
> thanks
>
> Blah, blah, this is why we don't consider this a bug
> ---
>


Oh, so debbugs actually breaks the reply-all workflow for *all* emails?

That would mean that bug emails are now handled differently from regular
emails on -hackers for example, wouldn't it? That seems like it's going to
cause issues.

-- 
 Magnus Hagander
 Me: http://www.hagander.net/
 Work: http://www.redpill-linpro.com/

Re: [HACKERS] bugs and bug tracking

[Tom Lane]

Magnus Hagander  writes:
> If I understand that correct, it completely breaks the current workflow of
> "reply-all"? When I need to comment on a bug, isntead of hitting reply-all,
> i should send it to the @bugs address? Or are you saying in those cases you
> still hit reply-all but just edit the actual address?

> (FWIW, I think editing the actual address is nowhere near as easy as just
> adding a Status:  to the message itself. It's likely easier to
> deal with on the *server* side, but it's definitely not easier for the
> user. Especially if you're in a MUA that doesn't let you easily edit a mail
> address (hello gmail! which is quite a few of our users..)

FWIW, I agree that encoding this sort of thing in the email address seems
like a pretty bad idea, because other people might reply-all to the
modified address.  Consider this flow:

bug submitted
insufficiently-thought-through reply to -done with "not a bug"
submitter replies (with cc to -done) with more details
reply: oh, you're right, so we should reopen it

At least half, if not all, of the subsequent traffic in the thread is
going to get cc'd to -done, thus repeatedly causing the bug to get
"closed" prematurely.

If you want such an API, I won't stop you from using it, but I will not
use it myself.  Please put in message-body commands as well.

regards, tom lane


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] bugs and bug tracking

[Alvaro Herrera]

Stephen Frost wrote:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
> > If you want such an API, I won't stop you from using it, but I will not
> > use it myself.  Please put in message-body commands as well.
> 
> So, unsurprisingly, debbugs does support all commands that can be sent
> to control@ also through the n...@bugs.postgresql.org system; the command
> simply needs to be prefixed with 'Control: ' and then '-1' can be used
> as the bug number (so you don't have to figure out what the right number
> is, etc), like so:
> 
> Control: close -1
> Control: tags -1 wontfix

Supposedly we will want our traffic to still flow via
pgsql-b...@postgresql.org, so the trick of grabbing the bug number from
the To address will not be available, will it?

Hmm, I guess we could have the bug form add
 To: n...@bugs.postgresql.org
 CC: pgsql-b...@postgresql.org
as headers, which should work for most people (since we reply-all), Josh
Berkus being the exception.

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


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Small documentation fix in src/interfaces/ecpg/preproc/po/pt_BR.po

[Euler Taveira]

On 07-10-2015 14:05, Alvaro Herrera wrote:

Euler Taveira wrote:

On 06-10-2015 19:49, Andreas 'ads' Scherbaum wrote:

When working on a script, I stumbled over a mistake in the pt_BR.po
translation for ecpg. Patch attached.


I've already fixed it in the translation git. It'll be available only in the
next set of releases.


Thanks.  No point in patching 9.0 anymore, BTW.


Yeah, I remembered that after git push.


--
   Euler Taveira   Timbira - http://www.timbira.com.br/
   PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento


--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] [DOCS] max_worker_processes on the standby

[Fujii Masao]

On Fri, Oct 2, 2015 at 11:58 PM, Alvaro Herrera
 wrote:
> Fujii Masao wrote:
>
>> What happens if pg_xact_commit_timestamp() is called in standby after
>> track_commit_timestamp is disabled in master, DeactivateCommitTs() is
>> called and all commit_ts files are removed in standby? I tried that case
>> and got the following assertion failure.
>
> Ah.  So the standby needs to keep the module activated if it's enabled
> locally, even when it receives a message that the master turned it off.
> Here's a patch.

I'm afraid that this behavior might confuse the users.

Please imagine the following scenario.

1. start up the server with track_commit_timestamp disabled
2. run several transactions
3. shut down the server with immediate mode
4. restart the server with track_commit_timestamp enabled
5. run "SELECT pg_last_committed_xact()"
6. run "SELECT pg_xact_commit_timestamp(xid) FROM pg_last_committed_xact()"
7. restart the server
8. run "SELECT pg_last_committed_xact()"

Firstly, in #5, pg_last_committed_xact() returns the XID and
timestamp of the last transaction which was executed in #2
(i.e., while track_commit_timestamp was disabled).
This is confusing. I think that both pg_last_committed_xact()
and pg_xact_commit_timestamp() should return only the transaction
which was executed with track_commit_timestamp enabled.

Secondly, SELECT query in #6 returns NULL. This means that
pg_xact_commit_timestamp() may not handle the transaction
which pg_last_committed_xact() handles. This is also confusing.

Finally, in #8, pg_last_committed_xact() returns NULL while
it returned non-NULL before the restart. This is also confusing.

Regards,

-- 
Fujii Masao


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] bugs and bug tracking

[Stephen Frost]

* Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
> Stephen Frost wrote:
> > * Tom Lane (t...@sss.pgh.pa.us) wrote:
> > > If you want such an API, I won't stop you from using it, but I will not
> > > use it myself.  Please put in message-body commands as well.
> > 
> > So, unsurprisingly, debbugs does support all commands that can be sent
> > to control@ also through the n...@bugs.postgresql.org system; the command
> > simply needs to be prefixed with 'Control: ' and then '-1' can be used
> > as the bug number (so you don't have to figure out what the right number
> > is, etc), like so:
> > 
> > Control: close -1
> > Control: tags -1 wontfix
> 
> Supposedly we will want our traffic to still flow via
> pgsql-b...@postgresql.org, so the trick of grabbing the bug number from
> the To address will not be available, will it?

There are a few different ways which we could integrate with pgsql-bugs,
depending on exactly what we want.

The Debian debbugs system currently emails to the following lists:

debian-bugs-closed - All emails which close bugs
debian-bugs-dist - All submitted bug reports and further info
debian-bugs-forwarded - Bug report forwarded upstream emails
debian-bugs-rc - All mail regarding release critical bugs

I'm sure we could create more.

The emails which go through debbugs will have the bug # pre-pended to
the Subject: line.

> Hmm, I guess we could have the bug form add
>  To: n...@bugs.postgresql.org
>  CC: pgsql-b...@postgresql.org
> as headers, which should work for most people (since we reply-all), Josh
> Berkus being the exception.

My thinking was that we'd have the form email sub...@bugs.postgresql.org
and then have pgsql-bugs receive the emails that go to debian-bugs-dist
(basically, all email that goes through the system).  That way, the
emails which hit pgsql-bugs can be responded to with updates, changes,
etc.  To avoid duplicate emails hitting pgsql-bugs, we might need to put
in place something that checks if pgsql-bugs was on the To: or Cc: line
and, if so, the email isn't sent to it again (honestly, for all I know,
debbugs might even support doing exactly that already..).

Perhaps it'd be better to have pgsql-bugs be the "Package owner", who
also gets emails about bug activity on their packages.  That way, we
could have a 'jdbc' package whose owner is pgsql-jdbc and pgsql-bugs
wouldn't end up with that bug traffic (which, I believe, is what we'd
want...).

I'll ask Don what suggestions he has regarding the best approach.

Thanks!

Stephen


signature.asc
Description: Digital signature

Re: [HACKERS] bugs and bug tracking

[Stephen Frost]

* Stephen Frost (sfr...@snowman.net) wrote:
> Perhaps it'd be better to have pgsql-bugs be the "Package owner", who
> also gets emails about bug activity on their packages.  That way, we
> could have a 'jdbc' package whose owner is pgsql-jdbc and pgsql-bugs
> wouldn't end up with that bug traffic (which, I believe, is what we'd
> want...).

To clarify, I mean 'Maintainer', and this would be identical to how the
PostgreSQL packages in Debian are currently maintained:

Maintainers for postgresql are Debian PostgreSQL Maintainers
.

And, handily, that list is archived here:

http://lists.alioth.debian.org/pipermail/pkg-postgresql-public/

One example of how it's used can be seen with this thread:

http://lists.alioth.debian.org/pipermail/pkg-postgresql-public/2015-September/002803.html

Thanks!

Stephen


signature.asc
Description: Digital signature

Re: [HACKERS] bugs and bug tracking

[Alvaro Herrera]

Nathan Wagner wrote:

> I am still working out exactly how to find multiple matching commits
> along different branches.  I'm running git patch-id on every commit,
> but that will take a while.

See src/tools/git_changelog (both the output and the implementation).
Isn't that rather what you want?  patch-id will give different answers
for patches that required conflict fixing.

> How often are the bugs mail list archives updated?  I've got a bunch of
> posts to the bugs list in my inbox that aren't in the archive download.

As each message is received.  What posts do you see that are not in the
archive?

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


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] bugs and bug tracking

[Magnus Hagander]

On Wed, Oct 7, 2015 at 8:47 PM, Alvaro Herrera 
wrote:

> Nathan Wagner wrote:
>
> > I am still working out exactly how to find multiple matching commits
> > along different branches.  I'm running git patch-id on every commit,
> > but that will take a while.
>
> See src/tools/git_changelog (both the output and the implementation).
> Isn't that rather what you want?  patch-id will give different answers
> for patches that required conflict fixing.
>
> > How often are the bugs mail list archives updated?  I've got a bunch of
> > posts to the bugs list in my inbox that aren't in the archive download.
>
> As each message is received.  What posts do you see that are not in the
> archive?
>

I'm pretty sure Nathan is talking about the publically available mbox
files, which are updated by rsync on a schedule. I don't recall exactly how
often.

However - Nathan, I'd suggest you don't focus too hard on that. As I said
before if we go somewhere with this in the end, it should use the APIs to
get the data, in which case they will be instant as Alvaro says. Some delay
during testing should not be a problem, I hope.


-- 
 Magnus Hagander
 Me: http://www.hagander.net/
 Work: http://www.redpill-linpro.com/

Re: [HACKERS] bugs and bug tracking

[Tom Lane]

Stephen Frost  writes:
> I *really* don't like the idea of rewriting the From/To completely to
> force all mail through a relay and I'm pretty sure that "fix" would be
> far worse than the problem.

Agreed; but adding a Reply-To: header seems quite reasonable.  (Unless
gmail ignores that, which I wouldn't put past it ...)

> One thing which can be easily done with debbugs is that someone can
> forward or bounce the direct email they receive from the user to the
> bug#@bugs address and have the info added, if the user removed the bug
> email address.

Right.  But that requires the recipient to pay close attention to the
message's cc list, which I have to confess I seldom do.  Still, it's
better than nothing.

regards, tom lane


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] bugs and bug tracking

[Magnus Hagander]

On Wed, Oct 7, 2015 at 8:59 PM, Tom Lane  wrote:

> Stephen Frost  writes:
> > I *really* don't like the idea of rewriting the From/To completely to
> > force all mail through a relay and I'm pretty sure that "fix" would be
> > far worse than the problem.
>
> Agreed; but adding a Reply-To: header seems quite reasonable.  (Unless
> gmail ignores that, which I wouldn't put past it ...)
>

It does not.

I'm sure there's *some* MUA out there that does, but probably not the big
ones.

-- 
 Magnus Hagander
 Me: http://www.hagander.net/
 Work: http://www.redpill-linpro.com/

Re: [HACKERS] bugs and bug tracking

[Stephen Frost]

* Nathan Wagner (nw...@hydaspes.if.org) wrote:
> I have added full text searching to my tracker.  I only index the first
> 50 KB of each message.  There's apparently a one MB limit on that
> anyway, which a few messages exceed.  I figure anything important is
> probably in the first 50KB.  I could be wrong.  I could re-index fairly
> easily.  It seems to work pretty well.

Note that we have FTS for the -bugs, and all the other, mailing lists..

Thanks!

Stephen


signature.asc
Description: Digital signature

Re: [HACKERS] bugs and bug tracking

[Alvaro Herrera]

Josh Berkus wrote:
> On 10/07/2015 10:25 AM, Alvaro Herrera wrote:
> > Hmm, I guess we could have the bug form add
> >  To: n...@bugs.postgresql.org
> >  CC: pgsql-b...@postgresql.org
> > as headers, which should work for most people (since we reply-all), Josh
> > Berkus being the exception.
> 
> Well, this will just give you more opportunities to ignore me.

Currently, it just means I have to look harder for stuff you post -- I
certainly do not ignore you.  I worry that in the future it might mean
your messages don't make it to the "bug threads", if we have such a
thing.  See my followup to Stephen,
https://www.postgresql.org/message-id/20151007175841.GE4405%40alvherre.pgsql
where some traffic was not present in the mailing list archives but it
does appear in the bug report itself.  I think we need to make it very
hard for that to happen, and lack of CCs might become a problem.

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


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] bugs and bug tracking

[Andres Freund]

On 2015-10-07 14:58:41 -0300, Alvaro Herrera wrote:
> Stephen Frost wrote:
> > One example of how it's used can be seen with this thread:
> > 
> > http://lists.alioth.debian.org/pipermail/pkg-postgresql-public/2015-September/002803.html
> 
> So in the pipermail interface you get the impression that after three
> messages the thread stopped.  But if you go to
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=797804
> you realize that there's further traffic in the bug that wasn't sent to
> the list.  That's ungood.

That's just becaue the pipermail link is for September, no?

Greetings,

Andres Freund


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] bugs and bug tracking

[Stephen Frost]

* Josh Berkus (j...@agliodbs.com) wrote:
> As a serious response, "reply-all" is NOT the default for common GUI
> mail clients (TB, Apple, Gmail, etc.), and I know on TB that it's not
> even possible to make it the default (I miss Kmail).  So a system which
> depends on the user ... including outside bug reporters ... always
> hitting "reply all" is going to have some issues.

You mean like our current system?

For starters, unless we start asking our users to submit their gmail
passwords, there's no way to ensure we get all of the emails.

I *really* don't like the idea of rewriting the From/To completely to
force all mail through a relay and I'm pretty sure that "fix" would be
far worse than the problem.

debbugs, as noted previously, does set Reply-To by default, which means
that a user replying to an email (even without reply-all) from debbugs
should have the response go to both the bug and whomever responded to
the initial email.

One thing which can be easily done with debbugs is that someone can
forward or bounce the direct email they receive from the user to the
bug#@bugs address and have the info added, if the user removed the bug
email address.

Thanks!

Stephen


signature.asc
Description: Digital signature

Re: [HACKERS] bugs and bug tracking

[Alvaro Herrera]

Stephen Frost wrote:
> * Stephen Frost (sfr...@snowman.net) wrote:
> > Perhaps it'd be better to have pgsql-bugs be the "Package owner", who
> > also gets emails about bug activity on their packages.  That way, we
> > could have a 'jdbc' package whose owner is pgsql-jdbc and pgsql-bugs
> > wouldn't end up with that bug traffic (which, I believe, is what we'd
> > want...).
> 
> To clarify, I mean 'Maintainer', and this would be identical to how the
> PostgreSQL packages in Debian are currently maintained:
> 
> Maintainers for postgresql are Debian PostgreSQL Maintainers
> .
> 
> And, handily, that list is archived here:
> 
> http://lists.alioth.debian.org/pipermail/pkg-postgresql-public/
> 
> One example of how it's used can be seen with this thread:
> 
> http://lists.alioth.debian.org/pipermail/pkg-postgresql-public/2015-September/002803.html

So in the pipermail interface you get the impression that after three
messages the thread stopped.  But if you go to
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=797804
you realize that there's further traffic in the bug that wasn't sent to
the list.  That's ungood.

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


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] bugs and bug tracking

[Josh Berkus]

On 10/07/2015 10:25 AM, Alvaro Herrera wrote:
> Hmm, I guess we could have the bug form add
>  To: n...@bugs.postgresql.org
>  CC: pgsql-b...@postgresql.org
> as headers, which should work for most people (since we reply-all), Josh
> Berkus being the exception.

Well, this will just give you more opportunities to ignore me.

-- 
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] bugs and bug tracking

[Stephen Frost]

* Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
> Stephen Frost wrote:
> > * Stephen Frost (sfr...@snowman.net) wrote:
> > > Perhaps it'd be better to have pgsql-bugs be the "Package owner", who
> > > also gets emails about bug activity on their packages.  That way, we
> > > could have a 'jdbc' package whose owner is pgsql-jdbc and pgsql-bugs
> > > wouldn't end up with that bug traffic (which, I believe, is what we'd
> > > want...).
> > 
> > To clarify, I mean 'Maintainer', and this would be identical to how the
> > PostgreSQL packages in Debian are currently maintained:
> > 
> > Maintainers for postgresql are Debian PostgreSQL Maintainers
> > .
> > 
> > And, handily, that list is archived here:
> > 
> > http://lists.alioth.debian.org/pipermail/pkg-postgresql-public/
> > 
> > One example of how it's used can be seen with this thread:
> > 
> > http://lists.alioth.debian.org/pipermail/pkg-postgresql-public/2015-September/002803.html
> 
> So in the pipermail interface you get the impression that after three
> messages the thread stopped.  But if you go to
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=797804
> you realize that there's further traffic in the bug that wasn't sent to
> the list.  That's ungood.

Oh, huh, that's curious.  I had expected all of the emails to go to the
package maintainer address also.  I'm sure they all went to the -dist
list.  I'll ask Don about it.

Thanks!

Stephen


signature.asc
Description: Digital signature

Re: [HACKERS] bugs and bug tracking

[Stephen Frost]

* Andres Freund (and...@anarazel.de) wrote:
> On 2015-10-07 14:58:41 -0300, Alvaro Herrera wrote:
> > Stephen Frost wrote:
> > > One example of how it's used can be seen with this thread:
> > > 
> > > http://lists.alioth.debian.org/pipermail/pkg-postgresql-public/2015-September/002803.html
> > 
> > So in the pipermail interface you get the impression that after three
> > messages the thread stopped.  But if you go to
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=797804
> > you realize that there's further traffic in the bug that wasn't sent to
> > the list.  That's ungood.
> 
> That's just becaue the pipermail link is for September, no?

hahaha, yes. :)

Thanks!

Stephen


signature.asc
Description: Digital signature

Re: [HACKERS] bugs and bug tracking

[Josh Berkus]

On 10/07/2015 11:05 AM, Alvaro Herrera wrote:
> Josh Berkus wrote:
>> On 10/07/2015 10:25 AM, Alvaro Herrera wrote:
>>> Hmm, I guess we could have the bug form add
>>>  To: n...@bugs.postgresql.org
>>>  CC: pgsql-b...@postgresql.org
>>> as headers, which should work for most people (since we reply-all), Josh
>>> Berkus being the exception.
>>
>> Well, this will just give you more opportunities to ignore me.
> 
> Currently, it just means I have to look harder for stuff you post -- I
> certainly do not ignore you.  

I know, I'm just "Joshing" you.

> I worry that in the future it might mean
> your messages don't make it to the "bug threads", if we have such a
> thing.  See my followup to Stephen,
> https://www.postgresql.org/message-id/20151007175841.GE4405%40alvherre.pgsql
> where some traffic was not present in the mailing list archives but it
> does appear in the bug report itself.  I think we need to make it very
> hard for that to happen, and lack of CCs might become a problem.

As a serious response, "reply-all" is NOT the default for common GUI
mail clients (TB, Apple, Gmail, etc.), and I know on TB that it's not
even possible to make it the default (I miss Kmail).  So a system which
depends on the user ... including outside bug reporters ... always
hitting "reply all" is going to have some issues.

-- 
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] bugs and bug tracking

[Alvaro Herrera]

Stephen Frost wrote:
> * Andres Freund (and...@anarazel.de) wrote:
> > On 2015-10-07 14:58:41 -0300, Alvaro Herrera wrote:
> > > Stephen Frost wrote:
> > > > One example of how it's used can be seen with this thread:
> > > > 
> > > > http://lists.alioth.debian.org/pipermail/pkg-postgresql-public/2015-September/002803.html
> > > 
> > > So in the pipermail interface you get the impression that after three
> > > messages the thread stopped.  But if you go to
> > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=797804
> > > you realize that there's further traffic in the bug that wasn't sent to
> > > the list.  That's ungood.
> > 
> > That's just becaue the pipermail link is for September, no?
> 
> hahaha, yes. :)

Oh my, how '90s.

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


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] bugs and bug tracking

[Stephen Frost]

* Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
> So in the pipermail interface you get the impression that after three
> messages the thread stopped.  But if you go to
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=797804
> you realize that there's further traffic in the bug that wasn't sent to
> the list.  That's ungood.

As Andres noted, the messages all went to the list, it's just that they
crossed a month boundary and the rest of the thread is in October.

Per Don, generally speaking, the only emails that *don't* get sent to
the Maintainer email address are ones which are explicitly sent to the
special 'nnn-quiet@bugs' email address, which is available specifically
to allow maintainers to add info without having it be sent back out to
the maintainer address.

Thanks!

Stephen


signature.asc
Description: Digital signature

Re: [HACKERS] bugs and bug tracking

[Alvaro Herrera]

Josh Berkus wrote:
> On 10/07/2015 11:05 AM, Alvaro Herrera wrote:
> > Josh Berkus wrote:
> >> On 10/07/2015 10:25 AM, Alvaro Herrera wrote:
> >>> Hmm, I guess we could have the bug form add
> >>>  To: n...@bugs.postgresql.org
> >>>  CC: pgsql-b...@postgresql.org
> >>> as headers, which should work for most people (since we reply-all), Josh
> >>> Berkus being the exception.
> >>
> >> Well, this will just give you more opportunities to ignore me.
> > 
> > Currently, it just means I have to look harder for stuff you post -- I
> > certainly do not ignore you.  
> 
> I know, I'm just "Joshing" you.

Ah well.

> > I worry that in the future it might mean
> > your messages don't make it to the "bug threads", if we have such a
> > thing.  See my followup to Stephen,
> > https://www.postgresql.org/message-id/20151007175841.GE4405%40alvherre.pgsql
> > where some traffic was not present in the mailing list archives but it
> > does appear in the bug report itself.  I think we need to make it very
> > hard for that to happen, and lack of CCs might become a problem.
> 
> As a serious response, "reply-all" is NOT the default for common GUI
> mail clients (TB, Apple, Gmail, etc.), and I know on TB that it's not
> even possible to make it the default (I miss Kmail).  So a system which
> depends on the user ... including outside bug reporters ... always
> hitting "reply all" is going to have some issues.

Hm, that's something to keep in mind then when figuring out the detailed
specs of the system.

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


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] bugs and bug tracking

[Nathan Wagner]

I have added full text searching to my tracker.  I only index the first
50 KB of each message.  There's apparently a one MB limit on that
anyway, which a few messages exceed.  I figure anything important is
probably in the first 50KB.  I could be wrong.  I could re-index fairly
easily.  It seems to work pretty well.

I have changed the 'stale' status to 90 days.  I have triaged most of
the remaining bugs with a message count > 1.  This is in a separate
file if it some other system wants to collect the work.

I am still working out exactly how to find multiple matching commits
along different branches.  I'm running git patch-id on every commit,
but that will take a while.

Later tonight I will implement some in-message-body update syntax I'm
also going to create (internally) a web page for the bugs that allows
editing the status from that page.  I will post the details on that
once I've tested it a bit.  I'll probably make a web page allowing
updates as well.

How often are the bugs mail list archives updated?  I've got a bunch of
posts to the bugs list in my inbox that aren't in the archive download.

-- 
nw


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Small documentation fix in src/interfaces/ecpg/preproc/po/pt_BR.po

[Alvaro Herrera]

Euler Taveira wrote:
> On 06-10-2015 19:49, Andreas 'ads' Scherbaum wrote:
> >When working on a script, I stumbled over a mistake in the pt_BR.po
> >translation for ecpg. Patch attached.
> >
> I've already fixed it in the translation git. It'll be available only in the
> next set of releases.

Thanks.  No point in patching 9.0 anymore, BTW.

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


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] bugs and bug tracking

[Stephen Frost]

* Tom Lane (t...@sss.pgh.pa.us) wrote:
> If you want such an API, I won't stop you from using it, but I will not
> use it myself.  Please put in message-body commands as well.

So, unsurprisingly, debbugs does support all commands that can be sent
to control@ also through the n...@bugs.postgresql.org system; the command
simply needs to be prefixed with 'Control: ' and then '-1' can be used
as the bug number (so you don't have to figure out what the right number
is, etc), like so:

Control: close -1
Control: tags -1 wontfix

etc.

Thanks!

Stephen


signature.asc
Description: Digital signature

Re: [HACKERS] bugs and bug tracking

[Stephen Frost]

* Magnus Hagander (mag...@hagander.net) wrote:
> On Wed, Oct 7, 2015 at 4:56 PM, Stephen Frost  wrote:
> > reply-all works just fine, since you like to know *exactly* how it works
> > at a technical level, I just checked and the bug email address is
> > automatically included in the Reply-To: header rather than being CC'd
> > or From.  The bug submitter's email is also in the Reply-To.
> 
> Well, to play the devils advocate here - we explicitly *don't* set reply-to
> headers on our mailinglists, and have done many rounds of bikeshedding as
> to why :P

It's not a mailing list and it's probably configurable anyway.

> What I'd want is to just hit Reply-All, and add a keyword something like
> "bug: closed" to the email, and that's it.

Control: close -1

> > One thing that's important to understand is that this system (in
> > particular, the email interface) is *not* for our users (more
> > specifically, it's not for the individuals who submit bugs via the bug
> > form).
> 
> It's not for our end users, at least those parts, I agree.
> 
> But it's for all our developers, not just committers.

Agreed, just saying we need to realize that there is a difference
between users and individuals who are active participants in the
community (and therefore have some familiarity with our mailing lists,
etc...).

Thanks!

Stephen


signature.asc
Description: Digital signature