On Fri, Mar 24, 2017 at 7:58 PM, Teodor Sigaev wrote:
> Thank you all, pushed.
Thanks.
--
Michael
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Thank you all, pushed
Michael Paquier wrote:
On Fri, Mar 24, 2017 at 1:45 AM, Teodor Sigaev wrote:
I believe patch looks good and it's ready to commit.
Thanks for the review!
As I understand, it fixes bug introduced by
commit 7117685461af50f50c03f43e6a622284c8d54694
Date: Tue Apr 5 20:03
On Fri, Mar 24, 2017 at 1:45 AM, Teodor Sigaev wrote:
> I believe patch looks good and it's ready to commit.
Thanks for the review!
> As I understand, it fixes bug introduced by
> commit 7117685461af50f50c03f43e6a622284c8d54694
> Date: Tue Apr 5 20:03:49 2016 +0200
>
> Implement backup API
Hi!
I believe patch looks good and it's ready to commit. As I understand, it fixes
bug introduced by
commit 7117685461af50f50c03f43e6a622284c8d54694
Date: Tue Apr 5 20:03:49 2016 +0200
Implement backup API functions for non-exclusive backups
And, suppose, it should be backpatched to 9.6
On Thu, Mar 16, 2017 at 12:46 AM, Andres Freund wrote:
> Hi,
>
> On 2017-03-15 15:28:03 +0900, Michael Paquier wrote:
>> diff --git a/src/backend/access/transam/xlog.c
>> b/src/backend/access/transam/xlog.c
>> index 64335f909e..eaf8e32fe1 100644
>> --- a/src/backend/access/transam/xlog.c
>> +++ b
Hi,
On 2017-03-15 15:28:03 +0900, Michael Paquier wrote:
> diff --git a/src/backend/access/transam/xlog.c
> b/src/backend/access/transam/xlog.c
> index 64335f909e..eaf8e32fe1 100644
> --- a/src/backend/access/transam/xlog.c
> +++ b/src/backend/access/transam/xlog.c
> --- a/src/backend/access/tran
On 3/15/17 2:28 AM, Michael Paquier wrote:
> On Wed, Mar 15, 2017 at 12:27 AM, Anastasia Lubennikova
> wrote:
>> As far as I understand, in this thread were discussed two bugs of
>> pg_stop_backup().
>> Thanks to the clear descriptions above, I easily reproduced both of them.
>>
>> BUG#1:
>> Serv
The following review has been posted through the commitfest application:
make installcheck-world: tested, passed
Implements feature: tested, passed
Spec compliant: tested, passed
Documentation:tested, passed
As I see, this bugfix works as expected and the patch is smal
On Wed, Mar 15, 2017 at 12:27 AM, Anastasia Lubennikova
wrote:
> As far as I understand, in this thread were discussed two bugs of
> pg_stop_backup().
> Thanks to the clear descriptions above, I easily reproduced both of them.
>
> BUG#1:
> Server crashes on assertion on call of pg_stop_backup(fal
As far as I understand, in this thread were discussed two bugs of
pg_stop_backup().
Thanks to the clear descriptions above, I easily reproduced both of them.
BUG#1:
Server crashes on assertion on call of pg_stop_backup(false) after interrupted
call of pg_stop_backup(false).
TRAP: FailedAssertion
Grant Finnemore <[EMAIL PROTECTED]> writes:
> The query with no EXPLAIN (ANALYSE) completes fine.
> The query with EXPLAIN ANALYSE completes fine.
> However, with just EXPLAIN (no ANALYSE)
Need a complete test case please, not just the query. All I get here is
ERROR: relation "tagged_asset" does
Grant Finnemore napsal(a):
CrashReporter trace:
Date/Time: 2007-05-31 10:21:39.285 +0200
OS Version: 10.4.9 (Build 8P2137)
Report Version: 4
Command: postmaster
Path:./bin/postmaster
Parent: postmaster [23091]
Version: ??? (???)
PID:23096
Thread: 0
Exception: EXC_BAD_ACCES
Harvell F <[EMAIL PROTECTED]> writes:
> I've got a database corruption/backend crash problem with my 8.1.3
> database on Mac OS X Server 10.4. I'm beginning the process of
> trying to recover it. If anyone is interested in trying to fully
> understand the what, where, and why of the crash,
"Harvell F" <[EMAIL PROTECTED]> writes:
> Just as a follow up, it turns out that our fiberchannel RAID was power
> cycled
> while the systems were up and running. There are several write errors in the
> postgresql log.
>
> Now I'm off to try to recover the data...
That's still a problem, i
Just as a follow up, it turns out that our fiberchannel RAID was
power cycled while the systems were up and running. There are
several write errors in the postgresql log.
Now I'm off to try to recover the data...
--
F Harvell
407 467-1919
On 18 Apr 2007, at 10:08, Harvell F wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Tom Lane wrote:
> SM <[EMAIL PROTECTED]> writes:
>> I got a backend crash in Postgresql 8.2.3 with the plpgsql function.
>> The following statement in psql causes a signal 11:
>> psql=# create function testpl() returns void as 'begin return;
>> end;'l
Ok, I nailed the bug, but i'm not sure what the correct fix is.
Attached tsearch_morph.diff that remedies this problem by avoiding it.
Also there's a debug aid patch if someone would like to know how i
finally found it out :)
There problem in the lemmatize() function is that GETDICT(...) returned
Oleg Bartunov <[EMAIL PROTECTED]> wrote:
>
> So, the problem may be in rh 7.3 ?
>
Might be, i'm debugging it now, and i can see that the dicts[] array in
morph.c is beeing overwritten with junk.
I can trigger it with this query:
select txt2txtidx('Can - Live 1971-77');
Is there any good way of
On Tue, 3 Dec 2002, Magnus Naeslund(f) wrote:
> Christopher Kings-Lynne <[EMAIL PROTECTED]> wrote:
> >> I'll reinstall tsearch and try again soon.
> >> Is it necesary to install OpenFTS contrib aswell, or do i get away
> >> with only installing tsearch?
> >> Now i do both...
> >
> > Can you give u
Christopher Kings-Lynne <[EMAIL PROTECTED]> wrote:
>
> Works on FreeBSD/Alpha for me. Maybe you've got some weirdness with
> bad RAM chips or something?
>
> Chris
Could be, but it only shows when i do this, and the server has been up
for several months.
If everything else failes, i'll run memtest
> No i can't, it's not my data to give :(
OK
> But it doesn't matter since if you run "gmake installcheck" in
> contrib/tsearch it will explode.
>
> A funny thing is that i installed pg7.3 on an linux intel celeron system
> (rh8.0) w/128 mb memory, and THERE it works!
Works on FreeBSD/Alpha for
Christopher Kings-Lynne <[EMAIL PROTECTED]> wrote:
>> I'll reinstall tsearch and try again soon.
>> Is it necesary to install OpenFTS contrib aswell, or do i get away
>> with only installing tsearch?
>> Now i do both...
>
> Can you give us the compressed text? I can try it on my installation
> and
> I'll reinstall tsearch and try again soon.
> Is it necesary to install OpenFTS contrib aswell, or do i get away with
> only installing tsearch?
> Now i do both...
Can you give us the compressed text? I can try it on my installation and
see if there's the same problem?
Chris
-
Teodor Sigaev <[EMAIL PROTECTED]> wrote:
>
> Sorry, I have no any idea. Just only full reinstall (with initdb
> and rm -rf /usr/local/pgsql) postgresql...
> Can you give me login on you computer for a several hours?
>
The thing is that when i ran the thing breakpointing on parsetext() at
the
As you wish...
This is a bt taken from a core file this time (the other ones were from
attached processes).
The whole thing has been recompiled with no additional compiler flags
(i.e. removed -march=athlon -O3), but still with --enable-debug
and --enable-cassert.
Sorry, I have no any idea. J
Some more (useless) info.
objdump -x /lib/*.so /usr/lib/*.so /lib/i686/*.so /usr/kerberos/lib/*.so
/usr/local/pgsql/bin/* /usr/local/pgsql/lib/*.so | grep lemmatize
reviels only one lemmatize symbol.
The offending address 0x02d1 is not mapped anywhere in the address
space according to /proc/
Oleg Bartunov <[EMAIL PROTECTED]> wrote:
> Magnus, we need backtrace from 'make installcheck'
>
As you wish...
This is a bt taken from a core file this time (the other ones were from
attached processes).
The whole thing has been recompiled with no additional compiler flags
(i.e. removed -march=ath
On Tue, 3 Dec 2002, Magnus Naeslund(f) wrote:
> Teodor Sigaev <[EMAIL PROTECTED]> wrote:
> > Pls, send backtrace... :)
> >
>
> I already have, twice.
Magnus, we need backtrace from 'make installcheck'
>
> Magnus
>
> ---(end of broadcast)---
> TIP 4
Teodor Sigaev wrote:
Does it crashed?
# select txt2txtidx('Can - Live 1971-77');
Line txtidx.c:366 :
lemm = lemmatize(token, &lenlemm, type);
lemmatize() is defined in morph.c. Did you use another modules for
postgresql?
It seems to me that we see a name conflict. Function lemmatize is
de
Teodor Sigaev <[EMAIL PROTECTED]> wrote:
> Pls, send backtrace... :)
>
I already have, twice.
Magnus
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
Pls, send backtrace... :)
Magnus Naeslund(f) wrote:
Oleg Bartunov <[EMAIL PROTECTED]> wrote:
Magnus,
what is an output of 'make installcheck' ?
As i said, it segfaults:
[root@fet1b tsearch]# gmake installcheck
gmake -C ../../src/test/regress pg_regress
gmake[1]: Entering directory `/usr/s
Teodor Sigaev <[EMAIL PROTECTED]> wrote:
> Does it crashed?
> # select txt2txtidx('Can - Live 1971-77');
>
>
> Line txtidx.c:366 :
> lemm = lemmatize(token, &lenlemm, type);
>
> lemmatize() is defined in morph.c. Did you use another modules for
> postgresql?
>
> It seems to me that we see a name c
Oleg Bartunov <[EMAIL PROTECTED]> wrote:
> Magnus,
>
> what is an output of 'make installcheck' ?
As i said, it segfaults:
[root@fet1b tsearch]# gmake installcheck
gmake -C ../../src/test/regress pg_regress
gmake[1]: Entering directory `/usr/src/postgresql-7.3/src/test/regress'
gmake[1]: `pg_re
Does it crashed?
# select txt2txtidx('Can - Live 1971-77');
Line txtidx.c:366 :
lemm = lemmatize(token, &lenlemm, type);
lemmatize() is defined in morph.c. Did you use another modules for postgresql?
It seems to me that we see a name conflict. Function lemmatize is defined in
somewhere also.
On Tue, 3 Dec 2002, Magnus Naeslund(f) wrote:
> Oleg Bartunov <[EMAIL PROTECTED]> wrote:
> >
> > Please, tell us postgresql version. Did you reinstall tsearch after
> > upgrading ? Test-suite (data, sql) demonstrated the problem would be
> > nice.
> >
>
> pgsql 7.3, about 700mb text database with
More info, the gdb> sharedlibrary loaded some more symbols:
(gdb) bt
#0 0x02d1 in ?? ()
#1 0x401faf48 in parsetext (prs=0xbfffea60, buf=0x4277eb3c "Can - Live
1971-77", buflen=18) at txtidx.c:366
#2 0x401fb5e6 in txt2txtidx (fcinfo=0xbfffeaf0) at txtidx.c:487
#3 0x080ec45c in ExecMakeFunct
Oleg Bartunov <[EMAIL PROTECTED]> wrote:
>
> Please, tell us postgresql version. Did you reinstall tsearch after
> upgrading ? Test-suite (data, sql) demonstrated the problem would be
> nice.
>
pgsql 7.3, about 700mb text database with product descriptions.
I'm working on isolation the behavior, t
On Tue, 3 Dec 2002, Magnus Naeslund(f) wrote:
> I'm evaluating tsearch contrib module, and i get a backend crash when
> i'm about to use a tsearch function.
>
> When i issue
> update things set nidx=txt2txtidx(productname),
> didx=txt2txtidx(longdescription);
>
> The backend dies in a segfault.
>
Tom Lane <[EMAIL PROTECTED]> wrote:
>
> Be sure to eliminate the possibility that you're loading the wrong
> version of the .so (ie, loading a 7.2 tsearch.so into 7.3). People
> get bit by that quite frequently right after an upgrade ...
>
Well, this is a clean install, so that isn't a problem.
"Magnus Naeslund\(f\)" <[EMAIL PROTECTED]> writes:
> It's either that it can't load the lib (shouldn't it complain?) or it's
> a bad pointer.
Be sure to eliminate the possibility that you're loading the wrong
version of the .so (ie, loading a 7.2 tsearch.so into 7.3). People
get bit by that quite
Tom Lane <[EMAIL PROTECTED]> wrote:
> "Magnus Naeslund(f)" <[EMAIL PROTECTED]> writes:
>> The backend dies in a segfault.
>
>> Backtrace:
>
>> #0 0x02d1 in ?? ()
>> #1 0x401faf48 in ?? ()
>> #2 0x401fb5e6 in ?? ()
>> #3 0x080d8f5c in ExecMakeFunctionResult (fcache=0x82d3710,
>> arguments=0x
"Magnus Naeslund(f)" <[EMAIL PROTECTED]> writes:
> The backend dies in a segfault.
> Backtrace:
> #0 0x02d1 in ?? ()
> #1 0x401faf48 in ?? ()
> #2 0x401fb5e6 in ?? ()
> #3 0x080d8f5c in ExecMakeFunctionResult (fcache=0x82d3710,
> arguments=0x82ce170, econtext=0x82d3580, isNull=0xbfffec8f
I've definitely seen errors from including vacuum and/or analyze
statements in functions, I think I've seen crashes too. If you check the
docs I'm pretty sure they mention the specifics of not being able to use
such statements.
Robert Treat
On Wed, 2002-09-18 at 04:09, Michael Paesold wrote:
> H
Rod Taylor <[EMAIL PROTECTED]> writes:
> On Wed, 2002-09-18 at 11:03, Tom Lane wrote:
>> "Michael Paesold" <[EMAIL PROTECTED]> writes:
> I have written a test function, that will create a sequence and a table,
> than insert one million rows into the table, analyze the table and create an
> index o
On Wed, 2002-09-18 at 11:03, Tom Lane wrote:
> "Michael Paesold" <[EMAIL PROTECTED]> writes:
> > I have written a test function, that will create a sequence and a table,
> > than insert one million rows into the table, analyze the table and create an
> > index on one of the columns.
>
> You can't
"Michael Paesold" <[EMAIL PROTECTED]> writes:
> I have written a test function, that will create a sequence and a table,
> than insert one million rows into the table, analyze the table and create an
> index on one of the columns.
You can't run ANALYZE inside a function. In CVS tip there's a che
"Oliver Elphick" <[EMAIL PROTECTED]> writes:
> Table `job' is inherited by `manufactured_job' and `purchased_job'. This
> query works on either inherited table but not on the whole hierarchy:
I've committed a fix to CVS.
regards, tom lane
---(end
47 matches
Mail list logo
