Re: [HACKERS] [bug fix] pg_ctl always uses the same event source

[Amit Kapila]

On Fri, Apr 18, 2014 at 5:21 PM, MauMau maumau...@gmail.com wrote:
 From: Amit Kapila amit.kapil...@gmail.com

 Currently -e option is accepted with all the options that can be provided
 in pg_ctl.  Shouldn't we accept it only with options related to service,
 because that is only when it will be used.  Basically write_stderr() will
 write to event log only incase of service.


 Thank you for your kind and patient review.  I hope this will bear fruit.

 I don't find it so strange that -e is accepted by all operation modes of
 pg_ctl --- pg_ctl seems to handle switches that way.  For example, -c is
 only relevant to start and restart, but it is accepted by all modes.  -D is
 not relevant to pg_ctl kill, but it is not rejected.  Plus, I prepared for
 the future possibility that other modes of pg_ctl will use event log.

Okay, as there is no check for not-required switches with other options,
we can ignore this as well.

I have verified the patch and it works fine on Windows, as per my
verification event-source in pg_ctl will be only used once the user has
registered the service and then when it tries to preform start/stop on
service.  Although current usecase seems to be quite narrow for a new
switch, however in future we can extend it to use for other messages
in pg_ctl as well.

Only one minor suggestion:
+Name of the event source for pg_ctl to use for event log.  The
+default is PostgreSQL.

From this description, it is not clear when the event log will be used
in pg_ctl.  For example, if user uses -e option with register, then he
might expect any failure during register command will be logged into
eventlog, but that is not true.  So I think we should improve the docs
to reflect the usage of -e.

On Linux, I am getting below build failure for pg_ctl

pg_ctl.c: In function ‘main’:
pg_ctl.c:2173: error: ‘event_source’ undeclared (first use in this function)
pg_ctl.c:2173: error: (Each undeclared identifier is reported only once
pg_ctl.c:2173: error: for each function it appears in.)
make[3]: *** [pg_ctl.o] Error 1
make[2]: *** [all-pg_ctl-recurse] Error 2
make[1]: *** [all-bin-recurse] Error 2
make: *** [all-src-recurse] Error 2


With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.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] tab completion for setting search_path

[Jeff Janes]

On Friday, May 2, 2014, Jeff Janes jeff.ja...@gmail.com wrote:

 I've been working with an app that uses a schema name whose spelling is
 hard to type, and the lack of tab completion for SET search_path TO was
 bugging me.  So see attached.

 I filter out the system schemata, but not public.

 For commit fest next.


Once more, with attachment

Cheers,

Jeff
diff --git a/src/bin/psql/tab-complete.c b/src/bin/psql/tab-complete.c
new file mode 100644
index 6d26ffc..dec3d4a
*** a/src/bin/psql/tab-complete.c
--- b/src/bin/psql/tab-complete.c
*** psql_completion(const char *text, int st
*** 3230,3235 
--- 3230,3242 
  
  			COMPLETE_WITH_LIST(my_list);
  		}
+ 		else if (pg_strcasecmp(prev2_wd, search_path) == 0)
+ 		{
+ 			COMPLETE_WITH_QUERY(Query_for_list_of_schemas
+  AND nspname not like 'pg\\_%%' 
+  AND nspname not like 'information_schema' 
+  UNION SELECT 'DEFAULT' );
+ 		}
  		else
  		{
  			static const char *const my_list[] =

-- 
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] New and interesting replication issues with 9.2.8 sync rep

[Andres Freund]

On 2014-05-02 18:57:08 -0700, Josh Berkus wrote:
 Just got a report of a replication issue with 9.2.8 from a community member:
 
 Here's the sequence:
 
 1) A -- B (sync rep)
 
 2) Shut down B
 
 3) Shut down A
 
 4) Start up B as a master
 
 5) Start up A as sync replica of B
 
 6) A successfully joins B as a sync replica, even though its transaction
 log is 1016 bytes *ahead* of B.
 
 7) Transactions written to B all hang
 
 8) Xlog on A is now corrupt, although the database itself is OK

This is fundamentally borked practice.

 Now, the above sequence happened because of the user misunderstanding
 what sync rep really means.  However, A should not have been able to
 connect with B in replication mode, especially in sync rep mode; that
 should have failed.  Any thoughts on why it didn't?

I'd guess that B, while starting up, has written further WAL records
bringing it further ahead of A.

