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
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
"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
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 noticed
(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 ad
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
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
ht
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 am
"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
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 gr
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
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 use
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
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 pag
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 -lxsl
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
&&
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 f
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'
Euler Taveira de Oliveira wrote:
> I mean that you need to put 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 subscription:
h
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.
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 parti
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 p
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
Zdenek Kotala napsal(a):
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 and 4.
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 a
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
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
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
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
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.
http://msdn.micros
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
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 obje
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
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 failures/iss
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
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-hacker
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:
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 lan
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 T
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
>
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 l
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 d
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 t
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
44 matches
Mail list logo