Re: [BUGS] BUG #7534: walreceiver takes long time to detect n/w breakdown

[Heikki Linnakangas]

On 21.09.2012 14:18, Amit kapila wrote:

On Tuesday, September 18, 2012 6:02 PM Fujii Masao wrote:
On Mon, Sep 17, 2012 at 4:03 PM, Amit Kapila  wrote:


Approach-2 :
Provide a variable wal_send_status_interval, such that if this is 0, then
the current behavior would prevail and if its non-zero then KeepAlive
message would be send maximum after that time.
The modified code of WALSendLoop will be as follows:




Which way you think is better or you have any other idea to handle.



I think #2 is better because it's more intuitive to a user.


Please find a patch attached for implementation of Approach-2.


Hmm, I think we need to step back a bit. I've never liked the way 
replication_timeout works, where it's the user's responsibility to set 
wal_receiver_status_interval < replication_timeout. It's not very 
user-friendly. I'd rather not copy that same design to this walreceiver 
timeout. If there's two different timeouts like that, it's even worse, 
because it's easy to confuse the two.


So let's think how this should ideally work from a user's point of view. 
I think there should be just two settings: walsender_timeout and 
walreceiver_timeout. walsender_timeout specifies how long a walsender 
will keep a connection open if it doesn't hear from the walreceiver, and 
walreceiver_timeout is the same for walreceiver. The system should 
figure out itself how often to send keepalive messages so that those 
timeouts are not reached.


In walsender, after half of walsender_timeout has elapsed and we haven't 
received anything from the client, the walsender process should send a 
"ping" message to the client. Whenever the client receives a Ping, it 
replies. The walreceiver does the same; when half of walreceiver_timeout 
has elapsed, send a Ping message to the server. Each Ping-Pong roundtrip 
resets the timer in both ends, regardless of which side initiated it, so 
if e.g walsender_timeout < walreceiver_timeout, the client will never 
have to initiate a Ping message, because walsender will always reach the 
walsender_timeout/2 point first and initiate the heartbeat message.


The Ping/Pong messages don't necessarily need to be new message types, 
we can use the message types we currently have, perhaps with an 
additional flag attached to them, to request the other side to reply 
immediately.


- Heikki


--
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 #6758: ./configure script sets HAVE_WCSTOMBS_L 1

[Andrew Hastie]

Apologies for delay in progressing this, but I only have access to an 
AIX7.1 system periodically.


Just to confirm that source build of 9.2.1 release now builds clean 
against AIXv7.1 with xlc v12.1 compiler.


Thanks,
Andrew



On 31/08/12 20:20, Tom Lane wrote:

Andrew Hastie  writes:

On 31/08/12 15:59, Tom Lane wrote:

As a temporary workaround, you should probably just modify pg_config.h
after configure runs, to remove the HAVE_WCSTOMBS_L symbol.

Confirm that the workaround works just fine. Now have PG 9.1.5 up and
running on AIX just fine.

Thanks for checking.  If you have time, perhaps you'd like to apply the
committed patch:
http://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=97395185b85b786523ee41225b53bd84c98d34f4
and confirm that all is well when using that.

regards, tom lane






--
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 #6758: ./configure script sets HAVE_WCSTOMBS_L 1

[Andrew Hastie]

Apologies for delay in progressing this, but I only have access to an 
AIX7.1 system periodically.


Just to confirm that source build of 9.2.1 release now builds clean 
against AIXv7.1 with xlc v12.1 compiler.


Thanks,
Andrew



On 31/08/12 20:20, Tom Lane wrote:

Andrew Hastie  writes:

On 31/08/12 15:59, Tom Lane wrote:

As a temporary workaround, you should probably just modify pg_config.h
after configure runs, to remove the HAVE_WCSTOMBS_L symbol.

Confirm that the workaround works just fine. Now have PG 9.1.5 up and
running on AIX just fine.

Thanks for checking.  If you have time, perhaps you'd like to apply the
committed patch:
http://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=97395185b85b786523ee41225b53bd84c98d34f4
and confirm that all is well when using that.

regards, tom lane




--

/*Andrew Hastie*/*
Software Engineer
Rocket.AS Support and Development
Rocket Software
*Innovation Centre · Warwick Technology Park, Warwick CV34 6UW · UK
Tel: +44.1926.482545
Email: andrew.has...@rocketsoftware.com 


Web: www.rocketsoftware.com/as 

Re: [BUGS] BUG #7573: data loss in corner case using delete_old_cluster.sh (pg_upgrade)

[Bruce Momjian]

On Fri, Sep 28, 2012 at 01:18:26AM +, maxim.bo...@gmail.com wrote:
> The following bug has been logged on the website:
> 
> Bug reference:  7573
> Logged by:  Maxim Boguk
> Email address:  maxim.bo...@gmail.com
> PostgreSQL version: 9.2.0
> Operating system:   Linux
> Description:
> 
> Hi,
> 
> today while performing migration of test database (with no critical data...
> and that was good thing).
> I found very nasty corner case with using delete_old_cluster.sh after
> pg_upgrade.
> 
> Test database have a bit unusual tablespace layout:
> main tablespace partition was mounted inside data directory of the old
> cluster...
> E.g.:
> data directory - /var/lib/postgresql/9.2/main
> main tablespace (another partition mount point) -
> /var/lib/postgresql/9.2/main/largedb