Greetings,

Andres Freund

-- 
 Andres Freund 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] Sending out a request for more buildfarm animals?

[Andres Freund]

On 2014-05-02 21:07:55 -0400, Noah Misch wrote:
 On Fri, May 02, 2014 at 05:04:01PM +0200, Andres Freund wrote:
  There's pretty little coverage of non mainstream platforms/compilers in
  the buildfarm atm. Maybe we should send an email on -announce asking for
  new ones?
  There's no coverage for OS-wise;
  * AIX (at all)
  * HP-UX (for master at least)
  (* Tru64)
  (* UnixWare)
  
  Architecture wise there's no coverage for:
  * some ARM architecture varians
  * mips
  * s390/x
  * sparc 32bit
  (* s390)
  (* alpha)
  (* mipsel)
  (* M68K)
  
  A couple of those aren't that important (my opinion indicated by ()),
  but the other ones really should be covered or desupported.
 
 More coverage of non-gcc compilers would be an asset to the buildfarm.
 
 +1 for sending a call for help to -announce.  I agree with your importance
 estimates, particularly on the OS side.  -1 for making code-level changes to
 desupport a platform based on the lack of a buildfarm member, though I don't
 mind documentation/advocacy changes on that basis.

I was thinking of changing
http://www.postgresql.org/docs/devel/static/supported-platforms.html to
list untested platforms similar to the way M32R and VAX are
documented. I.e. code exists, but we have no clue whether it works.

Greetings,

Andres Freund

-- 
 Andres Freund 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] tab completion for setting search_path

[Andres Freund]

On 2014-05-03 00:13:45 -0700, Jeff Janes wrote:
 On Friday, May 2, 2014, Jeff Janes jeff.ja...@gmail.com wrote:
 
  I've been working with an app that uses a schema name whose spelling is
  hard to type, and the lack of tab completion for SET search_path TO was
  bugging me.  So see attached.
 
  I filter out the system schemata, but not public.

That'd be nice.

 diff --git a/src/bin/psql/tab-complete.c b/src/bin/psql/tab-complete.c
 new file mode 100644
 index 6d26ffc..dec3d4a
 *** a/src/bin/psql/tab-complete.c
 --- b/src/bin/psql/tab-complete.c
 *** psql_completion(const char *text, int st
 *** 3230,3235 
 --- 3230,3242 
   
   COMPLETE_WITH_LIST(my_list);
   }
 + else if (pg_strcasecmp(prev2_wd, search_path) == 0)
 + {
 + COMPLETE_WITH_QUERY(Query_for_list_of_schemas
 +  AND nspname 
 not like 'pg\\_%%' 
 +  AND nspname 
 not like 'information_schema' 
 +  UNION SELECT 
 'DEFAULT' );
 + }

Why should we exclude system schemata? That seems more likely to be
confusing than helpful? I can see a point in excluding another backend's
temp tables, but otherwise?

Greetings,

Andres Freund

-- 
 Andres Freund 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] quiet inline configure check misses a step for clang

[Andres Freund]

On 2014-05-01 16:17:17 -0400, Tom Lane wrote:
 Andres Freund and...@2ndquadrant.com writes:
  Patch attached.
 
 Committed with minor comment-smithing.

Interestingly this seems to have allowed the quiet inline test to
succeedd on HP-UX ac++ as well:
http://buildfarm.postgresql.org/cgi-bin/show_stage_log.pl?nm=anoledt=2014-05-02%2023%3A36%3A53stg=config
Seems it uses a similar logic to clang. For a lot longer.

Greetings,

Andres Freund

-- 
 Andres Freund 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] Sending out a request for more buildfarm animals?

[Dave Page]

Hamid@EDB; Can you please have someone configure anole to build git
head as well as the other branches? Thanks.

Andres, Andrew; I think the only other gap EDB could fill at the
moment is RHEL6 on Power7 (though we do have a couple of Power8 boxes
on order that should be here pretty soon). Dotterel is building some
branches (including head). I'm not sure what generation of Power CPU
that box has. Bernd?

