On 5/17/08, Andrew Dunstan [EMAIL PROTECTED] wrote:
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
second pass. There are 130 files in this list. Offhand I'd say the vast
majority should have markers.
Yeah, that list looks reasonably sane. The main thing I was worried
On Fri, 2008-05-16 at 21:50 -0400, Tom Lane wrote:
Neil Conway [EMAIL PROTECTED] writes:
Ugh. The fact that the RESTART IDENTITY part of TRUNCATE is
non-transactional is a pretty unsightly wort.
Actually, I agree. Shall we just revert that feature? The ALTER
SEQUENCE part of this patch
Something committed in about the last 24 hours or so has caused my
Windows buildfarm members to hang completely while running the
regression tests. It's happened for both MinGW and MSVC builds.
To get the buildfarm run to complete in some fashion, I had to kill 2
psql processes, and then 2
Bernd Helmle wrote:
segment_size: Reports heap segment size
wal_segment_size: Reports wal segment size
block_size: Available yet
wal_block_size: wal block size
+1. We already have block_size in GUC.
--
Euler Taveira de Oliveira
http://www.timbira.com/
--
Sent via pgsql-hackers mailing
Simon Riggs [EMAIL PROTECTED] writes:
On Fri, 2008-05-16 at 21:50 -0400, Tom Lane wrote:
Actually, I agree. Shall we just revert that feature?
Perhaps, but we should also take into account that TRUNCATE is not and
never will be MVCC compliant, so its not something you'd expect to run
except
On Sat, 2008-05-17 at 12:04 -0400, Tom Lane wrote:
So what I think we should do is leave the patch there, revise the
warning per Neil's complaint, and add a TODO item to reimplement
RESTART IDENTITY transactionally.
Sounds good.
--
Simon Riggs www.2ndQuadrant.com
PostgreSQL
Buildfarm member spoonbill's last four HEAD builds have all failed in
the same utterly bizarre way. It looks like about half of the test
results files got truncated at random places --- no errors, no nothing,
the file just ends early. What's up with that?
regards, tom
Tom Lane wrote:
Buildfarm member spoonbill's last four HEAD builds have all failed in
the same utterly bizarre way. It looks like about half of the test
results files got truncated at random places --- no errors, no nothing,
the file just ends early. What's up with that?
psql is coredumping:
Stefan Kaltenbrunner [EMAIL PROTECTED] writes:
psql is coredumping:
Huh. I wonder why it's only happening on that one machine.
Is there anything particularly unusual about datatype sizes
or alignment rules on that platform?
regards, tom lane
--
Sent via pgsql-hackers
Tom Lane wrote:
Stefan Kaltenbrunner [EMAIL PROTECTED] writes:
psql is coredumping:
Huh. I wonder why it's only happening on that one machine.
Is there anything particularly unusual about datatype sizes
or alignment rules on that platform?
hmm well it is a 64bit Sparc box running OpenBSD
Tom Lane wrote:
Stefan Kaltenbrunner [EMAIL PROTECTED] writes:
psql is coredumping:
Huh. I wonder why it's only happening on that one machine.
Is there anything particularly unusual about datatype sizes
or alignment rules on that platform?
hmm actually - the windows buildfarm
Stefan Kaltenbrunner [EMAIL PROTECTED] writes:
Tom Lane wrote:
Huh. I wonder why it's only happening on that one machine.
But if i had to guess this more likely caused by the special malloc
flags used on spoonbill (FGJPZ) - per your recommendations in:
Hah, yeah, that's it. The code was
Stefan Kaltenbrunner [EMAIL PROTECTED] writes:
psql is coredumping:
BTW, this exposes a pretty nasty omission in pg_regress: it fails to
say anything about a nonzero exit code from a psql child process
that's running a test. Seems like wait_for_tests() ought to complain
about that. Any
Tom Lane wrote:
Stefan Kaltenbrunner [EMAIL PROTECTED] writes:
Tom Lane wrote:
Huh. I wonder why it's only happening on that one machine.
But if i had to guess this more likely caused by the special malloc
flags used on spoonbill (FGJPZ) - per your recommendations in:
Hah, yeah, that's
On Sat, 17 May 2008, Tom Lane wrote:
Does anyone know how to get the child
process exit status on Windows?
GetExitCodeProcess, if you've got the process handle handy (which I assume
you do, since you most likely were calling one of the WaitFor...Object
family of functions.
On Thu, 15 May 2008, Marko Kreen wrote:
On 5/15/08, Josh Berkus [EMAIL PROTECTED] wrote:
Has PL/proxy been tested on other OSes? FreeBSD/Solaris/Windows?
It definitely works on Linux and MacOS. I've seen ports for *BSD.
I think any unix-like OS-es should work fine.
I've compiled it with
Steve,
I've compiled it with a minor Makefile modification on Solaris and it
seems to work (it passes all the unit tests but the one involving
random; we might want to rethink that test so 'passes' on platforms with
different implementations of random()). However, I haven't deployed it
into
I wrote:
BTW, this exposes a pretty nasty omission in pg_regress: it fails to
say anything about a nonzero exit code from a psql child process
that's running a test. Seems like wait_for_tests() ought to complain
about that. Any objections?
So I coded this up, and fortunately thought to try
2008/5/15 [EMAIL PROTECTED]:
A more sophisticated implementation would automatically retrieve from
the summary table when the main table is referenced, if possible.
If this means that e.g. a query would know by itself that it could
get the data from the view instead of from the main table,
I wrote:
We could possibly extend the syntax of regression schedule files to have
a way to say what's the expected exit status, but that seems like more
work than it's worth. Would it be all right to just remove the test of
on error stop mode?
What I did for the moment is just make it
Zdenek Kotala napsal(a):
snip
How it works:
When PLC module is loaded, then for each page which does not have native
page version conversion routine is called. Buffer is mark as a dirty and
upgraded page is inserted into WAL.
Unfortunately, this approach does not work between layout 3
Tom Lane wrote:
We could possibly extend the syntax of regression schedule files to have
a way to say what's the expected exit status, but that seems like more
work than it's worth. Would it be all right to just remove the test of
on error stop mode?
Woulnd't it be enough to report the exist
Zdenek,
Unfortunately, this approach does not work between layout 3 and 4. It
works only for heap on platfrom with maxallign=4.
The main problem is that PageHeader has been extended to 24 bytes and it
requires reindexing, TOAST chunk resizing, converted tuples does not fit
on page on
On 5/17/08, Steve Singer [EMAIL PROTECTED] wrote:
Somewhat unrelated, I can see use-cases for replacing the call to random()
with something that allows user defined polices for RUN ON ANY.
Well, thats why the RUN ON userfunc(..); exists. Also notice the function
can tag more that one
Bruce Momjian wrote:
Since ecpg localization was added today, I am unable to compile
src/interfaces/ecpg. I get:
$ gmake -w clean
gmake: Entering directory
`/usr/var/local/src/gen/pgsql/CURRENT/pgsql/src/interfaces/ecpg' rm -f
usage: rm [-dfiPRrW] file ...
Fixed.
--
Euler Taveira de Oliveira wrote:
I mean that you need to put locale.h and setlocale(LC_MESSAGES, ) at
.pgc so you get localized messages from ecpg program.
That seems perfectly reasonable.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
Peter Eisentraut [EMAIL PROTECTED] writes:
Woulnd't it be enough to report the exist status if a test fails, instead of
requiring a certain exit status for success?
What I have it doing is reporting the exit status if not zero, but it's
only an annotation on the short-form output; it doesn't
Josh Berkus napsal(a):
Zdenek,
Unfortunately, this approach does not work between layout 3 and 4. It
works only for heap on platfrom with maxallign=4.
The main problem is that PageHeader has been extended to 24 bytes and it
requires reindexing, TOAST chunk resizing, converted tuples does not
psql's print.c contains this piece of code:
/*
* PageOutput
*
* Tests if pager is needed and returns appropriate FILE pointer.
*/
FILE *
PageOutput(int lines, unsigned short int pager)
{
/* check whether we need / can / are supposed to use pager */
if (pager
#ifndef WIN32
I was displeased to discover just now that in a standard RPM build of
PG 8.3, psql and the other basic client programs pull in libxml2 and
libxslt; this creates a package dependency that should not be there
by any stretch of the imagination.
The reason of course is that configure puts -lxml2
Andrew Dunstan wrote:
psql's print.c contains this piece of code:
/*
* PageOutput
*
* Tests if pager is needed and returns appropriate FILE pointer.
*/
FILE *
PageOutput(int lines, unsigned short int pager)
{
/* check whether we need / can / are supposed to use pager */
On 5/18/08, Tom Lane [EMAIL PROTECTED] wrote:
I was displeased to discover just now that in a standard RPM build of
PG 8.3, psql and the other basic client programs pull in libxml2 and
libxslt; this creates a package dependency that should not be there
by any stretch of the imagination.
Bruce Momjian wrote:
Andrew Dunstan wrote:
psql's print.c contains this piece of code:
/*
* PageOutput
*
* Tests if pager is needed and returns appropriate FILE pointer.
*/
FILE *
PageOutput(int lines, unsigned short int pager)
{
/* check whether we need / can / are supposed to
Andrew Dunstan [EMAIL PROTECTED] writes:
Something committed in about the last 24 hours or so has caused my
Windows buildfarm members to hang completely while running the
regression tests. It's happened for both MinGW and MSVC builds.
baiji and dawn_bat are both green now, so apparently
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
Something committed in about the last 24 hours or so has caused my
Windows buildfarm members to hang completely while running the
regression tests. It's happened for both MinGW and MSVC builds.
baiji and dawn_bat are both
Marko Kreen [EMAIL PROTECTED] writes:
On 5/18/08, Tom Lane [EMAIL PROTECTED] wrote:
I was displeased to discover just now that in a standard RPM build of
PG 8.3, psql and the other basic client programs pull in libxml2 and
libxslt; this creates a package dependency that should not be there
by
Tom Lane wrote:
1. Use -Wl,--as-needed as linker flag. Portability unknown...
Can be autoconfed.
This might actually be the best solution. OS X has a similar disease
but some trolling of the ld man page suggests that -dead_strip_dylibs
might work there. Taking this path would
Andrew Dunstan [EMAIL PROTECTED] writes:
1. Use -Wl,--as-needed as linker flag. Portability unknown...
Didn't we run into problems with this before?
Hm, yeah, thanks for reminding me to check the archives. We tried to do
exactly this three years ago, and it crashed and burned. See
On Sat, 17 May 2008, Marko Kreen wrote:
On 5/17/08, Steve Singer [EMAIL PROTECTED] wrote:
Somewhat unrelated, I can see use-cases for replacing the call to random()
with something that allows user defined polices for RUN ON ANY.
Well, thats why the RUN ON userfunc(..); exists. Also notice
(Resending since it didn't work the first time. Not sure if attaching a
tar file was the culprit.)
I'd like to propose adding the following probes (some of which came from
Simon) to 8.4.
I think these probe provide very useful data. Although some of the data
can be collected now, the main
On Sat, 17 May 2008, Tom Lane wrote:
I was displeased to discover just now that in a standard RPM build of
PG 8.3, psql and the other basic client programs pull in libxml2 and
libxslt; this creates a package dependency that should not be there
by any stretch of the imagination.
When we
Tom Lane [EMAIL PROTECTED] writes:
Peter Eisentraut [EMAIL PROTECTED] writes:
Woulnd't it be enough to report the exist status if a test fails, instead of
requiring a certain exit status for success?
What I have it doing is reporting the exit status if not zero, but it's
only an annotation
Greg Smith [EMAIL PROTECTED] writes:
On Sat, 17 May 2008, Tom Lane wrote:
I was displeased to discover just now that in a standard RPM build of
PG 8.3, psql and the other basic client programs pull in libxml2 and
libxslt; this creates a package dependency that should not be there
by any
On 5/18/08, Steve Singer [EMAIL PROTECTED] wrote:
On Sat, 17 May 2008, Marko Kreen wrote:
On 5/17/08, Steve Singer [EMAIL PROTECTED] wrote:
Somewhat unrelated, I can see use-cases for replacing the call to
random()
with something that allows user defined polices for RUN ON ANY.
44 matches
Mail list logo
