On Thu, Aug 11, 2016 at 5:33 AM, Alvaro Herrera
wrote:
> Michael Paquier wrote:
>> On Fri, Aug 5, 2016 at 12:21 AM, Alvaro Herrera
>> wrote:
>> > If somebody had some spare time to devote to this, I would suggest to
>> > implement something in core that can be used to specify a list of
>> > comma
Michael Paquier wrote:
> On Fri, Aug 5, 2016 at 12:21 AM, Alvaro Herrera
> wrote:
> > If somebody had some spare time to devote to this, I would suggest to
> > implement something in core that can be used to specify a list of
> > commands to run, and a list of files-to-be-saved-in-bf-log emitted b
On Fri, Aug 5, 2016 at 10:11 AM, Tom Lane wrote:
> Robert Haas writes:
>> I think it would be an interesting project for someone to try to
>> figure out how to make 'make check-extended-query-protocol' or similar
>> work.
>
> Seems like it would not be that hard to put some kind of option in psql
Robert Haas writes:
> I think it would be an interesting project for someone to try to
> figure out how to make 'make check-extended-query-protocol' or similar
> work.
Seems like it would not be that hard to put some kind of option in psql
to issue queries with PQexecParams not plain PQexec. How
On Tue, Aug 2, 2016 at 10:33 PM, Tatsuo Ishii wrote:
> In my understanding, we don't have any regression test for protocol
> level prepared query (we do have SQL level prepared query tests,
> though). Shouldn't we add those tests to the regression test suites?
A few years ago, EDB had a bug that
On Fri, Aug 5, 2016 at 12:21 AM, Alvaro Herrera
wrote:
> If somebody had some spare time to devote to this, I would suggest to
> implement something in core that can be used to specify a list of
> commands to run, and a list of files-to-be-saved-in-bf-log emitted by
> each command. We could have
Michael Paquier wrote:
> On Thu, Aug 4, 2016 at 12:14 AM, Dave Cramer wrote:
> > We currently run tests every time a PR is created on github, but I don't
> > think there are any animals running the JDBC test suite
> >
> > We can add tests, what exactly do we want to test. Then setting up an animal
On Thu, Aug 4, 2016 at 12:14 AM, Dave Cramer wrote:
> We currently run tests every time a PR is created on github, but I don't
> think there are any animals running the JDBC test suite
>
> We can add tests, what exactly do we want to test. Then setting up an animal
> to run the tests would be fair
On 3 August 2016 at 10:53, Tom Lane wrote:
> Tatsuo Ishii writes:
> >>> In my understanding, we don't have any regression test for protocol
> >>> level prepared query (we do have SQL level prepared query tests,
> >>> though). Shouldn't we add those tests to the regression test suites?
>
> >> I t
Tatsuo Ishii writes:
>>> In my understanding, we don't have any regression test for protocol
>>> level prepared query (we do have SQL level prepared query tests,
>>> though). Shouldn't we add those tests to the regression test suites?
>> I thought that ECPG was covering a portion of that. Right?
[Sorry for a top post. For unknown reason I couldn' get mails from
pgsql-hackers since this morning and I have to check the archive]
>> In my understanding, we don't have any regression test for protocol
>> level prepared query (we do have SQL level prepared query tests,
>> though). Shouldn't we a
On Wed, Aug 3, 2016 at 11:33 AM, Tatsuo Ishii wrote:
> In my understanding, we don't have any regression test for protocol
> level prepared query (we do have SQL level prepared query tests,
> though). Shouldn't we add those tests to the regression test suites?
I thought that ECPG was covering a p
In my understanding, we don't have any regression test for protocol
level prepared query (we do have SQL level prepared query tests,
though). Shouldn't we add those tests to the regression test suites?
Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > * Tom Lane (t...@sss.pgh.pa.us) wrote:
> >> broken that way as rowsecurity.sql, which is (still) creating roles
> >> named "alice" and "bob", but it's not acceptable like this.
>
> > Attached is a patch to fix all of the role usag
Stephen Frost writes:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>> broken that way as rowsecurity.sql, which is (still) creating roles
>> named "alice" and "bob", but it's not acceptable like this.
> Attached is a patch to fix all of the role usage in rowsecurity.sql
> (I believe, feel free to let
Tom,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> broken that way as rowsecurity.sql, which is (still) creating roles
> named "alice" and "bob", but it's not acceptable like this.
Attached is a patch to fix all of the role usage in rowsecurity.sql
(I believe, feel free to let me know if there's anyth
On Sun, Mar 9, 2014 at 09:23:33AM -0300, Martín Marqués wrote:
> OK, noticed how horrible this patch was (thanks for the heads up from
> Jaime Casanova). This happens when trying to fetch changes one made on
> a test copy after a day of lots of work back to a git repository: you
> just make very s
OK, noticed how horrible this patch was (thanks for the heads up from
Jaime Casanova). This happens when trying to fetch changes one made on
a test copy after a day of lots of work back to a git repository: you
just make very silly mistakes.
Well, now I got the changes right (tested the patch, bec
I was testing some builds I was doing and found that the regression
tests fails when doing the against a Hot Standby server:
$ make standbycheck
[...]
== running regression test queries==
test hs_standby_check ... ok
test hs_standby_allowed ... FAILED
On Mon, 2013-04-01 at 19:51 -0700, Jeff Janes wrote:
> I've reproduced the problem, this time in block 74 of relation
> base/16384/4931589, and a tarball of the data directory is here:
>
>
> https://docs.google.com/file/d/0Bzqrh1SO9FcELS1majlFcTZsR0k/edit?usp=sharing
>
>
>
> (the table is in
On Wed, 2013-04-03 at 09:48 -0700, Jeff Janes wrote:
> And why did those uninitialized pages trigger warnings when they were
> autovacced, but not when they were seq scanned in a query?
>
A scan won't trigger that warning. Empty pages are sometimes the
expected result of a crash when the file is
On 2013-04-03 09:48:54 -0700, Jeff Janes wrote:
> On Wed, Apr 3, 2013 at 2:31 AM, Andres Freund wrote:
>
> >
> >
> I just checked and unfortunately your dump doesn't contain all that much
> > valid WAL:
> > ...
> >
>
>
> > So just two checkpoint records.
> >
> > Unfortunately I fear that won't
On Wed, Apr 3, 2013 at 2:31 AM, Andres Freund wrote:
>
>
I just checked and unfortunately your dump doesn't contain all that much
> valid WAL:
> ...
>
> So just two checkpoint records.
>
> Unfortunately I fear that won't be enough to diagnose the problem,
> could you reproduce it with a higher
On 2013-04-01 19:51:19 -0700, Jeff Janes wrote:
> On Mon, Apr 1, 2013 at 10:37 AM, Jeff Janes wrote:
>
> > On Tue, Mar 26, 2013 at 4:23 PM, Jeff Davis wrote:
> >
> >>
> >> Patch attached. Only brief testing done, so I might have missed
> >> something. I will look more closely later.
> >>
> >
> >
On 2013-04-01 19:51:19 -0700, Jeff Janes wrote:
> On Mon, Apr 1, 2013 at 10:37 AM, Jeff Janes wrote:
>
> > On Tue, Mar 26, 2013 at 4:23 PM, Jeff Davis wrote:
> >
> >>
> >> Patch attached. Only brief testing done, so I might have missed
> >> something. I will look more closely later.
> >>
> >
> >
On 2 April 2013 02:53, Jeff Davis wrote:
>> Any idea
>> what is going on?
>
> Not right now.
Since I'm now responsible for the quality of this patch, I need to say
this before someone else does: we have until the end of the week to
fix this conclusively, or I will need to consider whether to rev
On Monday, April 1, 2013, Jeff Davis wrote:
> On Mon, 2013-04-01 at 10:37 -0700, Jeff Janes wrote:
>
> > Over 10,000 cycles of crash and recovery, I encountered two cases of
> > checksum failures after recovery, example:
> >
> >
> > 14264 SELECT 2013-03-28 13:08:38.980 PDT:WARNING: page verificat
On Mon, Apr 1, 2013 at 10:37 AM, Jeff Janes wrote:
> On Tue, Mar 26, 2013 at 4:23 PM, Jeff Davis wrote:
>
>>
>> Patch attached. Only brief testing done, so I might have missed
>> something. I will look more closely later.
>>
>
> After applying your patch, I could run the stress test described he
On Mon, 2013-04-01 at 10:37 -0700, Jeff Janes wrote:
> Over 10,000 cycles of crash and recovery, I encountered two cases of
> checksum failures after recovery, example:
>
>
> 14264 SELECT 2013-03-28 13:08:38.980 PDT:WARNING: page verification
> failed, calculated checksum 7017 but expected 1098
On Tue, Mar 26, 2013 at 4:23 PM, Jeff Davis wrote:
> On Tue, 2013-03-26 at 02:50 +0900, Fujii Masao wrote:
> > Hi,
> >
> > I found that the regression test failed when I created the database
> > cluster with the checksum and set wal_level to archive. I think that
> > there are some bugs around ch
On 26 March 2013 23:23, Jeff Davis wrote:
> Patch attached. Only brief testing done, so I might have missed
> something. I will look more closely later.
Thanks, I'll look at that tomorrow.
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Trai
On 25 March 2013 17:50, Fujii Masao wrote:
> I found that the regression test failed when I created the database
> cluster with the checksum and set wal_level to archive. I think that
> there are some bugs around checksum feature. Attached is the regression.diff.
Apologies for not responding to
On Tue, 2013-03-26 at 02:50 +0900, Fujii Masao wrote:
> Hi,
>
> I found that the regression test failed when I created the database
> cluster with the checksum and set wal_level to archive. I think that
> there are some bugs around checksum feature. Attached is the regression.diff.
Thank you for
Hi,
I found that the regression test failed when I created the database
cluster with the checksum and set wal_level to archive. I think that
there are some bugs around checksum feature. Attached is the regression.diff.
Regards,
--
Fujii Masao
regression.diffs
Description: Binary data
--
Sen
Peter Eisentraut writes:
> On Fri, 2011-04-15 at 16:09 -0400, Tom Lane wrote:
>> That doesn't seem like a particularly good idea in view of the recent
>> changes in psql to try to intuit a default encoding from its locale
>> environment. If I say --encoding in the command line, that means I want
On Fri, 2011-04-15 at 16:09 -0400, Tom Lane wrote:
> Peter Eisentraut writes:
> > What I'd suggest is that we take out the bit of code in pg_regress.c
> > that overrides the client encoding.
>
> That doesn't seem like a particularly good idea in view of the recent
> changes in psql to try to intu
Peter Eisentraut writes:
> What I'd suggest is that we take out the bit of code in pg_regress.c
> that overrides the client encoding.
That doesn't seem like a particularly good idea in view of the recent
changes in psql to try to intuit a default encoding from its locale
environment. If I say --
Using pg_regress --encoding sets both the server encoding of the test
database and the client encoding. (The choice of server encoding is
further constrained by locale, but that's a different issue.)
Looking at the expected variants of the pesky plpython_unicode test
plpython_unicode.out
Hmm well the KOI8 tests unsurprisingly produce random results on
non-KOI8 input. It's pure chance you didn't get EILSEQ.
Because KOI8 is not multibyte encoding.
What errno did you get for the C locale test? On which input
character?Perhaps it's sihnalljng EILSEQ for every byte >0x80 ? That
s
Hmm well the KOI8 tests unsurprisingly produce random results on non-
KOI8 input. It's pure chance you didn't get EILSEQ.
What errno did you get for the C locale test? On which input character?
Perhaps it's sihnalljng EILSEQ for every byte >0x80 ? That seems
broken to me but perhaps not to a
Say what? What OSes is that?
See attached test program. It tries to convert multibyte russian word in
UTF8 to wide char with C, ru_RU-KOI8-R and ru_RU.UTF-8 locales. The word
contains 6 letters.
FreeBSD 7.2 (short output):
C==
mbstowcs returns 12
ru_RU.KOI8-R=
On Wed, Feb 25, 2009 at 6:44 PM, Teodor Sigaev wrote:
> mbstowcs/wcstombs doesn't work with C-locale in other OSes too, so that's
> not needed.
Say what? What OSes is that?
--
greg
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
htt
Um, I think your patch like the overkill reaction of C-locale...
Patch makes char2wchar and wchar2char symmetric to C-locale.
However, I tried your patch.
make check MULTIBYTE=euc_jp NO_LOCALE=true
...
===
All 120 tests passed.
===
Anyway, either should
Hi Teodor-san.
Sorry late reaction.
- Original Message -
From: "Teodor Sigaev"
If there's an effective function like pg_wchar2mb_with_len() which
converts wchar_t strings to server encoded strings, we had better
simply call it for char2wchar().
I don't see a way to produce correct
pg_mb2wchar_with_len() converts server encoded strings to pg_wchar
strings. But pg_wchar is typedef'd as unsigned int which is not the
same as wchar_t at least on Windows (unsigned short).
Oops. The problem is here. TParserInit allocates twice less memory than needed.
And it happens if sizeof(wch
Teodor Sigaev wrote:
I think that Mr. Inoue's patch is right.
why isn't it taken into consideration yet?
I can't check that patch because I don't have a Windows box.
But I did some investigations. As I understand, the patch prevents from
calling of wcstombs/mbstowcs with C locale and I checked
I think that Mr. Inoue's patch is right.
why isn't it taken into consideration yet?
I can't check that patch because I don't have a Windows box.
But I did some investigations. As I understand, the patch prevents from calling
of wcstombs/mbstowcs with C locale and I checked trace for that. But
Hi.
Sorry late reaction.
I try check of CVS-HEAD now.
$ make check NO_LOCALE=true
...
===
All 120 tests passed.
===
However, same action as Inou-sane is seen.
make check MULTIBYTE=euc_jp NO_LOCALE=true
The differences that caused some tests to fail can
Hi,
I see a regression test failure in my mingw-vista port
when I invoke the command
make check MULTIBYTE=euc_jp NO_LOCALE=yes
.
It causes a crash at tsearch.
The crash seems to occur when the server encoding isn't
UTF-8 with no locale.
The attached is a patch to avoid the crash.
regards,
Hiros
Tom Lane napsal(a):
I wrote:
Another possible answer is to change the minimum to be just 64K always.
I'm not certain that it's really sensible to tie the minimum work_mem to
BLCKSZ --- I don't think we do anything where work_mem is controlling a
pool of page buffers, do we?
I've committed this
I wrote:
> Another possible answer is to change the minimum to be just 64K always.
> I'm not certain that it's really sensible to tie the minimum work_mem to
> BLCKSZ --- I don't think we do anything where work_mem is controlling a
> pool of page buffers, do we?
I've committed this change in HEAD.
On Apr 21, 2008, at 7:25 AM, Peter Eisentraut wrote:
Am Montag, 21. April 2008 schrieb Zdenek Kotala:
I compiled postgreSQL with 1kB block size and regresion test
fails. Main
problem is that output is correct but in different order. See
attachment.
This was previously reported:
http://arch
Zdenek Kotala <[EMAIL PROTECTED]> writes:
> Tom Lane napsal(a):
>> Zdenek Kotala <[EMAIL PROTECTED]> writes:
>>> Regression test MUST BE bulletproof.
>>
>> I'm sorry, but this is not, never has been, and never will be an
>> iron-clad project rule. When you get a failure you are supposed
>> to ins
Tom Lane napsal(a):
Zdenek Kotala <[EMAIL PROTECTED]> writes:
By the way is any reason to have work_mem * 1024 "everywhere" when we have unit
support in GUC?
Well, would you like to be able to set work_mem higher than 4GB on large
machines?
I see, another int64 issues.
Thanks Zdenek
Tom Lane napsal(a):
Zdenek Kotala <[EMAIL PROTECTED]> writes:
Regression test MUST BE bulletproof.
I'm sorry, but this is not, never has been, and never will be an
iron-clad project rule. When you get a failure you are supposed
to inspect it to see if it's a problem.
Yes, but when you find
Zdenek Kotala <[EMAIL PROTECTED]> writes:
> By the way is any reason to have work_mem * 1024 "everywhere" when we have
> unit
> support in GUC?
Well, would you like to be able to set work_mem higher than 4GB on large
machines?
regards, tom lane
--
Sent via pgsql-hacker
Zdenek Kotala <[EMAIL PROTECTED]> writes:
> Regression test MUST BE bulletproof.
I'm sorry, but this is not, never has been, and never will be an
iron-clad project rule. When you get a failure you are supposed
to inspect it to see if it's a problem.
regards, tom lane
--
On Tue, Apr 22, 2008 at 4:25 PM, Martijn van Oosterhout <[EMAIL PROTECTED]>
wrote:
> On Tue, Apr 22, 2008 at 10:31:53AM +0200, Zdenek Kotala wrote:
> > When you are able detect ordering difference you are able also check if
> it
> > is important for the test or not without any extra effort. Only w
Martijn van Oosterhout napsal(a):
On Tue, Apr 22, 2008 at 10:31:53AM +0200, Zdenek Kotala wrote:
When you are able detect ordering difference you are able also check if it
is important for the test or not without any extra effort. Only what we
need is put some flag to test that order is not imp
On Tue, Apr 22, 2008 at 10:31:53AM +0200, Zdenek Kotala wrote:
> When you are able detect ordering difference you are able also check if it
> is important for the test or not without any extra effort. Only what we
> need is put some flag to test that order is not important.
Not true. Sorting the
Tom Lane napsal(a):
Another possible answer is to change the minimum to be just 64K always.
I'm not certain that it's really sensible to tie the minimum work_mem to
BLCKSZ --- I don't think we do anything where work_mem is controlling a
pool of page buffers, do we?
Yeah, I try to find all usag
Andrew Dunstan napsal(a):
Peter Eisentraut wrote:
Am Montag, 21. April 2008 schrieb Martijn van Oosterhout:
I wonder if it would be feasable to, whenever a regression test fails
to sort both files and compare again. This should tell you if the
difference are *only* rearrangement automatical
Peter Eisentraut napsal(a):
Am Montag, 21. April 2008 schrieb Tom Lane:
That sounds like a pretty bad idea, since it would treat ordering
differences as insignificant even when they aren't --- for example,
an ordering difference in the output of a query that *has* an
ORDER BY is usually a bug.
Am Montag, 21. April 2008 schrieb Tom Lane:
> That sounds like a pretty bad idea, since it would treat ordering
> differences as insignificant even when they aren't --- for example,
> an ordering difference in the output of a query that *has* an
> ORDER BY is usually a bug.
Well, we wouldn't treat
On Mon, Apr 21, 2008 at 10:54 PM, Pavan Deolasee
<[EMAIL PROTECTED]> wrote:
> Case 1.
>
> Insert 100 records --- goes into block 1 .. 10
> Delete 100 records
> Insert 100 more records --- goes into 11 .. 20
>
>
> Case 2.
>
> Insert 100 records --- goes into block 1 .. 10
> Delete 100 record
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Am Montag, 21. April 2008 schrieb Zdenek Kotala:
>> set work_mem = 64;
>> + ERROR: 64 is outside the valid range for parameter "work_mem" (256 ..
>> 2097151) -- Test bitmap-and.
> This should probably be fixed by using a unit specification on work_me
On Mon, Apr 21, 2008 at 8:20 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
>
> No, the reason you don't see that is that plain VACUUM doesn't move
> tuples around.
>
I know. But plain VACUUM can free up dead space which can be used for
subsequent updates/inserts and that can cause reordering. For exa
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Am Montag, 21. April 2008 schrieb Martijn van Oosterhout:
>> I wonder if it would be feasable to, whenever a regression test fails
>> to sort both files and compare again. This should tell you if the
>> difference are *only* rearrangement automatically
Peter Eisentraut wrote:
Am Montag, 21. April 2008 schrieb Martijn van Oosterhout:
I wonder if it would be feasable to, whenever a regression test fails
to sort both files and compare again. This should tell you if the
difference are *only* rearrangement automatically, without having to
eyeb
Am Montag, 21. April 2008 schrieb Martijn van Oosterhout:
> I wonder if it would be feasable to, whenever a regression test fails
> to sort both files and compare again. This should tell you if the
> difference are *only* rearrangement automatically, without having to
> eyeball the output.
That so
On Mon, Apr 21, 2008 at 02:25:31PM +0200, Peter Eisentraut wrote:
> > I think affected test should contain order by keyword.
>
> For previously established reasons, we don't want to add ORDER BY clauses to
> every test that might fail under exceptional circumstances so we test all
> plan types e
Am Montag, 21. April 2008 schrieb Zdenek Kotala:
> I'm only testing behavior with different block size and I think it is not
> good idea to support only 8kB for regtest. When 4kB is used then PG fails
> in Join regresion test and with 16kB, 32kB it fails because:
>
> *** ./expected/bitmapops.out
Peter Eisentraut napsal(a):
Am Montag, 21. April 2008 schrieb Zdenek Kotala:
I compiled postgreSQL with 1kB block size and regresion test fails. Main
problem is that output is correct but in different order. See attachment.
This was previously reported:
http://archives.postgresql.org/pgsql-ha
"Pavan Deolasee" <[EMAIL PROTECTED]> writes:
> Now that we have autovacuum on by default, we might get into random
> failures because of re-ordering. Though I don't seem to recall anybody
> complaining yet, it could just be that we are lucky or our regression
> suite don't have long enough running
On Mon, Apr 21, 2008 at 5:55 PM, Peter Eisentraut <[EMAIL PROTECTED]> wrote:
>
> For previously established reasons, we don't want to add ORDER BY clauses to
> every test that might fail under exceptional circumstances so we test all
> plan types equally. I think very small block sizes are fai
Am Montag, 21. April 2008 schrieb Zdenek Kotala:
> I compiled postgreSQL with 1kB block size and regresion test fails. Main
> problem is that output is correct but in different order. See attachment.
This was previously reported:
http://archives.postgresql.org/pgsql-hackers/2006-11/msg00901.php
I compiled postgreSQL with 1kB block size and regresion test fails. Main problem
is that output is correct but in different order. See attachment.
I think affected test should contain order by keyword.
Any comments?
Zdenek
*** ./expected/join.out Wed Jan 9 21:42:28 200
"Kuriakose, Cinu Cheriyamoozhiyil" <[EMAIL PROTECTED]> writes:
> 78 of 79 tests passed, 1 failed test(s) ignored.
> Please tell me what shall I do to resolve this issue.
Nothing --- the reason it's ignored is it's not significant.
I concur though with Greg's question: why aren't you building so
"Kuriakose, Cinu Cheriyamoozhiyil" <[EMAIL PROTECTED]> writes:
> Hi All,
>
> I am trying to run Regression test on postgreSQL-7.2.8, it got installed
> successfully, but the regression test is not going through, it is giving the
> following errors...
What architecture is this? And why would you
Hi All,
I am trying to run Regression test on postgreSQL-7.2.8, it got installed
successfully, but the regression test is not going through, it is giving the
following errors...
==
78 of 79 tests passed, 1 failed test(s) ignored.
==
Gevik Babakhani wrote:
I would like to create some regression tests for the uuid datatype.
Should those also be included in the patch to review or the regression
tests are done by the commiters?
In the patch.
cheers
andrew
---(end of broadcast)
I would like to create some regression tests for the uuid datatype.
Should those also be included in the patch to review or the regression
tests are done by the commiters?
Regards,
Gevik.
---(end of broadcast)---
TIP 6: explain analyze is your frie
Tom Lane schrieb:
"Michael Paesold" <[EMAIL PROTECTED]> writes:
The tests fail for PST/PDT in 2034.
This probably indicates that you've got TZ data reflecting the new US
DST rules. We have not updated the pre-8.0 regression test results
to deal with that.
You're right as far as I can tell
"Michael Paesold" <[EMAIL PROTECTED]> writes:
> The tests fail for PST/PDT in 2034.
This probably indicates that you've got TZ data reflecting the new US
DST rules. We have not updated the pre-8.0 regression test results
to deal with that.
regards, tom lane
-
Attached are regression diffs for 7.4.10, compiled from source on RHEL 3 U6
(gcc 3.2.3 20030502, glibc-2.3.2-95.37) using:
make distclean
./configure '--with-perl' '--prefix=/usr/local/postgresql-7.4.10'
make && make install && make check
The tests fail for PST/PDT in 2034.
Looking at the buil
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> The regression test files plpgsql and rangefuncs both create a dup()
> function, and as they are run in parallel this just caused an error for
> me, as attached. This just happened once for me, but it still ought to
> be corrected.
Wups, that's my
The regression test files plpgsql and rangefuncs both create a dup()
function, and as they are run in parallel this just caused an error for
me, as attached. This just happened once for me, but it still ought to
be corrected.
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
*** ./
Stefan Kaltenbrunner <[EMAIL PROTECTED]> writes:
> iirc the error I got was something along the line of:
> ERROR: catalog is missing 1 attribute(s) for relid 17231
It's possible that that's the same problem but in a form triggered by
ALTER ADD COLUMN.
I was able to reproduce the problem I saw, a
Tom Lane wrote:
Bruce Momjian <[EMAIL PROTECTED]> writes:
I am still seeing random regression test failures on my SMP BSD/OS
machine. It basically happens when doing 'gmake check'.
I have tried running repeated tests and can't get it to reproduce, but
when checking patches it has happened perhaps
Bruce Momjian <[EMAIL PROTECTED]> writes:
> I am still seeing random regression test failures on my SMP BSD/OS
> machine. It basically happens when doing 'gmake check'.
> I have tried running repeated tests and can't get it to reproduce, but
> when checking patches it has happened perhaps once a
"make check" produces the following regression.diffs:
*** ./expected/geometry.out Fri Oct 31 22:07:07 2003
--- ./results/geometry.out Thu Aug 26 00:51:46 2004
***
*** 117,123
| (5.1,34.5) | [(1,2),(3,4)] | (3,4)
| (-5,-12) | [(1,2),(3,
I am still seeing random regression test failures on my SMP BSD/OS
machine. It basically happens when doing 'gmake check'.
I have tried running repeated tests and can't get it to reproduce, but
when checking patches it has happened perhaps once a week for the past
six weeks. It happens once and
As I posted yesterday, I've got the priviledges test failing (it's the
only one). I posted a single-step run, and I've not heard from
anyone.
I can set up an account for anyone that want's to play with it to figure
out what I've got messed up
LER
just to refresh folks memory, here is the failu
Hi all,
I have produced some code coverage data using gcov + ltp to show which
parts of the source code the regression tests are hitting and which parts
they aren't. The results are at: http://www.alcove.com.au/pgregress/
Thanks,
Gavin
---(end of broadcast)-
Strange. I know we check for bison >= 1.875, and you have that, and so
do I, but I don't see those regression failures. Is it possible you
have old bison output files from an older bison release?
---
Neil Conway wrote:
> W
I didn't know about "make maintainer-clean" either.
---
Neil Conway wrote:
> On Thu, Aug 07, 2003 at 04:09:33PM -0400, Tom Lane wrote:
> I think the check is only a warning though; and the only thing that
> > actually fails
On Thu, Aug 07, 2003 at 04:09:33PM -0400, Tom Lane wrote:
I think the check is only a warning though; and the only thing that
> actually fails to build is ecpg's preproc.y. It's possible his current
> copy of parser/gram.c was built with an older bison before he hit the
> hard failure, and then h
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Strange. I know we check for bison >= 1.875, and you have that, and so
> do I, but I don't see those regression failures. Is it possible you
> have old bison output files from an older bison release?
I think the check is only a warning though; and the
When I run the regression tests against current sources, I get
failures because bison-generated error messages use "parse
error", not "syntax error". I vaguely recall running into
this issue before I left for the summer -- did we resolve
it?
[EMAIL PROTECTED] neil]$ uname -a
FreeBSD arch.wavefire.
OK, on it now!
---
Tom Lane wrote:
> I said:
> >> I have a theory about the failures that occur while creating tables.
> >> If a relcache flush were to occur due to SI buffer overrun between
> >> creation of the new rel's re
1 - 100 of 136 matches
Mail list logo