On Fri, May 2, 2014 at 4:04 PM, Andres Freund and...@2ndquadrant.com wrote:
 Hi,

 There's pretty little coverage of non mainstream platforms/compilers in
 the buildfarm atm. Maybe we should send an email on -announce asking for
 new ones?
 There's no coverage for OS-wise;
 * AIX (at all)
 * HP-UX (for master at least)
 (* Tru64)
 (* UnixWare)

 Architecture wise there's no coverage for:
 * some ARM architecture varians
 * mips
 * s390/x
 * sparc 32bit
 (* s390)
 (* alpha)
 (* mipsel)
 (* M68K)

 A couple of those aren't that important (my opinion indicated by ()),
 but the other ones really should be covered or desupported.

 Greetings,

 Andres Freund

 --
  Andres Freund http://www.2ndQuadrant.com/
  PostgreSQL Development, 24x7 Support, Training  Services



-- 
Dave Page
Chief Architect, Tools  Installers
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake


-- 
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] Supporting multiple column assignment in UPDATE (9.5 project)

[Marko Tiikkaja]

On 5/2/14, 10:10 PM, Merlin Moncure wrote:

On Fri, May 2, 2014 at 3:03 PM, Tom Lane t...@sss.pgh.pa.us wrote:

Meh.  Then you could have a query that works fine until you add a column
to the table, and it stops working.  If nobody ever used column names
identical to table names it'd be all right, but unfortunately people
seem to do that a lot...


That's already the case with select statements


I don't think that's true if you table-qualify your column references 
and don't use SELECT *.



and, if a user were
concerned about that, always have the option of aliasing the table as
nearly 100% of professional developers do:

SELECT f FROM foo f;
etc.


So e.g.:

  UPDATE foo f SET f = ..;

would resolve to the table, despite there being a column called f? 
That would break backwards compatibility.


How about:

  UPDATE foo SET ROW(foo) = (1,2,3);

ISTM that this could be parsed unambiguously, though it's perhaps a bit 
ugly.



Regards,
Marko Tiikkaja


--
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_get_viewdefs() indentation considered harmful

[Marko Tiikkaja]

Hi all,

Now that we're on the topic of view deparsing, what are your thoughts on 
making this less painful?


local:marko=#* create view foov as select exists(select * from foo);
CREATE VIEW
local:marko=#* \d+ foov
  View public.foov
 Column |  Type   | Modifiers | Storage | Description
+-+---+-+-
 exists | boolean |   | plain   |
View definition:
 SELECT (EXISTS ( SELECT foo.way,
foo.too,
foo.many,
foo.columns,
foo.here
   FROM foo)) AS exists;


I've switched to using SELECT 1 in EXISTS for this reason, but perhaps 
other people haven't yet done that..



Regards,
Marko Tiikkaja


--
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_get_viewdefs() indentation considered harmful

[Andrew Dunstan]

On 05/03/2014 09:17 AM, Marko Tiikkaja wrote:

Hi all,

Now that we're on the topic of view deparsing, what are your thoughts 
on making this less painful?


local:marko=#* create view foov as select exists(select * from foo);
CREATE VIEW
local:marko=#* \d+ foov
  View public.foov
 Column |  Type   | Modifiers | Storage | Description
+-+---+-+-
 exists | boolean |   | plain   |
View definition:
 SELECT (EXISTS ( SELECT foo.way,
foo.too,
foo.many,
foo.columns,
foo.here
   FROM foo)) AS exists;


I've switched to using SELECT 1 in EXISTS for this reason, but perhaps 
other people haven't yet done that..







I've done that for quite a few years. I think it's better style than 
using *.


cheers

andrew



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

[HACKERS] need of anonymous record

[Peter Krauss]

My notion of anonymous record, and the need of this kind of higher-order
type, are discussed in the links below,

http://stackoverflow.com/q/23439240
  Functions can not to *return individual items of a record*

http://stackoverflow.com/q/21246201
  PostgreSQL v9.X have real '*array of record*' ?

The first question is about performance: *returns table* have the same
performance than *returns record*??
If yes, the *record* datatype is somewhat outdated?


The second question/discussion shows a more deeper problem, where perhaps
the use of string index in array syntax (something like x['a']) would be a
good syntax solution.
Craig Ringer shows another suggestion in the (second) link.


I am new here, I do not know how, but I'm available to help... Can a future
version of PostgreSQL implement some solution?


Peter

Re: [HACKERS] Sending out a request for more buildfarm animals?

[Bernd Helmle]

It's a POWER 7 machine. 

On 3. Mai 2014 10:31:34 MESZ, Dave Page dave.p...@enterprisedb.com wrote:
Hamid@EDB; Can you please have someone configure anole to build git
head as well as the other branches? Thanks.

