Re: [HACKERS] Draft release notes up for review

2013-04-20 Thread Boszormenyi Zoltan 

2013-03-29 02:46 keltezéssel, Tom Lane írta:

Since there has been some, um, grumbling about the quality of the
release notes of late, I've prepared draft notes for next week's
releases, covering commits through today.  These are now committed
into the master branch for review, and should show up at
http://www.postgresql.org/docs/devel/static/
after guaibasaurus' next buildfarm run, about three hours from now.

Please comment if you find anything that could be improved.


The sgml converter seems to choke on the UTF-8 characters that my name contains:

Add configuration variable lock_timeout to limit lock wait duration (Zoltán 
Böszörményi)

I don't mind if my name is written without the accented characters like in the 
other entry:

Have pg_basebackup --write-recovery-conf output a minimal recovery.conf (Zoltan 
Boszormenyi, Magnus Hagander)


Alternatively the sgml tool can be taught to emit proper HTML accented 
characters
or my name can be written as "Zoltán Böszörményi"

Best regards,
Zoltán Böszörményi



regards, tom lane





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

Re: [HACKERS] 9.3 Beta1 status report

2013-04-20 Thread Pavan Deolasee 
On Sun, Apr 21, 2013 at 11:06 AM, Peter Geoghegan  wrote:

> On Sat, Apr 20, 2013 at 10:02 PM, Bruce Momjian  wrote:
> > 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.
>
> I've noticed a few things:
>
> * Allow heap-only tuple updates on system tables (Andres Freund)
>
> Didn't Andres just fix a bug wherein HOT updates usually wouldn't
> occur on system tables following the commit of the foreign key locks
> patch? While HOT's development occurred at a time before I followed
> pgsql-hackers, I seem to recall someone telling me that Tom insisted
> upon HOT working with system catalogs specifically because if it
> wasn't good enough to work there, it wasn't good enough to work
> anywhere, or something like that. I guess the source of the confusion
> is specifically that at one point HOT really didn't work with system
> catalogs. But, if I'm not mistaken, never in a released version.
>
>
Yeah, HOT was always supported on the system tables in the released
versions. Early days, I tried to convince Tom that its OK to not support
HOT on system tables because updating it frequently is not that common. But
he rejected that on the grounds you explained above. Similarly, we had
other limitations such as CREATE INDEX CONCURRENTLY was broken in the early
submitted versions, but Tom insisted on getting that to work as well before
he will consider the patch. In retrospect, even though we had to burn
midnight oil to get all those limitations straight up, IMHO it made the
code more solid. Of course, Tom had a magic eye to find many corner cases,
fix them and simplify the code before committing the patch.

Andreas reported and fixed a bug which was an oversight in the FK locks
patch. I think he also discovered an old bug that the tableoid was not
being properly checked for HOT conditions but that had very limited impact
since its not common to have indexes on tableoids.

Thanks,
Pavan

-- 
Pavan Deolasee
http://www.linkedin.com/in/pavandeolasee

Re: [HACKERS] 9.3 Beta1 status report

2013-04-20 Thread Peter Geoghegan 
On Sat, Apr 20, 2013 at 10:02 PM, Bruce Momjian  wrote:
> 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.

I've noticed a few things:

* Allow heap-only tuple updates on system tables (Andres Freund)

Didn't Andres just fix a bug wherein HOT updates usually wouldn't
occur on system tables following the commit of the foreign key locks
patch? While HOT's development occurred at a time before I followed
pgsql-hackers, I seem to recall someone telling me that Tom insisted
upon HOT working with system catalogs specifically because if it
wasn't good enough to work there, it wasn't good enough to work
anywhere, or something like that. I guess the source of the confusion
is specifically that at one point HOT really didn't work with system
catalogs. But, if I'm not mistaken, never in a released version.

* Improve grouping of sessions waiting for commit_delay (Peter Geoghegan)

I think this should be under "General Performance". It's definitely a
performance feature.

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

[HACKERS] 9.3 Beta1 status report

