[HACKERS] Re: [GENERAL] Symbols and versioning of binary releases; running a symbol server
On Thu, Jun 16, 2011 at 02:52, Craig Ringer cr...@postnewspapers.com.au wrote: Hi (EnterpriseDB) folks I've been working with someone off list to get some information about a crash they encounter during a batch run. We're generating a crash dump, but I'm having some issues getting matching symbols so I can examine it. One thing that would help with this would be if the EnterpriseDB releases included their build revision in the output of SELECT version(), so it's always clear exactly what build is in use. I've also noticed in this process that the File version on postgres.exe bears no apparent relationship to the EnterpriseDB release number. For example, postgresql 8.4.2-2 has a File Version of 8.4.2-104 while 8.4.2-1 has a file version of (IIRC) 8.4.2-9343 . Is there any way that can be improved? 1) This is not actually an EnterpriseDB thing - those versions and stamps are set by the build system 2) Why -general, and not -hackers? ;) I'll move it... To get to your points: The last digit of the version number is actually the build *day*. It's calculated by the formula: my $d = ($year - 100) . $yday; I have a feeling we've overflowed that field. The value today should'äve been 11166. I think we overflowed it when the year turned 2000, without noticing! The docs claim it's a 16 bit integer though, which should've worked. We could (once we've figured out why it's wrong) put that number in the version string as well. Or some other number - if we can pick a good one. I don't think the EDB installers should have a *different* string than what you'd get if you built the same thing manually... Even better would be to put zipped symbols directories onto the EDB download site, arranged by Pg version. Bonus points for having symlinks from the Or right alongside the downloads themselves. md5sum of postgres.exe to the matching symbols. Better again would be to run a public symbol server with symbols for all builds EnterpriseDB releases: http://chadaustin.me/2009/03/reporting-crashes-in-imvu-creating-your-very-own-symbol-server/ ... so there's no need to play version guessing games, you just point your debugger at the symbol server and it fetches what it needs on demand. Come to think of it, I can probably run a public symbol server myself if the EDB folks don't want to, but it'd be lovely if they were willing to do so because it could be integrated into the release process to ensure symbols were never missing for a build that hit public release. Hmm. That site talks about sharing them over a windows fileshar,e I doubt anybody wants to do that publically. Now, if this can be made to serve off a simple http (or ftp) server, we could probably run a server for it off the infrastructure - but that's assuming someone actually uploads the symbols as builds are created ;) And it requires the server not to be windows, and using simple protocols... -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] [Streaming] Datum compression
Hello, I think about following functionality to add to streaming. In some way earlier or later soemone will add possibility for gzip communication. As I try to make streaming, I wonder if it is possible to change TOAST compression to GZIP/zLib, currently is LZMA. I want to make this: if user want to use compression during communication, server will be able to send compressed datum, instead of doing recompression. GZIP is actually quite popular, and skipping plain Windows C, it's supported on all driver platforms, including Java and .NET. What do You think about this approach. Regards, Radek. -- 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] Keywords in pg_hba.conf should be field-specific
2011/6/15 Pavel Stehule pavel.steh...@gmail.com: Hello I try to apply your patch, but it is finished with some failed hinks. Please, can you refresh your patch Regards Pavel [pavel@nemesis postgresql]$ patch -p1 pghba.patch patching file src/backend/libpq/hba.c Hunk #1 succeeded at 45 (offset 2 lines). Hunk #2 succeeded at 56 (offset 2 lines). Hunk #3 succeeded at 120 (offset 2 lines). Hunk #4 succeeded at 212 (offset 2 lines). Hunk #5 succeeded at 244 (offset 2 lines). Hunk #6 succeeded at 286 (offset 2 lines). Hunk #7 succeeded at 327 (offset 2 lines). Hunk #8 succeeded at 363 (offset 2 lines). Hunk #9 succeeded at 372 (offset 2 lines). Hunk #10 succeeded at 411 (offset 2 lines). Hunk #11 FAILED at 470. Hunk #12 succeeded at 783 (offset 4 lines). Hunk #13 FAILED at 795. Hunk #14 succeeded at 866 (offset 25 lines). Hunk #15 succeeded at 882 (offset 25 lines). Hunk #16 succeeded at 899 (offset 25 lines). Hunk #17 succeeded at 918 (offset 25 lines). Hunk #18 succeeded at 939 (offset 25 lines). Hunk #19 succeeded at 972 (offset 25 lines). Hunk #20 succeeded at 989 (offset 25 lines). Hunk #21 FAILED at 995. Hunk #22 succeeded at 1034 (offset 25 lines). Hunk #23 succeeded at 1102 (offset 25 lines). Hunk #24 succeeded at 1112 (offset 25 lines). Hunk #25 succeeded at 1167 (offset 25 lines). Hunk #26 FAILED at 1178. Hunk #27 succeeded at 1255 (offset 25 lines). Hunk #28 succeeded at 1267 (offset 25 lines). Hunk #29 succeeded at 1360 (offset 25 lines). Hunk #30 succeeded at 1657 (offset 25 lines). Hunk #31 succeeded at 1686 (offset 25 lines). Hunk #32 succeeded at 1834 (offset 25 lines). Hunk #33 succeeded at 1845 (offset 25 lines). Hunk #34 succeeded at 2006 (offset 25 lines). Hunk #35 succeeded at 2074 (offset 25 lines). 4 out of 35 hunks FAILED -- saving rejects to file src/backend/libpq/hba.c.rej patching file src/include/libpq/hba.h -- 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] creating CHECK constraints as NOT VALID
On Wed, Jun 15, 2011 at 7:08 PM, Alvaro Herrera alvhe...@commandprompt.com wrote: Yeah, nothing serious. Updated patch attached. The wording in the doc changes could probably use some look over. looks good to me... at least it compiles, and function as i would expect... tomorrow i will read the code more carefully and look at the docs, but probably this is just fine to be commited... -- Jaime Casanova www.2ndQuadrant.com Professional PostgreSQL: Soporte 24x7 y capacitación -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [WIP] Support for ANY/ALL(array) op scalar (Was: Re: [HACKERS] Boolean operators without commutators vs. ALL/ANY)
On Jun16, 2011, at 04:19 , Tom Lane wrote: Florian Pflug f...@phlo.org writes: Comments are extremely welcome, especially ones regarding the overall approach taken in this patch. If people consider that to be acceptable, I'd try to add the missing features and add documentation. Quite honestly, I don't like this one bit and would rather you not pursue the idea. There is no such syntax in the standard, and presumably that's not because the SQL committee never thought of it. They may have some incompatible idea in mind for the future, who knows? The SQL standard doesn't have CREATE OPERATOR though, so for them the asymmetry of the ANY/ALL constructs don't translate to a missing feature, though. For us, however it does. We might try to doge that by decreeing that boolean operators better have commutators, but that doesn't help for non-core-defined operators. So I'd very much like us to provide some way to get the effect of ANY/ALL op scalar without having to resort to UNNEST and BOOL_AND/OR. But I'm absolutely not wedded to the syntax ANY/ALL op scalar. One other idea I've been kicking around is to generate commutators automatically for all binary operators that return boolean. If no name for the commutator is specified (i.e. if CREATE OPERATOR is called without a value for COMMUTATOR), it's be named COMMUTATOR op, and would thus be useably only via OPERATOR(...). Implementation-wise we'd need to add a flag to FmgrInfo which tells the fmgr to swap the function's arguments, and would need to centralize the translation of operator OIDs to FmgrInfos. best regards, Florian Pflug -- 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] WIP: Fast GiST index build
Actually, I would like to measure CPU and IO load independently for more comprehensive benchmarks. Can you advice me some appropriate tools for it? -- With best regards, Alexander Korotkov.
[HACKERS] Re: [GENERAL] Symbols and versioning of binary releases; running a symbol server
On 16/06/2011 2:47 PM, Magnus Hagander wrote: We could (once we've figured out why it's wrong) put that number in the version string as well. Or some other number - if we can pick a good one. I don't think the EDB installers should have a *different* string than what you'd get if you built the same thing manually... In this case a different (or additional) string for EDB releases is exactly what I'm after - a string that uniquely identifies a release made with an EDB installer, so that 8.4.2-1 can be reliably identified as separate from 8.4.2-2 and separate again from a hand-built Pg or a .zip release. Maybe an attribute other than File Version can be used, as custom attributes can IIRC be defined easily. That said, it turns out it doesn't matter much if you have a proper symbols cache maintained by symstore.exe . It just figures it out based on the hash of the binary, so you don't need to know exactly what release you're using. Even better would be to put zipped symbols directories onto the EDB download site, arranged by Pg version. Bonus points for having symlinks from the Or right alongside the downloads themselves. Well, they're already in the installer bundles. It'd just be nice to have an easily browsed directory of all the old versions, one that didn't require downloading and unpacking the installer for that version. To download 8.4.2-2 at all I had to go to download the latest EDB release, note the URL and play substitution games. Maybe I just didn't find the old versions link that'll turn out to be lurking somewhere. Again, though, a proper symbols server would pretty much take care of this problem. Hmm. That site talks about sharing them over a windows fileshar,e I doubt anybody wants to do that publically. Oops. The Microsoft symbol server serves over HTTP and I hadn't noticed that the proposed method in that article was SMB as I was rushing off to work when I finished that post. It looks like running your own symbol over http is simple, though. Just expose the directory tree created by symstore.exe over http. No Windows-specific stuff required. I just tested it out with a local Apache instance and it works fine. Most instructions talk about symproxy.exe but it turns out you don't need that unless you want to run a proxy for Microsoft's symbol server. That's is undesirable and unnecessary in a public symbol server. It'd be pretty trivial to rsync a copy of the symbols directory created by symstore.exe from the build host over to a public web server, so offering an http symbol server looks quite painless. As for adding the symbols, that just needs to be part of the release process, such that an EDB release can't get to the download page without first having had its symbols added to the store. The Windows symstore command from Debugging Tools for Windows is requried to update the symbol store. It's invoked as: C:\Program Files\PostgreSQL\8.4symstore add /s C:\Users\Craig\Developer\PgSymbols /t PostgreSQL /v 9.0.0-1 /compress /r /f C:\Program Files\PostgreSQL\9.0 to store to a local symbol store C:\Users\Craig\Developer\PgSymbols . If used for a public server that would be a local or UNC path to a directory that was getting rsync'd to a public web server instead. -- Craig Ringer Tech-related writing at http://soapyfrogs.blogspot.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] .gitignore for some of cygwin files
On tor, 2011-06-09 at 16:25 +0200, Magnus Hagander wrote: Based on this list, a global exclude for *.exe and lib*dll.def seems reasonable. We already have finer-grained excludes for various lib*dll.def variations in the libpq and ecpg subdirectories. Those should be cleaned up if we are adding a global one. -- 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] Re: [GENERAL] Symbols and versioning of binary releases; running a symbol server
On Thu, Jun 16, 2011 at 11:31 AM, Craig Ringer cr...@postnewspapers.com.au wrote: In this case a different (or additional) string for EDB releases is exactly what I'm after - a string that uniquely identifies a release made with an EDB installer, so that 8.4.2-1 can be reliably identified as separate from 8.4.2-2 and separate again from a hand-built Pg or a .zip release. That's not feasible, as the -x part of the number is the installer build number and is unrelated to the build of the binaries. We regularly rebuild the installers to fix minor issues without rebuilding the binaries. To download 8.4.2-2 at all I had to go to download the latest EDB release, note the URL and play substitution games. Maybe I just didn't find the old versions link that'll turn out to be lurking somewhere. I'm not sure I understand the problem. We ship the symbols in the package, so why did you have to go looking for an old version to debug an issue? -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: 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
Re: [HACKERS] Re: [GENERAL] Symbols and versioning of binary releases; running a symbol server
On 16/06/2011 6:38 PM, Dave Page wrote: To download 8.4.2-2 at all I had to go to download the latest EDB release, note the URL and play substitution games. Maybe I just didn't find the old versions link that'll turn out to be lurking somewhere. I'm not sure I understand the problem. We ship the symbols in the package, so why did you have to go looking for an old version to debug an issue? Because I was debugging a dump. I didn't have that version installed on my machine. I could've just got them to send a zipped copy of their symbols directory, too. It turns out that it doesn't matter whether individual releases can be perfectly identified; the symbol server indexer takes care of that. I'll just collect symbols from each release and pop them in my symbol cache so I don't have to worry in future. Publishing a complete symbol cache via a symbol server would be pretty handy, though. If needs be it's something I'll do, it'll just be harder for me to keep it up to date and not miss any releases. -- Craig Ringer Tech-related writing at http://soapyfrogs.blogspot.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] proposal: a validator for configuration files
Hi On May14, 2011, at 00:49 , Alexey Klyukin wrote: The patch forces the parser to report all errors (max 100) from the ProcessConfigFile/ParseConfigFp. Currently, only the first parse error or an invalid directive is reported. Reporting all of them is crucial to automatic validation of postgres config files. This patch is based on the one submitted earlier by Selena Deckelmann: http://archives.postgresql.org/pgsql-hackers/2009-03/msg00345.php It incorporates suggestions by Tom Lane for avoiding excessive bloat in logs in case there is a junk instead of postgresql.conf. http://archives.postgresql.org/pgsql-hackers/2009-03/msg01142.php Here's my review of your patch. The patch is in context diff format and applies cleanly to HEAD. It doesn't contain superfluous whitespace changes any more is and quite readable. First, the behaviour. The first problem I ran into when I tried to test this is that it *only* reports multiple errors during config file reload on SIHUP, not during postmaster startup. I guess it's been done that way because we ereport(ERROR,..) not ereport(LOG,...) during postmaster startup, so it's not immediatly clear how to report multiple errors. But that proplem seems solvable. What if you ereport(LOG,..)ed the individual errors during postmaster startup, and then emitted an ereport(ERROR) at the end if errors occurred? The ERROR could either repeat the first error that was encountered, or simply say config file contains errors. Now to the code. I see that you basically replaced goto cleanup... in both ParseConfigFp() and ProcessConfigFile() with ++errorcount, and arranged for ParseConfigFp() to return false, and for ProcessConfigFile() to skip the GUC updates if errorcount 0. The actual value of errorcount is never inspected. The value is also wrong in the case of include files containing more than error, since ParseConfigFp() simply increments errorcount by one for each failed ParseConfigFile() of an included file. I thus suggest that you replace errorcount with a boolean erroroccurred. You've also introduced a bug in ParseConfigFp(). Previously, if an included file contained an error, it did goto cleanup_exit() and thus didn't ereport() on it's own. With your patch applied it ereport()s a parse error at the location of the include directive, which seems wrong. Finally, I believe that ParseConfigFp() should make at least some effort to resync after hitting a parser error. I suggest that you simply fast-forward to the next GUC_EOL token after reporting a parser error. best regards, Florian Pflug -- 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] Latch implementation that wakes on postmaster death on both win32 and Unix
I had another quick look-over this patch, and realised that I made a
minor mistake:
+void
+ReleasePostmasterDeathWatchHandle(void)
+{
+ /* MyProcPid won't have been set yet */
+ Assert(PostmasterPid != getpid());
+ /* Please don't ask twice */
+ Assert(postmaster_alive_fds[POSTMASTER_FD_OWN] != -1);
+ /* Release parent's ownership fd - only postmaster should hold it */
+ if (close(postmaster_alive_fds[ POSTMASTER_FD_OWN]))
+ {
+ ereport(FATAL,
+ (errcode_for_socket_access(),
+errmsg(Failed to close file descriptor associated with
Postmaster death in child process %d, MyProcPid)));
+ }
+ postmaster_alive_fds[POSTMASTER_FD_OWN] = -1;
+}
+
MyProcPid is used in this errmsg, and as noted in the first comment,
it isn't expected to be initialised when
ReleasePostmasterDeathWatchHandle() is called. Therefore, MyProcPid
should be replaced with a call to getpid(), just as it is for
Assert(PostmasterPid != getpid()).
I suppose that you could take the view that MyProcPid ought to be
initialised before the function is called, but I thought this was the
least worst way. Better to do it this way than to touch all the
different ways in which MyProcPid might be initialised, I suspect.
--
Peter Geoghegan http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training and 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] Latch implementation that wakes on postmaster death on both win32 and Unix
On 16.06.2011 15:07, Peter Geoghegan wrote:
I had another quick look-over this patch, and realised that I made a
minor mistake:
+void
+ReleasePostmasterDeathWatchHandle(void)
+{
+ /* MyProcPid won't have been set yet */
+ Assert(PostmasterPid != getpid());
+ /* Please don't ask twice */
+ Assert(postmaster_alive_fds[POSTMASTER_FD_OWN] != -1);
+ /* Release parent's ownership fd - only postmaster should hold it */
+ if (close(postmaster_alive_fds[ POSTMASTER_FD_OWN]))
+ {
+ ereport(FATAL,
+ (errcode_for_socket_access(),
+errmsg(Failed to close file descriptor associated with
Postmaster death in child process %d, MyProcPid)));
+ }
+ postmaster_alive_fds[POSTMASTER_FD_OWN] = -1;
+}
+
MyProcPid is used in this errmsg, and as noted in the first comment,
it isn't expected to be initialised when
ReleasePostmasterDeathWatchHandle() is called. Therefore, MyProcPid
should be replaced with a call to getpid(), just as it is for
Assert(PostmasterPid != getpid()).
I suppose that you could take the view that MyProcPid ought to be
initialised before the function is called, but I thought this was the
least worst way. Better to do it this way than to touch all the
different ways in which MyProcPid might be initialised, I suspect.
Hmm, I'm not sure having the pid in that error message is too useful in
the first place. The process was just spawned, and it will die at that
error. When you try to debug that sort of error, what you would compare
the pid with? And you can include the pid in log_line_prefix if it turns
out to be useful after all.
PS. error messages should begin with lower-case letter.
--
Heikki Linnakangas
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] pg_upgrade using appname to lock out other users
* Bruce Momjian (br...@momjian.us) wrote: Right, we will re-check at the time they do the actual upgrade. This was requested so people can prepare for the real upgrade without having to stop their live server. Exactly. A very good thing to have, and something which I needed and would have been very upset to not have. My case was PostGIS being in the old cluster and not available in the new cluster. I had to fix that before moving forward, but I'm glad that didn't require shutting down the old cluster to find out. Thanks, Stephen signature.asc Description: Digital signature
[HACKERS] Patch - Debug builds without optimization
Hello,
I'm sending following patch which disables optimization when
--enable-debug is passed. It was nasty (for me, at least) that debug
build required passing of CFLAGS with -O0 to get nice traceable code.
Regards,
Radekdiff --git a/configure.in b/configure.in
old mode 100644
new mode 100755
index e6232af..3759645
--- a/configure.in
+++ b/configure.in
@@ -194,10 +194,10 @@ PGAC_ARG_BOOL(enable, spinlocks, yes,
[do not use spinlocks])
#
-# --enable-debug adds -g to compiler flags
+# --enable-debug adds -g and (-O0) to compiler flags
#
PGAC_ARG_BOOL(enable, debug, no,
- [build with debugging symbols (-g)])
+ [build with debugging symbols (-g) and no optimization (-O0)])
AC_SUBST(enable_debug)
#
@@ -402,7 +402,7 @@ unset CFLAGS
# If the user specifies something in the environment, that is used.
# else: If the template file set something, that is used.
# else: If coverage was enabled, don't set anything.
-# else: If the compiler is GCC, then we use -O2.
+# else: If the compiler is GCC, then we use -O2, unless debug is passed.
# else: If the compiler is something else, then we use -O, unless debugging.
if test $ac_env_CFLAGS_set = set; then
@@ -412,11 +412,18 @@ elif test ${CFLAGS+set} = set; then
elif test $enable_coverage = yes; then
: # no optimization by default
elif test $GCC = yes; then
- CFLAGS=-O2
+ # if the user selected debug mode, use -O0, instead of nothing equivalent to
+ # (-O1)
+ if test $enable_debug != yes; then
+CFLAGS=-O0
+ else
+CFLAGS=-O2
+ fi
else
- # if the user selected debug mode, don't use -O
+ # if the user selected debug mode, use -O0, instead of nothing equivalent to
+ # (-O1)
if test $enable_debug != yes; then
-CFLAGS=-O
+CFLAGS=-O0
fi
fi
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] reminder: buildfarm members need to add 9.1
We have branched somewhat earlier than has been usual for release 9.1. Buildfarm animal owners who have not already done so need to add REL9_1_STABLE to their rotations. 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] Latch implementation that wakes on postmaster death on both win32 and Unix
On 16 June 2011 13:15, Heikki Linnakangas heikki.linnakan...@enterprisedb.com wrote: Hmm, I'm not sure having the pid in that error message is too useful in the first place. The process was just spawned, and it will die at that error. When you try to debug that sort of error, what you would compare the pid with? And you can include the pid in log_line_prefix if it turns out to be useful after all. All fair points. FWIW, I think it's pretty unlikely that anyone will ever see this error message. -- Peter Geoghegan http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training and 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] Patch - Debug builds without optimization
On Thu, 16 Jun 2011 14:30:27 +0200, Radosław Smogura wrote:
Hello,
I'm sending following patch which disables optimization when
--enable-debug is passed. It was nasty (for me, at least) that debug
build required passing of CFLAGS with -O0 to get nice traceable code.
Regards,
Radek
Sorry for mess, this should be submited.
diff --git a/configure.in b/configure.in
old mode 100644
new mode 100755
index e6232af..47edf82
--- a/configure.in
+++ b/configure.in
@@ -194,10 +194,10 @@ PGAC_ARG_BOOL(enable, spinlocks, yes,
[do not use spinlocks])
#
-# --enable-debug adds -g to compiler flags
+# --enable-debug adds -g and (-O0) to compiler flags
#
PGAC_ARG_BOOL(enable, debug, no,
- [build with debugging symbols (-g)])
+ [build with debugging symbols (-g) and no optimization (-O0)])
AC_SUBST(enable_debug)
#
@@ -402,7 +402,7 @@ unset CFLAGS
# If the user specifies something in the environment, that is used.
# else: If the template file set something, that is used.
# else: If coverage was enabled, don't set anything.
-# else: If the compiler is GCC, then we use -O2.
+# else: If the compiler is GCC, then we use -O2, unless debug is passed.
# else: If the compiler is something else, then we use -O, unless debugging.
if test $ac_env_CFLAGS_set = set; then
@@ -412,7 +412,13 @@ elif test ${CFLAGS+set} = set; then
elif test $enable_coverage = yes; then
: # no optimization by default
elif test $GCC = yes; then
- CFLAGS=-O2
+ # if the user selected debug mode, use -O0, instead of nothing equivalent to
+ # (-O1)
+ if test $enable_debug == yes; then
+CFLAGS=-O0
+ else
+CFLAGS=-O2
+ fi
else
# if the user selected debug mode, don't use -O
if test $enable_debug != yes; then
--
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] Patch - Debug builds without optimization
On Jun16, 2011, at 14:30 , Radosław Smogura wrote: I'm sending following patch which disables optimization when --enable-debug is passed. It was nasty (for me, at least) that debug build required passing of CFLAGS with -O0 to get nice traceable code. Unfortunately, with some compilers (gcc, I'm looking at you) you get considerably fewer warnings with -O0 than with -O1, even if you specify -Wall. The reason seems to be that some of the warnings need information produces by some of the optimization passes. I usually use -O1 for debug builds, these are usually still at least somewhat debuggable with gdb. best regards, Florian Pflug -- 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] use less space in xl_xact_commit patch
With regards to the naming, I think it would be better if we kept XLOG_XACT_COMMIT record exactly as it is now, and make the second record an entirely new record called XLOG_XACT_COMMIT_FASTPATH. That way we retain backwards compatibility. If you'd like to rework like that please, otherwise I can take it from here if you'd like. I think I did it; while doing it, I think I've found a bug: I didn't update recoveryStopsHere. Please double check that, as I really don't know what I'm doing there... Should I also change the struct name from xl_xact_commit to xl_xact_commit_fast_path? How can I test it with weird stuff as subtransactions, shared cache invalidation messages...? make installcheck should cover those. Ok, all tests passed. commitlog_lessbytes_v3.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] use less space in xl_xact_commit patch
On Wed, Jun 15, 2011 at 10:55 AM, Leonardo Francalanci m_li...@yahoo.it wrote: On Wed, May 25, 2011 at 3:05 PM, Simon Riggs si...@2ndquadrant.com wrote: Leonardo, can you submit an updated version of this patch today that incorporates Simon's suggestion? Mmmh, maybe it was simpler than I thought; I must be missing something... patch attached No, I think it is that simple. Patch looks OK on initial eyeball. More detailed review to follow. With regards to the naming, I think it would be better if we kept XLOG_XACT_COMMIT record exactly as it is now, and make the second record an entirely new record called XLOG_XACT_COMMIT_FASTPATH. That way we retain backwards compatibility. If you'd like to rework like that please, otherwise I can take it from here if you'd like. How can I test it with weird stuff as subtransactions, shared cache invalidation messages...? make installcheck should cover those. -- 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] use less space in xl_xact_commit patch
On Thu, Jun 16, 2011 at 2:00 PM, Leonardo Francalanci m_li...@yahoo.it wrote: With regards to the naming, I think it would be better if we kept XLOG_XACT_COMMIT record exactly as it is now, and make the second record an entirely new record called XLOG_XACT_COMMIT_FASTPATH. That way we retain backwards compatibility. If you'd like to rework like that please, otherwise I can take it from here if you'd like. I think I did it; while doing it, I think I've found a bug: I didn't update recoveryStopsHere. Please double check that, as I really don't know what I'm doing there... Should I also change the struct name from xl_xact_commit to xl_xact_commit_fast_path? Yes please. How can I test it with weird stuff as subtransactions, shared cache invalidation messages...? make installcheck should cover those. Ok, all tests passed. Even better. Will review, thanks. -- 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] Small SSI issues
On 15.06.2011 19:10, Kevin Grittner wrote: There is an unnecessary include of predicate.h in nbtree.c we should delete. That seems safe enough. ... It seems like it might be a good idea to apply pgindent formating to the latest SSI changes, to minimize conflict on back-patching any bug fixes. I've attached a patch to do this formatting -- entirely whitespace changes from a pgindent run against selected files. Ok, committed the pgindent patch and removed the unnecessary include. -- Heikki Linnakangas 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] use less space in xl_xact_commit patch
On Thu, Jun 16, 2011 at 7:25 AM, Simon Riggs si...@2ndquadrant.com wrote: With regards to the naming, I think it would be better if we kept XLOG_XACT_COMMIT record exactly as it is now, and make the second record an entirely new record called XLOG_XACT_COMMIT_FASTPATH. That way we retain backwards compatibility. I liked your previous suggestion of commit and commit-with-info better. There's nothing particularly fast about this; it's just less info. So to speak. -- 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
Re: [HACKERS] Small SSI issues
On 15.06.2011 19:10, Kevin Grittner wrote: There is one issue you raised in this post: http://archives.postgresql.org/message-id/4def3194.6030...@enterprisedb.com Robert questioned whether it should be 9.1 material here: http://archives.postgresql.org/message-id/BANLkTint2i2fHDTdr=Xq3K=yrxegovg...@mail.gmail.com I posted a patch here: http://archives.postgresql.org/message-id/4defb16902250003e...@gw.wicourts.gov Should I put that patch into a 9.2 CF? Yeah. I've added it to the September commitfest. -- Heikki Linnakangas 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] use less space in xl_xact_commit patch
On Thu, Jun 16, 2011 at 9:22 AM, Robert Haas robertmh...@gmail.com wrote: On Thu, Jun 16, 2011 at 7:25 AM, Simon Riggs si...@2ndquadrant.com wrote: With regards to the naming, I think it would be better if we kept XLOG_XACT_COMMIT record exactly as it is now, and make the second record an entirely new record called XLOG_XACT_COMMIT_FASTPATH. That way we retain backwards compatibility. I liked your previous suggestion of commit and commit-with-info better. There's nothing particularly fast about this; it's just less info. So to speak. At any rate we shouldn't name the stuct one way (xl_xact_commit and xl_xact_commit_with_info) and the constants the other way (XLOG_XACT_COMMIT and XLOG_XACT_COMMIT_FASTPATH). They should match. -- 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
Re: [HACKERS] Patch - Debug builds without optimization
--On 16. Juni 2011 14:30:27 +0200 Radosław Smogura rsmog...@softperience.eu wrote: Hello, I'm sending following patch which disables optimization when --enable-debug is passed. It was nasty (for me, at least) that debug build required passing of CFLAGS with -O0 to get nice traceable code. -O0 hides bugs in your code (e.g. look at http://archives.postgresql.org/message-id/9714F5232AB2C4FCFCB392D5@amenophis and replies for an example to do it better). Doing this automatically on debug builds would be a step backwards. -- Thanks Bernd -- 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] patch: update README-SSI
On 15.06.2011 23:28, Dan Ports wrote: +SSI is based on the observation [2] that each snapshot isolation +anomaly corresponds to a cycle that contains a dangerous structure +of two adjacent rw-conflict edges: + + Tin -- Tpivot -- Tout +rw rw + +SSI works by watching for this dangerous structure, and rolling +back a transaction when needed to prevent any anomaly. This means it +only needs to track rw-conflicts between concurrent transactions, not +wr- and ww-dependencies. It also means there is a risk of false +positives, because not every dangerous structure corresponds to an +actual serialization failure. + +The PostgreSQL implementation uses two additional optimizations: + +* Tout must commit before any other transaction in the cycle + (see proof of Theorem 2.1 of [2]). We only roll back a transaction + if Tout commits before Tpivot and Tin. + +* if Tin is read-only, there can only be an anomaly if Tout committed + before Tin takes its snapshot. This optimization is an original + one. Proof: + + - Because there is a cycle, there must be some transaction T0 that +precedes Tin in the serial order. (T0 might be the same as Tout). + + - The dependency between T0 and Tin can't be a rw-conflict, +because T1 was read-only, so it must be a ww- or wr-dependency. +Those can only occur if T0 committed before T1 started. There's no mention on what T1 is. I believe it's supposed to be Tin, in the terminology used in the graph. I don't see how there can be a ww-dependency between T0 and Tin. There can't be a rw-conflict because Tin is read-only, so surely there can't be a ww-conflict either? (the proof is still valid, though) + - Because Tout must commit before any other transaction in the +cycle, it must commit before T0 commits -- and thus before T1 +starts. Another reference to T1. Patch looks good otherwise. -- Heikki Linnakangas 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] use less space in xl_xact_commit patch
On Thu, Jun 16, 2011 at 2:22 PM, Robert Haas robertmh...@gmail.com wrote: On Thu, Jun 16, 2011 at 7:25 AM, Simon Riggs si...@2ndquadrant.com wrote: With regards to the naming, I think it would be better if we kept XLOG_XACT_COMMIT record exactly as it is now, and make the second record an entirely new record called XLOG_XACT_COMMIT_FASTPATH. That way we retain backwards compatibility. I liked your previous suggestion of commit and commit-with-info better. There's nothing particularly fast about this; it's just less info. So to speak. The important thing is that we retain backwards compatibility with current XLOG_XACT_COMMIT. I'm not worried what we call the other one. -- 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] use less space in xl_xact_commit patch
The important thing is that we retain backwards compatibility with current XLOG_XACT_COMMIT. I'm not worried what we call the other one. Ok, let me see if I got it right: #define XLOG_XACT_COMMIT0x00 should become: #define XLOG_XACT_COMMIT_WITH_INFO 0x00 and I'll add a #define XLOG_XACT_COMMIT 0x60 Than I'll leave 2 structs, xl_xact_commit_with_info and xl_xact_commit. Leonardo -- 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_upgrade using appname to lock out other users
Tom Lane wrote: Ross J. Reedstrom reeds...@rice.edu writes: As an operations guy, the idea of an upgrade using a random, non-repeatable port selection gives me the hebejeebees. Yeah, I agree. The latest version of the patch doesn't appear to have any random component to it, though --- it just expects the user to provide port numbers as switches. Oh, you wanted pg_upgrade to pick a random port number? I can do that, but how would it check to see it is unused? -- Bruce Momjian br...@momjian.ushttp://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] Why polecat and colugos are failing to build back branches
On Jun 15, 2011, at 7:51 PM, Tom Lane t...@sss.pgh.pa.us wrote: ... installation paths. About the only good thing to be said about it is that these characters are so troublesome that Unix users are unlikely to use them in directory names anyway. So I'm guessing you don't want this path name? I was going to throw some \n and in it also, maybe some *,' and for good measure -) Shall I just stick with spaces? drwxr-xr-x 2 Robert wheel68B Jun 15 17:26 pg bu!ldfa$m\a\$y/ Robert-Creagers-iMac:src Robert$ Later, Rob -- 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] procpid?
On 06/15/2011 04:13 AM, Rainer Pruy wrote: I much prefer reading an IDLE in transaction on a quick glance over having to search a column and recognize a t from an f to find out whether there is a transaction pending or not. This is a fair observation. If we provide a second view here that reorganizes the data toward something more appropriate for monitoring systems to process it, you may be right that the result will be a step backwards for making it human-readable. They may end up being similar, co-existing views aimed at different uses, rather than one clearly replacing the other one day. -- Greg Smith 2ndQuadrant USg...@2ndquadrant.com Baltimore, MD PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.us -- 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] [Streaming] Datum compression
=?utf-8?q?Rados=C5=82aw_Smogura?= rsmog...@softperience.eu writes: I think about following functionality to add to streaming. In some way earlier or later soemone will add possibility for gzip communication. As I try to make streaming, I wonder if it is possible to change TOAST compression to GZIP/zLib, currently is LZMA. I want to make this: if user want to use compression during communication, server will be able to send compressed datum, instead of doing recompression. GZIP is actually quite popular, and skipping plain Windows C, it's supported on all driver platforms, including Java and .NET. What do You think about this approach. The fact that TOAST depends on a non-gzip compressor is intentional. The code that's there is faster than gzip, IIRC, and also there is no problem with it possibly not being available on a particular system. You haven't provided any justification that would overrule these reasons. 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] psql describe.c cleanup
On Wed, Jun 15, 2011 at 9:01 AM, Merlin Moncure mmonc...@gmail.com wrote: On Tue, Jun 14, 2011 at 9:08 PM, Josh Kupershmidt schmi...@gmail.com wrote: On Tue, Jun 14, 2011 at 12:15 PM, Merlin Moncure mmonc...@gmail.com wrote: What I do wonder though is if the ; appending should really be happening in printQuery() instead of in each query -- the idea being that formatting for external consumption should be happening in one place. Maybe that's over-thinking it though. That's a fair point, and hacking up printQuery() would indeed solve my original gripe about copy-pasting queries out of psql -E. But more generally, I think that standardizing the style of the code is a Good Thing, particularly where style issues impact usability (like here). sure -- if anyone would like to comment on this one way or the other feel free -- otherwise I'll pass the patch up the chain as-is...it's not exactly the 'debate of the century' :-). done. marked ready for committer. merlin -- 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_upgrade using appname to lock out other users
On Thu, Jun 16, 2011 at 09:48:12AM -0400, Bruce Momjian wrote: Tom Lane wrote: Ross J. Reedstrom reeds...@rice.edu writes: As an operations guy, the idea of an upgrade using a random, non-repeatable port selection gives me the hebejeebees. Yeah, I agree. The latest version of the patch doesn't appear to have any random component to it, though --- it just expects the user to provide port numbers as switches. Oh, you wanted pg_upgrade to pick a random port number? I can do that, but how would it check to see it is unused? Oh, no! Lost in translation - randomness in this context would be bad. Heebee-jeebees (usual spelling, I guess) (idiom) used to describe a feeling of anxiety, apprehension, depression or illness http://en.wikipedia.org/wiki/Heebie-jeebies Ross -- Ross Reedstrom, Ph.D. reeds...@rice.edu Systems Engineer Admin, Research Scientistphone: 713-348-6166 Connexions http://cnx.orgfax: 713-348-3665 Rice University MS-375, Houston, TX 77005 GPG Key fingerprint = F023 82C8 9B0E 2CC6 0D8E F888 D3AE 810E 88F0 BEDE -- 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] Patch - Debug builds without optimization
Florian Pflug f...@phlo.org writes: On Jun16, 2011, at 14:30 , RadosÅaw Smogura wrote: I'm sending following patch which disables optimization when --enable-debug is passed. It was nasty (for me, at least) that debug build required passing of CFLAGS with -O0 to get nice traceable code. Unfortunately, with some compilers (gcc, I'm looking at you) you get considerably fewer warnings with -O0 than with -O1, even if you specify -Wall. Yes. There is *zero* chance of this being accepted, because it would break a lot of warnings that developers need to see. I usually use -O1 for debug builds, these are usually still at least somewhat debuggable with gdb. I tend to do that too, but I still think that folding it into --enable-debug would be a mistake. The normal assumption (at least when using gcc) is that --enable-debug doesn't cost any performance. We would annoy many people, especially packagers, if that stopped being true. I could see providing some other nonstandard configure switch that changed the default -O level ... but realistically, would that do anything that you couldn't already do by setting CFLAGS, ie ./configure CFLAGS=-O0 -g 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] Latch implementation that wakes on postmaster death on both win32 and Unix
Peter Geoghegan wrote:
--- 247,277
* do that), and the select() will return immediately.
*/
drainSelfPipe();
! if (latch-is_set (wakeEvents WL_LATCH_SET))
! {
! result |= WL_LATCH_SET;
! found = true;
! /*
!* Leave loop immediately, avoid blocking again.
!* Since latch is set, no other factor could have
!* coincided that could make us wake up
!* independently of the latch being set, so no
!* need to worry about having missed something.
!*/
break;
}
I don't understand that comment. Why can't e.g postmaster death happen
at the same time as a latch is set? I think the code is fine as it is,
we just need to document that if there are several events that would
wake up WaitLatch(), we make no promise that we return all of them in
the return value. I believe all the callers would be fine with that.
--
Heikki Linnakangas
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] procpid?
Since the CF is upon us and discussion is settling, let's see if I can wrap this bikeshedding up into a more concrete proposal that someone can return to later. The ideas floating around have gelled into: -Add a new pg_stat_sessions function that is implemented similarly to pg_stat_activity. For efficiency and simplicity sake, internally this will use the same sort of SRF UI that pg_stat_get_activity does inside src/backend/utils/adt/pgstatfuncs.c There will need to be some refactoring here to reduce code duplication between that and the new function (which will presumably named pg_stat_get_sessions) -The process ID field here will be named pid to match other system views, rather than the current procpid -State information such as whether the session is idle, idle in a transaction, or has a query visible to this backend will be presented as booleans similar to the current waiting field. A possible additional state to expose is the concept of active, which ends up being derived using logic like visible !idle !idle_transaction !waiting in some monitoring systems. -A case could be made for making some of these state fields null, instead true or false, in situations where the session is not visible. If you don't have rights to see the connection activity, setting idle, idle_transaction, and active all to null may be the right thing to do. More future bikeshedding is likely on this part, once an initial patch is ready for testing. I'd want to get some specific tests against the common monitoring goals of tools like check_postgres and the Munin plug-in to see which implementation makes more sense for them as input on that. -It is still useful to set current_query to descriptive text in the cases where the transaction is IDLE etc. That text is not ambiguous with a real query, it is useful for a human-readable view, and it improves the potential for pg_stat_sessions to fully replace a deprecated pg_stat_activity (instead of just co-existing with it). That the query text is overloaded with this information seems agreed to be a good thing; it's just that filtering on the state information there should not require parsing it. The additional booleans will handle that. If idle sessions can be filtered using WHERE NOT idle, whether the current_query for them reads IDLE or is null won't matter to typical monitoring use. Given no strong preference there, using IDLE is both familiar and more human readable. I'll go add this as a TODO now. -- Greg Smith 2ndQuadrant USg...@2ndquadrant.com Baltimore, MD PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.us -- 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] use less space in xl_xact_commit patch
Robert Haas robertmh...@gmail.com writes: On Thu, Jun 16, 2011 at 7:25 AM, Simon Riggs si...@2ndquadrant.com wrote: With regards to the naming, I think it would be better if we kept XLOG_XACT_COMMIT record exactly as it is now, and make the second record an entirely new record called XLOG_XACT_COMMIT_FASTPATH. That way we retain backwards compatibility. I liked your previous suggestion of commit and commit-with-info better. There's nothing particularly fast about this; it's just less info. So to speak. Yes. There is no need to preserve backwards compatibility here, so let's just design the records in a way that makes sense on its own. 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] Why polecat and colugos are failing to build back branches
Robert Creager rob...@logicalchaos.org writes: On Jun 15, 2011, at 7:51 PM, Tom Lane t...@sss.pgh.pa.us wrote: installation paths. About the only good thing to be said about it is that these characters are so troublesome that Unix users are unlikely to use them in directory names anyway. So I'm guessing you don't want this path name? I was going to throw some \n and in it also, maybe some *,' and for good measure -) Shall I just stick with spaces? drwxr-xr-x 2 Robert wheel68B Jun 15 17:26 pg bu!ldfa$m\a\$y/ Robert-Creagers-iMac:src Robert$ There seems to be about no chance of making that work :-(. In practice, names with spaces seem to be the only cases we've heard complaints about, so I doubt it's worth getting worked up over. 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] Patch - Debug builds without optimization
On Jun16, 2011, at 16:10 , Tom Lane wrote: Florian Pflug f...@phlo.org writes: I usually use -O1 for debug builds, these are usually still at least somewhat debuggable with gdb. I tend to do that too, but I still think that folding it into --enable-debug would be a mistake. +1. I didn't mean to suggest we fold -O1 into --enable-debug, I was just handling out advice to the OP ;-) best regards, Florian Pflug -- 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] On-the-fly index tuple deletion vs. hot_standby
On Thu, Jun 16, 2011 at 12:02:47AM +0100, Simon Riggs wrote: On Tue, Jun 14, 2011 at 5:28 AM, Noah Misch n...@leadboat.com wrote: On Mon, Jun 13, 2011 at 04:16:06PM +0100, Simon Riggs wrote: On Mon, Jun 13, 2011 at 3:11 AM, Robert Haas robertmh...@gmail.com wrote: On Sun, Jun 12, 2011 at 3:01 PM, Noah Misch n...@leadboat.com wrote: Assuming that conclusion, I do think it's worth starting with something simple, even if it means additional bloat on the master in the wal_level=hot_standby + vacuum_defer_cleanup_age / hot_standby_feedback case. In choosing those settings, the administrator has taken constructive steps to accept master-side bloat in exchange for delaying recovery conflict. ?What's your opinion? I'm pretty disinclined to go tinkering with 9.1 at this point, too. Not least because a feature already exists in 9.1 to cope with this problem: hot standby feedback. A standby's receipt of an XLOG_BTREE_REUSE_PAGE record implies that the accompanying latestRemovedXid preceded or equaled the master's RecentXmin at the time of issue (see _bt_page_recyclable()). ?Neither hot_standby_feedback nor vacuum_defer_cleanup_age affect RecentXmin. ?Therefore, neither facility delays conflicts arising directly from B-tree page reuse. ?See attached test script, which yields a snapshot conflict despite active hot_standby_feedback. OK, agreed. Bug. Good catch, Noah. Fix is to use RecentGlobalXmin for the cutoff when in Hot Standby mode, so that it is under user control. Attached patch will be applied to head and backpatched to 9.1 and 9.0 to fix this. Thanks. We still hit a conflict when btpo.xact == RecentGlobalXmin and the standby has a transaction older than any master transaction. This happens because the tests at nbtpage.c:704 and procarray.c:1843 both pass when the xid exactly is that of the oldest standby transaction (line numbers as of git cb94db91b). I only know this because the test script from my last message hits this case; it might never get hit in real usage. Still, seems like a hole not worth leaving. I think the most-correct fix is to TransactionIdRetreat the btpo.xact before using it as xl_btree_reuse_page.lastestRemovedXid. btpo.xact is the first known-safe xid, but latestRemovedXid is the last known-unsafe xmin. nm -- 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] Latch implementation that wakes on postmaster death on both win32 and Unix
On 16 June 2011 15:27, Heikki Linnakangas heikki.linnakan...@enterprisedb.com wrote: I don't understand that comment. Why can't e.g postmaster death happen at the same time as a latch is set? I think the code is fine as it is, we just need to document that if there are several events that would wake up WaitLatch(), we make no promise that we return all of them in the return value. I believe all the callers would be fine with that. I see your perspective...there is a window for the Postmaster to die after the latch is set, but before it returns control to clients, and this won't be reported. I would argue that Postmaster death didn't actually coincide with the latch being set, because it didn't actually cause the select() to unblock, and therefore we don't have a responsibility to report it. Even if that view doesn't stand up to scrutiny, and it may not, it is a fairly academic point, because, as you say, it's unlikely that clients will ever much care. I'd be happy to document that we make no promises, on the off chance that some future caller might care. -- Peter Geoghegan http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training and 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] Re: Latch implementation that wakes on postmaster death on both win32 and Unix
On May26, 2011, at 11:25 , Peter Geoghegan wrote: I'm a bit disappointed that no one has commented on this yet. I would have appreciated some preliminary feedback. I noticed to your patch doesn't seem to register a SIGIO handler, i.e. it doesn't use async IO machinery (or rather a tiny part thereof) to get asynchronously notified if the postmaster dies. If that is on purpose, you can remove the fsetown() call, as it serves no purpose without such a handler I think. Or, you might want to add such a signal handler, and make it simply do kill(getpid(), SIGTERM). best regards, Florian Pflug -- 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] Patch - Debug builds without optimization
On 06/16/2011 10:10 AM, Tom Lane wrote: I could see providing some other nonstandard configure switch that changed the default -O level ... but realistically, would that do anything that you couldn't already do by setting CFLAGS, ie ./configure CFLAGS=-O0 -g I think a small discussion of the issue Radek ran into is appropriate to put somewhere, with this example. The install procedure section of the docs already includes a CFLAGS example: ./configure CC=/opt/bin/gcc CFLAGS='-O2 -pipe' There is also a section talking about setting options like --enable-cassert in the Developer's FAQ. Looking at all the info out there about developer/debug builds, it's really kind of sketchy and distributed though. No one place that pulls all the most common things people need together into one resource. What seems like the idea solution here is to add a new section to the install procedure with brief coverage of this entire area. Here's a prototype of text that might go there: = Installation for development and debugging = When modifying the PostgreSQL source code, or when trying to find the source of a bug in the program, it may be helpful to build the program in a way that makes this process easier. There are build-time only changes that enable better error checking and debugging, including: Pass --enable-cassert to configure. This can make bugs more visible, because they cause operations to abort with a clear error. That makes some types of debugging much easier. This is risky on a production server, as described in the documentation for this parameter. Pass --enable-debug to configure. This provides better information about what the server is doing when looking at it using a debugger. It's less risky to a production server than enabling assertions, and it normally has less of a performance impact hgtoo. See its documentation for more details. Disable compiler optimization. When using a debugger to trace into the source code of the server, steps may optimized away by the normal build process. In some situations --enable-debug will disable such optimization, but this is not always the case. Specifically disabling optimization is possible with many compilers by setting the compiler flags when configuration the source code build, such as: ./configure CFLAGS=-O0 -g This example for the gcc compiler disables optimizations, and tells the compiler to provide extra debugging information most useful with the gdb debugger. -- Greg Smith 2ndQuadrant USg...@2ndquadrant.com Baltimore, MD PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.us -- 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_upgrade using appname to lock out other users
On Thu, Jun 16, 2011 at 1:48 PM, Bruce Momjian br...@momjian.us wrote: Tom Lane wrote: Ross J. Reedstrom reeds...@rice.edu writes: As an operations guy, the idea of an upgrade using a random, non-repeatable port selection gives me the hebejeebees. Yeah, I agree. The latest version of the patch doesn't appear to have any random component to it, though --- it just expects the user to provide port numbers as switches. Oh, you wanted pg_upgrade to pick a random port number? I can do that, but how would it check to see it is unused? If no port is specified, that *might* be a reasonable behavior, but it certainly throws in a dose of the wrong sort of nondeterminism, hence heebie-jeebies... -- When confronted by a difficult problem, solve it by reducing it to the question, How would the Lone Ranger handle this? -- 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] proposal: a validator for configuration files
Florian, On Jun 16, 2011, at 2:34 PM, Florian Pflug wrote: Hi On May14, 2011, at 00:49 , Alexey Klyukin wrote: The patch forces the parser to report all errors (max 100) from the ProcessConfigFile/ParseConfigFp. Currently, only the first parse error or an invalid directive is reported. Reporting all of them is crucial to automatic validation of postgres config files. This patch is based on the one submitted earlier by Selena Deckelmann: http://archives.postgresql.org/pgsql-hackers/2009-03/msg00345.php It incorporates suggestions by Tom Lane for avoiding excessive bloat in logs in case there is a junk instead of postgresql.conf. http://archives.postgresql.org/pgsql-hackers/2009-03/msg01142.php Here's my review of your patch. The patch is in context diff format and applies cleanly to HEAD. It doesn't contain superfluous whitespace changes any more is and quite readable. First, the behaviour. The first problem I ran into when I tried to test this is that it *only* reports multiple errors during config file reload on SIHUP, not during postmaster startup. I guess it's been done that way because we ereport(ERROR,..) not ereport(LOG,...) during postmaster startup, so it's not immediatly clear how to report multiple errors. But that proplem seems solvable. What if you ereport(LOG,..)ed the individual errors during postmaster startup, and then emitted an ereport(ERROR) at the end if errors occurred? The ERROR could either repeat the first error that was encountered, or simply say config file contains errors. Makes sense. One problem I came across is that set_config_option from guc.c sets the elevel by itself. I've changed it to emit LOG errors on PGC_S_FILE source, apparently all the callers of this function with this source are from guc-file.l, so hopefully I won't break anything with this change. Now to the code. I see that you basically replaced goto cleanup... in both ParseConfigFp() and ProcessConfigFile() with ++errorcount, and arranged for ParseConfigFp() to return false, and for ProcessConfigFile() to skip the GUC updates if errorcount 0. The actual value of errorcount is never inspected. The value is also wrong in the case of include files containing more than error, since ParseConfigFp() simply increments errorcount by one for each failed ParseConfigFile() of an included file. I thus suggest that you replace errorcount with a boolean erroroccurred. I can actually pass errorcount down from the ParseConfigFp() to report the total number of errors (w/ the include files) at the end of ProcessConfigFile if there is any interest in having the number of errors reported to a user. If not - I'll change it to boolean. You've also introduced a bug in ParseConfigFp(). Previously, if an included file contained an error, it did goto cleanup_exit() and thus didn't ereport() on it's own. With your patch applied it ereport()s a parse error at the location of the include directive, which seems wrong. Right, I noticed that I skipped switching the buffers and restoring the Lineno as well. I'll fix it in the next revision. Finally, I believe that ParseConfigFp() should make at least some effort to resync after hitting a parser error. I suggest that you simply fast-forward to the next GUC_EOL token after reporting a parser error. Makes sense. Thank you for the review. I'll post an updated patch, addressing you concerns, shortly. Alexey. -- Command Prompt, Inc. http://www.CommandPrompt.com PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- 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] procpid?
On 06/15/2011 12:41 PM, Robert Haas wrote: But I will note that we had better be darn sure to make all the changes we want to make in one go, because I dowanna have to create pg_sessions2 (or pg_tessions?) in a year or three. I just added a new section to the TODO to start collecting up some of these related ideas into one place: http://wiki.postgresql.org/wiki/Todo#Monitoring so we might try to get as many as possible all in one go. The other item on there related to pg_stat_activity that might impact this design was adding a column for tracking progress of commands like CREATE INDEX and VACUUM (I updated to note CLUSTER falls into that category too). While query progress will always be a hard problem, adding a field to store some sort of progress indicator might be useful even if it only worked on these two initially. Anyway, topic for another time. The only other item related to this view on the TODO was Have pg_stat_activity display query strings in the correct client encoding. That might be worthwhile to bundle into this rework, but it doesn't seem something that impacts the UI such that it must be considered early. -- Greg Smith 2ndQuadrant USg...@2ndquadrant.com Baltimore, MD PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.us -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] [WIP] [Stream] Preview of pg_type changes
Hello, Here I would like to expose changes to pg_type and type infrastructure about streaming. Changes are as follows: - added new column typstreamin typestremout - general contract for those is for streamin same as receive (receive use internal), for streamout it is (internal, type) - changes to psql help - and all functionality for type manipulation. There is no streamin/streamout methods implemented. If someone wants and have time, as this is WIP patch, then suggestions are welcome. Regards, Radek stream_pg_type.patch.gz Description: GNU Zip compressed 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] Latch implementation that wakes on postmaster death on both win32 and Unix
This patch breaks silent_mode=on. In silent_mode, postmaster forks early on, to detach from the controlling tty. It uses fork_process() for that, which with patch closes the write end of the postmaster-alive pipe, but that's wrong because the child becomes the postmaster process. On a stylistic note, the extern declaration in unix_latch.c is ugly, extern declarations should be in header files. Come to think of it, I feel the Init- and ReleasePostmasterDeathWatchHandle() functions should go to postmaster.c. postmaster_alive_fds[] and PostmasterHandle serve the same purpose, declaration and initialization of both should be kept together, perhaps by moving the initialization of PostmasterHandle into Init- and ReleasePostmasterDeathWatchHandle(). -- Heikki Linnakangas 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] procpid?
-BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 Or perhaps pg_connections. Yes, +1 to making things fully backwards compatible by keeping pg_stat_activity around but making a better designed and better named table (view/SRF/whatever). I thought about that too when reading the thread the first time, but pg_stat_sessions sounds better. Our documentation also primarily refers to a database connection as a session, i think. No, this is clearly connections, not sessions. At least based on the items in the postgresql.conf file, especially max_connections (probably one of the items most closely associated with pg_stat_activity) - -- Greg Sabino Mullane g...@turnstep.com End Point Corporation http://www.endpoint.com/ PGP Key: 0x14964AC8 201106161132 http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8 -BEGIN PGP SIGNATURE- iEYEAREDAAYFAk36IjYACgkQvJuQZxSWSsg8MgCgkMNw1o37cgmtJdYBAsGl7kz6 Q8sAoISFra0LyQjyKw3zcapWBdCLh2RV =EYAc -END PGP SIGNATURE- -- 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] [WIP] [Stream] Preview of pg_type changes
Hello 2011/6/16 Radosław Smogura rsmog...@softperience.eu: Hello, Here I would like to expose changes to pg_type and type infrastructure about streaming. Changes are as follows: - added new column typstreamin typestremout - general contract for those is for streamin same as receive (receive use internal), for streamout it is (internal, type) - changes to psql help - and all functionality for type manipulation. what is difference between typestremout function and typesend function? Regards Pavel Stehule There is no streamin/streamout methods implemented. If someone wants and have time, as this is WIP patch, then suggestions are welcome. Regards, Radek -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers -- 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] proposal: a validator for configuration files
On Jun16, 2011, at 17:23 , Alexey Klyukin wrote: On Jun 16, 2011, at 2:34 PM, Florian Pflug wrote: The first problem I ran into when I tried to test this is that it *only* reports multiple errors during config file reload on SIHUP, not during postmaster startup. I guess it's been done that way because we ereport(ERROR,..) not ereport(LOG,...) during postmaster startup, so it's not immediatly clear how to report multiple errors. But that proplem seems solvable. What if you ereport(LOG,..)ed the individual errors during postmaster startup, and then emitted an ereport(ERROR) at the end if errors occurred? The ERROR could either repeat the first error that was encountered, or simply say config file contains errors. Makes sense. One problem I came across is that set_config_option from guc.c sets the elevel by itself. I've changed it to emit LOG errors on PGC_S_FILE source, apparently all the callers of this function with this source are from guc-file.l, so hopefully I won't break anything with this change. Hm, wouldn't a test for context == PGC_POSTMASTER be more appropriate? I see that you basically replaced goto cleanup... in both ParseConfigFp() and ProcessConfigFile() with ++errorcount, and arranged for ParseConfigFp() to return false, and for ProcessConfigFile() to skip the GUC updates if errorcount 0. The actual value of errorcount is never inspected. The value is also wrong in the case of include files containing more than error, since ParseConfigFp() simply increments errorcount by one for each failed ParseConfigFile() of an included file. I thus suggest that you replace errorcount with a boolean erroroccurred. I can actually pass errorcount down from the ParseConfigFp() to report the total number of errors (w/ the include files) at the end of ProcessConfigFile if there is any interest in having the number of errors reported to a user. If not - I'll change it to boolean. Nah, just use a boolean, unless you have concrete plans to actually use the errorcount for something other than test a la errorcount 0. best regards, Florian Pflug -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] POSIX shared memory patch status
What's the current state of the POSIX shared memory patch? I grabbed the patch from http://archives.postgresql.org/message-id/d9edacf7-53f1-4355-84f8-2e74cd19d...@themactionfaction.com and it doesn't seem to apply cleanly any more. Are you planning to continue working on it? If I understood the conclusion of the discussions correctly, the current plan is to continue using a small SysV shared memory segment for the interlock, and POSIX shared memory for the rest. That lets us stay below SHMMAX even if it's small, which is convenient for admins. Was there a conclusion on whether we should use fnctl() to provide some extra safety in the current interlock mechanism? I'm feeling that that should probably be split off to a separate patch, it would be easier to review separately. -- Heikki Linnakangas 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] On-the-fly index tuple deletion vs. hot_standby
On Thu, Jun 16, 2011 at 3:47 PM, Noah Misch n...@leadboat.com wrote: On Thu, Jun 16, 2011 at 12:02:47AM +0100, Simon Riggs wrote: On Tue, Jun 14, 2011 at 5:28 AM, Noah Misch n...@leadboat.com wrote: On Mon, Jun 13, 2011 at 04:16:06PM +0100, Simon Riggs wrote: On Mon, Jun 13, 2011 at 3:11 AM, Robert Haas robertmh...@gmail.com wrote: On Sun, Jun 12, 2011 at 3:01 PM, Noah Misch n...@leadboat.com wrote: Assuming that conclusion, I do think it's worth starting with something simple, even if it means additional bloat on the master in the wal_level=hot_standby + vacuum_defer_cleanup_age / hot_standby_feedback case. In choosing those settings, the administrator has taken constructive steps to accept master-side bloat in exchange for delaying recovery conflict. ?What's your opinion? I'm pretty disinclined to go tinkering with 9.1 at this point, too. Not least because a feature already exists in 9.1 to cope with this problem: hot standby feedback. A standby's receipt of an XLOG_BTREE_REUSE_PAGE record implies that the accompanying latestRemovedXid preceded or equaled the master's RecentXmin at the time of issue (see _bt_page_recyclable()). ?Neither hot_standby_feedback nor vacuum_defer_cleanup_age affect RecentXmin. ?Therefore, neither facility delays conflicts arising directly from B-tree page reuse. ?See attached test script, which yields a snapshot conflict despite active hot_standby_feedback. OK, agreed. Bug. Good catch, Noah. Fix is to use RecentGlobalXmin for the cutoff when in Hot Standby mode, so that it is under user control. Attached patch will be applied to head and backpatched to 9.1 and 9.0 to fix this. Thanks. We still hit a conflict when btpo.xact == RecentGlobalXmin and the standby has a transaction older than any master transaction. This happens because the tests at nbtpage.c:704 and procarray.c:1843 both pass when the xid exactly is that of the oldest standby transaction (line numbers as of git cb94db91b). I only know this because the test script from my last message hits this case; it might never get hit in real usage. Still, seems like a hole not worth leaving. I think the most-correct fix is to TransactionIdRetreat the btpo.xact before using it as xl_btree_reuse_page.lastestRemovedXid. btpo.xact is the first known-safe xid, but latestRemovedXid is the last known-unsafe xmin. I think you are pointing out another bug, rather than a problem in my last commit. The bug was caused by assuming that the xid is a latestRemovedXid, as is the case in the rest of Hot Standby, which masks the off-by-one error through poor use of terms. I agree with your suggested fix. Thanks again. -- Simon Riggs http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training Services bt_recycle_offby1.v1.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] Patch - Debug builds without optimization
Excerpts from Radosław Smogura's message of jue jun 16 08:30:27 -0400 2011: Hello, I'm sending following patch which disables optimization when --enable-debug is passed. It was nasty (for me, at least) that debug build required passing of CFLAGS with -O0 to get nice traceable code. I disagree with this change. Debug builds are very useful to have in production, and you don't want to be running -O0 there. I have found that you can use a src/Makefile.custom like this for those times when you want to debug stuff in a particular set of files: CFLAGS := $(patsubst -O2,-O0,$(CFLAGS)) Then you remove the .o files that you want to debug, and rerun make. This places the burden on the developer wanting to mess with random code changes. Of course, this means that production builds are not as debuggable, but IME it's much less of a problem there. -- Álvaro Herrera alvhe...@commandprompt.com The PostgreSQL Company - Command Prompt, Inc. PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- 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] Latch implementation that wakes on postmaster death on both win32 and Unix
Excerpts from Peter Geoghegan's message of jue jun 16 08:42:39 -0400 2011: On 16 June 2011 13:15, Heikki Linnakangas heikki.linnakan...@enterprisedb.com wrote: Hmm, I'm not sure having the pid in that error message is too useful in the first place. The process was just spawned, and it will die at that error. When you try to debug that sort of error, what you would compare the pid with? And you can include the pid in log_line_prefix if it turns out to be useful after all. All fair points. FWIW, I think it's pretty unlikely that anyone will ever see this error message. ... in which case the getpid() call is not that expensive anyway. I agree that the PID should be part of the log_line_prefix though, which is why I was trying to propose we include it (or the session ID) in the default log_line_prefix along with a suitable timestamp. -- Álvaro Herrera alvhe...@commandprompt.com The PostgreSQL Company - Command Prompt, Inc. PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- 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] [WIP] [Stream] Preview of pg_type changes
This is some attempt to make streaming protocol. Difference is that instead of returning bytes it is intended to take stream, and self-stream. I posted, one day, some requirements for streaming, I can't reference it now, as I am away from computer. Regards, Radek -Original Message- From: Pavel Stehule Sent: 16 czerwca 2011 17:37 To: Radosław Smogura Cc: PG Hackers Subject: Re: [HACKERS] [WIP] [Stream] Preview of pg_type changes Hello 2011/6/16 Radosław Smogura rsmog...@softperience.eu: Hello, Here I would like to expose changes to pg_type and type infrastructure about streaming. Changes are as follows: - added new column typstreamin typestremout - general contract for those is for streamin same as receive (receive use internal), for streamout it is (internal, type) - changes to psql help - and all functionality for type manipulation. what is difference between typestremout function and typesend function? Regards Pavel Stehule There is no streamin/streamout methods implemented. If someone wants and have time, as this is WIP patch, then suggestions are welcome. Regards, Radek -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers -- 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] On-the-fly index tuple deletion vs. hot_standby
On Thu, Jun 16, 2011 at 4:53 PM, Simon Riggs si...@2ndquadrant.com wrote: I agree with your suggested fix. Please ignore the previous patch, which was sent in error. Here's the fix. I'll apply this tomorrow morning if we all still agree. -- Simon Riggs http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training Services bt_recycle_offby1.v1.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] FOREIGN TABLE doc fix
Right, but I think he needs the it's not easy, here's the whole workflow overview first. Ross -- Ross Reedstrom, Ph.D. reeds...@rice.edu Systems Engineer Admin, Research Scientistphone: 713-348-6166 Connexions http://cnx.orgfax: 713-348-3665 Rice University MS-375, Houston, TX 77005 GPG Key fingerprint = F023 82C8 9B0E 2CC6 0D8E F888 D3AE 810E 88F0 BEDE On Mon, Jun 13, 2011 at 04:54:13PM +0100, Dave Page wrote: On Mon, Jun 13, 2011 at 4:38 PM, Andrew Dunstan and...@dunslane.net wrote: On 06/13/2011 10:25 AM, Dave Page wrote: Don't hold your breath. We'll probably be making enough changes in the FDW infrastructure (particularly planner support) that making an FDW work on both 9.1 and 9.2 would be an exercise in frustration, if it's even possible. Oh joy. There's a GSoC student working on 2 non-trivial FDW's right now, and I have a couple I've been working on. If we're going to make the API incompatible to that extent, we might as well not bother :-( If nobody bothers then there won't be any experience on which to base a stable API. In particular, I think it's crucial that we get working FDWs for MySQL, SQLServer and Oracle ASAP. Yeah - MySQL is one of the ones I've been hacking on. It's hard to be motivated if its going to need a complete rewrite within a year though. I'll still have to work on it, as I've committed to giving talks on it, but others might not bother to even start. I think PostgreSQL has a better track record (especially recently) than most open source projects at supporting the shared incremental creation and improvement of first-class features. Yes, getting the first cut of FDW in place was hard: now it's time for users of that feature to take the leap of faith and write some code. The faith bit is that others _will_ come forward to help with the rewrites necessary to make it work (or work better) for their use cases. -- 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] On-the-fly index tuple deletion vs. hot_standby
On Thu, Jun 16, 2011 at 04:53:41PM +0100, Simon Riggs wrote: On Thu, Jun 16, 2011 at 3:47 PM, Noah Misch n...@leadboat.com wrote: Thanks. ?We still hit a conflict when btpo.xact == RecentGlobalXmin and the standby has a transaction older than any master transaction. ?This happens because the tests at nbtpage.c:704 and procarray.c:1843 both pass when the xid exactly is that of the oldest standby transaction (line numbers as of git cb94db91b). ?I only know this because the test script from my last message hits this case; it might never get hit in real usage. ?Still, seems like a hole not worth leaving. ?I think the most-correct fix is to TransactionIdRetreat the btpo.xact before using it as xl_btree_reuse_page.lastestRemovedXid. ?btpo.xact is the first known-safe xid, but latestRemovedXid is the last known-unsafe xmin. I think you are pointing out another bug, rather than a problem in my last commit. The bug was caused by assuming that the xid is a latestRemovedXid, as is the case in the rest of Hot Standby, which masks the off-by-one error through poor use of terms. Exactly. I agree with your suggested fix. (Note that TransactionIdRetreat mutates its argument and returns nothing.) Thanks, nm -- 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] use less space in xl_xact_commit patch
Excerpts from Leonardo Francalanci's message of jue jun 16 09:00:15 -0400 2011: Should I also change the struct name from xl_xact_commit to xl_xact_commit_fast_path? Yes, please. -- Álvaro Herrera alvhe...@commandprompt.com The PostgreSQL Company - Command Prompt, Inc. PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- 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] use less space in xl_xact_commit patch
On Thu, Jun 16, 2011 at 3:14 PM, Tom Lane t...@sss.pgh.pa.us wrote: Robert Haas robertmh...@gmail.com writes: On Thu, Jun 16, 2011 at 7:25 AM, Simon Riggs si...@2ndquadrant.com wrote: With regards to the naming, I think it would be better if we kept XLOG_XACT_COMMIT record exactly as it is now, and make the second record an entirely new record called XLOG_XACT_COMMIT_FASTPATH. That way we retain backwards compatibility. I liked your previous suggestion of commit and commit-with-info better. There's nothing particularly fast about this; it's just less info. So to speak. Yes. There is no need to preserve backwards compatibility here, so let's just design the records in a way that makes sense on its own. The only difference I'm proposing is the naming. It was foolish of me to propose that the data structure that is exactly the same should have a different name, yet the new structure should have the same name as the previous version. That will lead to confusion to no benefit. My second suggestion makes sense on its own, for no other reason. -- 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] PATCH: CreateComments: use explicit indexing for ``values''
On Jun14, 2011, at 17:47 , richhguard-monot...@yahoo.co.uk wrote: This patch makes the intent of each initialization clear by using the constants directly instead of in a comment, and has the effect of being able to verify each line on it's own. The original requires verification of the preceding i++'s. Here's a review of that patch. The patch applies cleanly to HEAD, looks correct, and passes make check. The patch makes the code far more readable and makes adding new columns to one of the affected system catalogs less error-prone. Since the chance of us ever back-patching changes to the system catalog's structure, the patch doesn't introduce additional back-patching hurdles. I'm thus marking this Read for Committer. best regards, Florian Pflug -- 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] use less space in xl_xact_commit patch
On Thu, Jun 16, 2011 at 12:12 PM, Simon Riggs si...@2ndquadrant.com wrote: On Thu, Jun 16, 2011 at 3:14 PM, Tom Lane t...@sss.pgh.pa.us wrote: Robert Haas robertmh...@gmail.com writes: On Thu, Jun 16, 2011 at 7:25 AM, Simon Riggs si...@2ndquadrant.com wrote: With regards to the naming, I think it would be better if we kept XLOG_XACT_COMMIT record exactly as it is now, and make the second record an entirely new record called XLOG_XACT_COMMIT_FASTPATH. That way we retain backwards compatibility. I liked your previous suggestion of commit and commit-with-info better. There's nothing particularly fast about this; it's just less info. So to speak. Yes. There is no need to preserve backwards compatibility here, so let's just design the records in a way that makes sense on its own. The only difference I'm proposing is the naming. It was foolish of me to propose that the data structure that is exactly the same should have a different name, yet the new structure should have the same name as the previous version. That will lead to confusion to no benefit. My second suggestion makes sense on its own, for no other reason. That's a reasonable point, but I still don't really like the name fastpath, because it's not faster, and it's not a path. It's just smaller. How about xl_xact_commit_simple or xl_xact_commit_compact or something like that? -- 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
Re: [HACKERS] procpid?
Greg Smith g...@2ndquadrant.com writes: The only other item related to this view on the TODO was Have pg_stat_activity display query strings in the correct client encoding. That might be worthwhile to bundle into this rework, but it doesn't seem something that impacts the UI such that it must be considered early. That entry is garbled to the point of uselessness anyway, as client encoding has got exactly zip to do with it. The point is that another backend's entry could be in a different *server* encoding, and what do you do if there's no equivalent character in your encoding? 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] proposal: a validator for configuration files
On Jun 16, 2011, at 6:49 PM, Florian Pflug wrote: On Jun16, 2011, at 17:23 , Alexey Klyukin wrote: On Jun 16, 2011, at 2:34 PM, Florian Pflug wrote: The first problem I ran into when I tried to test this is that it *only* reports multiple errors during config file reload on SIHUP, not during postmaster startup. I guess it's been done that way because we ereport(ERROR,..) not ereport(LOG,...) during postmaster startup, so it's not immediatly clear how to report multiple errors. But that proplem seems solvable. What if you ereport(LOG,..)ed the individual errors during postmaster startup, and then emitted an ereport(ERROR) at the end if errors occurred? The ERROR could either repeat the first error that was encountered, or simply say config file contains errors. Makes sense. One problem I came across is that set_config_option from guc.c sets the elevel by itself. I've changed it to emit LOG errors on PGC_S_FILE source, apparently all the callers of this function with this source are from guc-file.l, so hopefully I won't break anything with this change. Hm, wouldn't a test for context == PGC_POSTMASTER be more appropriate? In such a case the errors caused by command-line arguments won't stop the postmaster. PGC_S_FILE seems to handle this correctly. I'm not sure whether it is appropriate to use there though. I see that you basically replaced goto cleanup... in both ParseConfigFp() and ProcessConfigFile() with ++errorcount, and arranged for ParseConfigFp() to return false, and for ProcessConfigFile() to skip the GUC updates if errorcount 0. The actual value of errorcount is never inspected. The value is also wrong in the case of include files containing more than error, since ParseConfigFp() simply increments errorcount by one for each failed ParseConfigFile() of an included file. I thus suggest that you replace errorcount with a boolean erroroccurred. I can actually pass errorcount down from the ParseConfigFp() to report the total number of errors (w/ the include files) at the end of ProcessConfigFile if there is any interest in having the number of errors reported to a user. If not - I'll change it to boolean. Nah, just use a boolean, unless you have concrete plans to actually use the errorcount for something other than test a la errorcount 0. I just recalled a reason for counting the total number of errors. There is a condition that checks that the total number of errors is less than 100 and bails out if it's more than that (100 is arbitrary). The reason is to avoid bloating the logs w/ something totally unrelated to postgresql.conf. That was suggested by Tom Lane here: http://archives.postgresql.org/pgsql-hackers/2009-03/msg01142.php Thank you, Alexey. -- Command Prompt, Inc. http://www.CommandPrompt.com PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- 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] use less space in xl_xact_commit patch
Robert Haas robertmh...@gmail.com writes: That's a reasonable point, but I still don't really like the name fastpath, because it's not faster, and it's not a path. It's just smaller. How about xl_xact_commit_simple or xl_xact_commit_compact or something like that? bikeshed xl_xact_commit_short ? /bikeshed _simple would probably be my next choice. 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] POSIX shared memory patch status
On Thu, Jun 16, 2011 at 11:51 AM, Heikki Linnakangas heikki.linnakan...@enterprisedb.com wrote: What's the current state of the POSIX shared memory patch? I grabbed the patch from http://archives.postgresql.org/message-id/d9edacf7-53f1-4355-84f8-2e74cd19d...@themactionfaction.com and it doesn't seem to apply cleanly any more. Are you planning to continue working on it? If I understood the conclusion of the discussions correctly, the current plan is to continue using a small SysV shared memory segment for the interlock, and POSIX shared memory for the rest. That lets us stay below SHMMAX even if it's small, which is convenient for admins. +1, emphatically. Was there a conclusion on whether we should use fnctl() to provide some extra safety in the current interlock mechanism? I'm feeling that that should probably be split off to a separate patch, it would be easier to review separately. +1 for a separate patch. I see no reason why fixing that's got to be intertwined with this. It'd be relevant if we were planning to remove the current POSIX shm interlock, but so far nobody has offered a compelling explanation of why we should. The facility is supported pretty much everywhere; it's just the size limit that's a problem. -- 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
Re: [HACKERS] procpid?
--On 16. Juni 2011 15:33:35 + Greg Sabino Mullane g...@turnstep.com wrote: No, this is clearly connections, not sessions. At least based on the items in the postgresql.conf file, especially max_connections (probably one of the items most closely associated with pg_stat_activity) Well, but it doesn't show database connection(s) only, it also shows what actions are currently performed through the various connections on the databases and state information about them. I'm not a native english speaker, but i have the feeling that sessions is better suited for this kind of interactive monitoring. I believe Oracle also has a v$session view to query various information about what's going on. -- Thanks Bernd -- 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] procpid?
Tom Lane t...@sss.pgh.pa.us wrote: The point is that another backend's entry could be in a different *server* encoding, and what do you do if there's no equivalent character in your encoding? My first thought was that it was just a matter of picking a character to represent the unprintable characters. My second thought was that if you don't understand the encoding scheme, you're not even going to know where the character boundaries are. :-( -Kevin -- 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] Why polecat and colugos are failing to build back branches
On Thu, Jun 16, 2011 at 9:48 AM, Robert Creager rob...@logicalchaos.org wrote: On Jun 15, 2011, at 7:51 PM, Tom Lane t...@sss.pgh.pa.us wrote: ... installation paths. About the only good thing to be said about it is that these characters are so troublesome that Unix users are unlikely to use them in directory names anyway. So I'm guessing you don't want this path name? I was going to throw some \n and in it also, maybe some *,' and for good measure -) Shall I just stick with spaces? drwxr-xr-x 2 Robert wheel 68B Jun 15 17:26 pg bu!ldfa$m\a\$y/ Robert-Creagers-iMac:src Robert$ LOL. +1 for including that in the buildfarm, but only if you write the patch that makes it work yourself...! -- 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
Re: [HACKERS] proposal: a validator for configuration files
On Jun16, 2011, at 18:46 , Alexey Klyukin wrote: On Jun 16, 2011, at 6:49 PM, Florian Pflug wrote: Hm, wouldn't a test for context == PGC_POSTMASTER be more appropriate? In such a case the errors caused by command-line arguments won't stop the postmaster. PGC_S_FILE seems to handle this correctly. I'm not sure whether it is appropriate to use there though. Ah, yeah, you're right. PGC_S_FILE sounds fine, then. I guess this means you can drop the check for context == PGC_SIGHUP though, because surely the source must be PGC_S_DEFAULT or PGC_S_FILE if context == PGC_SIGHUP, right? So the check would become if (source == PGC_S_FILE || source == PGC_S_DEFAULT) where it now says if (context == PGC_SIGHUP || source == PGC_S_DEFAULT) I see that you basically replaced goto cleanup... in both ParseConfigFp() and ProcessConfigFile() with ++errorcount, and arranged for ParseConfigFp() to return false, and for ProcessConfigFile() to skip the GUC updates if errorcount 0. The actual value of errorcount is never inspected. The value is also wrong in the case of include files containing more than error, since ParseConfigFp() simply increments errorcount by one for each failed ParseConfigFile() of an included file. I thus suggest that you replace errorcount with a boolean erroroccurred. I can actually pass errorcount down from the ParseConfigFp() to report the total number of errors (w/ the include files) at the end of ProcessConfigFile if there is any interest in having the number of errors reported to a user. If not - I'll change it to boolean. Nah, just use a boolean, unless you have concrete plans to actually use the errorcount for something other than test a la errorcount 0. I just recalled a reason for counting the total number of errors. There is a condition that checks that the total number of errors is less than 100 and bails out if it's more than that (100 is arbitrary). The reason is to avoid bloating the logs w/ something totally unrelated to postgresql.conf. That was suggested by Tom Lane here: http://archives.postgresql.org/pgsql-hackers/2009-03/msg01142.php Ah, right, I missed that. Guess it'll have to stay a counter, then. Still, I don't think it's worth the effort to make the count correct in case of included files, so I'd say just add a comment explaining that the count isn't totally accurate. best regards, Florian Pflug -- 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] Re: starting to review the Extend NOT NULL representation to pg_constraint patch
Thanks, I am looking at the new version from Bernd's git repo. One problem I noticed is that it doesn't really work correctly for all callers of heap_create_with_catalog -- you're only passing the cooked not null constraints in DefineRelation, but there are some other places that call heap_create_with_catalog too. In particular, bootstrap mode is not handled; I haven't checked the other callers yet. I'm looking for the best way to handle that. So, question: do we need pg_constraint rows to exist for all NOT NULL constraints, including those in system catalogs, and including those in bootstrap catalogs? If we're going to require that, we're going to need to add a few initial data lines to the pg_constraint catalog definition, plus some code to handle the other bootstrap cases (non bootstrap relations). We could also declare that we don't need pg_constraint rows for NOT NULL constraints in system catalogs; but if we're going to do that, I guess we'd better disallow tables from inheriting system catalogs. Right now it's not disallowed but I guess it's pretty useless alvherre=# create table bar() inherits (pg_class); CREATE TABLE ... on the other hand, being able to use a catalog in a LIKE column definition sounds like it could be useful: alvherre=# create table qux (now timestamp, like pg_class); CREATE TABLE alvherre=# \d qux Tabla «public.qux» Columna |Tipo | Modificadores +-+--- now| timestamp without time zone | relname| name| not null relnamespace | oid | not null reltype| oid | not null -- Álvaro Herrera alvhe...@commandprompt.com The PostgreSQL Company - Command Prompt, Inc. PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- 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] Patch - Debug builds without optimization
Excerpts from Bernd Helmle's message of jue jun 16 09:37:24 -0400 2011: --On 16. Juni 2011 14:30:27 +0200 Radosław Smogura rsmog...@softperience.eu wrote: Hello, I'm sending following patch which disables optimization when --enable-debug is passed. It was nasty (for me, at least) that debug build required passing of CFLAGS with -O0 to get nice traceable code. -O0 hides bugs in your code (e.g. look at http://archives.postgresql.org/message-id/9714F5232AB2C4FCFCB392D5@amenophis and replies for an example to do it better). Doing this automatically on debug builds would be a step backwards. Hah, seems I don't always do it the same way ;-) -- Álvaro Herrera alvhe...@commandprompt.com The PostgreSQL Company - Command Prompt, Inc. PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- 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] POSIX shared memory patch status
On Jun 16, 2011, at 11:51 AM, Heikki Linnakangas wrote: What's the current state of the POSIX shared memory patch? I grabbed the patch from http://archives.postgresql.org/message-id/d9edacf7-53f1-4355-84f8-2e74cd19d...@themactionfaction.com and it doesn't seem to apply cleanly any more. Are you planning to continue working on it? If I understood the conclusion of the discussions correctly, the current plan is to continue using a small SysV shared memory segment for the interlock, and POSIX shared memory for the rest. That lets us stay below SHMMAX even if it's small, which is convenient for admins. Was there a conclusion on whether we should use fnctl() to provide some extra safety in the current interlock mechanism? I'm feeling that that should probably be split off to a separate patch, it would be easier to review separately. Hello, Please try a merge from my github branch: https://github.com/agentm/postgres/tree/posix_shmem I don't believe any conclusions were reached because the debate concerned whether or not fcntl locking was sufficient. I thought so while others pointed out that the proposed interlock would not work with mutli-client NFSv3 despite the fact that the current interlock doesn't either. I originally made the patch because SysV memory sometimes requires reboots which is especially annoying when expanding an existing production db server. Even if the next version of postgresql incorporates a hybrid SysV/POSIX shmem setup, reboots may still be required if one runs any other processes requiring SysV shmem (such as older versions of postgresql). In any case, I lost interest in maintaining the patch and would not object to having the patch removed from the CommitFest. Cheers, M -- 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] Re: starting to review the Extend NOT NULL representation to pg_constraint patch
Alvaro Herrera alvhe...@commandprompt.com writes: So, question: do we need pg_constraint rows to exist for all NOT NULL constraints, including those in system catalogs, and including those in bootstrap catalogs? If we're going to require that, we're going to need to add a few initial data lines to the pg_constraint catalog definition, plus some code to handle the other bootstrap cases (non bootstrap relations). Installing such rows during bootstrap would be problematic, because what do you do for catalogs that are created before pg_constraint? Possible solution is to leave bootstrap's behavior alone, and have a step during initdb's post-bootstrap stuff that creates a matching pg_constraint row for every pg_attribute entry that's marked attnotnull. We could also declare that we don't need pg_constraint rows for NOT NULL constraints in system catalogs; but if we're going to do that, I guess we'd better disallow tables from inheriting system catalogs. I have a feeling that omitting these entries for system catalogs would bite us in other ways down the road, even if inheritance were the only soft spot right now. 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] patch: update README-SSI
On Thu, Jun 16, 2011 at 04:39:09PM +0300, Heikki Linnakangas wrote: There's no mention on what T1 is. I believe it's supposed to be Tin, in the terminology used in the graph. Yes, I changed the naming after I originally wrote it, and missed a couple spots. T1 should be Tin. I don't see how there can be a ww-dependency between T0 and Tin. There can't be a rw-conflict because Tin is read-only, so surely there can't be a ww-conflict either? Yes, it can only be a wr-conflict. Good catch. Dan -- Dan R. K. Ports MIT CSAILhttp://drkp.net/ -- 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_upgrade using appname to lock out other users
On Wed, Jun 15, 2011 at 1:35 PM, Bruce Momjian br...@momjian.us wrote: I now believe we are overthinking all this. pg_upgrade has always supported specification of a port number. Why not just tell users to specify an unused port number 1023, and not to use the default value? 1. Because it shouldn't be the user's problem to figure out a good choice of port number. 2. Because we also really ought to be ignoring the contents of pg_hba.conf during an upgrade, and instead have some mechanism that allows pg_upgrade to be sure of getting in (without creating a security hole in the process). I agree that back-patching these changes wouldn't be a wonderful thing, but we are going to do a lot more releases that have pg_upgrade in them in the future than we've already done in the past. It's not a bad thing to try to start improving on the basic mechanism, even if takes a while for versions that support that mechanism to become commonplace. Limiting what we're willing to do the server to improve the pg_upgrade experience in the future to what we're willing to back-patch is not going to be a winning strategy. -- 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
Re: [HACKERS] Re: starting to review the Extend NOT NULL representation to pg_constraint patch
On Thu, Jun 16, 2011 at 1:25 PM, Tom Lane t...@sss.pgh.pa.us wrote: Possible solution is to leave bootstrap's behavior alone, and have a step during initdb's post-bootstrap stuff that creates a matching pg_constraint row for every pg_attribute entry that's marked attnotnull. That seems like a pretty good solution. I have a feeling that omitting these entries for system catalogs would bite us in other ways down the road, even if inheritance were the only soft spot right now. I share that feeling. -- 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
Re: [HACKERS] use less space in xl_xact_commit patch
On Thu, Jun 16, 2011 at 5:34 PM, Robert Haas robertmh...@gmail.com wrote: On Thu, Jun 16, 2011 at 12:12 PM, Simon Riggs si...@2ndquadrant.com wrote: On Thu, Jun 16, 2011 at 3:14 PM, Tom Lane t...@sss.pgh.pa.us wrote: Robert Haas robertmh...@gmail.com writes: On Thu, Jun 16, 2011 at 7:25 AM, Simon Riggs si...@2ndquadrant.com wrote: With regards to the naming, I think it would be better if we kept XLOG_XACT_COMMIT record exactly as it is now, and make the second record an entirely new record called XLOG_XACT_COMMIT_FASTPATH. That way we retain backwards compatibility. I liked your previous suggestion of commit and commit-with-info better. There's nothing particularly fast about this; it's just less info. So to speak. Yes. There is no need to preserve backwards compatibility here, so let's just design the records in a way that makes sense on its own. The only difference I'm proposing is the naming. It was foolish of me to propose that the data structure that is exactly the same should have a different name, yet the new structure should have the same name as the previous version. That will lead to confusion to no benefit. My second suggestion makes sense on its own, for no other reason. That's a reasonable point, but I still don't really like the name fastpath, because it's not faster, and it's not a path. It's just smaller. How about xl_xact_commit_simple or xl_xact_commit_compact or something like that? Sure, anything like that is fine for me. Rather annoyed at my email client because I lost my first email on this topic, then had to retype it all from memory. The second copy omitted things like or similar name, that's not important which would have avoided the last couple of mails. :-( -- 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] Boolean operators without commutators vs. ALL/ANY
On Thu, Jun 16, 2011 at 12:50 AM, Tom Lane t...@sss.pgh.pa.us wrote: We deprecated those names for the geometric operators largely because there wasn't any visual correlation between the commutator pairs. I can't see introducing the same pairing for regex operators if we already decided the geometric case was a bad idea. I'm having trouble avoiding the conclusion that we're trying to shove a round peg into a square hole. The idea that we have to have a commutator for every operator just because we don't handle left and right symmetrically sits poorly with me. I can't really argue with your statement that it's the easiest way to address Florian's gripe, but because it almost surely is. But it still feels like a kludge. The syntax foo = ANY(bar) is really quite a poorly-designed syntax, because the top-level operation is really ANY, and it has three arguments: foo, =, bar. If the SQL committee had standardized on ANY(foo = $0, bar) or some such thing we wouldn't be having this conversation. -- 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
Re: [HACKERS] patch: update README-SSI
On 16.06.2011 20:33, Dan Ports wrote: On Thu, Jun 16, 2011 at 04:39:09PM +0300, Heikki Linnakangas wrote: There's no mention on what T1 is. I believe it's supposed to be Tin, in the terminology used in the graph. Yes, I changed the naming after I originally wrote it, and missed a couple spots. T1 should be Tin. I don't see how there can be a ww-dependency between T0 and Tin. There can't be a rw-conflict because Tin is read-only, so surely there can't be a ww-conflict either? Yes, it can only be a wr-conflict. Good catch. Ok, I'll commit with those changes. -- Heikki Linnakangas 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] planinstr, showing planner time on EXPLAIN
On Tue, Jun 14, 2011 at 11:18 PM, Hitoshi Harada umi.tan...@gmail.com wrote: Yesterday on PGXN I just released the first version of planinstr, a plugin module to append planner time to EXPLAIN. I post this here since it is mostly for developers. http://www.pgxn.org/dist/planinstr/ db1=# load '$libdir/planinstr'; LOAD db1=# explain select * from pg_class; QUERY PLAN --- Seq Scan on pg_class (cost=0.00..141.87 rows=3287 width=194) Plan time: 0.119 ms db1=# explain analyze select count(*) from size_m; QUERY PLAN Aggregate (cost=26272.00..26272.01 rows=1 width=0) (actual time=51.938..51.938 rows=1 loops=1) - Append (cost=0.00..23147.00 rows=125 width=0) (actual time=0.037..45.809 rows=2 loops=1) - Seq Scan on size_m (cost=0.00..847.00 rows=2 width=0) (actual time=0.037..41.863 rows=2 loops=1) .. snip .. - Seq Scan on myt1000 size_m (cost=0.00..22.30 rows=1230 width=0) (actual time=0.001..0.001 rows=0 loops=1) Total runtime: 75.217 ms Plan time: 61.353 ms (1005 rows) Wow, that is awesome. I sorta wish we had something like that in core -- and I don't even think it should be optional, I think it should just always give you that additional piece of information. I can't immediately count the number of times this would have helped me, but it's significant. -- 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
Re: [HACKERS] WIP: Fast GiST index build
My current idea is to measure number of IO accesses by pg_stat_statements and measure CPU usage by /proc/PID/stat. Any thoughts? -- With best regards, Alexander Korotkov. On Thu, Jun 16, 2011 at 1:33 PM, Alexander Korotkov aekorot...@gmail.comwrote: Actually, I would like to measure CPU and IO load independently for more comprehensive benchmarks. Can you advice me some appropriate tools for it? -- With best regards, Alexander Korotkov.
Re: [HACKERS] Boolean operators without commutators vs. ALL/ANY
Robert Haas robertmh...@gmail.com writes: I'm having trouble avoiding the conclusion that we're trying to shove a round peg into a square hole. The idea that we have to have a commutator for every operator just because we don't handle left and right symmetrically sits poorly with me. I can't really argue with your statement that it's the easiest way to address Florian's gripe, but because it almost surely is. But it still feels like a kludge. The syntax foo = ANY(bar) is really quite a poorly-designed syntax, because the top-level operation is really ANY, and it has three arguments: foo, =, bar. If the SQL committee had standardized on ANY(foo = $0, bar) or some such thing we wouldn't be having this conversation. [ shrug... ] Take it up with the committee. The syntax is what it is, and we should select our operators to fit it, not vice versa. 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] proposal: a validator for configuration files
On Jun 16, 2011, at 8:01 PM, Florian Pflug wrote: On Jun16, 2011, at 18:46 , Alexey Klyukin wrote: On Jun 16, 2011, at 6:49 PM, Florian Pflug wrote: Hm, wouldn't a test for context == PGC_POSTMASTER be more appropriate? In such a case the errors caused by command-line arguments won't stop the postmaster. PGC_S_FILE seems to handle this correctly. I'm not sure whether it is appropriate to use there though. Ah, yeah, you're right. PGC_S_FILE sounds fine, then. I guess this means you can drop the check for context == PGC_SIGHUP though, because surely the source must be PGC_S_DEFAULT or PGC_S_FILE if context == PGC_SIGHUP, right? So the check would become if (source == PGC_S_FILE || source == PGC_S_DEFAULT) where it now says if (context == PGC_SIGHUP || source == PGC_S_DEFAULT) Yes, AFAIK PGC_SIGHUP is redundant, thank you for the suggestion. I just recalled a reason for counting the total number of errors. There is a condition that checks that the total number of errors is less than 100 and bails out if it's more than that (100 is arbitrary). The reason is to avoid bloating the logs w/ something totally unrelated to postgresql.conf. That was suggested by Tom Lane here: http://archives.postgresql.org/pgsql-hackers/2009-03/msg01142.php Ah, right, I missed that. Guess it'll have to stay a counter, then. Still, I don't think it's worth the effort to make the count correct in case of included files, so I'd say just add a comment explaining that the count isn't totally accurate. Well, while thinking about this I decided to leave the counter for the ParseConfigFp, but drop it in ProcessConfigFile. The case we are protecting against is a single file full of junk. It's unlikely that this junk would contain include directives with valid file paths, neither it's likely to find a file with a correct syntax, but full of invalid directives. Thank you, Alexey. -- Command Prompt, Inc. http://www.CommandPrompt.com PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- 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] proposal: a validator for configuration files
On Jun16, 2011, at 20:14 , Alexey Klyukin wrote: On Jun 16, 2011, at 8:01 PM, Florian Pflug wrote: On Jun16, 2011, at 18:46 , Alexey Klyukin wrote: I just recalled a reason for counting the total number of errors. There is a condition that checks that the total number of errors is less than 100 and bails out if it's more than that (100 is arbitrary). The reason is to avoid bloating the logs w/ something totally unrelated to postgresql.conf. That was suggested by Tom Lane here: http://archives.postgresql.org/pgsql-hackers/2009-03/msg01142.php Ah, right, I missed that. Guess it'll have to stay a counter, then. Still, I don't think it's worth the effort to make the count correct in case of included files, so I'd say just add a comment explaining that the count isn't totally accurate. Well, while thinking about this I decided to leave the counter for the ParseConfigFp, but drop it in ProcessConfigFile. The case we are protecting against is a single file full of junk. It's unlikely that this junk would contain include directives with valid file paths, neither it's likely to find a file with a correct syntax, but full of invalid directives. Sounds good. best regards, Florian Pflug -- 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] Boolean operators without commutators vs. ALL/ANY
On Jun16, 2011, at 19:54 , Robert Haas wrote: On Thu, Jun 16, 2011 at 12:50 AM, Tom Lane t...@sss.pgh.pa.us wrote: We deprecated those names for the geometric operators largely because there wasn't any visual correlation between the commutator pairs. I can't see introducing the same pairing for regex operators if we already decided the geometric case was a bad idea. I'm having trouble avoiding the conclusion that we're trying to shove a round peg into a square hole. The idea that we have to have a commutator for every operator just because we don't handle left and right symmetrically sits poorly with me. I can't really argue with your statement that it's the easiest way to address Florian's gripe, but because it almost surely is. But it still feels like a kludge. Well, I think there are basically three choices here, kludge or no kludge. (1) We either decree once and for all that binary operations ought to have commutators, modify CREATE TYPE to issue a warning if you create one without, add the missing ones, and add a check for that to opr_sanity (possibly excluding some deprecated operators). or (2) We arrange for commutators of binary operators to be created automatically. or (3) Or we bit the bullet and provide something similar to ANY/ALL op scalar. We do have the liberty to pick whatever syntax we feel comfortable with, though, since we're out of SQL standard territory anyway. What I *wouldn't* like us to is just a few missing commutators and be done with it. That pretty much guarantees that this issue will pop up again some time in the future. I personally prefer (3), but would also be content with (1), and be ready to provide a patch for that. To be fair, (1) really doesn't seem that kludgy if one takes into account that all indexable operators must have commutators anyway. I haven't checked how viable (2) actually is, but I dare say that it's probably quite a bit of work. Essentially, we'd need a way to automatically swap a function's argument before invoking the function, which I'm not sure that fmgr can cleanly be persuaded to do. Now all that's required is to agree on a way forward ;-) best regards, Florian Pflug -- 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] WIP: Fast GiST index build
On 16.06.2011 21:13, Alexander Korotkov wrote: My current idea is to measure number of IO accesses by pg_stat_statements and measure CPU usage by /proc/PID/stat. Any thoughts? Actually, you get both of those very easily with: set log_statement_stats=on LOG: QUERY STATISTICS DETAIL: ! system usage stats: ! 0.000990 elapsed 0.00 user 0.00 system sec ! [0.00 user 0.008000 sys total] ! 0/0 [32/0] filesystem blocks in/out ! 0/0 [0/959] page faults/reclaims, 0 [0] swaps ! 0 [0] signals rcvd, 0/0 [0/0] messages rcvd/sent ! 0/0 [10/1] voluntary/involuntary context switches STATEMENT: SELECT generate_series(1,100); -- Heikki Linnakangas 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] time-delayed standbys
On Wed, Jun 15, 2011 at 1:58 AM, Fujii Masao masao.fu...@gmail.com wrote: When the replication connection is terminated, the standby tries to read WAL files from the archive. In this case, there is no walreceiver process, so how does the standby calculate the clock difference? Good question. Also, just because we have streaming replication available doesn't mean that we should force people to use it. It's still perfectly legit to set up a standby that only use archive_command and restore_command, and it would be nice if this feature could still work in such an environment. I anticipate that most people want to use streaming replication, but a time-delayed standby is a good example of a case where you might decide you don't need it. It could be useful to have all the WAL present (but not yet applied) if you're thinking you might want to promote that standby - but my guess is that in many cases, the time-delayed standby will be *in addition* to one or more regular standbys that would be the primary promotion candidates. So I can see someone deciding that they'd rather not have the load of another walsender on the master, and just let the time-delayed standby read from the archive. Even if that were not an issue, I'm still more or less of the opinion that trying to solve the time synchronization problem is a rathole anyway. To really solve this problem well, you're going to need the standby to send a message containing a timestamp, get a reply back from the master that contains that timestamp and a master timestamp, and then compute based on those two timestamps plus the reply timestamp the maximum and minimum possible lag between the two machines. Then you're going to need to guess, based on several cycles of this activity, what the actual lag is, and adjust it over time (but not too quckly, unless of course a large manual step has occurred) as the clocks potentially drift apart from each other. This is basically what ntpd does, except that it can be virtually guaranteed that our implementation will suck by comparison. Time synchronization is neither easy nor our core competency, and I think trying to include it in this feature is going to result in a net loss of reliability. errmsg(parameter \%s\ requires a temporal value, recovery_time_delay), We should s/a temporal/an Integer? It seems strange to ask for an integer when what we want is an amount of time in seconds or minutes... After we run pg_ctl promote, time-delayed replication should be disabled? Otherwise, failover might take very long time when we set recovery_time_delay to high value. Yeah, I think so. http://forge.mysql.com/worklog/task.php?id=344 According to the above page, one purpose of time-delayed replication is to protect against user mistakes on master. But, when an user notices his wrong operation on master, what should he do next? The WAL records of his wrong operation might have already arrived at the standby, so neither promote nor restart doesn't cancel that wrong operation. Instead, probably he should shutdown the standby, investigate the timestamp of XID of the operation he'd like to cancel, set recovery_target_time and restart the standby. Something like this procedures should be documented? Or, we should implement new promote mode which finishes a recovery as soon as promote is requested (i.e., not replay all the available WAL records)? I like the idea of a new promote mode; and documenting the other approach you mention doesn't sound bad either. Either one sounds like a job for a separate patch, though. The other option is to pause recovery and run pg_dump... -- 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
Re: [HACKERS] Re: starting to review the Extend NOT NULL representation to pg_constraint patch
--On 16. Juni 2011 13:25:05 -0400 Tom Lane t...@sss.pgh.pa.us wrote: Possible solution is to leave bootstrap's behavior alone, and have a step during initdb's post-bootstrap stuff that creates a matching pg_constraint row for every pg_attribute entry that's marked attnotnull. +1 for this idea. I never came to an end about this because i didn't have any clue how to do it efficiently. -- Thanks Bernd -- 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] WIP: Fast GiST index build
Oh, actually it's so easy. Thanks. -- With best regards, Alexander Korotkov. On Thu, Jun 16, 2011 at 10:26 PM, Heikki Linnakangas heikki.linnakan...@enterprisedb.com wrote: On 16.06.2011 21:13, Alexander Korotkov wrote: My current idea is to measure number of IO accesses by pg_stat_statements and measure CPU usage by /proc/PID/stat. Any thoughts? Actually, you get both of those very easily with: set log_statement_stats=on LOG: QUERY STATISTICS DETAIL: ! system usage stats: ! 0.000990 elapsed 0.00 user 0.00 system sec ! [0.00 user 0.008000 sys total] ! 0/0 [32/0] filesystem blocks in/out ! 0/0 [0/959] page faults/reclaims, 0 [0] swaps ! 0 [0] signals rcvd, 0/0 [0/0] messages rcvd/sent ! 0/0 [10/1] voluntary/involuntary context switches STATEMENT: SELECT generate_series(1,100); -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com
Re: [HACKERS] Boolean operators without commutators vs. ALL/ANY
On Thu, Jun 16, 2011 at 2:22 PM, Florian Pflug f...@phlo.org wrote: On Jun16, 2011, at 19:54 , Robert Haas wrote: On Thu, Jun 16, 2011 at 12:50 AM, Tom Lane t...@sss.pgh.pa.us wrote: We deprecated those names for the geometric operators largely because there wasn't any visual correlation between the commutator pairs. I can't see introducing the same pairing for regex operators if we already decided the geometric case was a bad idea. I'm having trouble avoiding the conclusion that we're trying to shove a round peg into a square hole. The idea that we have to have a commutator for every operator just because we don't handle left and right symmetrically sits poorly with me. I can't really argue with your statement that it's the easiest way to address Florian's gripe, but because it almost surely is. But it still feels like a kludge. Well, I think there are basically three choices here, kludge or no kludge. (1) We either decree once and for all that binary operations ought to have commutators, modify CREATE TYPE to issue a warning if you create one without, add the missing ones, and add a check for that to opr_sanity (possibly excluding some deprecated operators). or (2) We arrange for commutators of binary operators to be created automatically. or (3) Or we bit the bullet and provide something similar to ANY/ALL op scalar. We do have the liberty to pick whatever syntax we feel comfortable with, though, since we're out of SQL standard territory anyway. What I *wouldn't* like us to is just a few missing commutators and be done with it. That pretty much guarantees that this issue will pop up again some time in the future. I personally prefer (3), but would also be content with (1), and be ready to provide a patch for that. To be fair, (1) really doesn't seem that kludgy if one takes into account that all indexable operators must have commutators anyway. I haven't checked how viable (2) actually is, but I dare say that it's probably quite a bit of work. Essentially, we'd need a way to automatically swap a function's argument before invoking the function, which I'm not sure that fmgr can cleanly be persuaded to do. Now all that's required is to agree on a way forward ;-) Well, Tom seems pretty strongly in favor of #1, or some variant of it, and while I don't find that to be enormously elegant it does have the virtue of being quite a bit less work than any of the other options. I think the chances of that being a complete and permanent solution are less than 50%, but perhaps it's close enough for government work. -- 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
Re: [HACKERS] POSIX shared memory patch status
On 16.06.2011 20:22, A.M. wrote: I don't believe any conclusions were reached because the debate concerned whether or not fcntl locking was sufficient. I thought so while others pointed out that the proposed interlock would not work with mutli-client NFSv3 despite the fact that the current interlock doesn't either. I originally made the patch because SysV memory sometimes requires reboots which is especially annoying when expanding an existing production db server. Even if the next version of postgresql incorporates a hybrid SysV/POSIX shmem setup, reboots may still be required if one runs any other processes requiring SysV shmem (such as older versions of postgresql). In any case, I lost interest in maintaining the patch and would not object to having the patch removed from the CommitFest. Ok, I'll mark this as returned with feedback then. Thanks for your efforts anyway! -- Heikki Linnakangas 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] Re: starting to review the Extend NOT NULL representation to pg_constraint patch
Excerpts from Bernd Helmle's message of jue jun 16 14:30:48 -0400 2011: --On 16. Juni 2011 13:25:05 -0400 Tom Lane t...@sss.pgh.pa.us wrote: Possible solution is to leave bootstrap's behavior alone, and have a step during initdb's post-bootstrap stuff that creates a matching pg_constraint row for every pg_attribute entry that's marked attnotnull. +1 for this idea. I never came to an end about this because i didn't have any clue how to do it efficiently. Okay, I have done it this way -- adding one more fixup function to initdb is very easy. I only wish that the ending \n in the query to initdb would be optional -- it took me a while to realize that if you omit it, the query doesn't get run at all. Oh well. -- Álvaro Herrera alvhe...@commandprompt.com The PostgreSQL Company - Command Prompt, Inc. PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- 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] procpid?
Excerpts from Greg Sabino Mullane's message of jue jun 16 15:33:35 UTC 2011: Hash: RIPEMD160 Or perhaps pg_connections. Yes, +1 to making things fully backwards compatible by keeping pg_stat_activity around but making a better designed and better named table (view/SRF/whatever). I thought about that too when reading the thread the first time, but pg_stat_sessions sounds better. Our documentation also primarily refers to a database connection as a session, i think. No, this is clearly connections, not sessions. At least based on the items in the postgresql.conf file, especially max_connections (probably one of the items most closely associated with pg_stat_activity) That doesn't include autovacuum, though, whereas the new view would. -- Álvaro Herrera alvhe...@commandprompt.com The PostgreSQL Company - Command Prompt, Inc. PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- 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] Nested CASE-WHEN scoping
Hello 2011/6/3 Heikki Linnakangas heikki.linnakan...@enterprisedb.com: On 31.05.2011 19:10, Heikki Linnakangas wrote: For index expressions, we could use a function similar to ChangeVarNodes(), that shifts all the paramids in the already-planned expression, preparing it for inclusion within the enclosing plan. I'm a bit worried that that might screw up the logic used to compare if an expression matches the index expression, though; the param ids in the two expressions won't match. Yeah, the expression comparison logic gets all confused by this :-(. I couldn't figure out a way to make it work without making the comparison a whole lot more complicated than it is today. I'm going back to my original thoughts of a new kind of node to replace CaseTestExpr, which allows referencing values from upper levels in the expression tree. So, here's a WIP patch using that approach. I've replaced CaseTestExpr with ExpressionParam. ExpressionParam has a levelsup field, which is similar to varlevelsup in Var. With levelsup == 0, ExpressionParam works just like CaseTestExpr did. With levelsup == 1, it refers to the value from above the enclosing CaseExpr (or any other node that uses these ExpressionParams/CaseTestExprs). I have a query - should be ExpressionParam used for removing a multiple function call when composite result is expanded? With some similar optimization a SELECT (fce(x)).* FROM tab will be optimal Regards Pavel Stěhule The complicated part is to ensure that levelsup is always set correctly. At parse time, levelsup is always set to 0, as the syntax doesn't allow referencing upper levels directly. When an SQL function is inlined, any ExpressionParams in the expressions that are substituted for Params need to have their levelsup adjusted, so that it still refers to the right value if there's CASE expressions in the inlined function. Also, when an ExpressionParam is replaced with a Const, the levelsup fields of any other ExpressionParams within the CaseExpr referring to higher levels need to have their levelsup decremented to account for the fact that the CaseExpr doesn't push the expression parameter anymore. At execution time, the expression parameters form a stack. We've always done the save-restore logic, but the stack is now represented explicitly as a List in ExprContext. When an ExpressionParam is evaluated, the nth element is fetched from the stack, corresponding to levelsup. -- Heikki Linnakangas 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 -- 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] Boolean operators without commutators vs. ALL/ANY
Florian Pflug f...@phlo.org writes: Well, I think there are basically three choices here, kludge or no kludge. (1) We either decree once and for all that binary operations ought to have commutators, modify CREATE TYPE to issue a warning if you create one without, add the missing ones, and add a check for that to opr_sanity (possibly excluding some deprecated operators). or (2) We arrange for commutators of binary operators to be created automatically. or (3) Or we bit the bullet and provide something similar to ANY/ALL op scalar. We do have the liberty to pick whatever syntax we feel comfortable with, though, since we're out of SQL standard territory anyway. All three of these are massive overkill. What we need is a general policy that providing commutators is a good idea. We do not need to try to make it 100.00% with an enforcement mechanism. As for #2, what's your plan for automatically selecting a commutator operator name? (Having said that, I *was* thinking of adding an opr_sanity test ... but not expecting that we'd get it to find zero rows.) 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