Andres, Andrew; I think the only other gap EDB could fill at the
moment is RHEL6 on Power7 (though we do have a couple of Power8 boxes
on order that should be here pretty soon). Dotterel is building some
branches (including head). I'm not sure what generation of Power CPU
that box has. Bernd?

On Fri, May 2, 2014 at 4:04 PM, Andres Freund and...@2ndquadrant.com
wrote:
 Hi,

 There's pretty little coverage of non mainstream platforms/compilers
in
 the buildfarm atm. Maybe we should send an email on -announce asking
for
 new ones?
 There's no coverage for OS-wise;
 * AIX (at all)
 * HP-UX (for master at least)
 (* Tru64)
 (* UnixWare)

 Architecture wise there's no coverage for:
 * some ARM architecture varians
 * mips
 * s390/x
 * sparc 32bit
 (* s390)
 (* alpha)
 (* mipsel)
 (* M68K)

 A couple of those aren't that important (my opinion indicated by ()),
 but the other ones really should be covered or desupported.

 Greetings,

 Andres Freund

 --
  Andres Freund http://www.2ndQuadrant.com/
  PostgreSQL Development, 24x7 Support, Training  Services



-- 
Dave Page
Chief Architect, Tools  Installers
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

-- 
Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.

Re: [HACKERS] need of anonymous record

[David G Johnston]

Peter Padua Krauss wrote
 The first question is about performance: *returns table* have the same
 performance than *returns record*??
 If yes, the *record* datatype is somewhat outdated?

Table defines the possibility to return a set while record can only ever
return a single value; so likely the set version is less performant but
regardless they have different semantics.


 I am new here, I do not know how, but I'm available to help... Can a
 future
 version of PostgreSQL implement some solution?

Craig's reply in the array post explained the reality quite well.  SQL is
strongly typed so while some improvement on the use of anonymous record
types is possible the SQL way of doing things would be to CREATE TYPE. 
Hstore and JSON provides an alternative means to define a column in a
dynamic way.  

It is unlikely that records types would ever be altered for dynamic member
access given that these types exist. But it is not impossible given a good
implementation. The one benefit is that current attempts give errors so
making it work only has to avoid performance regressions and not screw up
the parser.

As Craig said: how much does this bother you? If you cannot code C yourself
are you willing to pay someone to implement this feature?  The cost-benefit
analysis suggests this particular need is a poor area to invest resources
in.

David J.



--
View this message in context: 
http://postgresql.1045698.n5.nabble.com/need-of-anonymous-record-tp5802301p5802303.html
Sent from the PostgreSQL - hackers mailing list archive at Nabble.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] need of anonymous record

[Andrew Dunstan]

On 05/03/2014 09:55 AM, Peter Krauss wrote:
My notion of anonymous record, and the need of this kind of 
higher-order type, are discussed in the links below,


http://stackoverflow.com/q/23439240
  Functions can not to /return individual items of a record/

http://stackoverflow.com/q/21246201
  PostgreSQL v9.X have real '/array of record/' ?

The first question is about performance: /returns table/ have the 
same performance than /returns record/??

If yes, the /record/ datatype is somewhat outdated?


Quite apart from other considerations such as the clear lack of 
understanding of semantics here, I at least am not going to follow 
threads to stackoverflow. If you want to discuss the actual or desired 
semantics of Postgres, the proper place is the Postgres mailing lists.


cheers

andrew



--
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] Possible fix for occasional failures on castoroides etc

[Andres Freund]

On 2012-09-17 08:23:01 -0400, Dave Page wrote:
 On Sun, Sep 16, 2012 at 12:44 PM, Andrew Dunstan and...@dunslane.net wrote:
 
  On 09/16/2012 12:04 PM, Tom Lane wrote:
 
  It's annoying that the buildfarm animals running on older versions of
  Solaris randomly fail with Connection refused errors, such as in
  today's example:
 
  http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=castoroidesdt=2012-09-15%2015%3A42%3A52
 
  I believe what's probably happening there is that the kernel has a small
  hard-wired limit on the length of the postmaster's accept queue, and you
  get this failure if too many connection attempts arrive faster than the
  postmaster can service them.  If that theory is correct, we could
  probably prevent these failures by reducing the number of tests run in
  parallel, which could be done by adding say
  MAX_CONNECTIONS=5
  to the environment in which the regression tests run.  I'm not sure
  though if that's build_env or some other setting for the buildfarm
  script --- Andrew?
 
 
 
 
 
  Yes, in the build_env section of the config file.
 
  It's in the distributed sample config file, commented out.
 
 I've added MAX_CONNECTIONS=5 to both Castoroides and Protosciurus.

