date:20130422

Re: [HACKERS] 9.3 Beta1 status report

2013-04-22 Thread Boszormenyi Zoltan


2013-04-21 15:10 keltezéssel, Bruce Momjian írta:

On Sun, Apr 21, 2013 at 09:34:10AM +0200, Boszormenyi Zoltan wrote:

2013-04-21 07:02 keltezéssel, Bruce Momjian írta:

I am not sure if Tom shared yet, but we are planning to package 9.3
beta1 on April 29, with a release on May 2.  Those dates might change,
but that is the current plan.  I have completed a draft 9.3 release
notes, which you can view here:

http://momjian.us/pgsql_docs/release-9-3.html

I will be working on polishing them for the next ten days, so any
feedback, patches, or commits are welcome.  I still need to add lots of
SGML markup.

How comes Álvaro's name comes out right in your page but not at
http://www.postgresql.org/docs/devel/static/release-9-3.html ?

Anyway, I attached a patch to fix my name in your page using markups.

Thanks, applied.


Thank you.


   I had not yet gotten to doing the SGML markup for
non-ASCII characters.




--
--
Zoltán Böszörményi
Cybertec Schönig  Schönig GmbH
Gröhrmühlgasse 26
A-2700 Wiener Neustadt, Austria
Web: http://www.postgresql-support.de
 http://www.postgresql.at/



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

[HACKERS] Fast promotion, loose ends

2013-04-22 Thread Heikki Linnakangas

We never reached a consensus on the user interface of the new 'fast 
promotion'. We should settle that before beta. The thread died here:


http://www.postgresql.org/message-id/CA+U5nMKmDD7hGCYzOo=iFM=eK5OPDXCEzmq79fgLWr0TJk=s...@mail.gmail.com

Simon said in that email that he's waiting for further comments, so let 
me reiterate my view on this:


The current situation is that to do 'fast promotion', you have to use 
pg_ctl promote -m fast. 'slow' promotion is the default.


I didn't like that, because:

1. The slow method has no advantage over the fast method. Therefore I 
think the fast method should be the default, when promoting a standby. 
To be conservative, just in case there are bugs in the fast method, we'd 
still use the slow method for crash recovery and end of point-in-time 
recovery. That provides an escape hatch, so that if the fast method 
fails because of a bug, you can still start up the database.


2. There is no way to perform 'fast promotion' using the trigger file. 
That feature is only available using pg_ctl promote. When pg_ctl 
promote was introduced, it was not meant to replace the trigger file 
method, as that is also very useful in many situations. (as explained 
here: http://www.postgresql.org/message-id/5112a54b.8090...@vmware.com)


Putting points 1 and 2 together, I think the best solution is to always 
perform 'fast' promotion when in standby mode, and remove pg_ctl -m 
fast/smart option altogether. There is no need to expose that to users.


- Heikki


--
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] Fast promotion, loose ends

2013-04-22 Thread Simon Riggs

On 22 April 2013 08:13, Heikki Linnakangas hlinnakan...@vmware.com wrote:
We never reached a consensus on the user interface of the new 'fast
promotion'. We should settle that before beta. The thread died here:

http://www.postgresql.org/message-id/CA+U5nMKmDD7hGCYzOo=iFM=eK5OPDXCEzmq79fgLWr0TJk=s...@mail.gmail.com

Simon said in that email that he's waiting for further comments, so let me
reiterate my view on this:

I'm very happy to discuss this some more, thanks for bringing it up.

The current situation is that to do 'fast promotion', you have to use
pg_ctl promote -m fast. 'slow' promotion is the default.

I didn't like that, because:

1. The slow method has no advantage over the fast method. Therefore I think
the fast method should be the default, when promoting a standby. To be
conservative, just in case there are bugs in the fast method, we'd still use
the slow method for crash recovery and end of point-in-time recovery. That
provides an escape hatch, so that if the fast method fails because of a bug,
you can still start up the database.

In general, I agree. My only advantage for slow is that we know it works.

2. There is no way to perform 'fast promotion' using the trigger file. That
feature is only available using pg_ctl promote. When pg_ctl promote was
introduced, it was not meant to replace the trigger file method, as that is
also very useful in many situations. (as explained here:
http://www.postgresql.org/message-id/5112a54b.8090...@vmware.com)

I realise that it *is* possible to trigger fast promotion using a
file, since that is exactly the method we use to implement the feature
by pg_ctl.

In fact, pg_ctl promote is just a nice paint job over the trigger file concept.

So, to initiate promotion, you can create a file called
$DATADIR/fast_promote or $DATADIR/promote

Does that solve the issue?

Putting points 1 and 2 together, I think the best solution is to always
perform 'fast' promotion when in standby mode, and remove pg_ctl -m
fast/smart option altogether. There is no need to expose that to users.

We can make pg_ctl promote write the fast_promote file by default and
remove the command line option altogether.

I would like to retain the option to promote with a full checkpoint,
for safety reasons, so continue to use both fast_promote and promote
files under the covers.

--
Simon Riggs 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] Fast promotion, loose ends

