Joe Conway <[EMAIL PROTECTED]> writes:
> Assuming the only real problem here is the control data (long shot, I
> know), and the actual database files and transaction logs are OK, is
> there any reasonable way to reconstruct the correct contol data? Or is
> that the point at which you use pg_rese
Tom Lane wrote:
My advice is to backup the $PGDATA tree (which you said was in
progress), then pg_resetxlog, then cross-check the hell out of the data
you see. Only if you can detect some data problems can we guess at
something else to do ...
OK. I plan to gather the usual suspects and try to get
Tom Lane wrote:
Joe Conway <[EMAIL PROTECTED]> writes:
Any theories on how we screwed up?
I hesitate to suggest this, but maybe a cron job blindly copying data
from point A to point B?
Not likely, but I'll check.
Offhand my bets would revolve around (a) multiple postmasters trying
to run the same
Joe Conway <[EMAIL PROTECTED]> writes:
> Any theories on how we screwed up?
I hesitate to suggest this, but maybe a cron job blindly copying data
from point A to point B?
I'm not sure that that could entirely explain the facts. My
recollection of the xlog.c logic is that the pg_control file is r
Tom Lane wrote:
...
pg_control last modified: Tue Dec 14 15:39:26 2004
...
Time of latest checkpoint:Tue Nov 2 17:05:32 2004
[ blink... ] That seems like an unreasonable gap between checkpoints,
especially for a production server. Can you see an explanation?
Hmmm, this is
On Mon, Dec 13, 2004 at 03:04:01PM -, Mark Cave-Ayland wrote:
> Hi strk,
>
> > -Original Message-
> > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> > Sent: 13 December 2004 14:05
> > To: Mark Cave-Ayland
> > Cc: [EMAIL PROTECTED]
> > Subject: Re: [postgis-devel] RE: join selecti
We still seem to have occasional problems with dropdb while running
contrib installcheck. The symptoms look like this:
== dropping database "regression" ==
dropdb: database removal failed: ERROR: database "regression" is being
accessed by other users
On Mon, Dec 13, 2004 at 10:16:09AM -, Mark Cave-Ayland wrote:
>
> > -Original Message-
> > From: strk [mailto:[EMAIL PROTECTED]
> > Sent: 10 December 2004 15:35
> > To: Mark Cave-Ayland
> > Cc: [EMAIL PROTECTED]
> > Subject: join selectivity
> >
> >
> > Taking a look at join selecti
Joe Conway <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Please show the output of pg_controldata, or a hex dump of pg_control
>> if pg_controldata fails.
> OK, here it is:
> ...
> pg_control last modified: Tue Dec 14 15:39:26 2004
> ...
> Time of latest checkpoint:Tue
Hi,
Here is a port report for NetBSD 2.0 mac68k, with sources of
postgresql8.0.0rc1.
Here is the configure line used :
./configure --prefix=/data/postgresql/pgsql-8.0.0rc1 --with-openssl
--with-python --with-perl --with-tcl --with-krb5 --with-pam
But some tweaking was necessary to make it wor
Tom Lane wrote:
Joe Conway <[EMAIL PROTECTED]> writes:
I've got a down production server (will not restart) with the following
tail to its log file:
Please show the output of pg_controldata, or a hex dump of pg_control
if pg_controldata fails.
OK, here it is:
# pg_controldata /replica/pgdata
pg_co
Tom Lane wrote:
Joe Conway <[EMAIL PROTECTED]> writes:
I've got a down production server (will not restart) with the following
tail to its log file:
Please show the output of pg_controldata, or a hex dump of pg_control
if pg_controldata fails.
OK, will do shortly.
The server experienced a hang (a
Joe Conway <[EMAIL PROTECTED]> writes:
> I've got a down production server (will not restart) with the following
> tail to its log file:
Please show the output of pg_controldata, or a hex dump of pg_control
if pg_controldata fails.
> The server experienced a hang (as yet unexplained) yesterday a
Why is non-Win32 building the *.def files? Seems it should be only
Win32. I realize distprep has to build them of course.
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED] | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts
Joe Conway wrote:
> This is a SuSE 9, 8-way Xeon IBM x445, with nfs mounted Network
> Appliance for database storage, postgresql-7.4.5-36.4.
>
> The server experienced a hang (as yet unexplained) yesterday and was
> restarted at 2004-12-13 16:38:49 according to syslog. I'm told by the
> network
I've got a down production server (will not restart) with the following
tail to its log file:
2004-12-13 15:05:52 LOG: recycled transaction log file "0165004C"
2004-12-13 15:26:01 LOG: recycled transaction log file "0165004D"
2004-12-13 16:39:55 LOG: database system was shut do
On Wed, 2004-12-15 at 00:00, Mark Wong wrote:
> http://www.osdl.org/projects/dbt2dev/results/dev4-010/211
>
Thanks Mark for turning that around so quickly. Looks good...
Results performed to compare
test 207
http://www.osdl.org/projects/dbt2dev/results/dev4-010/207
test 211 with bg3.patc
Sorry, wrong link, right one here:
http://www.osdl.org/projects/dbt2dev/results/dev4-010/211
Mark
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
On Tue, 2004-12-14 at 09:23 -0500, Tom Lane wrote:
> At this point in the release cycle I'm not sure we should be making
> any significant changes for anything less than a crashing bug.
Yes, that's true, and I am definitely hesitant to make changes during
RC. That said, "adjust bgwriter defaults"
Tom Lane wrote:
strk <[EMAIL PROTECTED]> writes:
==15489== Syscall param write(buf) contains uninitialised or unaddressable byte(s)
Valgrind is fairly useless for debugging postgres, because it doesn't
know the difference between alignment-pad bytes in a struct and real
data. What you've got here
Got it: _bt_preprocess_keys is setting keys_are_unique in cases where it
shouldn't. The test at the bottom of that routine used to be correct,
but no longer is, because the number of keys returned could be more than
the number of attributes being tested when redundant cross-data-type quals
are pro
On Tue, 2004-12-14 at 19:40, Tom Lane wrote:
> "Zeugswetter Andreas DAZ SD" <[EMAIL PROTECTED]> writes:
> > Is it possible to do a patch that produces a dirty buffer list in LRU order
> > and stops early when eighter maxpages is reached or bgwriter_percent
> > pages are scanned ?
>
> Only if you r
Sibtay Abbas <[EMAIL PROTECTED]> writes:
> i am not able to write to file until the pl call
> handler interface. this is the template which i am
> following
> PG_FUNCTION_INFO_V1(my_call_handler);
> Datum
> my_call_handler(PG_FUNCTION_ARGS)
> {
> ...my code...
> int fd = open("filena
"Merlin Moncure" <[EMAIL PROTECTED]> writes:
> Try it with explain/analyze which reports 4 rows.
I don't see four rows. I do see different results when I add the third
redundant WHERE clause: it switches to a different index and fails to
find the row it should find. I suspect the problem is loca
Sorry for the delay; here are results with the bg3.patch with database
parameters that should match run 207. I haven't been able to take the
time too look over the results myself, but I tried to make sure this
run was the same as 207:
http://www.osdl.org/projects/dbt2dev/results/dev4-010/2
That's a good point. Should we just use cc_r for all thread compiles on
AIX if they are using cc and not gcc? I am not ready to have the
backend compiled with cc_r at this stage so I think this level of
support has to wait until 8.1.
-
On Dec 14, 2004, at 12:51 PM, Bruce Momjian wrote:
Peter Eisentraut wrote:
Bruce Momjian wrote:
Huh, isn't this port testing? Do we not want to fix port bugs at
this stage?
We are not really fixing anything, because it was never expected to
work
before. We are adding new functionality. It is, o
"Andrew Dunstan" <[EMAIL PROTECTED]> writes:
> Tom Lane said:
>> At the moment I think a "sleep" in the contrib makefile is sufficient
>> (though note I intended to apply it only to installcheck not the other
>> actions ;-))
> If you're going to make a separate rule for installcheck (which I agree
It's becoming pretty obvious that PG 8.0 won't be released on Dec 15.
That was an optimistic target to begin with, and last week's network
problems have put it out of reach.
After some discussion, the core committee has decided to go week-to-week
on this: once an RC release survives for a week wit
On Tue, Dec 14, 2004 at 10:31:41AM -0800, Sibtay Abbas wrote:
> i am not able to write to file until the pl call
> handler interface.
What are you expecting to happen and what actually does happen?
Saying only "it doesn't work" doesn't give us much to go on.
> this is the template which i am fol
"Zeugswetter Andreas DAZ SD" <[EMAIL PROTECTED]> writes:
> Is it possible to do a patch that produces a dirty buffer list in LRU order
> and stops early when eighter maxpages is reached or bgwriter_percent
> pages are scanned ?
Only if you redefine the meaning of bgwriter_percent. At present it's
I confirmed the problem on a linux server running beta3...so this
problem is quite reproducible by running the attached scripts on a
freshly loaded database.
To reproduce the problem [adjust host,etc as necessary]:
1. type/cat test_boolean.sql | psql template1 (this will create a
database called
Peter Eisentraut wrote:
> Bruce Momjian wrote:
> > Huh, isn't this port testing? Do we not want to fix port bugs at
> > this stage?
>
> We are not really fixing anything, because it was never expected to work
> before. We are adding new functionality. It is, of course, a
> borderline case. B
hello
i am not able to write to file until the pl call
handler interface. this is the template which i am
following
PG_FUNCTION_INFO_V1(my_call_handler);
Datum
my_call_handler(PG_FUNCTION_ARGS)
{
...my code...
int fd = open("filename",O_WRONLY);
write(fd,buffer,strlen(bu
Bruce Momjian wrote:
> Huh, isn't this port testing? Do we not want to fix port bugs at
> this stage?
We are not really fixing anything, because it was never expected to work
before. We are adding new functionality. It is, of course, a
borderline case. But for example, do we have any informa
Peter Eisentraut wrote:
> Am Dienstag, 14. Dezember 2004 16:51 schrieb Brad Nicholson:
> > AIX 5.1
> >
> > I applied Bruce's patch, configured with --enable-thread-safety and
> > everything went smoothly.
>
> Nonetheless, threading support on AIX being a new feature, I don't think this
> should g
> (2) Remove bgwriter_percent. I have yet to hear anyone argue that
> there's an actual need for bgwriter_percent in tuning
> bgwriter behavior,
One argument for it is to avoid writing very hot pages.
> (3) Change the meaning of bgwriter_percent, per Simon's proposal. Make
> it mean "the perce
AIX 5.1
I applied Bruce's patch, configured with --enable-thread-safety and
everything went smoothly.
==
All 96 tests passed.
==
Brad.
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to
Bruce wrote:
> That is bizarre. Does EXPLAIN show any difference?
>
>
--
esp=# explain analyze select 1::int4, * from data1.po_line_file
esp-# where pol_po_no = '0002' and
esp-# (pol_po_no = '0002' and
> That is bizarre. Does EXPLAIN show any difference?
Uh oh.
esp=# reindex table data1.parts_order_line_file;
REINDEX
esp=# explain analyze select 1::int4, * from data1.po_line_file
esp-# where pol_po_no = '0002' and
esp-# (pol_po_no = '0002' and pol_po_rel_no = 0) and
esp-#
strk <[EMAIL PROTECTED]> writes:
> ==15489== Syscall param write(buf) contains uninitialised or unaddressable
> byte(s)
Valgrind is fairly useless for debugging postgres, because it doesn't
know the difference between alignment-pad bytes in a struct and real
data. What you've got here is a gripe
Hi all.
I'm getting error reports from valgrind while debugging postgis.
It seems that the error only shows up when I build a GiST index
AND vacuum analyze.
If I drop the index the error goes away.
If I create the index the error still doesn't show.
If I vacuum analyze, the error is back, but not
42 matches
Mail list logo
