Re: [BUGS] PostgreSQL-9.0alpha: jade required?

[Joseph Conway]

Tom Lane wrote:
> I wrote:
>> * $(GENERATED_SGML) is removed by make clean, therefore also by
>> make distclean
>> Ergo, this type of failure is *guaranteed* when trying to build
>> from a distribution tarball.  This needs to be rethought.
> 
> I looked at this some more, and this time I noticed that the makefile
> has
> 
> .SECONDARY: postgres.xml $(GENERATED_SGML) HTML.index
> 
> which puts the lie to the above theory.  Also, in some simple testing
> here I've not been able to reproduce the behavior of make wanting to
> rebuild the HTML doc files when working from the alpha4 tarball.  So
> I'm feeling baffled again.

I have tested a few different ways on a fresh CentOS vm and have been
unable to reproduce the issue either (including make clean prior to
build, mv openjade and jade so they are not found by configure)

> I can think of a couple of possible theories at this point:
> 
> * those reporting problems are using versions of gmake that have bugs in
> handling .SECONDARY files.

I added Deepak on whose machine I witnessed the problem to the cc list
so that he can tell us what OS it was in his case.

> * those reporting problems have re-autoconf'd.  Since version.sgml
> is declared to depend on $(top_srcdir)/configure, this would result
> in a forced docs rebuild.  It might help a bit to make it depend on
> configure.in instead; though I'm far from sure this explains the
> complaints.

I'm reasonably certain he did not do this before seeing the problem. I
think it was a simple untar, configure, make, make install...

Joe

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

Re: [BUGS] BUG #5465: dblink TCP connection hangs blocking translation from being terminated

[Joseph Conway]

Magnus Hagander wrote:
> On Wed, May 19, 2010 at 5:10 AM, Valentine Gogichashvili
>  wrote:
>> The following bug has been logged online:
>>
>> Bug reference:  5465
>> Logged by:  Valentine Gogichashvili
>> Email address:  val...@gmail.com
>> PostgreSQL version: 8.2.1
>> Operating system:   Red Hat 3.4.6-3 (kernel 2.6.9-42.0.3.ELsmp)
>> Description:dblink TCP connection hangs blocking translation from
>> being terminated
>> Details:
>>
>> Hi all,
>>
>> we have an issue on our productive server. A stored procedure, that uses
>> dblink to get some data from the remote database hangs not responding to
>> kill signal and holds several locks on some tables as well as an advisory
>> lock. So I have this transaction to be completed in order to have a
>> possibility to operate the database normally.
> 
> I believe this is a known issue in dblink, where it's not possible to
> cancel it when it's waiting in the TCP layer in the kernel.
> Unfortunately, there is no fix ATM - there was some work towards it
> for 9.0 at one point, but I think this is actually the first real
> bug-report on the issue...

I thought the known issue was only on Windows though...
Note that this is not dblink specific but rather libpq.

>> How would it be possible to shutdown the DB in case this session process is
>> not responding to normal kill signals? Will it hinder the database from
>> shutting down normally? My previous experience with issuing immediate stops
>> or killing with -9 had been quite catastrophic and I could not start the DB
>> afterwards. What would you suggest in this case?
> 
> kill -9 on a client will make the postmaster restart the whole
> process, so yes, it's a very heavy operation.

Can you grab the process with gdb and call elog() manually?

Joe


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