Can you show us the data directory path of the old and new clusters?

pg_upgrade really doesn't know what is inside that old cluster, so it
just deletes everything under the data directory.

I guess I could check if the path of the old cluster somehow matches the
leading path of the new cluster, but I doubt that would be fool-proof
either, e.g. symlinks.

> May be it is good idea to add:
>--one-file-system
>   when removing a hierarchy recursively, skip any directory that
> is on a file system different from that of the corresponding command line
> argument
> 
> to rm call into that script.
> 
> However, it is Linux only feature.
> 
> PS: Yes I know that keeping any foreign data inside PostgreSQL data
> directory is bad idea.

I don't see how adding --one-file-system would help us.  They could have
place it under the old cluster in the same file system.

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

  + It's impossible for everything to be true. +


-- 
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 #7534: walreceiver takes long time to detect n/w breakdown

[Robert Haas]

On Mon, Oct 1, 2012 at 6:38 AM, Heikki Linnakangas
 wrote:
> Hmm, I think we need to step back a bit. I've never liked the way
> replication_timeout works, where it's the user's responsibility to set
> wal_receiver_status_interval < replication_timeout. It's not very
> user-friendly. I'd rather not copy that same design to this walreceiver
> timeout. If there's two different timeouts like that, it's even worse,
> because it's easy to confuse the two.

I agree, but also note that wal_receiver_status_interval serves
another user-visible purpose as well.

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


-- 
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 #7534: walreceiver takes long time to detect n/w breakdown

[Fujii Masao]

On Mon, Oct 1, 2012 at 7:38 PM, Heikki Linnakangas
 wrote:
> Hmm, I think we need to step back a bit. I've never liked the way
> replication_timeout works, where it's the user's responsibility to set
> wal_receiver_status_interval < replication_timeout. It's not very
> user-friendly. I'd rather not copy that same design to this walreceiver
> timeout. If there's two different timeouts like that, it's even worse,
> because it's easy to confuse the two.

Agreed.

I'd like to specify the replication timeout like we do TCP keepalives, i.e.,
what about introducing something like following parameters?

walsender_keepalives_idle
walsender_keepalives_interval
walsender_keeaplives_count
walreceiver_keepalives_idle
walreceiver_keepalives_interval
walreceiver_keepalives_count

I believe many users are basically familiar with TCP keepalives and how to
specify it. So I think that this approach would be intuitive to users. Also
this approach includes your proposal. If you specify

walsender_keepalives_idle = walsender_timeout / 2
walsender_keepalives_interval = -1 (disable; Ping is never sent
again if there is no reply after first Ping is sent)
walsender_keepalives_count = 1

the replication timeout works as you proposed. But of course the downside
of this approach is that the number of parameter for replication timeout is
increased from two (replication_timeout and
wal_receiver_status_interval) to six,
and those parameters are confusingly similar to existing
tcp_keepalives parameters,
which might cause another confusion to users. One idea to solve this problem is
to use existing tcp_keepalives paramters values for the replication timeout.

Regards,

-- 
Fujii Masao


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

[BUGS] Postgres 9.2 with Postgis 1.5.3 Upgrade

[Freddie Burgess]

Does anyone know of any known issues (show-stoppers) with upgrading to
Postgresql 9.2  but retaining Postgis 1.5.3 or Postgis 1.5.5?

 

Thanks

 

Re: [BUGS] BUG #7534: walreceiver takes long time to detect n/w breakdown

[Robert Haas]

On Mon, Oct 1, 2012 at 12:57 PM, Fujii Masao  wrote:
> I believe many users are basically familiar with TCP keepalives and how to
> specify it. So I think that this approach would be intuitive to users.

My experience is that many users are unfamiliar with TCP keepalives
and that when given the options they tend to do it wrong.  I think a
simpler system would be better.

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


-- 
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 #7534: walreceiver takes long time to detect n/w breakdown

[Alvaro Herrera]

Excerpts from Robert Haas's message of lun oct 01 21:02:54 -0300 2012:
> On Mon, Oct 1, 2012 at 12:57 PM, Fujii Masao  wrote:
> > I believe many users are basically familiar with TCP keepalives and how to
> > specify it. So I think that this approach would be intuitive to users.
> 
> My experience is that many users are unfamiliar with TCP keepalives
> and that when given the options they tend to do it wrong.  I think a
> simpler system would be better.

+1

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


-- 
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 #7574: CASE in WHERE condition change result set

[Alvaro Herrera]

Excerpts from urvancevav's message of vie sep 28 05:58:42 -0300 2012:
> The following bug has been logged on the website:
> 
> Bug reference:  7574
> Logged by:  Andrei
> Email address:  urvance...@gmail.com
> PostgreSQL version: 9.2.1
> Operating system:   3.2.0-31-generic #50-Ubuntu SMP Fri Sep 7 16:16:45
> Description:
> 
> in query like this:

> [ snipped ]

> CASE operator in the WHERE condition actually sets clazz_ to 0 instead of
> filtering it.

Can you please provide a complete example?  That would be something that
someone else can load into an empty database and observe the failure.

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


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