Re: [HACKERS] We should Axe /contrib/start-scripts
On Thu, Aug 27, 2009 at 02:38, Tom Lanet...@sss.pgh.pa.us wrote: I did have another thought. It could compare the time from uptime to the timestamp on the lock file. If the server's been restarted since the time in the lock file then it must be stale. uhm. unless clock's been changed... Yeah, you can't trust system clocks too much either :-(. I was actually having second thoughts about the idea of using file locking. The only environment in which I've heard of file locks not being trustworthy is NFS, and if you're running a DB on NFS you've probably got worse problems than this one. That is a bad generalization. A lot of people run their databases very successfully on NFS. It just requires that you have a good NFS server, know how to set it up, know how to set up your network, have a good NFS client and know how to set *it* up. Though I would assume that locks would be trustworthy in this case as well... Notably, if you mistakenly try to start postmasters on two different machines against the same NFS-mounted directory, the PID-based interlock will certainly fail, while file locking might save you. That's in no way limited to NFS though... The difference being that in a lot of other cases you just end up with a completely corrupt filesystem :) So maybe we should take another look at that. Has anyone heard of other contexts in which file locks don't work? Has Windows got them? Certainly: http://msdn.microsoft.com/en-us/library/aa365202%28VS.85%29.aspx for example. -- 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
Re: [HACKERS] MySQL Compatibility WAS: 8.5 release timetable, again
Tom Lane wrote: Greg Stark gsst...@mit.edu writes: Actually it always bothered me that we don't have implicit casts from integer-boolean. I can't see any ambiguity or unintentional effects this would cause problems with. Am I missing something? Personally, as an old Pascal-lover, I always thought that C's failure to distinguish between int and boolean was the single biggest design mistake in the language. I'm very glad that SQL doesn't make that mistake, and I don't want to go against the standard to introduce it. Then you should love Python where everything non-empty is regarded True in boolean context ;-) Cheers Tino smime.p7s Description: S/MIME Cryptographic Signature
[HACKERS] Build system problem in 8.3.x
Hi, we have come across a problem in 8.3.x (8.3.5 and 8.3.7 was tested) while building PostgreSQL for 32-bit on 64-bit RHEL5 and Fedora 9. The following defines were used before running configure: export CFLAGS=-m32 export LD=ld -melf_i386 The above are needed because when SUBSYS.o files are created, the $(LD) ... lines don't contain $(LDFLAGS) anywhere, so overriding $(LD) on the command line has to be done instead. However, there's one additional problem that can be solved by the attached one liner. The problem is that during building the core, something (test/regress) requires contrib/spi/refint.so to be built. The error follows: make -C ../../../contrib/spi refint.so autoinc.so make[3]: Entering directory `/home/zozo/Schönig-számlák/lucent/postgresql-8.3.5/contrib/spi' gcc -m32 -Wall -Wmissing-prototypes -Wpointer-arith -Winline -Wdeclaration-after-statement -Wendif-labels -fno-strict-aliasing -fwrapv -fpic -DREFINT_VERBOSE -I. -I../../src/include -D_GNU_SOURCE -c -o refint.o refint.c gcc -shared -o refint.so refint.o /usr/bin/ld: i386 architecture of input file `refint.o' is incompatible with i386:x86-64 output I tried building contrib manually, but it turned out that the same error happens whenever contrib/*/Makefile contains MODULES instead of MODULE_big. I modified Makefile.port in the attached patch, and now all the contrib files also build correctly. Best regards, Zoltán Böszörményi -- Bible has answers for everything. Proof: But let your communication be, Yea, yea; Nay, nay: for whatsoever is more than these cometh of evil. (Matthew 5:37) - basics of digital technology. May your kingdom come - superficial description of plate tectonics -- Zoltán Böszörményi Cybertec Schönig Schönig GmbH http://www.postgresql.at/ *** src/Makefile.port.old 2009-08-27 10:56:46.0 +0200 --- src/Makefile.port 2009-08-27 10:56:46.0 +0200 *** *** 11,16 endif %.so: %.o ! $(CC) -shared -o $@ $ sqlmansect = 7 --- 11,16 endif %.so: %.o ! $(CC) $(CFLAGS) -shared -o $@ $ sqlmansect = 7 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Patches for static check on geo_ops.c
Grzegorz Jaskiewicz wonderful static checker coughed up 5 errors in
geo_ops.c. None of them of any particular excitement or of earth
shattering nature. A patch is attached below that should correct these.
(The more little issue we eliminate, the more the large ones will stand
out.)
At line 3131 value stored into 'dist' variable is never referenced again.
At line 3014 value stored into 'dist' variable is never referenced again.
At line 2942 value stored into 'd' variable is never referenced again.
At line 2953 value stored into 'd' variable is never referenced again.
At line 2993 value stored into 'd' variable is never referenced again.
? patchfile_clang
Index: src/backend/utils/adt/geo_ops.c
===
RCS file: /projects/cvsroot/pgsql/src/backend/utils/adt/geo_ops.c,v
retrieving revision 1.103
diff -c -r1.103 geo_ops.c
*** src/backend/utils/adt/geo_ops.c 28 Jul 2009 09:47:59 - 1.103
--- src/backend/utils/adt/geo_ops.c 27 Aug 2009 09:31:30 -
***
*** 2939,2945
memcpy(point, l1-p[1], sizeof(Point));
}
! if ((d = dist_ps_internal(l2-p[0], l1)) dist)
{
result = DatumGetPointP(DirectFunctionCall2(close_ps,
PointPGetDatum(l2-p[0]),
--- 2939,2945
memcpy(point, l1-p[1], sizeof(Point));
}
! if (dist_ps_internal(l2-p[0], l1) dist)
{
result = DatumGetPointP(DirectFunctionCall2(close_ps,
PointPGetDatum(l2-p[0]),
***
*** 2950,2956
LsegPGetDatum(l2)));
}
! if ((d = dist_ps_internal(l2-p[1], l1)) dist)
{
result = DatumGetPointP(DirectFunctionCall2(close_ps,
PointPGetDatum(l2-p[1]),
--- 2950,2956
LsegPGetDatum(l2)));
}
! if (dist_ps_internal(l2-p[1], l1) dist)
{
result = DatumGetPointP(DirectFunctionCall2(close_ps,
PointPGetDatum(l2-p[1]),
***
*** 2990,2996
point.x = box-low.x;
point.y = box-high.y;
statlseg_construct(lseg, box-low, point);
! dist = d = dist_ps_internal(pt, lseg);
statlseg_construct(seg, box-high, point);
if ((d = dist_ps_internal(pt, seg)) dist)
--- 2990,2996
point.x = box-low.x;
point.y = box-high.y;
statlseg_construct(lseg, box-low, point);
! dist = dist_ps_internal(pt, lseg);
statlseg_construct(seg, box-high, point);
if ((d = dist_ps_internal(pt, seg)) dist)
***
*** 3011,3017
statlseg_construct(seg, box-high, point);
if ((d = dist_ps_internal(pt, seg)) dist)
{
- dist = d;
memcpy(lseg, seg, sizeof(lseg));
}
--- 3011,3016
***
*** 3128,3134
statlseg_construct(seg, box-high, point);
if ((d = lseg_dt(lseg, seg)) dist)
{
- dist = d;
memcpy(bseg, seg, sizeof(bseg));
}
--- 3127,3132
--
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] MySQL Compatibility WAS: postgresql.conf settings autoconfiguration
Dear all, Just a quick message about postgresql.conf auto-configuration. When MySQL users test PostgreSQL, they load their data and run simple SQL queries. If postgresql.conf is configured with default values, it may produce slow results. Would there be a way for postgresql.conf to auto configure? This is how MySQL works. Nothing is configurable. And people love it. So why not implement a simple auto configuration mechanism which would set basic parameters. Example autotune=true; autotune_profile='web site'; autotune_profile='dedicated SQL server'; ... Kind regards, Jean-Michel signature.asc Description: Ceci est une partie de message numériquement signée
Re: [HACKERS] MySQL Compatibility WAS: 8.5 release timetable, again
Tom Lane írta: Greg Stark gsst...@mit.edu writes: Actually it always bothered me that we don't have implicit casts from integer-boolean. I can't see any ambiguity or unintentional effects this would cause problems with. Am I missing something? Personally, as an old Pascal-lover, I always thought that C's failure to distinguish between int and boolean was the single biggest design mistake in the language. On the other hand, the first two programming languages I have learnt was Sinclair ZX Spectrum BASIC and Z80 assembly, I welcomed C being so near to assembly... :-) I'm very glad that SQL doesn't make that mistake, and I don't want to go against the standard to introduce it. In that we agree. SQL is not C. Best regards, Zoltán Böszörményi -- Bible has answers for everything. Proof: But let your communication be, Yea, yea; Nay, nay: for whatsoever is more than these cometh of evil. (Matthew 5:37) - basics of digital technology. May your kingdom come - superficial description of plate tectonics -- Zoltán Böszörményi Cybertec Schönig Schönig GmbH http://www.postgresql.at/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Build system problem in 8.3.x
Boszormenyi Zoltan wrote: we have come across a problem in 8.3.x (8.3.5 and 8.3.7 was tested) while building PostgreSQL for 32-bit on 64-bit RHEL5 and Fedora 9. The following defines were used before running configure: export CFLAGS=-m32 export LD=ld -melf_i386 The above are needed because when SUBSYS.o files are created, the $(LD) ... lines don't contain $(LDFLAGS) anywhere, so overriding $(LD) on the command line has to be done instead. However, there's one additional problem that can be solved by the attached one liner. The problem is that during building the core, something (test/regress) requires contrib/spi/refint.so to be built. If you're willing to override $(LD), seems you could get around that additional problem by overriding $(CC) as well: export CC=$(CC) -m32 export LD=ld -melf_i386 *** src/Makefile.port.old 2009-08-27 10:56:46.0 +0200 --- src/Makefile.port 2009-08-27 10:56:46.0 +0200 *** *** 11,16 endif %.so: %.o ! $(CC) -shared -o $@ $ sqlmansect = 7 --- 11,16 endif %.so: %.o ! $(CC) $(CFLAGS) -shared -o $@ $ sqlmansect = 7 I guess we should change that rule to use $(LD) instead of $(CC), and include $(LDFLAGS) in the rules that build SUBSYS.o. Or maybe there's a reason they are what they are, I don't know. (SUBSYS.o's are gone in 8.4 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] Unicode UTF-8 table formatting for psql text output
On Tue, Aug 25, 2009 at 10:32:50PM -0400, Alvaro Herrera wrote:
Roger Leigh escribió:
An updated copy of the patch is attached.
Did you give expanded output a look? (\x) I find it a bit weird that
the first line shows a single-pixel wide line but the subsequent ones
are thicker.
Yes, it's just due to the fact that the middle lines are using a
thicker line character, while the top and bottom lines are thin.
This can easily be changed to be e.g. all thin.
BTW I think you should also look at multiline fields,
a │ b
━━━┿━━━
4 │ some text
: and some more
: and then some
(1 filas)
And wrapped:
alvherre=# select * from foo;
a │ b
━━━┿
5 │ En un lugar de la Mancha, de cuyo nombre no quiero acordarme, no ha
mucho
; tiempo que vivía un hidalgo
(1 fila)
I initially left these exactly the same as for ASCII (the ':' and ';'
usage). However, it's quite possible to make it use other characters.
We could use the same lines, or two, three or four dashed lines
('╎' and '╏', or ┆' and '┇' or '┊' and '┋').
There are also additional characters such as half-lines
('╶', '╷', '╹' and '╻'). Is this the kind of this you are referring
to?
The wrapping code also appears slightly broken anyway, since
continuation lines don't get '|' printed for subsequent blank columns
on the same line:
# SELECT * FROM testw;
a │ b │ c │ kfduagahkjdfghalksdkfhajsdkl
━━━┿━┿━━━┿━━
1 │ This is a test stri │ │
; ng
2 │ sbuild-createchroot │ │
; installs build-ess
; entials so your wor
; king
3 │ sbuild-createchroot │ │
; installs build-ess
; entials so your wor
; king environment sh
; ould already be ok.
; You will need only
; to add a few more
; packages in the chr
; oot, using e.g.
(3 rows)
(this is unchanged from psql behaviour in CVS.)
I also see in the code that under some circumstances (curr_nl_line), a
'+' is used instead of a space when printing table headers, but I
haven't been able to trigger this yet. We could also use dashed
horizontal rules here.
Regards,
Roger
--
.''`. Roger Leigh
: :' : Debian GNU/Linux http://people.debian.org/~rleigh/
`. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/
`-GPG Public Key: 0x25BFB848 Please GPG sign your mail.
signature.asc
Description: Digital signature
Re: [HACKERS] Build system problem in 8.3.x
Heikki Linnakangas írta:
Boszormenyi Zoltan wrote:
we have come across a problem in 8.3.x (8.3.5 and 8.3.7 was tested)
while building PostgreSQL for 32-bit on 64-bit RHEL5 and Fedora 9.
The following defines were used before running configure:
export CFLAGS=-m32
export LD=ld -melf_i386
The above are needed because when SUBSYS.o files are created,
the $(LD) ... lines don't contain $(LDFLAGS) anywhere, so overriding
$(LD) on the command line has to be done instead.
However, there's one additional problem that can be solved by the
attached one liner. The problem is that during building the core,
something (test/regress) requires contrib/spi/refint.so to be built.
If you're willing to override $(LD), seems you could get around that
additional problem by overriding $(CC) as well:
export CC=$(CC) -m32
export LD=ld -melf_i386
Yes, it's true. Ultimately CFLAGS and LDFLAGS should be
the way to control special compilation or linking. But there's
a problem:
export CFLAGS=-m32
export LDFLAGS=-melf_i386
$ ./configure --prefix=/home/zozo/pgc835_32 --enable-depend --enable-debug
checking build system type... x86_64-unknown-linux-gnu
checking host system type... x86_64-unknown-linux-gnu
checking which template to use... linux
checking whether to build with 64-bit integer date/time support... no
checking whether NLS is wanted... no
checking for default port number... 5432
checking for gcc... gcc
checking for C compiler default output file name... configure: error: C
compiler cannot create executables
See `config.log' for more details.
In config.log:
configure:2246: checking for C compiler default output file name
configure:2249: gcc -m32 -melf_i386 conftest.c 5
cc1: error: unrecognized command line option -melf_i386
configure:2252: $? = 1
configure: failed program was:
| /* confdefs.h. */
|
| #define PACKAGE_NAME PostgreSQL
| #define PACKAGE_TARNAME postgresql
| #define PACKAGE_VERSION 8.3.5
| #define PACKAGE_STRING PostgreSQL 8.3.5
| #define PACKAGE_BUGREPORT pgsql-b...@postgresql.org
| #define PG_VERSION 8.3.5
| #define DEF_PGPORT 5432
| #define DEF_PGPORT_STR 5432
| /* end confdefs.h. */
|
| int
| main ()
| {
|
| ;
| return 0;
| }
configure:2291: error: C compiler cannot create executables
GCC should get only CFLAGS on the compilation line,
it passes -melf_i386 to LD automatically.
Also, modifying LD and CC may stir up some problems in the
USE_PGXS=1 machinery, I don't know. Adding $(LDFLAGS)
to Makefiles would be the way to go, some discussion is needed.
*** src/Makefile.port.old2009-08-27 10:56:46.0 +0200
--- src/Makefile.port2009-08-27 10:56:46.0 +0200
***
*** 11,16
endif
%.so: %.o
!$(CC) -shared -o $@ $
sqlmansect = 7
--- 11,16
endif
%.so: %.o
!$(CC) $(CFLAGS) -shared -o $@ $
sqlmansect = 7
I guess we should change that rule to use $(LD) instead of $(CC), and
include $(LDFLAGS) in the rules that build SUBSYS.o. Or maybe there's a
reason they are what they are, I don't know.
Maybe the one who wrote the Makefiles for this SUBSYS.o
scheme could tell us. Maybe the reason is simply multilib systems
weren't so widespread at the time.
(SUBSYS.o's are gone in 8.4 anyway)
I know, but older 8.x versions are still supported, such build-system
fixes might be allowed to go in...
--
Bible has answers for everything. Proof:
But let your communication be, Yea, yea; Nay, nay: for whatsoever is more
than these cometh of evil. (Matthew 5:37) - basics of digital technology.
May your kingdom come - superficial description of plate tectonics
--
Zoltán Böszörményi
Cybertec Schönig Schönig GmbH
http://www.postgresql.at/
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] clang's static checker report.
On 24 Aug 2009, at 14:40, Peter Eisentraut wrote: On mån, 2009-08-24 at 00:42 +0100, Grzegorz Jaskiewicz wrote: --enable-cassert, enabled, and also added exit_* in pg_dump to list of functions that never return. A few more functions to mark noreturn: DateTimeParseError(), and die_horribly() in pg_dump done. new scan at: http://zlew.org/postgresql_static_check/scan-build-2009-08-27-2/ archive at: http://zlew.org/postgresql_static_check/postgresql_static_check_27thAugust2009.tar.xz If people find it useful (altho, I've only seen single commit as result of that checker, and nothing fancy either) - I can write a script that would update it on daily basis. what you people say ? New Patch : Index: src/Makefile.global.in === RCS file: /projects/cvsroot/pgsql/src/Makefile.global.in,v retrieving revision 1.258 diff -u -b -r1.258 Makefile.global.in --- src/Makefile.global.in 26 Aug 2009 22:24:42 - 1.258 +++ src/Makefile.global.in 27 Aug 2009 11:54:36 - @@ -205,7 +205,10 @@ endif endif # not PGXS +ifndef CC CC = @CC@ +endif + GCC = @GCC@ SUN_STUDIO_CC = @SUN_STUDIO_CC@ CFLAGS = @CFLAGS@ Index: src/bin/pg_dump/pg_backup.h === RCS file: /projects/cvsroot/pgsql/src/bin/pg_dump/pg_backup.h,v retrieving revision 1.52 diff -u -b -r1.52 pg_backup.h --- src/bin/pg_dump/pg_backup.h 11 Jun 2009 14:49:07 - 1.52 +++ src/bin/pg_dump/pg_backup.h 27 Aug 2009 11:54:37 - @@ -150,7 +150,7 @@ extern void exit_horribly(Archive *AH, const char *modulename, const char *fmt,...) -__attribute__((format(printf, 3, 4))); +__attribute__((format(printf, 3, 4))) __attribute__ ((analyzer_noreturn)); /* Lets the archive know we have a DB connection to shutdown if it dies */ Index: src/bin/pg_dump/pg_backup_archiver.h === RCS file: /projects/cvsroot/pgsql/src/bin/pg_dump/pg_backup_archiver.h,v retrieving revision 1.82 diff -u -b -r1.82 pg_backup_archiver.h --- src/bin/pg_dump/pg_backup_archiver.h7 Aug 2009 22:48:34 - 1.82 +++ src/bin/pg_dump/pg_backup_archiver.h27 Aug 2009 11:54:37 - @@ -325,7 +325,7 @@ /* Used everywhere */ extern const char *progname; -extern void die_horribly(ArchiveHandle *AH, const char *modulename, const char *fmt,...) __attribute__((format(printf, 3, 4))); +extern void die_horribly(ArchiveHandle *AH, const char *modulename, const char *fmt,...) __attribute__((format(printf, 3, 4))) __attribute__((analyzer_noreturn)); extern void warn_or_die_horribly(ArchiveHandle *AH, const char *modulename, const char *fmt,...) __attribute__((format(printf, 3, 4))); extern void write_msg(const char *modulename, const char *fmt,...) __attribute__((format(printf, 2, 3))); Index: src/bin/pg_dump/pg_dump.h === RCS file: /projects/cvsroot/pgsql/src/bin/pg_dump/pg_dump.h,v retrieving revision 1.156 diff -u -b -r1.156 pg_dump.h --- src/bin/pg_dump/pg_dump.h 2 Aug 2009 22:14:52 - 1.156 +++ src/bin/pg_dump/pg_dump.h 27 Aug 2009 11:54:37 - @@ -481,7 +481,7 @@ extern void *pg_realloc(void *ptr, size_t size); extern void check_conn_and_db(void); -extern void exit_nicely(void); +extern void exit_nicely(void) __attribute__((analyzer_noreturn)); extern void parseOidArray(const char *str, Oid *array, int arraysize); Index: src/include/postgres.h === RCS file: /projects/cvsroot/pgsql/src/include/postgres.h,v retrieving revision 1.92 diff -u -b -r1.92 postgres.h --- src/include/postgres.h 1 Jan 2009 17:23:55 - 1.92 +++ src/include/postgres.h 27 Aug 2009 11:54:37 - @@ -691,6 +691,6 @@ extern int ExceptionalCondition(const char *conditionName, const char *errorType, -const char *fileName, int lineNumber); + const char *fileName, int lineNumber) __attribute__ ((analyzer_noreturn)); #endif /* POSTGRES_H */ Index: src/include/utils/datetime.h === RCS file: /projects/cvsroot/pgsql/src/include/utils/datetime.h,v retrieving revision 1.75 diff -u -b -r1.75 datetime.h --- src/include/utils/datetime.h11 Jun 2009 14:49:13 - 1.75 +++ src/include/utils/datetime.h27 Aug 2009 11:54:37 - @@ -300,7 +300,7 @@ int *dtype, struct pg_tm * tm, fsec_t *fsec); extern void DateTimeParseError(int dterr, const char *str, - const char *datatype); + const char *datatype) __attribute__((__noreturn__)); extern int DetermineTimeZoneOffset(struct pg_tm * tm, pg_tz *tzp); Index: src/include/utils/elog.h
Re: [HACKERS] Patches for static check on geo_ops.c
On 27 Aug 2009, at 10:46, Paul Matthews wrote: Grzegorz Jaskiewicz wonderful static checker coughed up 5 errors in geo_ops.c. None of them of any particular excitement or of earth shattering nature. A patch is attached below that should correct these. (The more little issue we eliminate, the more the large ones will stand out.) I am flattered, but I am merely a user of it - running it against postgresql's source. The checker is written by wonderful llvm developers, so you should thank them (and apple, for sponsoring development of the checker). -- 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] clang's static checker report.
heh, sorry folks for the noise again :/ There was a fair amount of false positives there - due to nature of Assert() macro. Mainly, since assert_enabled is a runtime variable, not a macro (which I sadly overlooked). So, hardcoding it to (1) (using CPP) removed quite few false positives. New results at: http://zlew.org/postgresql_static_check/scan-build-2009-08-27-4/ archive at: http://zlew.org/postgresql_static_check/postgresql_static_check_27thAugust2009_2.tar.xz Please tell me, if you think that it can be improved more. -- 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] 8.5 release timetable, again
On Wed, Aug 26, 2009 at 7:39 PM, Bruce Momjianbr...@momjian.us wrote: Peter Eisentraut wrote: Much of the delay and uncertainty during beta in my mind comes from the situation that we wait for negative results and don't trust the release until we have seen and fixed enough of them. Instead of waiting for concrete, positive results and producing the release with confidence. Yep, that is our dilemma. To get positive results in which you can have confidence, you have to know that the testing which was done actually did a reasonably good job exercising the code in a way that would have flushed out bugs, had any been present. That sounds a lot like the definition of a regression test suite. Of course, we have that already, but it's nowhere near comprehensive. Maybe we should be looking at an expanded test suite that runs on a time scale of hours rather than seconds. Actually, didn't Peter talk about something like this at PGCon? I don't think that any test suite is going to eliminate the need for beta-testing. But if we could say that we had a regression test suite which covered X% of our code, and it passed on all Y platforms tested, that would certainly be a confidence booster, especially for large values of X. What we're basically doing now is hoping that beta-testers come up with some novel tests, and that's a bit hit-or-miss. Part of the question, of course, is how to build up such a regression test suite. One way to do it is try to add a test every time you fix a bug, such that the new test fails on the unpatched code and passes with the fix... or we could have a expanded-regression-test only commitfest during beta, or something. I think people would be willing to put in some work on this. I certainly would. I run the regression tests frequently during development but unless I'm making system catalog changes they rarely catch anything. I'm not prepared to write the whole thing myself, but I would definitely be willing to develop and contribute some tests. ...Robert -- 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] Unicode UTF-8 table formatting for psql text output
Roger Leigh escribió:
On Tue, Aug 25, 2009 at 10:32:50PM -0400, Alvaro Herrera wrote:
Roger Leigh escribió:
An updated copy of the patch is attached.
Did you give expanded output a look? (\x) I find it a bit weird that
the first line shows a single-pixel wide line but the subsequent ones
are thicker.
Yes, it's just due to the fact that the middle lines are using a
thicker line character, while the top and bottom lines are thin.
This can easily be changed to be e.g. all thin.
Yeah, I think expanded output should use the same char for all lines.
BTW I think you should also look at multiline fields,
a │ b
━━━┿━━━
4 │ some text
: and some more
: and then some
(1 filas)
And wrapped:
alvherre=# select * from foo;
a │ b
━━━┿
5 │ En un lugar de la Mancha, de cuyo nombre no quiero acordarme, no ha
mucho
; tiempo que vivía un hidalgo
(1 fila)
I initially left these exactly the same as for ASCII (the ':' and ';'
usage). However, it's quite possible to make it use other characters.
We could use the same lines, or two, three or four dashed lines
('╎' and '╏', or ┆' and '┇' or '┊' and '┋').
This works for me (say ╎ for newline-separated strings and ┊ for wrapped
output).
The wrapping code also appears slightly broken anyway, since
continuation lines don't get '|' printed for subsequent blank columns
on the same line:
Yeah ... maybe there's a point to this, or maybe it's just a bug -- I
don't know.
I also see in the code that under some circumstances (curr_nl_line), a
'+' is used instead of a space when printing table headers, but I
haven't been able to trigger this yet. We could also use dashed
horizontal rules here.
Hmm, can't say I know what's this about.
--
Alvaro Herrerahttp://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.
--
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] 8.5 release timetable, again
Robert Haas robertmh...@gmail.com wrote: Maybe we should be looking at an expanded test suite that runs on a time scale of hours rather than seconds. if we could say that we had a regression test suite which covered X% of our code, and it passed on all Y platforms tested, that would certainly be a confidence booster, especially for large values of X. Part of the question, of course, is how to build up such a regression test suite. Aren't there code coverage monitoring tools that could be run during regression tests? Sure it would take some time to review the results and fashion tests to exercise chunks of code which were missed, but at least we could quantify X and try to make incremental progress on increasing it -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] MySQL Compatibility WAS: 8.5 release timetable, again
Le mercredi 26 août 2009 à 15:51 -0700, Josh Berkus a écrit : I doubt this would be an accurate description of all Drupal developers. My opinion was : Before adding replication to PostgreSQL, it would be better to support a basic set of MySQL syntax seems relevant: DELETE FROM table1, table2 FROM table1 INNER JOIN table2 ON ... UPDATE table1, table1 SET table1.foo=1, table2.bar=3 WHERE table1.foo=2 INNER JOIN table2 ..., etc ... There is not much to add to PostgreSQL, but it seems relevant. Otherwise, replicating some MySQL SQL syntax will not work. As you know, people willing to use PostgreSQL replication are possibly already MySQL replication users. So if they test and PostgreSQL fails, this is too bad. Drupal was only an example, I did not mean to criticize all Drupal developers. Just to say they focus on PHP and not SQL. They don't have time to port MySQL code. Besides, they are very nice people. So I apologize for this short (false) focus. Bye, Jean-Michel signature.asc Description: Ceci est une partie de message numériquement signée
Re: [HACKERS] 8.5 release timetable, again
Robert Haas robertmh...@gmail.com writes: ... That sounds a lot like the definition of a regression test suite. Of course, we have that already, but it's nowhere near comprehensive. Maybe we should be looking at an expanded test suite that runs on a time scale of hours rather than seconds. mysql's got one of those, and I haven't noticed that it's kept their defect rate down any. Hour-long regression suites are the sort of thing developers won't run. Worse, regression suites are necessarily designed to exercise only 100%-reproducible behavior. I don't think that any test suite is going to eliminate the need for beta-testing. Precisely... What I'd like to see is some sort of test mechanism for WAL recovery. What I've done sometimes in the past (and recently had to fix the tests to re-enable) is to kill -9 a backend immediately after running the regression tests, let the system replay the WAL for the tests, and then take a pg_dump and compare that to the dump gotten after a conventional run. However this is quite haphazard since (a) the regression tests aren't especially designed to exercise all of the WAL logic, and (b) pg_dump might not show the effects of some problems, particularly not corruption in non-system indexes. It would be worth the trouble to create a more specific test methodology. In short: merely making the tests bigger doesn't impress me in the least. Focused testing on areas we aren't covering at all could be worth the trouble. 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] Unicode UTF-8 table formatting for psql text output
Alvaro Herrera escribió:
I initially left these exactly the same as for ASCII (the ':' and ';'
usage). However, it's quite possible to make it use other characters.
We could use the same lines, or two, three or four dashed lines
('╎' and '╏', or ┆' and '┇' or '┊' and '┋').
This works for me (say ╎ for newline-separated strings and ┊ for wrapped
output).
So it'd look like this:
alvherre=# select * from foo;
a │ b
━━━┿
1 │ En un lugar de la Mancha, de cuyo nombre no quiero acordarme, no ha mucho
┊ tiempo que vivía un hidalgo de los de lanza en astillero, adarga antigua,
┊ rocín flaco y galgo corredor. Una olla de algo más vaca que carnero, salpi
┊ cón las más noches, duelos y quebrantos los sábados, lantejas los viernes,
┊ algún palomino de añadidura los domingos, consumían las tres partes de su
┊ hacienda. El resto della concluían sayo de velarte, calzas de velludo par
┊ a las fiestas, con sus pantuflos de lo mesmo, y los días de entresemana se
┊ honraba con su vellorí de lo más fino. Tenía en su casa una ama que pasa
┊ ba de los cuarenta, y una sobrina que no llegaba a los veinte, y un mozo d
┊ e campo y plaza, que así ensillaba el rocín como tomaba la podadera.
2 │ —«Nunca fuera caballero de
╎ damas tan bien servido
╎ como fuera don Quijote
╎ cuando de su aldea vino:
╎ doncellas curaban dél;
╎ princesas, del su rocino»
(2 filas)
--
Alvaro Herrerahttp://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.
--
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] pretty print viewdefs
Tom Lane wrote:
Greg Stark gsst...@mit.edu writes:
Incidentally I just tried
\d information_schema.views
and it *does* seem to put newlines after some of the target list
items. After each of the CASE expressions it puts a newline. So you
*already* get a mixture of some multiple items on a line and some
one-per-line.
Yeah, sufficiently complex expressions (sub-selects, for an obvious
case) will get internal pretty-printing that might include newlines.
OK, drawing this together, what I did was to go back closer to my
original idea, but put this in a separate function, so nobody would get
too upset ;-)
Here is what my function does, and also what the current pretty
printing does:
andrew=# select pg_get_viewdef_long('foo');
pg_get_viewdef_long
--
SELECT 'a'::text AS b,
( SELECT 1
FROM dual) AS x,
random() AS y,
CASE
WHEN true THEN 1
ELSE 0
END AS c,
1 AS d
FROM dual;
(1 row)
andrew=# select pg_get_viewdef('foo',true);
pg_get_viewdef
-
SELECT 'a'::text AS b, ( SELECT 1
FROM dual) AS x, random() AS y,
CASE
WHEN true THEN 1
ELSE 0
END AS c, 1 AS d
FROM dual;
(1 row)
WIP Patch is attached. To complete it I would add a psql option to use
it, but maybe we should have a psql setting to enable it ... building
something extra into the \d* stuff looks a bit ugly, since we already
have a million options.
cheers
andrew
Index: src/include/catalog/pg_proc.h
===
RCS file: /cvsroot/pgsql/src/include/catalog/pg_proc.h,v
retrieving revision 1.549
diff -c -r1.549 pg_proc.h
*** src/include/catalog/pg_proc.h 4 Aug 2009 04:04:12 - 1.549
--- src/include/catalog/pg_proc.h 27 Aug 2009 14:22:04 -
***
*** 4071,4076
--- 4071,4080
DESCR(select statement of a view with pretty-print option);
DATA(insert OID = 2506 ( pg_get_viewdef PGNSP PGUID 12 1 0 0 f f f t f s 2 0 25 26 16 _null_ _null_ _null_ _null_ pg_get_viewdef_ext _null_ _null_ _null_ ));
DESCR(select statement of a view with pretty-print option);
+ DATA(insert OID = 2336 ( pg_get_viewdef_long PGNSP PGUID 12 1 0 0 f f f t f s 1 0 25 25 _null_ _null_ _null_ _null_ pg_get_viewdef_name_long _null_ _null_ _null_ ));
+ DESCR(select statement of a view with pretty-printing, columns line separated);
+ DATA(insert OID = 2337 ( pg_get_viewdef_long PGNSP PGUID 12 1 0 0 f f f t f s 1 0 25 26 _null_ _null_ _null_ _null_ pg_get_viewdef_long _null_ _null_ _null_ ));
+ DESCR(select statement of a view with pretty-printing, columns line separated);
DATA(insert OID = 2507 ( pg_get_indexdef PGNSP PGUID 12 1 0 0 f f f t f s 3 0 25 26 23 16 _null_ _null_ _null_ _null_ pg_get_indexdef_ext _null_ _null_ _null_ ));
DESCR(index description (full create statement or single expression) with pretty-print option);
DATA(insert OID = 2508 ( pg_get_constraintdef PGNSP PGUID 12 1 0 0 f f f t f s 2 0 25 26 16 _null_ _null_ _null_ _null_ pg_get_constraintdef_ext _null_ _null_ _null_ ));
Index: src/include/utils/builtins.h
===
RCS file: /cvsroot/pgsql/src/include/utils/builtins.h,v
retrieving revision 1.338
diff -c -r1.338 builtins.h
*** src/include/utils/builtins.h 4 Aug 2009 16:08:36 - 1.338
--- src/include/utils/builtins.h 27 Aug 2009 14:22:05 -
***
*** 582,589
--- 582,591
extern Datum pg_get_ruledef_ext(PG_FUNCTION_ARGS);
extern Datum pg_get_viewdef(PG_FUNCTION_ARGS);
extern Datum pg_get_viewdef_ext(PG_FUNCTION_ARGS);
+ extern Datum pg_get_viewdef_long(PG_FUNCTION_ARGS);
extern Datum pg_get_viewdef_name(PG_FUNCTION_ARGS);
extern Datum pg_get_viewdef_name_ext(PG_FUNCTION_ARGS);
+ extern Datum pg_get_viewdef_name_long(PG_FUNCTION_ARGS);
extern Datum pg_get_indexdef(PG_FUNCTION_ARGS);
extern Datum pg_get_indexdef_ext(PG_FUNCTION_ARGS);
extern char *pg_get_indexdef_string(Oid indexrelid);
Index: src/backend/utils/adt/ruleutils.c
===
RCS file: /cvsroot/pgsql/src/backend/utils/adt/ruleutils.c,v
retrieving revision 1.306
diff -c -r1.306 ruleutils.c
*** src/backend/utils/adt/ruleutils.c 1 Aug 2009 19:59:41 - 1.306
--- src/backend/utils/adt/ruleutils.c 27 Aug 2009 14:22:05 -
***
*** 71,80
--- 71,83
/* Pretty flags */
#define PRETTYFLAG_PAREN 1
#define PRETTYFLAG_INDENT 2
+ #define PRETTYFLAG_ONETARGET 4
/* macro to test if pretty action needed */
#define PRETTY_PAREN(context) ((context)-prettyFlags PRETTYFLAG_PAREN)
#define PRETTY_INDENT(context) ((context)-prettyFlags PRETTYFLAG_INDENT)
+ #define
Re: [HACKERS] Build system problem in 8.3.x
--On 27. August 2009 11:34:29 +0200 Boszormenyi Zoltan z...@cybertec.at wrote: make -C ../../../contrib/spi refint.so autoinc.so make[3]: Entering directory `/home/zozo/Schönig-számlák/lucent/postgresql-8.3.5/contrib/spi' gcc -m32 -Wall -Wmissing-prototypes -Wpointer-arith -Winline -Wdeclaration-after-statement -Wendif-labels -fno-strict-aliasing -fwrapv -fpic -DREFINT_VERBOSE -I. -I../../src/include -D_GNU_SOURCE -c -o refint.o refint.c gcc -shared -o refint.so refint.o /usr/bin/ld: i386 architecture of input file `refint.o' is incompatible with i386:x86-64 output I had a similar problem some time in the past on a multiarch SuSE on pSeries (however, it was the other way around, building 64-bit on 32-bit userspace). I blogged my solution here: http://psoos.blogspot.com/2008/05/building-postgresql-on-ibm-pseriessles.html -- 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] BUG #4996: postgres.exe memory consumption keeps going up
Greg Stark wrote: Now why did this message get delayed by 4 hours before maia-1 delivered it to me? That was long enough in this to completely lose the thread of conversation. Received: from postgresql.org (mail.postgresql.org [200.46.204.86]) by maia-1.hub.org (Postfix) with ESMTP id 2909CAFD073; Thu, 27 Aug 2009 03:21:19 + (UTC) Received: from localhost (unknown [200.46.208.211]) by mail.postgresql.org (Postfix) with ESMTP id 0AC3463486D for pgsql-bugs-postgresql@mail.postgresql.org; Wed, 26 Aug 2009 20:52:17 -0300 (ADT) Moderator delay? I note that the message jumped to me from mx2.hub.org instead of maia-1, but at exactly the same time (down to seconds) -- but at a different time zone. -- Alvaro Herrerahttp://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. -- 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] 8.5 release timetable, again
On Thu, Aug 27, 2009 at 10:11 AM, Tom Lanet...@sss.pgh.pa.us wrote: Robert Haas robertmh...@gmail.com writes: ... That sounds a lot like the definition of a regression test suite. Of course, we have that already, but it's nowhere near comprehensive. Maybe we should be looking at an expanded test suite that runs on a time scale of hours rather than seconds. mysql's got one of those, and I haven't noticed that it's kept their defect rate down any. Hour-long regression suites are the sort of thing developers won't run. Well, I'll run them. And I bet we could get volunteers to provide machines to run them every night, too, against CVS HEAD. This has been discussed before, and I wasn't the one who suggested it. I can't speak to the value (or lack thereof) of mysql's regression test suite as I know nothing about it, but even if it is completely worthless that does not prove that a worthwhile test suite can't be constructed. Worse, regression suites are necessarily designed to exercise only 100%-reproducible behavior. That is true, but our current testing methodology (hoping the beta-testers find the bugs) seems not to be completely satisfactory either. Which brings us to: I don't think that any test suite is going to eliminate the need for beta-testing. Precisely... What I'd like to see is some sort of test mechanism for WAL recovery. What I've done sometimes in the past (and recently had to fix the tests to re-enable) is to kill -9 a backend immediately after running the regression tests, let the system replay the WAL for the tests, and then take a pg_dump and compare that to the dump gotten after a conventional run. However this is quite haphazard since (a) the regression tests aren't especially designed to exercise all of the WAL logic, and (b) pg_dump might not show the effects of some problems, particularly not corruption in non-system indexes. It would be worth the trouble to create a more specific test methodology. Yep. I was thinking about this as an area for possible improvement. I don't immediately have a brilliant idea how to do it. I did have the idea of creating a loadable C function which would panic the database. This could be used to crash the database at a particular point (even in mid-query, with sufficient creativity). I think we would certainly need some more powerful way of checking pass/failure than exact-text comparisons on SQL query results. Being a perl guy, the first thing that occurs to me is to write some kind of test harness in perl that can issue SQL queries as well as do other things, but I don't have an exact design mapped out in my head, and I'm sure there are other viable approaches. In short: merely making the tests bigger doesn't impress me in the least. Focused testing on areas we aren't covering at all could be worth the trouble. Well, I wasn't suggesting adding a lot more testing of things that we're already testing. I was assuming that we would craft the additional tests to hit areas that we are not now covering well. My point here is only to what Peter said upthread: we want to be able to get positive results rather than waiting for enough negative results (whatever that means). To get positive results, you must have a test suite. While letting beta testers test whatever they want has some value, testing things we think might be likely hiding places for bugs (such as WAL recovery) has merit, too. Making those tests well-organized and easily repeatable is, IMHO, a Good Thing. ...Robert -- 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] BUG #4996: postgres.exe memory consumption keeps going up
2009/8/27 Alvaro Herrera alvhe...@commandprompt.com: Greg Stark wrote: Now why did this message get delayed by 4 hours before maia-1 delivered it to me? That was long enough in this to completely lose the thread of conversation. Received: from postgresql.org (mail.postgresql.org [200.46.204.86]) by maia-1.hub.org (Postfix) with ESMTP id 2909CAFD073; Thu, 27 Aug 2009 03:21:19 + (UTC) Received: from localhost (unknown [200.46.208.211]) by mail.postgresql.org (Postfix) with ESMTP id 0AC3463486D for pgsql-bugs-postgresql@mail.postgresql.org; Wed, 26 Aug 2009 20:52:17 -0300 (ADT) Moderator delay? I note that the message jumped to me from mx2.hub.org instead of maia-1, but at exactly the same time (down to seconds) -- but at a different time zone. Quite likely. It's often not possible to see the difference between moderation delay and mailsystem breakage delay, without looking at the logfiles. It'd be kind of neat of majordomo could insert a held for moderation at time and released from moderation at time headers or something. Anybody know if that's possible to do? -- 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
Re: [HACKERS] 8.5 release timetable, again
Robert Haas robertmh...@gmail.com writes: Well, I wasn't suggesting adding a lot more testing of things that we're already testing. I was assuming that we would craft the additional tests to hit areas that we are not now covering well. My point here is only to what Peter said upthread: we want to be able to get positive results rather than waiting for enough negative results (whatever that means). To get positive results, you must have a test suite. While letting beta testers test whatever they want has some value, testing things we think might be likely hiding places for bugs (such as WAL recovery) has merit, too. Making those tests well-organized and easily repeatable is, IMHO, a Good Thing. The problem here is the easily repeatable bit. Almost by definition, easily repeatable tests don't find hard-to-reproduce problems. I don't mean to suggest that they're without value, but they are no substitute for beta testers doing unpredictable things. 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] BUG #4996: postgres.exe memory consumption keeps going up
Magnus Hagander wrote: It'd be kind of neat of majordomo could insert a held for moderation at time and released from moderation at time headers or something. Anybody know if that's possible to do? You'd need to get Marc to patch the Majordomo2 source code ... I proposed a patch months ago to have message-ids expanded in the message footer, but no luck. -- Alvaro Herrerahttp://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] BUG #4996: postgres.exe memory consumption keeps going up
2009/8/27 Alvaro Herrera alvhe...@commandprompt.com: Magnus Hagander wrote: It'd be kind of neat of majordomo could insert a held for moderation at time and released from moderation at time headers or something. Anybody know if that's possible to do? You'd need to get Marc to patch the Majordomo2 source code ... I proposed a patch months ago to have message-ids expanded in the message footer, but no luck. Did you cook up an actual patch? The majordomo server actually is something that the community has access to... (it's not properly documented, of course, but it's there) -- 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
Re: [HACKERS] 8.5 release timetable, again
On Thu, Aug 27, 2009 at 3:11 PM, Tom Lanet...@sss.pgh.pa.us wrote: Precisely... What I'd like to see is some sort of test mechanism for WAL recovery. What I've done sometimes in the past (and recently had to fix the tests to re-enable) is to kill -9 a backend immediately after running the regression tests, let the system replay the WAL for the tests, and then take a pg_dump and compare that to the dump gotten after a conventional run. However this is quite haphazard since (a) the regression tests aren't especially designed to exercise all of the WAL logic, and (b) pg_dump might not show the effects of some problems, particularly not corruption in non-system indexes. It would be worth the trouble to create a more specific test methodology. What I've been thinking of doing is having the regression suite take a backup after initdb and set archive mode on. when the regression suite finishes start the backup up and replay all the WAL. I'm not sure how to compare the databases since I don't think pg_dump actually works here -- a lot of the data is dropped by the end of the test. But at least that would test that replaying WAL didn't cause any crashes. -- greg http://mit.edu/~gsstark/resume.pdf -- 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] [BUGS] fillfactor hides autovacuum parameters in 8.4.0
Itagaki Takahiro wrote: Here is a patch to fix a bug in handling default values in reloptions. This fix should be applied to HEAD and 8.4.0. I used 'magic number -1' to propagate not-specified information to autovacuum process. It might look strange because the default value is out of range of the reloption, but I think it has less impact to the codes comapred with other solutions (dynamic default values etc.). I realized that any other solution here is going to be more complex and thus less appropriate for backpatch. I still don't like this very much because it doesn't seem to offer enough flexibility to user-specified reloptions; but any patch we come up with here is going to be applicable to CVS HEAD. So I'm going to apply your patch to both 8.4 and HEAD; we can always improve it later, I guess. -- Alvaro Herrerahttp://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. -- 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] BUG #4996: postgres.exe memory consumption keeps going up
Magnus Hagander wrote:
2009/8/27 Alvaro Herrera alvhe...@commandprompt.com:
Magnus Hagander wrote:
It'd be kind of neat of majordomo could insert a held for moderation
at time and released from moderation at time headers or
something. Anybody know if that's possible to do?
You'd need to get Marc to patch the Majordomo2 source code ...
I proposed a patch months ago to have message-ids expanded in the
message footer, but no luck.
Did you cook up an actual patch? The majordomo server actually is
something that the community has access to... (it's not properly
documented, of course, but it's there)
Of course; attached.
I have not tried a patch for the feature you propose. It'd be good to
have those (and also an indication of which moderator approved the
message).
--
Alvaro Herrerahttp://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.
diff -cr majordomo/lib/Mj/Resend.pm majordomo.orig/lib/Mj/Resend.pm
*** majordomo/lib/Mj/Resend.pm 2007-10-31 16:27:46.0 -0300
--- majordomo.orig/lib/Mj/Resend.pm 2009-03-17 12:06:32.0 -0400
***
*** 707,712
--- 707,713
'SUBJECT'= $subject || '(no subject)',
'SUBSCRIBED' = ($avars{'days_since_subscribe'} 0) ? not : ,
'USER' = $user,
+ 'MESSAGE_ID' = $msgid,
};
if ($mode !~ /archive/) {
--
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] 8.5 release timetable, again
On Thu, Aug 27, 2009 at 11:29:42AM -0400, Tom Lane wrote: Robert Haas robertmh...@gmail.com writes: Well, I wasn't suggesting adding a lot more testing of things that we're already testing. I was assuming that we would craft the additional tests to hit areas that we are not now covering well. My point here is only to what Peter said upthread: we want to be able to get positive results rather than waiting for enough negative results (whatever that means). To get positive results, you must have a test suite. While letting beta testers test whatever they want has some value, testing things we think might be likely hiding places for bugs (such as WAL recovery) has merit, too. Making those tests well-organized and easily repeatable is, IMHO, a Good Thing. The problem here is the easily repeatable bit. Almost by definition, easily repeatable tests don't find hard-to-reproduce problems. I don't mean to suggest that they're without value, but they are no substitute for beta testers doing unpredictable things. I've wondered before about using a system emulator to snapshot the disk on each write (I'd expect you could put some pretty low level hooks in with qemu and gdb) and then run each snapshot in another system to make sure that either the transaction is rolled back or committed as appropriate. I guess this would take a while to run but may help catch some obscure bugs. Or this an area that's well tested already? -- Sam http://samason.me.uk/ -- 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] 8.5 release timetable, again
On Thu, Aug 27, 2009 at 11:29 AM, Tom Lanet...@sss.pgh.pa.us wrote: Robert Haas robertmh...@gmail.com writes: Well, I wasn't suggesting adding a lot more testing of things that we're already testing. I was assuming that we would craft the additional tests to hit areas that we are not now covering well. My point here is only to what Peter said upthread: we want to be able to get positive results rather than waiting for enough negative results (whatever that means). To get positive results, you must have a test suite. While letting beta testers test whatever they want has some value, testing things we think might be likely hiding places for bugs (such as WAL recovery) has merit, too. Making those tests well-organized and easily repeatable is, IMHO, a Good Thing. The problem here is the easily repeatable bit. Almost by definition, easily repeatable tests don't find hard-to-reproduce problems. I don't mean to suggest that they're without value, but they are no substitute for beta testers doing unpredictable things. I think you're overstating the case, but I don't want to argue the point, particularly. What I do want to do is find a way to address the problem described in the last sentence of this email: http://archives.postgresql.org/pgsql-hackers/2009-08/msg01614.php Both committers and non-committers are currently suffering from the fact that there is not a lot of time in the year which is set aside for development, i.e. neither CommitFest-time nor beta-time. To fix this problem, we can: 1. Make CommitFests shorter. 2. Make CommitFests less frequent. 3. Continue developing during CommitFests. 4. Make beta cycles shorter. 5. Make beta cycles less frequent (i.e. lengthen the release cycle). 6. Continue developing during beta. I believe (1) to be completely impractical and (3) to be self-defeating. I suspect (2) will backfire badly. That doesn't leave us with a lot of options. We can certainly do (5), but the downside is that features that get committed won't hit release for a very long time. I and others have suggested a couple of possible approaches toward (4) or (6), such as changing the way we do release notes, adding more regression tests to give us more (not perfect) confidence that the release is solid, and/or branching the tree during beta. None of those ideas have gotten a single vote of confidence from you or Bruce. What's your suggestion? ...Robert -- 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] 8.5 release timetable, again
On Thu, Aug 27, 2009 at 10:38 AM, Greg Starkgsst...@mit.edu wrote: What I've been thinking of doing is having the regression suite take a backup after initdb and set archive mode on. when the regression suite finishes start the backup up and replay all the WAL. I'm not sure how to compare the databases - execute 60 of the 121 tests (or at least those that create tables and insert/update/delete the most data) - crash the server and replay the WAL - execute the rest of the tests and cross your fingers :) -- Atentamente, Jaime Casanova Soporte y capacitación de PostgreSQL Asesoría y desarrollo de sistemas Guayaquil - Ecuador Cel. +59387171157 -- 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] Patches for static check on geo_ops.c
Paul Matthews p...@netspace.net.au writes: Grzegorz Jaskiewicz wonderful static checker coughed up 5 errors in geo_ops.c. None of them of any particular excitement or of earth shattering nature. A patch is attached below that should correct these. (The more little issue we eliminate, the more the large ones will stand out.) At line 3131 value stored into 'dist' variable is never referenced again. At line 3014 value stored into 'dist' variable is never referenced again. At line 2942 value stored into 'd' variable is never referenced again. At line 2953 value stored into 'd' variable is never referenced again. At line 2993 value stored into 'd' variable is never referenced again. I've applied the first three of these changes, but not the last two (the 'dist' assignments). clang seems to have a tin ear for style :-(. It's failing to notice that we have several similar code blocks in sequence in these two places, and making the last one different from the rest would decrease code readability and modifiability. I'm happy if the compiler optimizes away useless stores, but I don't really think it should presume to dictate code style to us on that basis. BTW, if we did apply those changes, I suppose clang would immediately start complaining that the preceding assignments to 'd' are useless. So by the time we'd made it happy, those code blocks would look quite different from their mates. 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] [pgsql-hackers] Daily digest v1.9418 (15 messages)
-- Forwarded message -- From: Kevin Grittner kevin.gritt...@wicourts.gov To: Robert Haas robertmh...@gmail.com, Bruce Momjian br...@momjian.us Date: Thu, 27 Aug 2009 09:07:05 -0500 Subject: Re: 8.5 release timetable, again Robert Haas robertmh...@gmail.com wrote: Maybe we should be looking at an expanded test suite that runs on a time scale of hours rather than seconds. if we could say that we had a regression test suite which covered X% of our code, and it passed on all Y platforms tested, that would certainly be a confidence booster, especially for large values of X. Part of the question, of course, is how to build up such a regression test suite. Aren't there code coverage monitoring tools that could be run during regression tests? Sure it would take some time to review the results and fashion tests to exercise chunks of code which were missed, but at least we could quantify X and try to make incremental progress on increasing it But the fact that a piece of code was executed doesn't mean it did the right thing. If it does something subtly wrong, will we notice? Jeff
Re: [HACKERS] pretty print viewdefs
Andrew Dunstan and...@dunslane.net writes: OK, drawing this together, what I did was to go back closer to my original idea, but put this in a separate function, so nobody would get too upset ;-) This seems seriously ugly. Why don't you have the flag just driving your original two-line addition? 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] pretty print viewdefs
Tom Lane wrote: Andrew Dunstan and...@dunslane.net writes: OK, drawing this together, what I did was to go back closer to my original idea, but put this in a separate function, so nobody would get too upset ;-) This seems seriously ugly. Why don't you have the flag just driving your original two-line addition? I am confused. The original two line addition was already in effect driven by the PRETTY_INDENT flag, because the appendContextKeyword call would be effectively a no-op if that flag wasn't on. But apparently some people don't want each column on a separate line, as I do, even when it's pretty printed, so, since that's what I want, I provided for it in a separate function, but I made the code take account of the cases you and Greg mentioned, where it already begins a new line for the column def. So, what exactly is ugly? My code? I can believe that. I have since made it slightly simpler by using a pstrdup'ed string instead of an extra StringInfo object. The output? That's a matter of taste, but I don't see how it's less ugly than what's there now. The idea of a new function? I don't see how to get what I want without it unless we're prepared to upset some of the people who have objected to my proposal. 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] [pgsql-hackers] Daily digest v1.9418 (15 messages)
Jeff Janes jeff.ja...@gmail.com wrote: But the fact that a piece of code was executed doesn't mean it did the right thing. If it does something subtly wrong, will we notice? That's why it takes some time to fashion a decent test. On the other hand, if code is not being exercised at at all during the beta testing phase, it could do something dramatically wrong and we wouldn't notice. -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] Build system problem in 8.3.x
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes: *** src/Makefile.port.old2009-08-27 10:56:46.0 +0200 --- src/Makefile.port2009-08-27 10:56:46.0 +0200 *** *** 11,16 endif %.so: %.o !$(CC) -shared -o $@ $ sqlmansect = 7 --- 11,16 endif %.so: %.o !$(CC) $(CFLAGS) -shared -o $@ $ sqlmansect = 7 I guess we should change that rule to use $(LD) instead of $(CC), and include $(LDFLAGS) in the rules that build SUBSYS.o. Or maybe there's a reason they are what they are, I don't know. (SUBSYS.o's are gone in 8.4 anyway) Those rules are used to build .so's, not SUBSYS.o's. I see that this change is already applied to Makefile.linux in HEAD, but I'm not sure it's worth back-patching by itself. We know that on Darwin, which is where the most work has been done on cross-arch/multiarch builds, you really need the SUBSYS.o-ectomy as well to make multiarch builds simple. And we're *not* back-patching that. I'm inclined to say that making this workable is an 8.4 feature and you should use 8.4 if you need it. 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] 8.5 release timetable, again
Greg Stark gsst...@mit.edu writes: On Thu, Aug 27, 2009 at 3:11 PM, Tom Lanet...@sss.pgh.pa.us wrote: ... However this is quite haphazard since (a) the regression tests aren't especially designed to exercise all of the WAL logic, and (b) pg_dump might not show the effects of some problems, particularly not corruption in non-system indexes. It would be worth the trouble to create a more specific test methodology. What I've been thinking of doing is having the regression suite take a backup after initdb and set archive mode on. when the regression suite finishes start the backup up and replay all the WAL. I'm not sure how to compare the databases since I don't think pg_dump actually works here -- a lot of the data is dropped by the end of the test. Yeah, that's another problem with using the existing tests for this purpose --- a lot of possibly-useful stuff isn't kept around to the end. And the desire to keep the test modules independent limits the amount of interaction between them too. I really think we'd need a bespoke set of tests to get very far with this. This reminds me that pg_dump/pg_restore is another large pile of code that receives no formalized testing whatsoever ... 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] MySQL Compatibility WAS: 8.5 release timetable, again
2009/8/27 Jean-Michel Pouré j...@poure.com: Otherwise, replicating some MySQL SQL syntax will not work. As you know, people willing to use PostgreSQL replication are possibly already MySQL replication users. So if they test and PostgreSQL fails, this is too bad. yeah! but some times the reason MySQL is not failing on those cases is because it's broken... Consider this one: http://archives.postgresql.org/pgsql-general/2005-12/msg00487.php we don't want to copy the bugs nor the bad designs decisions from MySQL, no that everything from MySQL is bad but i would be scary if we start supporting every single piece of code MySQL accepts -- Atentamente, Jaime Casanova Soporte y capacitación de PostgreSQL Asesoría y desarrollo de sistemas Guayaquil - Ecuador Cel. +59387171157 -- 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] [pgsql-hackers] Daily digest v1.9418 (15 messages)
-- Forwarded message -- From: Tom Lane t...@sss.pgh.pa.us To: Robert Haas robertmh...@gmail.com Date: Thu, 27 Aug 2009 10:11:24 -0400 Subject: Re: 8.5 release timetable, again What I'd like to see is some sort of test mechanism for WAL recovery. What I've done sometimes in the past (and recently had to fix the tests to re-enable) is to kill -9 a backend immediately after running the regression tests, let the system replay the WAL for the tests, and then take a pg_dump and compare that to the dump gotten after a conventional run. However this is quite haphazard since (a) the regression tests aren't especially designed to exercise all of the WAL logic, and (b) pg_dump might not show the effects of some problems, particularly not corruption in non-system indexes. It would be worth the trouble to create a more specific test methodology. I hacked mdwrite so that it had a static int counter. When the counter hit 400 and if the guc_of_death was set, it would write out a partial block (to simulate a partial page write) and then PANIC. I have some Perl code that runs against the database doing a bunch of updates until the database dies. Then when it can reconnect again it makes sure the data reflects what Perl thinks it should. This is how I (belatedly) found and traced down the bug in the visibility bit. (What I was trying to do is determine if my toying around with XLogInsert was breaking anything. Since the regression suit wouldn't show me a problem if one existed, I came up with this. Then I found things were broken even before I started toying with it...) I don't know how lucky I was to hit open a test that found an already existing bug. I have to assume I was somewhat lucky, simply because it took a run of many hours or overnight (with a simulated crash every 2 minutes or so) to reliably detect the problem. But how do you turn something like this into a regression test? Scattering the code with intentional crash inducing code that is there to exercise the error recover parts seems like it would be quite a mess. In short: merely making the tests bigger doesn't impress me in the least. Focused testing on areas we aren't covering at all could be worth the trouble. Do you have suggestions on what other areas need it? Jeff
Re: [HACKERS] pretty print viewdefs
Andrew Dunstan and...@dunslane.net writes: I am confused. The original two line addition was already in effect driven by the PRETTY_INDENT flag, because the appendContextKeyword call would be effectively a no-op if that flag wasn't on. But apparently some people don't want each column on a separate line, as I do, even when it's pretty printed, so, since that's what I want, I provided for it in a separate function, but I made the code take account of the cases you and Greg mentioned, where it already begins a new line for the column def. What I was imagining was simply providing an additional pretty-print flag that gives the alternatives of the current behavior, or the patch you originally proposed that adds newlines between targetlist items all the time. I don't think that you should complicate the behavior any more than that. Personally I would prefer the original patch to this one. 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] [pgsql-hackers] Daily digest v1.9418 (15 messages)
On Thu, Aug 27, 2009 at 12:47 PM, Jeff Janesjeff.ja...@gmail.com wrote: -- Forwarded message -- From: Tom Lane t...@sss.pgh.pa.us To: Robert Haas robertmh...@gmail.com Date: Thu, 27 Aug 2009 10:11:24 -0400 Subject: Re: 8.5 release timetable, again What I'd like to see is some sort of test mechanism for WAL recovery. What I've done sometimes in the past (and recently had to fix the tests to re-enable) is to kill -9 a backend immediately after running the regression tests, let the system replay the WAL for the tests, and then take a pg_dump and compare that to the dump gotten after a conventional run. However this is quite haphazard since (a) the regression tests aren't especially designed to exercise all of the WAL logic, and (b) pg_dump might not show the effects of some problems, particularly not corruption in non-system indexes. It would be worth the trouble to create a more specific test methodology. I hacked mdwrite so that it had a static int counter. When the counter hit 400 and if the guc_of_death was set, it would write out a partial block (to simulate a partial page write) and then PANIC. I have some Perl code that runs against the database doing a bunch of updates until the database dies. Then when it can reconnect again it makes sure the data reflects what Perl thinks it should. This is how I (belatedly) found and traced down the bug in the visibility bit. (What I was trying to do is determine if my toying around with XLogInsert was breaking anything. Since the regression suit wouldn't show me a problem if one existed, I came up with this. Then I found things were broken even before I started toying with it...) I don't know how lucky I was to hit open a test that found an already existing bug. I have to assume I was somewhat lucky, simply because it took a run of many hours or overnight (with a simulated crash every 2 minutes or so) to reliably detect the problem. But how do you turn something like this into a regression test? Scattering the code with intentional crash inducing code that is there to exercise the error recover parts seems like it would be quite a mess. This is pretty cool, IMO. Admittedly, it does seem hard to bottle it, but you managed it, so it's not completely impossible. What you could for this kind of thing is a series of patches and driver scripts, so you build PostgreSQL with the patch, then run the driver script against it. Probably we'd want to standardize some kind of framework for the driver scripts, once we had a list of ideas for testing and some idea what it should look like. ...Robert P.S. The subject line of this thread is not ideal. -- 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] clang's static checker report.
On Thu, Aug 27, 2009 at 06:39, Grzegorz Jaskiewiczg...@pointblue.com.pl wrote: heh, sorry folks for the noise again :/ There was a fair amount of false positives there - due to nature of Assert() macro. Mainly, since assert_enabled is a runtime variable, not a macro (which I sadly overlooked). So, hardcoding it to (1) (using CPP) removed quite few false positives. New results at: http://zlew.org/postgresql_static_check/scan-build-2009-08-27-4/ archive at: http://zlew.org/postgresql_static_check/postgresql_static_check_27thAugust2009_2.tar.xz Please tell me, if you think that it can be improved more. Looks like your still missing ExitPostmaster(1) see http://zlew.org/postgresql_static_check/scan-build-2009-08-27-4/report-iqR9gz.html#EndPath. and maybe ereport(ERROR) ? see http://zlew.org/postgresql_static_check/scan-build-2009-08-27-4/report-gkkK9S.html#EndPath it calls report_untranslatable_char() which in turn calls ereport(ERROR) (do you have to mark every function that calls ereport(ERROR) as one that exits?) :) -- 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] clang's static checker report.
Alex Hunsaker bada...@gmail.com writes: (do you have to mark every function that calls ereport(ERROR) as one that exits?) That would be an open-ended project, and probably in many cases wouldn't change the clang report anyway. I think it's only worth worrying about the ones that we find will suppress some false positives. 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] pretty print viewdefs
Tom Lane wrote: Andrew Dunstan and...@dunslane.net writes: I am confused. The original two line addition was already in effect driven by the PRETTY_INDENT flag, because the appendContextKeyword call would be effectively a no-op if that flag wasn't on. But apparently some people don't want each column on a separate line, as I do, even when it's pretty printed, so, since that's what I want, I provided for it in a separate function, but I made the code take account of the cases you and Greg mentioned, where it already begins a new line for the column def. What I was imagining was simply providing an additional pretty-print flag that gives the alternatives of the current behavior, or the patch you originally proposed that adds newlines between targetlist items all the time. I don't think that you should complicate the behavior any more than that. Personally I would prefer the original patch to this one. OK, and how are we going to set that flag? Like I did, with a separate function? I assume you are in effect saying you don't mind if there is an occasional blank line in the output. 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] hot standby - merged up to CVS HEAD
On Mon, 2009-08-17 at 11:19 +0300, Heikki Linnakangas wrote: I think there's a race condition in the way LogCurrentRunningXacts() is called at the end of checkpoint. This can happen in the master: 1. Checkpoint starts 2. Transaction 123 begins, and does some updates 3. Checkpoint ends. LogCurrentRunningXacts() is called. 4. LogCurrentRunningXacts() gets the list of currently running transactions by calling GetCurrentTransactionData(). 5. Transaction 123 ends, writing commit record to WAL 6. LogCurrentRunningXacts() writes the list of running XIDs to WAL. This includes XID 123, since that was still running at step 4. When that is replayed, ProcArrayUpdateTransactions() will zap the unobserved xids array with the list that includes XID 123, even though we already saw a commit record for it. That's not a race condition, but it does make the code more complex. The issue has been long understood. I don't think it's acceptable to take and hold both ProcArray and WALInsertLock. Those are now the two most heavily contended locks on the system. We have evidence that there are burst delays associated with various operations on just one of those locks, let alone two. If you're still doubtful, the problem I've been working on recently is the point that I overlooked the initial state of the lock table in my earlier patch. GetRunningTransactionData() also needs to have initial lock data. There is no way in hell that I could personally condone holding ProcArrayLock, WALInsertLock and all of the LockMgrLock partitions at same time. So we just have to eat the complexity. (No doubt someone will disagree with my strong language here, but please take it as an indication of exactly how bad an idea holding multiple locks will be). Slight timing issues are not too bad really. We just have to be careful to assume that there is a mismatch in the data and must have code to handle that. Anyway, I've been working on this problem for some time and continue to do so. -- Simon Riggs www.2ndQuadrant.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] pretty print viewdefs
Andrew Dunstan and...@dunslane.net writes: OK, and how are we going to set that flag? Like I did, with a separate function? I would be inclined to invent a variant of pg_get_viewdef with an additional parameter rather than choosing a new function name, but otherwise yeah. Or we could decide this isn't worth all the trouble and just go back to your original patch. By the time you get done with all the documentation and client-side hacking that would be required, this patch is going to be a lot larger than it seems worth. I assume you are in effect saying you don't mind if there is an occasional blank line in the output. What blank line? I would expect prettyprinting of expressions to sometimes insert an embedded newline, but not one at the beginning or end. Do you have a counterexample? 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] pretty print viewdefs
Tom Lane wrote: I assume you are in effect saying you don't mind if there is an occasional blank line in the output. What blank line? I would expect prettyprinting of expressions to sometimes insert an embedded newline, but not one at the beginning or end. Do you have a counterexample? Yes, CASE expressions, as in my previously posted example: SELECT 'a'::text AS b, ( SELECT 1 FROM dual) AS x, random() AS y, CASE WHEN true THEN 1 ELSE 0 END AS c, 1 AS d FROM dual; 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] MySQL Compatibility WAS: 8.5 release timetable, again
2009/8/27 Jaime Casanova jcasa...@systemguards.com.ec: 2009/8/27 Jean-Michel Pouré j...@poure.com: Otherwise, replicating some MySQL SQL syntax will not work. As you know, people willing to use PostgreSQL replication are possibly already MySQL replication users. So if they test and PostgreSQL fails, this is too bad. yeah! but some times the reason MySQL is not failing on those cases is because it's broken... Consider this one: http://archives.postgresql.org/pgsql-general/2005-12/msg00487.php we don't want to copy the bugs nor the bad designs decisions from MySQL, no that everything from MySQL is bad but i would be scary if we start supporting every single piece of code MySQL accepts And that behavior has changed to be sane in 5.0+, iirc. -- Rob Wultsch wult...@gmail.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] return a set of records
Hi, I need to return a set of records from a query, first I translate
from sqlf to sql and later I wanna return the query, but the server
crash (I guess it crashes around the yyparse call).
This is the sql:
CREATE OR REPLACE FUNCTION sqlf (text) RETURNS SETOF record
AS 'MODULE_PATHNAME', 'sqlf'
LANGUAGE C IMMUTABLE STRICT;
This is the function:
Datum sqlf(PG_FUNCTION_ARGS) {
char *query = TextDatumGetCString(PG_GETARG_DATUM(0));
void *result;
int ret,proc;
int j,i;
FuncCallContext *funcctx;
int call_cntr;
int max_calls;
TupleDesc tupdesc;
SPITupleTable *tuptable;
AttInMetadata *attinmeta;
yy_scan_string(query);
sqlf_yyparse(result);
// stuff done only on the first call of the function
if (SRF_IS_FIRSTCALL()) {
MemoryContext oldcontext;
// create a function context for cross-call persistence
funcctx = SRF_FIRSTCALL_INIT();
// switch to memory context appropriate for multiple
// function calls
oldcontext =MemoryContextSwitchTo(funcctx-multi_call_memory_ctx);
SPI_connect();
ret=SPI_execute(result,true,0);
proc=SPI_processed;
// total number of tuples to be returned
funcctx-max_calls = proc;
if (ret 0 SPI_tuptable != NULL){
tupdesc = SPI_tuptable-tupdesc;
tuptable = SPI_tuptable;
}
MemoryContextSwitchTo(oldcontext);
}
// stuff done on every call of the function
funcctx = SRF_PERCALL_SETUP();
call_cntr = funcctx-call_cntr;
max_calls = funcctx-max_calls;
attinmeta = funcctx-attinmeta;
j=0;
if (call_cntr max_calls) { // do when there is more left to send
Datum *values;
HeapTuple tuple;
Datum datum_result;
bool isnull;
values = (Datum **) palloc(tupdesc-natts * sizeof(Datum *));
for (i = 1; i = tupdesc-natts; i++)
values[i]=SPI_getbinval(tuple,tupdesc,i,isnull);
tuple=tuptable-vals[j];
// make the tuple into a datum
datum_result = HeapTupleGetDatum(tuple);
j++;
SRF_RETURN_NEXT(funcctx, datum_result);
} else { // do when there is no more left
SRF_RETURN_DONE(funcctx);
}
}
Greetings.
--
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] 8.5 release timetable, again
On tor, 2009-08-27 at 09:58 -0400, Robert Haas wrote: To get positive results in which you can have confidence, you have to know that the testing which was done actually did a reasonably good job exercising the code in a way that would have flushed out bugs, had any been present. That sounds a lot like the definition of a regression test suite. Of course, we have that already, but it's nowhere near comprehensive. Maybe we should be looking at an expanded test suite that runs on a time scale of hours rather than seconds. Actually, didn't Peter talk about something like this at PGCon? Let's look at it this way: If I were writing a compiler, then I would have two main test approaches. First, I would have an in-tree test suite that compiles a bunch of example code snippets and checks that the results are reasonable. Call that a regression test. It would be informed by code coverage analysis and previously reported bugs. Second, as part of my release cycle, I would have an agenda to try to compile a large set of real programs against my new compiler version. I would do that during the beta period. You will notice that GCC pretty much operates that way. We have regression tests. They could and should be expanded. That's a developer job, and we can start working on that now. But this discussion was about what to do during beta. And I think during beta you want to test PostgreSQL against a large set of real applications. But we could try to clarify how to actually do that in an organized way. Now, if you want to improve the regression tests, I would suggest going through the commits since 8.4beta and since 8.4.0 final release and ask how these problems could have been prevented or caught earlier. I suppose a test suite for WAL might be part of the answer, but a closer analysis might be insightful. -- 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] hot standby - merged up to CVS HEAD
On Thu, Aug 27, 2009 at 07:08:28PM +0100, Simon Riggs wrote: On Mon, 2009-08-17 at 11:19 +0300, Heikki Linnakangas wrote: I think there's a race condition in the way LogCurrentRunningXacts() is called at the end of checkpoint. This can happen in the master: 1. Checkpoint starts 2. Transaction 123 begins, and does some updates 3. Checkpoint ends. LogCurrentRunningXacts() is called. 4. LogCurrentRunningXacts() gets the list of currently running transactions by calling GetCurrentTransactionData(). 5. Transaction 123 ends, writing commit record to WAL 6. LogCurrentRunningXacts() writes the list of running XIDs to WAL. This includes XID 123, since that was still running at step 4. When that is replayed, ProcArrayUpdateTransactions() will zap the unobserved xids array with the list that includes XID 123, even though we already saw a commit record for it. That's not a race condition, but it does make the code more complex. The issue has been long understood. I don't think it's acceptable to take and hold both ProcArray and WALInsertLock. Those are now the two most heavily contended locks on the system. We have evidence that there are burst delays associated with various operations on just one of those locks, let alone two. If you're still doubtful, the problem I've been working on recently is the point that I overlooked the initial state of the lock table in my earlier patch. GetRunningTransactionData() also needs to have initial lock data. There is no way in hell that I could personally condone holding ProcArrayLock, WALInsertLock and all of the LockMgrLock partitions at same time. So we just have to eat the complexity. (No doubt someone will disagree with my strong language here, but please take it as an indication of exactly how bad an idea holding multiple locks will be). Slight timing issues are not too bad really. We just have to be careful to assume that there is a mismatch in the data and must have code to handle that. Anyway, I've been working on this problem for some time and continue to do so. Great! Where's the git repository? Cheers, David. -- David Fetter da...@fetter.org http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter Skype: davidfetter XMPP: david.fet...@gmail.com Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate -- 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] MySQL Compatibility WAS: 8.5 release timetable, again
2009/8/27 Rob Wultsch wult...@gmail.com: And that behavior has changed to be sane in 5.0+, iirc. 5.0.12+ actually... that is stated in the same thread... the point was that if we simply were saying: hey! mysql can interpret this, make postgres do the same then we could end up with a lot of broken stuff... just because mysql users think is wonderful to not have to write sane code... -- Atentamente, Jaime Casanova Soporte y capacitación de PostgreSQL Asesoría y desarrollo de sistemas Guayaquil - Ecuador Cel. +59387171157 -- 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] 8.5 release timetable, again
On Thu, Aug 27, 2009 at 2:54 PM, Peter Eisentrautpete...@gmx.net wrote: On tor, 2009-08-27 at 09:58 -0400, Robert Haas wrote: To get positive results in which you can have confidence, you have to know that the testing which was done actually did a reasonably good job exercising the code in a way that would have flushed out bugs, had any been present. That sounds a lot like the definition of a regression test suite. Of course, we have that already, but it's nowhere near comprehensive. Maybe we should be looking at an expanded test suite that runs on a time scale of hours rather than seconds. Actually, didn't Peter talk about something like this at PGCon? Let's look at it this way: If I were writing a compiler, then I would have two main test approaches. First, I would have an in-tree test suite that compiles a bunch of example code snippets and checks that the results are reasonable. Call that a regression test. It would be informed by code coverage analysis and previously reported bugs. Second, as part of my release cycle, I would have an agenda to try to compile a large set of real programs against my new compiler version. I would do that during the beta period. You will notice that GCC pretty much operates that way. We have regression tests. They could and should be expanded. That's a developer job, and we can start working on that now. But this discussion was about what to do during beta. And I think during beta you want to test PostgreSQL against a large set of real applications. But we could try to clarify how to actually do that in an organized way. Now, if you want to improve the regression tests, I would suggest going through the commits since 8.4beta and since 8.4.0 final release and ask how these problems could have been prevented or caught earlier. I suppose a test suite for WAL might be part of the answer, but a closer analysis might be insightful. What I want to do is address the concern about too much of any given year being consumed by beta and CommitFest. I'm not sure I know how to do that though. ...Robert -- 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] 8.5 release timetable, again
Hi, Robert Haas robertmh...@gmail.com writes: On Thu, Aug 27, 2009 at 2:54 PM, Peter Eisentrautpete...@gmx.net wrote: We have regression tests. They could and should be expanded. That's a developer job, and we can start working on that now. But this discussion was about what to do during beta. And I think during beta you want to test PostgreSQL against a large set of real applications. But we could try to clarify how to actually do that in an organized way. Exactly, and I think that what we're missing here is a simple tool for our users to check a new PostgreSQL release against their existing application. We already know how to either log all queries and analyze the log files (CSV makes it easier, pgfouine parses them too) or to have a fe/be protocol proxy to record application SQL traffic (tsung recorder does that). What we miss is a tool to run the captured queries through both versions of PG and report any resultset mismatch, of course with a way to account for ordering issues (but we've seen people rely on the ordering when they don't give an order by clause, then bug the lists about it if a new release changes it). What I want to do is address the concern about too much of any given year being consumed by beta and CommitFest. I'm not sure I know how to do that though. To do this I think we *need* to provide beta tester a validator kind of tool which they can use even without having an application unit test suite. And a way to easily report success or failure, and in case of success, a notion of their tests coverage (which is reduced to the list of PG features the application exercices, but an automated way to extract the information while running the tool would allow for hackers friendly categories). Anyone interrested into starting a project and coding the tool we so much need? Regards, -- dim PS: of course provided with such a tool, I'd run it for several applications as soon as possible, which might include every alpha release. PPS: I'll be happy to participate into such a project, but I seem to have a rather full plate already and a shrinking OpenSource free time, so waiting for me to get there won't help until it's about too late. -- 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] 8.5 release timetable, again
On Sun, 2009-08-23 at 01:57 -0400, Tom Lane wrote: Robert Haas robertmh...@gmail.com writes: I posted a note about a week ago which drew far less commentary than I expected, regarding the timetable for the release of 8.5. http://archives.postgresql.org/pgsql-hackers/2009-08/msg01256.php Perhaps this is already being discussed on -core, but if so the conclusions haven't been shared publicly. Core hasn't discussed 8.5 schedule since the discussions that Peter summarized in the message you cited above. I share your concern that release in time for PGCon isn't very realistic if we don't get more aggressive about schedule. On the other hand, we didn't get all that much done in this fest. If we cut back to a three-fest schedule I think we may succeed in releasing 8.5 early, but only because there is nothing interesting in it :-(. Dunno where the right balance is. General comment on thread: The level of detailed planning happening now is a change for the community and in general I think it's a good thing. In the past we've always said it will be shipped when it's ready, and now we seem to be caught by our own rules. There's no need to make hard decisions now. Let's keep some flexibility in our thinking. If the structures give us problems, lets change the structures. The idea is the plans help the developers, not hinder them or make it harder to include big features. In my view it is important that I have a holistic view of what I am doing and that means it is very difficult for others to help in a way that doesn't merely hinder me (or Fujii-san). Speed of coding is not the issue here, nor is the number of hands on a keyboard. I don't share the doubts or fears expressed that the two big patches will not make it into Postgres in this release. We now have more people experienced in these areas of code than at any other time in our history. We have almost-complete solutions from experienced developers. In particular, I have faith in Fujii-san. I would appreciate it if somebody could send out some messages of calm, while I/we work. The time for open review will come around soon enough. Faith and patience. Please. No need for Fawlty Towers re-runs. -- Simon Riggs www.2ndQuadrant.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] 8.5 release timetable, again
On Thu, Aug 27, 2009 at 08:48:43PM +0100, Simon Riggs wrote: On Sun, 2009-08-23 at 01:57 -0400, Tom Lane wrote: Robert Haas robertmh...@gmail.com writes: I posted a note about a week ago which drew far less commentary than I expected, regarding the timetable for the release of 8.5. http://archives.postgresql.org/pgsql-hackers/2009-08/msg01256.php Perhaps this is already being discussed on -core, but if so the conclusions haven't been shared publicly. Core hasn't discussed 8.5 schedule since the discussions that Peter summarized in the message you cited above. I share your concern that release in time for PGCon isn't very realistic if we don't get more aggressive about schedule. On the other hand, we didn't get all that much done in this fest. If we cut back to a three-fest schedule I think we may succeed in releasing 8.5 early, but only because there is nothing interesting in it :-(. Dunno where the right balance is. General comment on thread: The level of detailed planning happening now is a change for the community and in general I think it's a good thing. In the past we've always said it will be shipped when it's ready, and now we seem to be caught by our own rules. There's no need to make hard decisions now. Let's keep some flexibility in our thinking. If the structures give us problems, lets change the structures. The idea is the plans help the developers, not hinder them or make it harder to include big features. In my view it is important that I have a holistic view of what I am doing and that means it is very difficult for others to help in a way that doesn't merely hinder me (or Fujii-san). Speed of coding is not the issue here, nor is the number of hands on a keyboard. I don't share the doubts or fears expressed that the two big patches will not make it into Postgres in this release. We now have more people experienced in these areas of code than at any other time in our history. We have almost-complete solutions from experienced developers. In particular, I have faith in Fujii-san. I would appreciate it if somebody could send out some messages of calm, while I/we work. The time for open review will come around soon enough. With all due respect, the time for open review is now. You have already tried closed development several times, and it each time has been, more or less, a spectacular failure. Cheers, David. -- David Fetter da...@fetter.org http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter Skype: davidfetter XMPP: david.fet...@gmail.com Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate -- 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] 8.5 release timetable, again
Robert Haas escribió: What I want to do is address the concern about too much of any given year being consumed by beta and CommitFest. I'm not sure I know how to do that though. How much time were we in beta? I thought most time was spent trying to get to beta in the first place. -- Alvaro Herrerahttp://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] typo in doc/src/sgml/release-8.4.sgml
Patch -p1 attached. Cheers, Jan diff --git a/doc/src/sgml/release-8.4.sgml b/doc/src/sgml/release-8.4.sgml index 184bf47..50d9cb0 100644 --- a/doc/src/sgml/release-8.4.sgml +++ b/doc/src/sgml/release-8.4.sgml @@ -104,7 +104,7 @@ listitem para Properly show fractional seconds and milliseconds for - functionEXTRACT()/ (Tom) + functionEXTRACT()/ (Tom) /para /listitem -- 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] typo in doc/src/sgml/release-8.4.sgml
Jan Urbański wrote: Patch -p1 attached. Applied, thanks -- Alvaro Herrerahttp://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] 8.5 release timetable, again
On Thu, Aug 27, 2009 at 3:53 PM, David Fetter da...@fetter.org wrote: I would appreciate it if somebody could send out some messages of calm, while I/we work. The time for open review will come around soon enough. With all due respect, the time for open review is now. You have already tried closed development several times, and it each time has been, more or less, a spectacular failure. Unlike Robert and Heikki, I don't see you contributing to or assisting Simon's work. And, while I may be wrong, I doubt that you assisted in funding any of Simon's work on hot standby either. As such, it's my opinion that continuing to criticize him from the sidelines is not only rude, but is also a bad idea as it relates to his motivation in working on this feature. -- Jonah H. Harris, Senior DBA myYearbook.com
Re: [HACKERS] 8.5 release timetable, again
On Thu, Aug 27, 2009 at 3:56 PM, Alvaro Herreraalvhe...@commandprompt.com wrote: Robert Haas escribió: What I want to do is address the concern about too much of any given year being consumed by beta and CommitFest. I'm not sure I know how to do that though. How much time were we in beta? I thought most time was spent trying to get to beta in the first place. [ looks ] The final CommitFest began November 11, 2008. It closed March 25, 2009 (+ 144 days). Beta1 was released April 15, 2009 (+ 21 days). 8.4.0 was released July 1, 2009 (+ 77 days). The first CommitFest for 8.5 began on July 15, 2009 (+ 14 days). http://www.postgresql.org/about/news.1074 http://wiki.postgresql.org/index.php?title=CommitFest_2008-11action=history http://www.postgresql.org/docs/8.4/static/release-8-4.html In total, the tree was closed for 256 days, or 8.5 months, of which the final CommitFest accounted for approximately 56%. Had we closed the final CommitFest in 30 days rather than 144 days, and had everything else taken the same amount of time, the release would have occurred on March 9th and the first CommitFest for 8.5 would have started on March 23rd. Hmm... maybe that's not actually that bad. If we stuck to a similar schedule for 8.5, but with a timely last CF, then we'd have either (3 CF): 2009-11-15 Final CommitFest Begins 2009-12-15 Final CommitFest Ends 2010-01-05 Beta 2010-03-23 Release 2010-04-06 First CommitFest for 8.6 Begins Or (4 CF): 2010-01-15 Final CommitFest Begins 2010-02-15 Final CommitFest Ends 2010-03-08 Beta 2010-05-24 Release 2010-06-07 First CommitFest for 8.6 Begins Of course I don't think we'd actually need to start a CommitFest quite as quickly as we did this time, because with a shorter release cycle there ought to be a lot less patches already accumulated by the time we release, especially if there are clearly defined tasks for developers to do during the beta period. On the other hand, 8.4beta was arguably too short, since we missed some serious problems, so the picture above may be a bit too rosy. ...Robert -- 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] 8.5 release timetable, again
and...@dunslane.net (Andrew Dunstan) writes: Actually, what I had in mind was getting people to run their applications etc. in some non-production environment on the beta. I talked to a client today and he said sure, we have several development environments and we can put one or two on the beta and then let the developers just do their thing on it. Testing the things we know about is in a way less important than making sure nothing else got broken. I've gotten the DB work on one of our applications to the point where there's a meaningful set of DB tests that can be run in automated fashion. As a result, I rotate between PG versions periodically; every couple weeks, I recompile HEAD, and run a test against it to make sure I don't see any regressions. It would be insane to think about deploying on some 8.5-alpha version, but it's nice to have something I can run in ~5 minutes that exercises a fair bit of at least vaguely realistic functionality. -- cbbrowne,@,ca.afilias.info Christopher Browne Bother, said Pooh, Eeyore, ready two photon torpedoes and lock phasers on the Heffalump, Piglet, meet me in transporter room three -- 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] 8.5 release timetable, again
On Thu, Aug 27, 2009 at 04:22:58PM -0400, Jonah H. Harris wrote: On Thu, Aug 27, 2009 at 3:53 PM, David Fetter da...@fetter.org wrote: I would appreciate it if somebody could send out some messages of calm, while I/we work. The time for open review will come around soon enough. With all due respect, the time for open review is now. You have already tried closed development several times, and it each time has been, more or less, a spectacular failure. Unlike Robert and Heikki, I don't see you contributing to or assisting Simon's work. My assistance is of the form of actually getting it done. Simon's work is absolutely fantastic, but only when the rest of the community can actually help. When it shows up late, it actually hurts everybody, most of all Simon. And, while I may be wrong, I doubt that you assisted in funding any of Simon's work on hot standby either. As such, it's my opinion that continuing to criticize him from the sidelines is not only rude, but is also a bad idea as it relates to his motivation in working on this feature. If, your past strategy has a track record of failure, go with a new strategy, one pretty much universally adopted in PostgreSQL, will demotivate someone, I can't help that, and I doubt it's actually true. I'm trying to help here, and encouraging a failed strategy is not helping. Cheers, David. -- David Fetter da...@fetter.org http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter Skype: davidfetter XMPP: david.fet...@gmail.com Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate -- 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] 8.5 release timetable, again
Robert Haas robertmh...@gmail.com wrote: The final CommitFest began November 11, 2008. It closed March 25, 2009 (+ 144 days). Beta1 was released April 15, 2009 (+ 21 days). I'm not entirely clear on what was happening during the 21 days between the end of the CommitFest and and the release of beta1. I seem to remember Bruce saying that there were bugs being fixed, and that it didn't make sense to release a beta with known bugs of that magnitude, but I'm not clear on what was up with that. Did we close the CF with known bugs open, or were these missed in the CF and found after? Surely it shouldn't normally take three weeks to get a beta test version to the public after we close the last CF? Just looking for where we could pick up a few weeks more of development in each year -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] return a set of records
t Werner Echezuria wrote: Hi, I need to return a set of records from a query, first I translate from sqlf to sql and later I wanna return the query, but the server crash (I guess it crashes around the yyparse call). This is the sql: CREATE OR REPLACE FUNCTION sqlf (text) RETURNS SETOF record AS 'MODULE_PATHNAME', 'sqlf' LANGUAGE C IMMUTABLE STRICT; You function doesn't look too immutable. Is it really? 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] 8.5 release timetable, again
Robert Haas escribió: Of course I don't think we'd actually need to start a CommitFest quite as quickly as we did this time, because with a shorter release cycle there ought to be a lot less patches already accumulated by the time we release, especially if there are clearly defined tasks for developers to do during the beta period. On the other hand, 8.4beta was arguably too short, since we missed some serious problems, so the picture above may be a bit too rosy. Maybe what this says is that we need to get a pre-beta release out as early as possible, just after finalizing the last commitfest, and before the open items and Bruce-approved release note writing are sorted out. Probably the last alpha release will fill that role. Sadly, the greek folk did not consider having a letter between alpha and beta :-( -- Alvaro Herrerahttp://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. -- 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] 8.5 release timetable, again
Kevin Grittner escribió: Robert Haas robertmh...@gmail.com wrote: The final CommitFest began November 11, 2008. It closed March 25, 2009 (+ 144 days). Beta1 was released April 15, 2009 (+ 21 days). I'm not entirely clear on what was happening during the 21 days between the end of the CommitFest and and the release of beta1. I seem to remember Bruce saying that there were bugs being fixed, and that it didn't make sense to release a beta with known bugs of that magnitude, but I'm not clear on what was up with that. That's nonsense IMHO. We should have just released a version documenting the known bugs, and asking for people to test the rest of the system. -- Alvaro Herrerahttp://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] 8.5 release timetable, again
Kevin Grittner kevin.gritt...@wicourts.gov writes: Robert Haas robertmh...@gmail.com wrote: The final CommitFest began November 11, 2008. It closed March 25, 2009 (+ 144 days). Beta1 was released April 15, 2009 (+ 21 days). I'm not entirely clear on what was happening during the 21 days between the end of the CommitFest and and the release of beta1. Release note drafting is one part of it, but mostly it's loose end cleanup. Historically there have always been a pile of loose ends to be dealt with, and the CommitFest structure doesn't really do anything to avoid that. If you're interested, attached are all the commits between commitfest closure (which I announced immediately after committing the addition of contrib/btree_gin) and stamping beta1 (which was actually several days before the date Robert gives, because of the need for the packagers to do their thing). It appears to me that release notes weren't actually the bottleneck this time, though they have been in some prior cycles. Bruce committed a first draft immediately after the commitfest closed. Rather, it was arguing about things like \df behavior and cardinality() that took up the time. We could certainly have released a perhaps-less-polished beta earlier. I think that the traditional criterion is that we don't release beta1 as long as there are any known issues that might force an initdb. We were successful in avoiding a post-beta initdb this time, although IIRC the majority of release cycles have had one --- so maybe you could argue that that's not so important. It would certainly be less important if we had working pg_migrator functionality to ease the pain of going from beta to final. Now that we have the alpha-release mechanism defined, some of the pressure for a quick beta could be taken off by releasing a final alpha right after the final commitfest closes. regards, tom lane 2009-04-09 20:20 scrappy * configure, configure.in, doc/bug.template, src/include/pg_config.h.win32: commit and tag beta1 2009-04-09 19:22 tgl * doc/src/sgml/release.sgml: Update release notes through yesterday; some minor wordsmithing. 2009-04-09 18:32 momjian * doc/src/sgml/monitoring.sgml: Clarify documentation references to pg_stat_get_blocks_fetched and pg_stat_get_blocks_hit, per suggestion from Robert Haas. 2009-04-09 17:50 momjian * src/tools/RELEASE_CHANGES: No more need to update FAQs. 2009-04-09 17:35 petere * src/tools/RELEASE_CHANGES: Add URL for config.guess/sub updates 2009-04-09 17:33 petere * config/: config.guess, config.sub: Update config.guess and config.sub 2009-04-09 16:50 tgl * src/timezone/data/: africa, asia, leapseconds, northamerica, southamerica (REL8_1_STABLE), africa, asia, leapseconds, northamerica, southamerica (REL8_3_STABLE), africa, asia, leapseconds, northamerica, southamerica (REL8_0_STABLE), africa, asia, leapseconds, northamerica, southamerica (REL8_2_STABLE), africa, asia, leapseconds, northamerica, southamerica: Update time zone data files to tzdata release 2009e: DST law changes in Argentina/San_Luis, Cuba, Jordan (historical correction only), Morocco, Palestine, Syria, Tunisia. 2009-04-09 15:38 petere * src/: backend/nls.mk, backend/po/de.po, backend/po/es.po, backend/po/fr.po, backend/po/ja.po, backend/po/nl.po, backend/po/ru.po, backend/po/tr.po, bin/initdb/nls.mk, bin/initdb/po/de.po, bin/initdb/po/es.po, bin/initdb/po/fr.po, bin/initdb/po/ja.po, bin/initdb/po/ru.po, bin/pg_config/nls.mk, bin/pg_config/po/de.po, bin/pg_config/po/fr.po, bin/pg_config/po/ja.po, bin/pg_config/po/ru.po, bin/pg_config/po/tr.po, bin/pg_controldata/nls.mk, bin/pg_controldata/po/de.po, bin/pg_controldata/po/fr.po, bin/pg_controldata/po/ja.po, bin/pg_ctl/nls.mk, bin/pg_ctl/po/cs.po, bin/pg_ctl/po/de.po, bin/pg_ctl/po/fr.po, bin/pg_ctl/po/ja.po, bin/pg_ctl/po/ru.po, bin/pg_dump/nls.mk, bin/pg_dump/po/de.po, bin/pg_dump/po/fr.po, bin/pg_dump/po/ja.po, bin/pg_dump/po/tr.po, bin/pg_resetxlog/nls.mk, bin/pg_resetxlog/po/de.po, bin/pg_resetxlog/po/fr.po, bin/pg_resetxlog/po/ja.po, bin/pg_resetxlog/po/ru.po, bin/psql/nls.mk, bin/psql/po/de.po, bin/psql/po/es.po, bin/psql/po/fr.po, bin/psql/po/ja.po, bin/psql/po/tr.po, bin/scripts/nls.mk, bin/scripts/po/de.po, bin/scripts/po/fr.po, bin/scripts/po/ja.po, interfaces/ecpg/ecpglib/nls.mk, interfaces/ecpg/ecpglib/po/de.po, interfaces/ecpg/ecpglib/po/es.po, interfaces/ecpg/ecpglib/po/fr.po, interfaces/ecpg/preproc/nls.mk, interfaces/ecpg/preproc/po/de.po, interfaces/ecpg/preproc/po/es.po, interfaces/ecpg/preproc/po/fr.po, interfaces/libpq/nls.mk, interfaces/libpq/po/de.po,
Re: [HACKERS] 8.5 release timetable, again
On Thu, Aug 27, 2009 at 03:04:20PM -0400, Robert Haas wrote: On Thu, Aug 27, 2009 at 2:54 PM, Peter Eisentrautpete...@gmx.net wrote: On tor, 2009-08-27 at 09:58 -0400, Robert Haas wrote: To get positive results in which you can have confidence, you have to know that the testing which was done actually did a reasonably good job exercising the code in a way that would have flushed out bugs, had any been present. That sounds a lot like the definition of a regression test suite. Of course, we have that already, but it's nowhere near comprehensive. Maybe we should be looking at an expanded test suite that runs on a time scale of hours rather than seconds. Actually, didn't Peter talk about something like this at PGCon? Let's look at it this way: If I were writing a compiler, then I would have two main test approaches. First, I would have an in-tree test suite that compiles a bunch of example code snippets and checks that the results are reasonable. Call that a regression test. It would be informed by code coverage analysis and previously reported bugs. Second, as part of my release cycle, I would have an agenda to try to compile a large set of real programs against my new compiler version. I would do that during the beta period. You will notice that GCC pretty much operates that way. We have regression tests. They could and should be expanded. That's a developer job, and we can start working on that now. But this discussion was about what to do during beta. And I think during beta you want to test PostgreSQL against a large set of real applications. But we could try to clarify how to actually do that in an organized way. Now, if you want to improve the regression tests, I would suggest going through the commits since 8.4beta and since 8.4.0 final release and ask how these problems could have been prevented or caught earlier. I suppose a test suite for WAL might be part of the answer, but a closer analysis might be insightful. What I want to do is address the concern about too much of any given year being consumed by beta and CommitFest. I'm not sure I know how to do that though. How about something in the alphas to the effect of, Using PostgreSQL? Have a development server to spare? Try your application stack on alpha1! We'd love to hear back. Functionality, performance, you name it. Cheers, David. -- David Fetter da...@fetter.org http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter Skype: davidfetter XMPP: david.fet...@gmail.com Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate -- 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] 8.5 release timetable, again
David Fetter wrote: How about something in the alphas to the effect of, Using PostgreSQL? Have a development server to spare? Try your application stack on alpha1! We'd love to hear back. Functionality, performance, you name it. I don't know of anyone who is likely to want to try out alphas in their normal development environments. The client I approached was specifically prepared to test beta releases that way. 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] MySQL Compatibility WAS: 8.5 release timetable, again
Le jeudi 27 août 2009 à 14:27 -0500, Jaime Casanova a écrit : the point was that if we simply were saying: hey! mysql can interpret this, make postgres do the same then we could end up with a lot of broken stuff... just because mysql users think is wonderful to not have to write sane code... Not MySQL in general. Only the subset which helps and seems reasonable. Bye, JM signature.asc Description: Ceci est une partie de message numériquement signée
Re: [HACKERS] 8.5 release timetable, again
Simon, The level of detailed planning happening now is a change for the community and in general I think it's a good thing. In the past we've always said it will be shipped when it's ready, and now we seem to be caught by our own rules. There's no need to make hard decisions now. Let's keep some flexibility in our thinking. If the structures give us problems, lets change the structures. The idea is the plans help the developers, not hinder them or make it harder to include big features. There's some very good reasons for the health of the project to have specific release dates and stick to them. When will it be released is an important question to answer, and it's far better for the developers who *aren't* working on big features to not be elastic. So, with that in mind: what is your statement on three versus four commitfests? Does it make a difference to you? -- Josh Berkus PostgreSQL Experts Inc. www.pgexperts.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] Patches for static check on geo_ops.c
Tom Lane wrote: I've applied the first three of these changes, but not the last two (the 'dist' assignments). clang seems to have a tin ear for style :-(. It's failing to notice that we have several similar code blocks in sequence in these two places, and making the last one different from the rest would decrease code readability and modifiability. voice=Maxwell SmartAh! The old programming via copy-and-paste trick/voice. Maybe clang's ear for style isn't that bad after all. :-) -- 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] Unicode UTF-8 table formatting for psql text output
On Thu, Aug 27, 2009 at 10:17:32AM -0400, Alvaro Herrera wrote:
Alvaro Herrera escribió:
I initially left these exactly the same as for ASCII (the ':' and ';'
usage). However, it's quite possible to make it use other characters.
We could use the same lines, or two, three or four dashed lines
('╎' and '╏', or ┆' and '┇' or '┊' and '┋').
This works for me (say ╎ for newline-separated strings and ┊ for wrapped
output).
So it'd look like this:
alvherre=# select * from foo;
a │ b
━━━┿
1 │ En un lugar de la Mancha, de cuyo nombre no quiero acordarme, no ha
mucho
┊ tiempo que vivía un hidalgo de los de lanza en astillero, adarga
antigua,
┊ rocín flaco y galgo corredor. Una olla de algo más vaca que carnero,
salpi
┊ cón las más noches, duelos y quebrantos los sábados, lantejas los
viernes,
┊ algún palomino de añadidura los domingos, consumían las tres partes de
su
┊ hacienda. El resto della concluían sayo de velarte, calzas de velludo
par
┊ a las fiestas, con sus pantuflos de lo mesmo, y los días de entresemana
se
┊ honraba con su vellorí de lo más fino. Tenía en su casa una ama que
pasa
┊ ba de los cuarenta, y una sobrina que no llegaba a los veinte, y un mozo
d
┊ e campo y plaza, que así ensillaba el rocín como tomaba la podadera.
2 │ —«Nunca fuera caballero de
╎ damas tan bien servido
╎ como fuera don Quijote
╎ cuando de su aldea vino:
╎ doncellas curaban dél;
╎ princesas, del su rocino»
(2 filas)
The attached patch adds support for the above output in wrapped mode.
It also uses single dashes (half lines) to represent lines which
contain no data, just vertical padding. Output is unchanged for
ASCII output.
The last bit I'm missing is how to handle column wrapping for aligned
text output. This is was introduced on 8th May 2008 by Bryce Nesbitt,
committed by Bruce Momjian (git commit f92f424d). This patch
introduced the wrapped format, but I have not been able to activate
the codepaths that wrap column names in the table header (adding '+').
The logic in print_aligned_text goes like this:
col_count = cont-ncolumns;
...
more_col_wrapping = col_count;
curr_nl_line = 0;
while (more_col_wrapping)
{
for (i = 0; i cont-ncolumns; i++)
if (!(this_line + 1)-ptr) // Surely only true once at end of columns?
more_col_wrapping--;
curr_nl_line++;
}
I'm not convinced looking at the code that more_col_wrapping is ever
true except for the first time through the loop, and it's reached
zero after completion of the inner loop, so all of the code used when
curr_nl_line is 0 is never called. I'm sure I'm interpreting this
incorrectly, but I can't see under what circumstances I would get the
column name header line wrapped over multiple lines.
It may be that I just haven't got a table with column names of the
correct number and lengths to trigger it?
Regards,
Roger
--
.''`. Roger Leigh
: :' : Debian GNU/Linux http://people.debian.org/~rleigh/
`. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/
`-GPG Public Key: 0x25BFB848 Please GPG sign your mail.
diff --git a/src/bin/psql/print.c b/src/bin/psql/print.c
index 7505cd4..f85e507 100644
--- a/src/bin/psql/print.c
+++ b/src/bin/psql/print.c
@@ -21,6 +21,9 @@
#endif
#include locale.h
+#ifdef HAVE_LANGINFO_H
+#include langinfo.h
+#endif
#include catalog/pg_type.h
#include pqsignal.h
@@ -356,38 +359,75 @@ print_unaligned_vertical(const printTableContent *cont, FILE *fout)
/* Aligned text */
//
+static const printTextFormat asciiformat =
+{
+ {
+ { -, +, +, + },
+ { -, +, +, + },
+ { -, +, +, + },
+ { , |, |, | }
+ },
+ :,
+ ;,
+
+};
+
+static const struct printTextFormat utf8format =
+{
+ {
+ /* ─, ┌, ┬, ┐ */
+ { \342\224\200, \342\224\214, \342\224\254, \342\224\220 },
+ /* ━, ┝, ┿, ┥ */
+ { \342\224\201, \342\224\235, \342\224\277, \342\224\245 },
+ /* ─, └, ┴, ┘ */
+ { \342\224\200, \342\224\224, \342\224\264, \342\224\230 },
+ /* N/A, │, │, │ */
+ { , \342\224\202, \342\224\202, \342\224\202 },
+ },
+ /* ╎ */
+ \342\225\216,
+ /* ┊ */
+ \342\224\212,
+ /* ╷ */
+ \342\225\267
+};
/* draw line */
static void
_print_horizontal_line(const unsigned int ncolumns, const unsigned int *widths,
- unsigned short border, FILE *fout)
+ unsigned short border, printTextRule pos,
+ const printTextFormat *format,
+ FILE *fout)
{
unsigned int i,
j;
+ const printTextLineFormat *lformat = format-lrule[pos];
+
if (border == 1)
- fputc('-', fout);
+ fputs(lformat-hrule, fout);
else if (border == 2)
- fputs(+-, fout);
+ fprintf(fout, %s%s, lformat-leftvrule, lformat-hrule);
for (i = 0; i ncolumns; i++)
{
for (j = 0; j widths[i]; j++)
-
Re: [HACKERS] 8.5 release timetable, again
On Thu, Aug 27, 2009 at 6:09 PM, Tom Lanet...@sss.pgh.pa.us wrote: Kevin Grittner kevin.gritt...@wicourts.gov writes: Robert Haas robertmh...@gmail.com wrote: The final CommitFest began November 11, 2008. It closed March 25, 2009 (+ 144 days). Beta1 was released April 15, 2009 (+ 21 days). I'm not entirely clear on what was happening during the 21 days between the end of the CommitFest and and the release of beta1. Release note drafting is one part of it, but mostly it's loose end cleanup. Historically there have always been a pile of loose ends to be dealt with, and the CommitFest structure doesn't really do anything to avoid that. If you're interested, attached are all the commits between commitfest closure (which I announced immediately after committing the addition of contrib/btree_gin) and stamping beta1 (which was actually several days before the date Robert gives, because of the need for the packagers to do their thing). It appears to me that release notes weren't actually the bottleneck this time, though they have been in some prior cycles. Bruce committed a first draft immediately after the commitfest closed. Rather, it was arguing about things like \df behavior and cardinality() that took up the time. It felt, at the time, like the release notes were holding things up, hence the various and so-far-unsuccesful volunteering related to that task. But it's possible that there was enough parallel activity going on that it wasn't actually so. We could certainly have released a perhaps-less-polished beta earlier. I think that the traditional criterion is that we don't release beta1 as long as there are any known issues that might force an initdb. We were successful in avoiding a post-beta initdb this time, although IIRC the majority of release cycles have had one --- so maybe you could argue that that's not so important. It would certainly be less important if we had working pg_migrator functionality to ease the pain of going from beta to final. Now that we have the alpha-release mechanism defined, some of the pressure for a quick beta could be taken off by releasing a final alpha right after the final commitfest closes. Definitely. Looking at it in hindsight, 3 weeks seems like a reasonable amount of time between the end of the last CommitFest and the start of beta. It felt long at the time, but maybe that's partly because the CommitFest was so intermininable. I think what a lot of this boils down to is that we need a better system for managing the tasks that need to be completed at each stage of the release process, and who is working on each one, and what the status of it is, just as we do for CommitFests. ...Robert -- 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] [BUGS] fillfactor hides autovacuum parameters in 8.4.0
Alvaro Herrera alvhe...@commandprompt.com wrote: So I'm going to apply your patch to both 8.4 and HEAD; we can always improve it later, I guess. Thank you for your applying. I think the fix is ugly, too. We need to introduce cleaner solution for 8.5. Regards, --- ITAGAKI Takahiro NTT Open Source Software Center -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Memory context usage
Hi, How can I get the used memory of a memory context? Is there some function like: int getMemoryUsage( MemoryContext ) ? I still working in a subplan cache for a query optimizer and I need to know whether a temporary memory context is in certain limits. Thanks Adriano -- 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] 8.5 release timetable, again
Andrew Dunstan wrote: I don't know of anyone who is likely to want to try out alphas in their normal development environments. The client I approached was specifically prepared to test beta releases that way. Perhaps end-users won't, but I think companies who develop software that works on top of postgres will. Perhaps to make sure their existing software continues to work; or perhaps to get a head start working with new features. I test against CVS-head occasionally. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] patch: Review handling of MOVE and FETCH (ToDo)
Hello,
this small patch complete MOVE support in plpgsql and equalize plpgsql
syntax with sql syntax.
There are possible new directions:
FORWARD expr, FORWARD ALL, BACKWARD expr, BACKWARD all.
These directions are not allowed for FETCH statement, because returns more rows.
This patch is related to ToDo issue: Review handling of MOVE and FETCH
Regards
Pavel Stehule
p.s. Scrollable cursors are supported yet in plpgsql. Do you know,
somebody, why this point is in ToDo (plpgsql) still?
*** ./doc/src/sgml/plpgsql.sgml.orig 2009-08-27 17:14:26.926410144 +0200
--- ./doc/src/sgml/plpgsql.sgml 2009-08-27 17:32:47.928407934 +0200
***
*** 2656,2670
para
The options for the replaceabledirection/replaceable clause are
! the same as for commandFETCH/, namely
literalNEXT/,
literalPRIOR/,
literalFIRST/,
literalLAST/,
literalABSOLUTE/ replaceablecount/replaceable,
literalRELATIVE/ replaceablecount/replaceable,
! literalFORWARD/, or
! literalBACKWARD/.
Omitting replaceabledirection/replaceable is the same
as specifying literalNEXT/.
replaceabledirection/replaceable values that require moving
--- 2656,2670
para
The options for the replaceabledirection/replaceable clause are
! similar as for commandFETCH/, namely
literalNEXT/,
literalPRIOR/,
literalFIRST/,
literalLAST/,
literalABSOLUTE/ replaceablecount/replaceable,
literalRELATIVE/ replaceablecount/replaceable,
! literalFORWARD/ optional replaceablecount/replaceable | literalALL/ /optional, or
! literalBACKWARD/ optional replaceablecount/replaceable | literalALL/ /optional.
Omitting replaceabledirection/replaceable is the same
as specifying literalNEXT/.
replaceabledirection/replaceable values that require moving
*** ./src/pl/plpgsql/src/gram.y.orig 2009-08-26 22:43:23.138239357 +0200
--- ./src/pl/plpgsql/src/gram.y 2009-08-27 08:18:13.418238086 +0200
***
*** 72,77
--- 72,79
int until, const char *expected);
static List*read_raise_options(void);
+ static PLpgSQL_stmt_fetch *complete_direction(PLpgSQL_stmt_fetch *fetch, bool *check_FROM);
+
%}
%expect 0
***
*** 178,183
--- 180,186
* Keyword tokens
*/
%token K_ALIAS
+ %token K_ALL
%token K_ASSIGN
%token K_BEGIN
%token K_BY
***
*** 1621,1626
--- 1624,1635
if (yylex() != ';')
yyerror(syntax error);
+
+ if (!fetch-returns_row)
+ ereport(ERROR,
+ (errcode(ERRCODE_SYNTAX_ERROR),
+ errmsg(statement FETCH returns more rows.),
+ errhint(Multirows fetch are not allowed in PL/pgSQL.)));
fetch-lineno = $2;
fetch-rec = rec;
***
*** 2252,2257
--- 2261,2271
}
+ /*
+ * Read FETCH or MOVE statement direction. For statement for are only
+ * one row directions allowed. MOVE statement can use FORWARD [(n|ALL)],
+ * BACKWARD [(n|ALL)] directions too.
+ */
static PLpgSQL_stmt_fetch *
read_fetch_direction(void)
{
***
*** 2269,2274
--- 2283,2289
fetch-direction = FETCH_FORWARD;
fetch-how_many = 1;
fetch-expr = NULL;
+ fetch-returns_row = true;
/*
* Most of the direction keywords are not plpgsql keywords, so we
***
*** 2313,2323
}
else if (pg_strcasecmp(yytext, forward) == 0)
{
! /* use defaults */
}
else if (pg_strcasecmp(yytext, backward) == 0)
{
fetch-direction = FETCH_BACKWARD;
}
else if (tok != T_SCALAR)
{
--- 2328,2339
}
else if (pg_strcasecmp(yytext, forward) == 0)
{
! fetch = complete_direction(fetch, check_FROM);
}
else if (pg_strcasecmp(yytext, backward) == 0)
{
fetch-direction = FETCH_BACKWARD;
+ fetch = complete_direction(fetch, check_FROM);
}
else if (tok != T_SCALAR)
{
***
*** 2346,2351
--- 2362,2408
}
+ /*
+ * Allows directions:
+ * FORWARD expr, FORWARD ALL, FORWARD
+ * BACKWARD expr, BACKWARD ALL, BACKWARD
+ *
+ * so plpgsql should fully support PostgreSQL's MOVE statement.
+ */
+ static PLpgSQL_stmt_fetch *
+ complete_direction(PLpgSQL_stmt_fetch *fetch, bool *check_FROM)
+ {
+ int tok;
+ PLpgSQL_expr *expr;
+
+ tok = yylex();
+ if (tok == K_FROM || tok == K_IN)
+ {
+ *check_FROM = false;
+
+ return fetch;
+ }
+
+ if (tok == K_ALL)
+ {
+ fetch-how_many = fetch-direction == FETCH_FORWARD ? -1 : 0;
+ fetch-direction = FETCH_ABSOLUTE;
+ fetch-returns_row = false;
+ *check_FROM = true;
+
+ return fetch;
+ }
+
+ plpgsql_push_back_token(tok);
+ expr = read_sql_expression2(K_FROM, K_IN,
+ FROM or IN,
+ NULL);
+ fetch-returns_row = false;
+ *check_FROM = false;
+
+ return fetch;
+ }
+
static PLpgSQL_stmt *
make_return_stmt(int lineno)
{
Re: [HACKERS] join removal
On Sun, Aug 16, 2009 at 5:31 PM, Robert Haasrobertmh...@gmail.com wrote:
It seems that the needed checks are very similar to the ones that we
already implement when setting restrictinfo-mergeopfamilies. That is
filled in by get_mergejoin_opfamilies(), which checks for btree
opfamilies where the strategy number is BTEqualStrategyNumber. This
might cease to be the correct check in the (not-too-distant?) future
if we end up implementing other kinds of unique indices, but right now
btrees are all there is.
One possibility would be to have relation_is_distinct_for() call
get_mergejoin_opfamilies() for each operator; then for each index we
can check whether the opfamily of the relevant index column is in the
returned list. This seems a bit wasteful, though, since I believe
that relation_is_distinct_for() would be called from joinpath.c, which
has access to restrictinfo-mergeopfamilies already.
I'm wondering whether it would make more sense to modify the proposed
API for relation_is_distinct_for() in some way so that we don't lose
this information.
Here is an attempt at the latter approach. This doesn't actually
remove the join yet; it just checks whether the join can be removed.
I haven't tested it extensively yet, but am hoping for some feedback
on the basic approach.
...Robert
*** a/src/backend/optimizer/path/costsize.c
--- b/src/backend/optimizer/path/costsize.c
***
*** 109,114 bool enable_hashagg = true;
--- 109,115
bool enable_nestloop = true;
bool enable_mergejoin = true;
bool enable_hashjoin = true;
+ bool enable_joinremoval = true;
typedef struct
{
*** a/src/backend/optimizer/path/joinpath.c
--- b/src/backend/optimizer/path/joinpath.c
***
*** 16,26
--- 16,39
#include math.h
+ #include optimizer/clauses.h
#include optimizer/cost.h
#include optimizer/pathnode.h
#include optimizer/paths.h
+ typedef struct path_operator_clause {
+ List *mergeclause_list;
+ List *hashclause_list;
+ List *joinremovalclause_list;
+ List *joinremovalvarattno_list;
+ } path_operator_clause;
+
+ static bool join_is_removable(RelOptInfo *joinrel,
+ RelOptInfo *outerrel,
+ RelOptInfo *innerrel,
+ path_operator_clause *poc,
+ JoinType jointype);
static void sort_inner_and_outer(PlannerInfo *root, RelOptInfo *joinrel,
RelOptInfo *outerrel, RelOptInfo *innerrel,
List *restrictlist, List *mergeclause_list,
***
*** 31,47 static void match_unsorted_outer(PlannerInfo *root, RelOptInfo *joinrel,
JoinType jointype, SpecialJoinInfo *sjinfo);
static void hash_inner_and_outer(PlannerInfo *root, RelOptInfo *joinrel,
RelOptInfo *outerrel, RelOptInfo *innerrel,
! List *restrictlist,
JoinType jointype, SpecialJoinInfo *sjinfo);
static Path *best_appendrel_indexscan(PlannerInfo *root, RelOptInfo *rel,
RelOptInfo *outer_rel, JoinType jointype);
! static List *select_mergejoin_clauses(PlannerInfo *root,
! RelOptInfo *joinrel,
! RelOptInfo *outerrel,
! RelOptInfo *innerrel,
! List *restrictlist,
! JoinType jointype);
!
/*
* add_paths_to_joinrel
--- 44,61
JoinType jointype, SpecialJoinInfo *sjinfo);
static void hash_inner_and_outer(PlannerInfo *root, RelOptInfo *joinrel,
RelOptInfo *outerrel, RelOptInfo *innerrel,
! List *restrictlist, List *hashclauses,
JoinType jointype, SpecialJoinInfo *sjinfo);
static Path *best_appendrel_indexscan(PlannerInfo *root, RelOptInfo *rel,
RelOptInfo *outer_rel, JoinType jointype);
! static bool rel_attrs_needed_above_join(RelOptInfo *rel, RelOptInfo *joinrel);
! static void select_operator_clauses(PlannerInfo *root,
! RelOptInfo *joinrel,
! RelOptInfo *outerrel,
! RelOptInfo *innerrel,
! List *restrictlist,
! JoinType jointype,
! path_operator_clause *poc);
/*
* add_paths_to_joinrel
***
*** 75,135 add_paths_to_joinrel(PlannerInfo *root,
SpecialJoinInfo *sjinfo,
List *restrictlist)
{
! List *mergeclause_list = NIL;
/*
! * Find potential mergejoin clauses. We can skip this if we are not
! * interested in doing a mergejoin. However, mergejoin is currently our
! * only way of implementing full outer joins, so override mergejoin
! * disable if it's a full join.
*/
! if (enable_mergejoin || jointype == JOIN_FULL)
! mergeclause_list = select_mergejoin_clauses(root,
! joinrel,
! outerrel,
! innerrel,
! restrictlist,
! jointype);
/*
! * 1. Consider mergejoin paths where both relations must be explicitly
* sorted.
*/
sort_inner_and_outer(root, joinrel, outerrel, innerrel,
! restrictlist, mergeclause_list, jointype, sjinfo);
/*
! * 2. Consider paths where the outer relation need not be explicitly
* sorted. This
Re: [HACKERS] 8.5 release timetable, again
Josh Berkus wrote: There's some very good reasons for the health of the project to have specific release dates and stick to them. Help me understand why? The Linux kernel seems to do fine with a when it is ready cycle, where some releases(2.6.24) take twice the time of others(2.6.28)[1,2]. I imagine it has similar stability and lack-of-data-loss requirements as postgres does. I understand why commercial packagers like Ubuntu - especially public ones like Novell and Red Hat who have to forecast earnings - want to schedule their releases. And I can imagine they'd appreciate it if project releases aren't too close to their release schedules (if postgres releases right after they release they suffer from not having the current version; if postgres releases just before, they have limited testing time). [1] http://www.linuxfoundation.org/publications/linuxkerneldevelopment.php [2] http://fblinux.freebase.com/view/base/fblinux/views/linux_kernel_release So, with that in mind: what is your statement on three versus four commitfests? Does it make a difference to you? -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] [PATCH] Largeobject access controls
The attached patch provides access control features on largeobject.
This patch adds the ownership and two permissions (SELECT and UPDATE) on
largeobjects. The two permissions controls reader and writer accesses to
the largeobejcts. Only owner can unlink the largeobject which is owned by.
It also add a new attribute on the database role to control whether he
can create a new largeobject, or not. Because largeobject is not stored
within a certain namespace, we cannot control its creation using CREATE
permission.
The CREATE USER/ROLE statement got a new option: LARGEOBJECT/NOLARGEOBJECT.
It enables to controls whether the user can create a largeobject, or not.
The default is LARGEOBJECT which means user can create them.
This attribute is stored within pg_authid.rollargeobject defined as bool.
The pg_largeobject system catalog is reworked to manage its metadata.
CATALOG(pg_largeobject,2613)
{
Oid loowner;/* OID of the owner */
Oid lochunk;/* OID of the data chunks */
aclitem loacl[1]; /* access permissions */
} FormData_pg_largeobject;
Actual data chunks are stored in the toast relation of pg_largeobject,
and its chunk_id is stored in the pg_largeobject.lochunk.
As I noted before, there are several difficulties to implement partially
writable varlena type, so it uses the its toast relation just as a storage
to store its data chunks.
The GRANT/REVOKE statement also support largeobject, as follows:
GRANT SELECT ON LARGE OBJECT 1234 TO kaigai;
It follows the matter when COMMENT ON statement specifies a large object.
Thanks,
(Example)
postgres=# CREATE USER dog;-- user can create largeobjects in default
CREATE ROLE
postgres=# CREATE USER cat NOLARGEOBJECT;
CREATE ROLE
postgres=# \c - dog
psql (8.5devel)
You are now connected to database postgres as user dog.
postgres= SELECT lo_create(123);
lo_create
---
123
(1 row)
postgres= SELECT lo_create(100);
lo_create
---
100
(1 row)
postgres= GRANT SELECT ON LARGE OBJECT 123 TO cat;
GRANT
postgres= \c - cat
psql (8.5devel)
You are now connected to database postgres as user cat.
postgres= SELECT lo_create(456);
ERROR: permission denied to create largeobject
postgres= SELECT loread(lo_open(123, x'4'::int), 100);
loread
\x
(1 row)
postgres= SELECT lowrite(lo_open(123, x'2'::int), 'abcdefg');
ERROR: permission denied for largeobject 123
postgres= SELECT lo_unlink(123);
ERROR: must be owner of largeobject 123
===
[kai...@saba ~]$ diffstat sepgsql-02-blob-8.5devel-r2264.patch.gz
doc/src/sgml/ref/create_role.sgml | 13 +
doc/src/sgml/ref/create_user.sgml |1
doc/src/sgml/ref/grant.sgml|8
doc/src/sgml/ref/revoke.sgml |6
src/backend/catalog/aclchk.c | 246
src/backend/catalog/dependency.c | 14 +
src/backend/catalog/pg_largeobject.c | 139 +!!
src/backend/catalog/pg_shdepend.c |4
src/backend/commands/comment.c | 10
src/backend/commands/tablecmds.c |1
src/backend/commands/user.c| 32 ++
src/backend/libpq/be-fsstubs.c | 141 ++-
src/backend/parser/gram.y | 26 +!
src/backend/storage/large_object/inv_api.c | 344 ---
src/backend/utils/adt/acl.c|4
src/backend/utils/cache/syscache.c | 13 +
src/include/catalog/dependency.h |1
src/include/catalog/indexing.h |4
src/include/catalog/pg_authid.h| 14 !
src/include/catalog/pg_largeobject.h | 17 !
src/include/catalog/toasting.h | 10
src/include/nodes/parsenodes.h |1
src/include/parser/kwlist.h|2
src/include/utils/acl.h|6
src/include/utils/syscache.h |1
src/test/regress/expected/privileges.out | 202 +
src/test/regress/input/largeobject.source |7
src/test/regress/output/largeobject.source | 10
src/test/regress/sql/privileges.sql| 75 ++
29 files changed, 857 insertions(+), 107 deletions(-), 388 modifications(!)
--
OSS Platform Development Division, NEC
KaiGai Kohei kai...@ak.jp.nec.com
sepgsql-02-blob-8.5devel-r2264.patch.gz
Description: application/gzip
--
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] Memory context usage
Adriano Lange alange0...@gmail.com writes: How can I get the used memory of a memory context? MemoryContextStats() might help. It just dumps the info to stderr though. 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] 8.5 release timetable, again
On Fri, Aug 28, 2009 at 4:39 AM, Ron Mayerrm...@cheapcomplexdevices.com wrote: Josh Berkus wrote: There's some very good reasons for the health of the project to have specific release dates and stick to them. Help me understand why? The Linux kernel seems to do fine with a when it is ready cycle, where some releases(2.6.24) take twice the time of others(2.6.28)[1,2]. I imagine it has similar stability and lack-of-data-loss requirements as postgres does. Uhm, the Linux release process is actually now the canonical example of time-based release management. They used to do when it is ready and that led to such a dramatic catastrophic failure with 2.6 that they adopted the most dogmatically time-based system of any open source project. They basically don't do any integration testing and leave that up to the distributions now. Instead they have an rc release *every week* like clockwork and every 2-3 months the last one becomes a new version regardless of whether there's any notable new feature. Other than the first few releases after 2.6.0 when things were still fairly unstable and major fixes were going in the release cycle has been remarkaby regular modulo holidays and vacations: r | d | days --++-- ChangeLog-2.6.30 | 2009-06-10 | 79 ChangeLog-2.6.29 | 2009-03-23 | 89 ChangeLog-2.6.28 | 2008-12-24 | 75 ChangeLog-2.6.27 | 2008-10-10 | 89 ChangeLog-2.6.26 | 2008-07-13 | 87 ChangeLog-2.6.25 | 2008-04-17 | 84 ChangeLog-2.6.24 | 2008-01-24 | 107 ChangeLog-2.6.23 | 2007-10-09 | 92 ChangeLog-2.6.22 | 2007-07-09 | 74 ChangeLog-2.6.21 | 2007-04-26 | 81 ChangeLog-2.6.20 | 2007-02-04 | 67 ChangeLog-2.6.19 | 2006-11-29 | 70 ChangeLog-2.6.18 | 2006-09-20 | 94 ChangeLog-2.6.17 | 2006-06-18 | 90 ChangeLog-2.6.16 | 2006-03-20 | 76 ChangeLog-2.6.15 | 2006-01-03 | 67 ChangeLog-2.6.14 | 2005-10-28 | 60 ChangeLog-2.6.13 | 2005-08-29 | 73 ChangeLog-2.6.12 | 2005-06-17 | 107 ChangeLog-2.6.11 | 2005-03-02 | 68 ChangeLog-2.6.10 | 2004-12-24 | 66 ChangeLog-2.6.9 | 2004-10-19 | 66 ChangeLog-2.6.8 | 2004-08-14 | 59 ChangeLog-2.6.7 | 2004-06-16 | 37 ChangeLog-2.6.6 | 2004-05-10 | 36 ChangeLog-2.6.5 | 2004-04-04 | 24 ChangeLog-2.6.4 | 2004-03-11 | 22 ChangeLog-2.6.3 | 2004-02-18 | 14 ChangeLog-2.6.2 | 2004-02-04 | 26 ChangeLog-2.6.1 | 2004-01-09 | 22 ChangeLog-2.6.0 | 2003-12-18 | (31 rows) -- greg http://mit.edu/~gsstark/resume.pdf -- 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] Largeobject access controls
KaiGai Kohei kai...@ak.jp.nec.com wrote:
The pg_largeobject system catalog is reworked to manage its metadata.
CATALOG(pg_largeobject,2613)
{
Oid loowner;/* OID of the owner */
Oid lochunk;/* OID of the data chunks */
aclitem loacl[1]; /* access permissions */
} FormData_pg_largeobject;
Actual data chunks are stored in the toast relation of pg_largeobject,
and its chunk_id is stored in the pg_largeobject.lochunk.
A bit acrobatic, but insteresting idea.
I have some random comments:
* Do you measure performance of the new LO implementation?
AFAIK, Users expect performance benefits to LO; TOASTed
bytea slows down when the size of data is 100KB or greater
even if they don't use random seeks.
* We might take care of DROP ROLE and REASSIGN/DROP OWNED.
Or, we might have large object without owner.
It might require full-scanning of pg_largeobject table,
but we can accept it because the size of pg_largeobject
will be smaller; we have actual data out of the table.
* Don't we also need ALTER LARGE OBJECT oid OWNER TO user
for consistency?
Regards,
---
ITAGAKI Takahiro
NTT Open Source Software Center
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