I've just noticed (while checking whether backporting 4c8aa8b5aea caused
problems) that this doesn't seem to have fixed the issue. One further
thing to try would be to try whether tcp connections don't have the same
problem.

Greetings,

Andres Freund

-- 
 Andres Freund 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] Sending out a request for more buildfarm animals?

[Noah Misch]

On Sat, May 03, 2014 at 10:09:56AM +0200, Andres Freund wrote:
 On 2014-05-02 21:07:55 -0400, Noah Misch wrote:
  +1 for sending a call for help to -announce.  I agree with your importance
  estimates, particularly on the OS side.  -1 for making code-level changes to
  desupport a platform based on the lack of a buildfarm member, though I 
  don't
  mind documentation/advocacy changes on that basis.
 
 I was thinking of changing
 http://www.postgresql.org/docs/devel/static/supported-platforms.html to
 list untested platforms similar to the way M32R and VAX are
 documented. I.e. code exists, but we have no clue whether it works.

Sounds perfect.

-- 
Noah Misch
EnterpriseDB http://www.enterprisedb.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] Sending out a request for more buildfarm animals?

[Tomas Vondra]

On 3.5.2014 03:07, Noah Misch wrote:
 More coverage of non-gcc compilers would be an asset to the buildfarm.

Does that include non-gcc compilers on Linux/x86 platforms?

Magpie is pretty much dedicated to the buildfarm, and it's pretty much
doing nothing most of the time, so running the tests with other
compilers  (llvm/ic/...) would be just fine. Not sure how to do that,
though. Should I run the tests with multiple configurations, or should
we have one animal for each config?

Tomas


-- 
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] Sending out a request for more buildfarm animals?

[Tom Lane]

Tomas Vondra t...@fuzzy.cz writes:
 Magpie is pretty much dedicated to the buildfarm, and it's pretty much
 doing nothing most of the time, so running the tests with other
 compilers  (llvm/ic/...) would be just fine. Not sure how to do that,
 though. Should I run the tests with multiple configurations, or should
 we have one animal for each config?

I believe the intent is one animal name per configuration.

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] Sending out a request for more buildfarm animals?

[Andrew Dunstan]

On 05/03/2014 12:42 PM, Tomas Vondra wrote:

On 3.5.2014 03:07, Noah Misch wrote:

More coverage of non-gcc compilers would be an asset to the buildfarm.

Does that include non-gcc compilers on Linux/x86 platforms?

Magpie is pretty much dedicated to the buildfarm, and it's pretty much
doing nothing most of the time, so running the tests with other
compilers  (llvm/ic/...) would be just fine. Not sure how to do that,
though. Should I run the tests with multiple configurations, or should
we have one animal for each config?



No, don't run with multiple configs. That makes it much harder to see 
where problems come from. One animal per config, please.


cheers

andrew









--
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] Possible fix for occasional failures on castoroides etc

[Tom Lane]

Andres Freund and...@2ndquadrant.com writes:
 On 2012-09-17 08:23:01 -0400, Dave Page wrote:
 I've added MAX_CONNECTIONS=5 to both Castoroides and Protosciurus.

 I've just noticed (while checking whether backporting 4c8aa8b5aea caused
 problems) that this doesn't seem to have fixed the issue. One further
 thing to try would be to try whether tcp connections don't have the same
 problem.

I did some googling on this, and found out that people have seen identical
behavior on Solaris with mysql and other products, so at least we're not
alone.  Googling also reminded me that we could have a look at the source
(duh), which is still available from hg.openindiana.org.  I poked around
a bit and more or less confirmed the theory mentioned here:
https://www.varnish-cache.org/trac/ticket/865
That is, Solaris' unix-sockets code will generate ECONNREFUSED if it
finds that the socket is not connected and not waiting for a connection
*and* there is no saved error code.  One example is:

if (so-so_error != 0)
return (sogeterr(so, B_TRUE));
/*
 * Under normal circumstances, so_error should contain an error
 * in case the connect failed. However, it is possible for another
 * thread to come in a consume the error, so generate a sensible
 * error in that case.
 */