2013-04-20 Thread Bruce Momjian 
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.

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

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


-- 
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 help with TRAP: FailedAssertion("!(context != CurrentMemoryContext)"

2013-04-20 Thread Tom Lane 
Stephen Woodbridge  writes:
> Thank you for your reply. The frustrating thing about this is the same 
> source works fine in Linux. So here is the pseudo code of my source 
> removing non pgsql stuff and not expected to be runnable:

You can't hold a SPI context open across multiple calls of an SRF.
Even if it somehow failed to malfunction in isolation, this would
certainly not work in a query where some other called function was
also using SPI.

Possibly the reason the code accidentally fails to malfunction on Linux
is you're not using an --enable-cassert build there?  That would wipe
freed memory and thus help to reveal errors of this sort consistently,
whereas otherwise the failures would be context-dependent.

[ later ]
> Someone might want to look into this.

Even if there were good reason to think this was a system bug and not
yours, there's little anyone else can do when you've not provided a
complete, concrete test case.

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] Need help with TRAP: FailedAssertion("!(context != CurrentMemoryContext)"

2013-04-20 Thread Stephen Woodbridge 
OK, it looks like there is a bug related to MinGW builds. If I remove 
both  --enable-cassert --enable-debug from my configure then I get a 
build that works. Removing just  --enable-cassert  did not solve the 
problem. I did not try just removing --enable-debug only.


Someone might want to look into this.

Thanks,
  -Steve

On 4/20/2013 8:21 PM, Stephen Woodbridge wrote:

On 4/20/2013 5:00 PM, Andres Freund wrote:

On 2013-04-20 16:32:36 -0400, Stephen Woodbridge wrote:

Hi all,

I have been writing pg extensions for a while but I just  ran into a
problem
that has me stumped.

I have code for a SRF and it works fine on pg 9.2.2 on linux, but
fails with
am error in the logfile.

TRAP: FailedAssertion("!(context != CurrentMemoryContext)", File:
"mcxt.c",
Line: 172)


This means that the current memory context is being deleted. Are you
doing that or did you maybe MemoryContextSwitchTo to some context but
not back?


Andres,

Thank you for your reply. The frustrating thing about this is the same
source works fine in Linux. So here is the pseudo code of my source
removing non pgsql stuff and not expected to be runnable:

PG_FUNCTION_INFO_V1(myfunc);
Datum myfunc(PG_FUNCTION_ARGS)
{
   if (SRF_IS_FIRSTCALL()) {
 funcctx = SRF_FIRSTCALL_INIT();
 oldcontext = MemoryContextSwitchTo(funcctx->multi_call_memory_ctx);
 SPIcode = SPI_connect();

 // execute some SPI queries and load some structures
 // execute a query and save the tuptable and
 // other stuff in funcctx->user_fctx

 MemoryContextSwitchTo(oldcontext);
   }

   funcctx = SRF_PERCALL_SETUP();

   if (call_cntr < max_calls) {

 // process a row in my saved tuptable

 SRF_RETURN_NEXT(funcctx, result)
   }
   else { // we are all done cleanup
 // free stuff from my library
 SPI_freetuptable(my_tuptable);
 SPIcode = SPI_finish(); // < CRASHES HERE >
 SRF_RETURN_DONE(funcctx);
   }
}

So, like I said, it runs on Linux not in MinGW on windows. Anyway, did I
mess up the memory context switching? Is there a way I can force the
context to the appropriate place.

Thanks,
   -Steve






--
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 help with TRAP: FailedAssertion("!(context != CurrentMemoryContext)"

2013-04-20 Thread Stephen Woodbridge 

On 4/20/2013 5:00 PM, Andres Freund wrote:

On 2013-04-20 16:32:36 -0400, Stephen Woodbridge wrote:

Hi all,

I have been writing pg extensions for a while but I just  ran into a problem
that has me stumped.

I have code for a SRF and it works fine on pg 9.2.2 on linux, but fails with
am error in the logfile.

TRAP: FailedAssertion("!(context != CurrentMemoryContext)", File: "mcxt.c",
Line: 172)


This means that the current memory context is being deleted. Are you
doing that or did you maybe MemoryContextSwitchTo to some context but
not back?


Andres,

Thank you for your reply. The frustrating thing about this is the same 
source works fine in Linux. So here is the pseudo code of my source 
removing non pgsql stuff and not expected to be runnable:


PG_FUNCTION_INFO_V1(myfunc);
Datum myfunc(PG_FUNCTION_ARGS)
{
  if (SRF_IS_FIRSTCALL()) {
funcctx = SRF_FIRSTCALL_INIT();
oldcontext = MemoryContextSwitchTo(funcctx->multi_call_memory_ctx);
SPIcode = SPI_connect();

// execute some SPI queries and load some structures
// execute a query and save the tuptable and
// other stuff in funcctx->user_fctx

MemoryContextSwitchTo(oldcontext);
  }

  funcctx = SRF_PERCALL_SETUP();

  if (call_cntr < max_calls) {

// process a row in my saved tuptable

SRF_RETURN_NEXT(funcctx, result)
  }
  else { // we are all done cleanup
// free stuff from my library
SPI_freetuptable(my_tuptable);
SPIcode = SPI_finish(); // < CRASHES HERE >
SRF_RETURN_DONE(funcctx);
  }
}

So, like I said, it runs on Linux not in MinGW on windows. Anyway, did I 
mess up the memory context switching? Is there a way I can force the 
context to the appropriate place.


Thanks,
  -Steve


--
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 help with TRAP: FailedAssertion("!(context != CurrentMemoryContext)"

2013-04-20 Thread Andres Freund 
On 2013-04-20 16:32:36 -0400, Stephen Woodbridge wrote:
> Hi all,
> 
> I have been writing pg extensions for a while but I just  ran into a problem
> that has me stumped.
> 
> I have code for a SRF and it works fine on pg 9.2.2 on linux, but fails with
> am error in the logfile.
> 
> TRAP: FailedAssertion("!(context != CurrentMemoryContext)", File: "mcxt.c",
> Line: 172)

This means that the current memory context is being deleted. Are you
doing that or did you maybe MemoryContextSwitchTo to some context but
not back?

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

[HACKERS] Need help with TRAP: FailedAssertion("!(context != CurrentMemoryContext)"

2013-04-20 Thread Stephen Woodbridge 

Hi all,

I have been writing pg extensions for a while but I just  ran into a 
problem that has me stumped.


I have code for a SRF and it works fine on pg 9.2.2 on linux, but fails 
with am error in the logfile.


TRAP: FailedAssertion("!(context != CurrentMemoryContext)", File: 
"mcxt.c", Line: 172)


I have run it in single user mode with valgrind on linux and it is clean 
from memory overwrites or leaks. I fails under mingw 32 bit and mingw 64 
bit builds. I have other code that works fine so I don't think it is a 
build environment issue.


I have also run tests on the library using a test harness (ie: outside 
of postgresql) and it runs clean on windows and linux.


The code runs and generates the correct results, and this crash is when 
I call SPI_finish().


So I would appreciate any ideas on how I can trace done the issue and 
fix it.


Thanks,
  -Steve


The code and my mingw build is below, the paths would need to change for 
another environment. The source file in questions is 
address_standardizer.c if you want to look at it. If you want to run it 
let me know and I can provide details.


#!/bin/sh
wget -O pagc-postgresql.tgz 
'http://pagc.svn.sourceforge.net/viewvc/pagc/branches/sew-refactor/postgresql/?view=tar'

rm -rf postgresql
tar xzf pagc-postgresql.tgz
cd postgresql

export 
PATH='/c/ming32/projects/gettext/rel-gettext-0.18.1/bin:/c/ming32/projects/xsltproc:/c/ming32/projects/gtk/bin:/c/ming32/projects/rel-libiconv-1.13.1w32/include:.:/bin:/include:/mingw/bin:/mingw/include:/c/Windows/system32:/c/Windows:/usr/local/bin:/c/ming32/Silksvn/bin::/c/ming32/projects/pgx32/pg92w32/bin:/c/ming32/projects/pgx32/pg92w32/lib'


make SHLIB_LINK="-L/c/ming32/msys/local/lib -Wl,--enable-stdcall-fixup 
-lpostgres -lpgport -lwsock32 -lm  -lws2_32 -lshfolder -lpcre" 
CPPFLAGS=-I/usr/local/include && make install



--
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] [GSOC] questions about idea "rewrite pg_dump as library"

2013-04-20 Thread Joel Jacobson 
On Fri, Apr 12, 2013 at 1:07 PM, Hannu Krosing wrote:

> I was just thinking of moving the queries the pg_dump currently
> uses into UDF-s, which do _not_ use catalog cache, but will use
> the same SQL to query catalogs as pg_dump currently does
> using whatever snapshot mode is currently set .
>
> the pg_dump will need to still have the same queries for older
> versions of postgresql but for new versions pg_dump  can become
> catalog-agnostic.
>
> and I think that we can retire pg_dump support for older
> postgresql versions the same way we drop support for
> older versions of postgresql itself.



> main things I see would be
>
>  * get_list_of_objects(object_**type, pattern or namelist)
>  * get_sql_def_for_object(object_**type, object_name)
>  * sort_by_dependency(list of [obj_type, obj_name])
>
> from this you could easily construct most uses, especially if
> sort_by_dependency(list of [obj_type, obj_name])
> would be smart enough to break circular dependencies, like
> turning to tables with mutual FK-s into tabledefs without
> FKs + separate constraints.
>
>
+1

This is an excellent idea. This would allow doing all kinds of crazy things
outside of the scope of pg_dump.

2 years ago I was working on a system to version control the schema, inside
the database.
Don't know if it's a good idea or not, but one thing which bugged me a lot
was the lack of pg_get_[object type]def(oid) functions for all different
object types.
It also turned out to be quite complicated to do the pg_depend topological
sort yourself. I managed eventually, but it was running to slow because I
had to pass the entire content of pg_depend to a plperl function I wrote.

With this in place I would be motivated enough to resume my old project,
which is still online at https://github.com/gluefinance/pov if anyone is
interested.

Is it really necessary to write all the missing pg_get_[object
type]def(oid) functions in C? I think it would be quite easy to put them
together using pure SQL, you wouldn't even need PL/pgSQL.

This old view I once wrote manage to produce working create and drop
statements for most object types using SQL only:
https://github.com/gluefinance/pov/blob/master/sql/schema/pov/views/pg_depend_definitions.sql

It would also be nice with functions which returned the proper command to
DROP an object. I need it in this project in order to do schema
modifications where objects have to be dropped/recreated in a particular
order to not break dependencies. Perhaps there are other use cases out
there.

Re: [HACKERS] doc hdparm also support SATA

2013-04-20 Thread Peter Eisentraut 
On Sun, 2013-04-07 at 14:29 +0800, Jov wrote:
> from the pg doc：
> http://www.postgresql.org/docs/devel/static/wal-reliability.html :On Linux,
> IDE drives can be queried using hdparm -I; write caching is enabled if
> there is a * next to Write cache. hdparm -W 0 can be used to turn off write
> caching. SCSI drives can be queried using
> sdparm.
> Use sdparm --get=WCE to check whether the write cache is enabled and sdparm
> --clear=WCE to disable it.
> 
> from the hdparm man page :
> http://linux.die.net/man/8/hdparm :hdparm - get/set SATA/IDE device
> parameters
> 
> so,the doc is out date, it should mention hdparm also support SATA.

done



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

[HACKERS] Checksum failures generate warnings

2013-04-20 Thread Bruce Momjian 
Do we really want to generate just a warning for a checksum failure, and
not an error;  see PageIsVerified().

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

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


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