2013-04-22 Thread Heikki Linnakangas


On 22.04.2013 10:58, Simon Riggs wrote:

On 22 April 2013 08:13, Heikki Linnakangashlinnakan...@vmware.com  wrote:

2. There is no way to perform 'fast promotion' using the trigger file. That
feature is only available using pg_ctl promote. When pg_ctl promote was
introduced, it was not meant to replace the trigger file method, as that is
also very useful in many situations. (as explained here:
http://www.postgresql.org/message-id/5112a54b.8090...@vmware.com)


I realise that it *is* possible to trigger fast promotion using a
file, since that is exactly the method we use to implement the feature
by pg_ctl.

In fact, pg_ctl promote is just a nice paint job over the trigger file concept.

So, to initiate promotion, you can create a file called
$DATADIR/fast_promote or $DATADIR/promote

Does that solve the issue?


Hmm. That requires write access to $DATADIR, so that's not quite the 
same thing as the trigger_file recovery.conf option. But if you really 
want to keep the 'slow' option, we could add an option to recovery.conf 
for it. I'm thinking something like this:


trigger_file = '/mnt/foo/trigger'# file to watch for
trigger_file_method = 'slow' # slow / fast, 'fast' is default.

You would have to decide which method to use when you create 
recovery.conf file, rather than when you promote, but I think that would OK.



Putting points 1 and 2 together, I think the best solution is to always
perform 'fast' promotion when in standby mode, and remove pg_ctl -m
fast/smart option altogether. There is no need to expose that to users.


We can make pg_ctl promote write the fast_promote file by default and
remove the command line option altogether.


Sounds good to me.


I would like to retain the option to promote with a full checkpoint,
for safety reasons, so continue to use both fast_promote and promote
files under the covers.


Ok. As long as 'fast' is the default and you get the same functionality 
with the trigger file method and pg_ctl promote, that works for me.


Thanks!

- Heikki


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

[HACKERS] REFRESH MATERIALIZED VIEW command in PL block hitting Assert

2013-04-22 Thread Jeevan Chalke

Hi,

I have observed that following sequence is causing server crash.

CREATE MATERIALIZED VIEW temp_class_mv AS
  SELECT * FROM pg_class
  WITH NO DATA;

CREATE OR REPLACE FUNCTION test_refresh_mv()
RETURNS int
AS $$
BEGIN
 REFRESH MATERIALIZED VIEW temp_class_mv;
 return 1;
END; $$ LANGUAGE plpgsql;

SELECT test_refresh_mv();


I had a quick look over the crash and it is hitting following Assert in
spi.c:

else if (IsA(stmt, RefreshMatViewStmt))
{
Assert(strncmp(completionTag,
   REFRESH MATERIALIZED VIEW , 23) == 0);
_SPI_current-processed = strtoul(completionTag + 23,
  NULL, 10);
}

It seems like we are missing expected value for completionTag in
ExecRefreshMatView()

Thanks

-- 
Jeevan B Chalke
Senior Software Engineer, RD
EnterpriseDB Corporation
The Enterprise PostgreSQL Company

Phone: +91 20 30589500

Website: www.enterprisedb.com
EnterpriseDB Blog: http://blogs.enterprisedb.com/
Follow us on Twitter: http://www.twitter.com/enterprisedb

This e-mail message (and any attachment) is intended for the use of the
individual or entity to whom it is addressed. This message contains
information from EnterpriseDB Corporation that may be privileged,
confidential, or exempt from disclosure under applicable law. If you are
not the intended recipient or authorized to receive this for the intended
recipient, any use, dissemination, distribution, retention, archiving, or
copying of this communication is strictly prohibited. If you have received
this e-mail in error, please notify the sender immediately by reply e-mail
and delete this message.

Re: [HACKERS] REFRESH MATERIALIZED VIEW command in PL block hitting Assert

2013-04-22 Thread Andres Freund

On 2013-04-22 18:35:04 +0530, Jeevan Chalke wrote:
 Hi,
 
 I have observed that following sequence is causing server crash.
 
 CREATE MATERIALIZED VIEW temp_class_mv AS
   SELECT * FROM pg_class
   WITH NO DATA;
 
 CREATE OR REPLACE FUNCTION test_refresh_mv()
 RETURNS int
 AS $$
 BEGIN
  REFRESH MATERIALIZED VIEW temp_class_mv;
  return 1;
 END; $$ LANGUAGE plpgsql;
 
 SELECT test_refresh_mv();
 
 
 I had a quick look over the crash and it is hitting following Assert in
 spi.c:
 
 else if (IsA(stmt, RefreshMatViewStmt))
 {
 Assert(strncmp(completionTag,
REFRESH MATERIALIZED VIEW , 23) == 0);
 _SPI_current-processed = strtoul(completionTag + 23,
   NULL, 10);
 }
 
 It seems like we are missing expected value for completionTag in
 ExecRefreshMatView()

Possibly independent from this issue, but where did that 23 come from?
ISTM we're strtoul()ing EW somenumber here.

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] REFRESH MATERIALIZED VIEW command in PL block hitting Assert