if ((so-so_state  SS_ISCONNECTED) == 0)
return (ECONNREFUSED);

Now, I can't imagine where the other thread hypothesized in this comment
could be, so what I'm thinking is that maybe there's a bug somewhere that
drops the connection attempt without setting any error in so_error; or
maybe there's a race condition that releases the waiting client before
so_error is set.  But that still leaves the question of why the connection
attempt is getting dropped at all.

BTW, I also found no less an authority than W. Richard Stevens saying that
my theory that this could happen from accept queue overflow was wrong, at
least in a sane implementation:

https://groups.google.com/forum/#!topic/comp.unix.solaris/e8QxFyXxr84

: - there are too many outstanding connections that haven't
:   been accepted yet (perhaps you can up the second parameter
:   to listen)
:
: No.  When the pending connection queue is filled, TCP ignores an
: arriving SYN, it does not respond with an RST.  This is a soft error
: (a busy server) and by ignoring it, TCP forces the client to retransmit
: the SYN, hopefully finding a less busy server at some time in the future.
: For additional details and an example, check out pp. 257-260 of my TCP/IP
: Illustrated (Addison-Wesley, 1994).
: 
: Rich Stevens

Unfortunately, it seems the Solaris implementors didn't read Stevens,
because it looks to me like they *do* return ECONNREFUSED on accept queue
overflow.  Still, it's hard to see how that would be the issue if we're
still seeing this failure with only five clients.

There are just not that many references to ECONNREFUSED in the portions of
the Solaris source tree that look like they could be related to Unix
sockets, so it's hard to come up with more theories than this.

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

[HACKERS] pgindent run

[Bruce Momjian]

I am planning to run pgindent in a few days to prepare for beta.  Does
anyone have major patches that you are planning to apply soon?  If so, I
can delay pgindent until you are done.  

This run will also have a tabs-in-comments removal phase which will also
be run on supported back branches.

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

  + Everyone has their own god. +


-- 
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] Possible fix for occasional failures on castoroides etc

[Tom Lane]

I wrote:
 Unfortunately, it seems the Solaris implementors didn't read Stevens,
 because it looks to me like they *do* return ECONNREFUSED on accept queue
 overflow.  Still, it's hard to see how that would be the issue if we're
 still seeing this failure with only five clients.

Also, after further inspection of the source code, it appears to me that
the kernel's limit on accept queue length is hard-wired at 4096 in
Solaris.  So there's basically no way that we're hitting that limit in the
regression tests, and the MAX_CONNECTIONS configuration is irrelevant.

We seem to be left with the race condition theory.  In that connection,
this comment in /usr/src/uts/common/io/tl.c is interesting:

 *  The T_CONN_CON is generated when processing the T_CONN_REQ i.e. before
 *  a T_CONN_RES is received from the acceptor. This means that a socket
 *  connect will complete before the peer has called accept.

I'm not sure that explains anything of value, but it's probably unlike any
other implementation, which makes it perhaps relevant.  It implies that
this is totally unrelated to any server-side behavior; so if it's possible
for us to work around it at all, we'd have to do so client-side.

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] Possible fix for occasional failures on castoroides etc

[Andres Freund]

On 2014-05-03 13:25:32 -0400, Tom Lane wrote:
 Andres Freund and...@2ndquadrant.com writes:
  On 2012-09-17 08:23:01 -0400, Dave Page wrote:
  I've added MAX_CONNECTIONS=5 to both Castoroides and Protosciurus.
 
  I've just noticed (while checking whether backporting 4c8aa8b5aea caused
  problems) that this doesn't seem to have fixed the issue. One further
  thing to try would be to try whether tcp connections don't have the same
  problem.
 
 I did some googling on this, and found out that people have seen identical
 behavior on Solaris with mysql and other products, so at least we're not
 alone.

Yea, I found a couple report of that as well.

  Googling also reminded me that we could have a look at the source
 (duh), which is still available from hg.openindiana.org.

I didn't get that far ;)

I think we should try whether the problem disappears if tcp connections
are used. That ought to be much more heavily used in the real
world. Thus less likely to be buggy.

While It's not documented as such, passing --host=localhost to
pg_regress seems to have the desired effect. Dave, could you make your
animal specify that?

Greetings,

Andres Freund

-- 
 Andres Freund 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