2013-04-22 Thread Jeevan Chalke

On Mon, Apr 22, 2013 at 6:41 PM, Andres Freund and...@2ndquadrant.comwrote:

 On 2013-04-22 18:35:04 +0530, Jeevan Chalke wrote:
  Hi,
 
  I have observed that following sequence is causing server crash.
 
  CREATE MATERIALIZED VIEW temp_class_mv AS
SELECT * FROM pg_class
WITH NO DATA;
 
  CREATE OR REPLACE FUNCTION test_refresh_mv()
  RETURNS int
  AS $$
  BEGIN
   REFRESH MATERIALIZED VIEW temp_class_mv;
   return 1;
  END; $$ LANGUAGE plpgsql;
 
  SELECT test_refresh_mv();
 
 
  I had a quick look over the crash and it is hitting following Assert in
  spi.c:
 
  else if (IsA(stmt, RefreshMatViewStmt))
  {
  Assert(strncmp(completionTag,
 REFRESH MATERIALIZED VIEW , 23) ==
 0);
  _SPI_current-processed = strtoul(completionTag + 23,
NULL, 10);
  }
 
  It seems like we are missing expected value for completionTag in
  ExecRefreshMatView()

 Possibly independent from this issue, but where did that 23 come from?


23 is also bogus here.
It should be 26 i.e. length of REFRESH MATERIALIZED VIEW 

BTW, attached is the patch which works well for me, but need details review.

Thanks


 ISTM we're strtoul()ing EW somenumber here.

 Greetings,

 Andres Freund

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




-- 
Jeevan B Chalke
Senior Software Engineer, RD
EnterpriseDB Corporation
The Enterprise PostgreSQL Company

Phone: +91 20 30589500

Website: www.enterprisedb.com
EnterpriseDB Blog: http://blogs.enterprisedb.com/
Follow us on Twitter: http://www.twitter.com/enterprisedb

This e-mail message (and any attachment) is intended for the use of the
individual or entity to whom it is addressed. This message contains
information from EnterpriseDB Corporation that may be privileged,
confidential, or exempt from disclosure under applicable law. If you are
not the intended recipient or authorized to receive this for the intended
recipient, any use, dissemination, distribution, retention, archiving, or
copying of this communication is strictly prohibited. If you have received
this e-mail in error, please notify the sender immediately by reply e-mail
and delete this message.


mv_crash.patch
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] Fast promotion, loose ends

2013-04-22 Thread Shaun Thomas


On 04/22/2013 02:58 AM, Simon Riggs wrote:


So, to initiate promotion, you can create a file called
$DATADIR/fast_promote or $DATADIR/promote


Pardon my naiveté, but could it also be an option to read the method
from the promotion file?

echo slow  /my/promotion/path

That would work without any default naming scheme, and only incurs a
read on the file-handle.

--
Shaun Thomas
OptionsHouse | 141 W. Jackson Blvd. | Suite 500 | Chicago IL, 60604
312-676-8870
stho...@optionshouse.com

__

See http://www.peak6.com/email_disclaimer/ for terms and conditions related to 
this email


--
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] erroneous restore into pg_catalog schema

2013-04-22 Thread Robert Haas

On Wed, Apr 17, 2013 at 2:06 PM, Tom Lane t...@sss.pgh.pa.us wrote:
 I think this breaks contrib/adminpack, and perhaps other extensions.
 They'd not be hard to fix with script changes, but they'd be broken.

 In general, we would now have a situation where relocatable extensions
 could never be installed into pg_catalog.  That might be OK, but at
 least it would need to be documented.

 Also, I think we'd be pretty much hard-wiring the decision that pg_dump
 will never dump objects in pg_catalog, because its method for selecting
 the creation schema won't work in that case.  That probably is all right
 too, but we need to realize it's a consequence of this.

These are all good points.  I'm uncertain whether they are sufficient
justification for abandoning this idea and looking for another
solution, or whether we should live with them.  Any thoughts?

 As far as the code goes, OK except I strongly disapprove of removing
 the comment about temp_missing at line 3512.  The coding is not any less
 a hack in that respect for having been pushed into a subroutine.  If
 you want to rewrite the comment, fine, but failing to point out that
 something funny is going on is not a service to readers.

OK, how about something like this: Choose default creation namespace
(but note that temp_missing, if set, will trump this value).

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

57 matches

Mail list logo