[EMAIL PROTECTED] writes:
> Anyway, I'm not quite getting the idea of caching sequence values. I
> understand the performance benefits, but it seems problematic across
> multiple backends, almost ensuring "holes" in the sequence of numbers.
The point is to reduce lock contention on the sequence ta
"Joshua D. Drake" <[EMAIL PROTECTED]> writes:
> Using community PostgreSQL 7.4.2 I have tried to vacuum this database
> to no avail. Everytime I try I get this referenced errror. I even
> dumped and restored to a new database an get the same error.
Hmm, how about a stack trace from the errfinish c
Mario Weilguni <[EMAIL PROTECTED]> writes:
> Are there any tools available to dump datafiles for debugging
> purposes?
I often use pg_filedump, available here:
http://sources.redhat.com/rhdb/
> I think there is a corruption problem in Postgresql 7.4.2 with and
> only with the Ltree module.
Could
I have an idea, let me know what you all think.
rather than do:
select sum( field) from largetable
I want (need) to be able to do something like this:
select setval('myseq', select sum(field) from largetable);
and in a trigger
SELECT addval('myseq', field_size);
I have already created this f
Without more information about what the data is, there is really no way to
even guess.
Can you make the database available so it can be looked at?
> Hello,
>
> Using community PostgreSQL 7.4.2 I have tried to vacuum this database to
> no avail. Everytime
> I try I get this referenced errror. I ev
Hello,
Using community PostgreSQL 7.4.2 I have tried to vacuum this database to
no avail. Everytime
I try I get this referenced errror. I even dumped and restored to a new
database an get the same error.
I was also able to reindex the database but no help there.
Not much to say on google...
Data
> -Original Message-
> From: Nigel J. Andrews [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, February 24, 2004 3:33 PM
> To: Dann Corbit
> Cc: PostgreSQL-development
> Subject: Re: [HACKERS] Is indexing broken for bigint columns?
>
>
>
> Dann,
>
> Did you mean to forward this to -hackers?
Albretch wrote:
Gaetano Mendola <[EMAIL PROTECTED]> wrote in message news:<[EMAIL PROTECTED]>...
If you access a table more frequently then other and you have enough
RAM your OS will mantain that table on RAM, don't you think ?
BTW if you trust on your UPS I'm sure you are able to create a RAM
d
Are there any tools available to dump datafiles for debugging purposes? I think there
is a corruption problem in Postgresql 7.4.2 with and only with the Ltree module.
I've seen broken ltree entries in my database, and there were no updates on the
tables. This occurs once or twice a day, at rando
Gaetano Mendola <[EMAIL PROTECTED]> wrote in message news:<[EMAIL PROTECTED]>...
> If you access a table more frequently then other and you have enough
> RAM your OS will mantain that table on RAM, don't you think ?
> BTW if you trust on your UPS I'm sure you are able to create a RAM
> disk and pla
On Mon, 2004-06-07 at 06:20, Jan Wieck wrote:
> I tend to agree with you that spurious SYNC's aren't the end of the
> world. The idea of using notify to tell the syncThread somthing happened
> is probably the right way to do it, but at this time a little invasive.
> We need more time to investig
[EMAIL PROTECTED] (David Fetter) writes:
> I bumped across this several times, and am wondering what SQL99 and
> SQL200x have to say about column numbers or aliases in HAVING.
SQL99 not only does not allow them in GROUP BY or HAVING, but it doesn't
allow them in ORDER BY either, thereby eliminatin
> > If I were trying to solve Andreas' problem, I'd pipe stderr
> > to some program that stores recent log output in a file that
> > I know the location of and can read from the hypothetical
> > log-grabber function. Actually I don't see that there's any
> > need to involve Postgres itself in
Andreas wrote:
>
> AFAICS, we have some alternatives:
> - try to grab the currently created files/syslog/eventlog.
> Seems hard to
> do, because we'd depend on additional external tools.
> - redirect stderr to a postgresql.conf known file.
> Disadvantage: breaks
> piping.
> - maintain a shared
Shachar Shemesh wrote:
Robert Treat wrote:
On Sunday 06 June 2004 13:47, Shachar Shemesh wrote:
Hi list,
A postgresql migration I am doing (the same one for which the OLE DB
driver was written) has finally passed the proof-of-concept stage
(phew). I now have lots and lots of tidbits, tricks and
Tom Lane wrote:
Andreas Pflug <[EMAIL PROTECTED]> writes:
What if there's no file access
If you don't have any access to the machine then you are not really a
DBA, you only play one on TV.
However you may call me, I can think of many cases where I'd like to
look at the server log, withou
Robert Treat wrote:
On Sunday 06 June 2004 13:47, Shachar Shemesh wrote:
Hi list,
A postgresql migration I am doing (the same one for which the OLE DB
driver was written) has finally passed the proof-of-concept stage
(phew). I now have lots and lots of tidbits, tricks and tips for SQL
Server mig
Shridhar Daithankar wrote:
Bruce Momjian wrote:
Shridhar Daithankar wrote:
Bruce Momjian wrote:
http://www.hserus.net/~shridhar/regression.diffs.gz
http://www.hserus.net/~shridhar/regression.out
Uh, were did you get this snapshot? Hold old was it? These newline
problems were fixed perhaps 2 week
Bruce Momjian wrote:
Shridhar Daithankar wrote:
Bruce Momjian wrote:
http://www.hserus.net/~shridhar/regression.diffs.gz
http://www.hserus.net/~shridhar/regression.out
Uh, were did you get this snapshot? Hold old was it? These newline
problems were fixed perhaps 2 weeks ago.
ftp://ftp.postgresql.
On Sunday 06 June 2004 13:47, Shachar Shemesh wrote:
> Hi list,
>
> A postgresql migration I am doing (the same one for which the OLE DB
> driver was written) has finally passed the proof-of-concept stage
> (phew). I now have lots and lots of tidbits, tricks and tips for SQL
> Server migration, whi
Shridhar Daithankar wrote:
> Bruce Momjian wrote:
> >>http://www.hserus.net/~shridhar/regression.diffs.gz
> >>http://www.hserus.net/~shridhar/regression.out
> > Uh, were did you get this snapshot? Hold old was it? These newline
> > problems were fixed perhaps 2 weeks ago.
>
> ftp://ftp.postgresq
Andreas Pflug <[EMAIL PROTECTED]> writes:
> What if there's no file access
If you don't have any access to the machine then you are not really a
DBA, you only play one on TV. You can't for example start and stop the
postmaster remotely. So I don't have a lot of sympathy for the notion
that the l
Tom Lane wrote:
If I were trying to solve Andreas' problem, I'd pipe stderr to some
program that stores recent log output in a file that I know the location
of and can read from the hypothetical log-grabber function. Actually I
don't see that there's any need to involve Postgres itself in this iss
"Dave Page" <[EMAIL PROTECTED]> writes:
> Thanks Tom. I wonder if we (the pgAdmin team) finally need to bite the
> proverbial bullet and write a helper daemon that can allow access to
> logs as well as config files and pg_ctl etc. as an optional extra
> component.
Red Hat's RHDB group already did
Bruce Momjian wrote:
http://www.hserus.net/~shridhar/regression.diffs.gz
http://www.hserus.net/~shridhar/regression.out
Uh, were did you get this snapshot? Hold old was it? These newline
problems were fixed perhaps 2 weeks ago.
ftp://ftp.postgresql.org/pub/dev/postgresql-snapshot.tar.gz
It is tim
> -Original Message-
> From: Tom Lane [mailto:[EMAIL PROTECTED]
> Sent: 07 June 2004 15:32
> To: Dave Page
> Cc: Andreas Pflug; PostgreSQL Development
> Subject: Re: [HACKERS] serverlog function (log_destination file)
>
>
> If I were trying to solve Andreas' problem, I'd pipe stderr
On Mon, Jun 07, 2004 at 16:06:53 +0200,
Andreas Pflug <[EMAIL PROTECTED]> wrote:
>
> AFAICS, we have some alternatives:
You could also pipe the logs to a program that writes them to a table
in the database. As long as the logging level wasn't set so high that
inserting the log entries was logge
"Dave Page" <[EMAIL PROTECTED]> writes:
> ... what about adding a GUC variable that can be used to specify an
> amount of shared memory to use as a fifo area in which a copy of the log
> output is stored for return to clients that might want it (accessing it
> via internal functions)?
No, that's a
Shridhar Daithankar wrote:
> Andrew Dunstan wrote:
>
> > Shridhar Daithankar wrote:
> >
> >> Hi,
> >>
> >> I checked out the windows port to play with. It compiled file but
> >> 'make check' produced attached regression diff.
> >>
> >> I am using the nightly snapshot. Is it too early to look at
Bruce Momjian wrote:
Andreas Pflug wrote:
I'd like to see the serverlog even if I can't "go and look at the log
file", because I don't have file access to the server.
Understand. Unfortunately, we don't allow such functionality. The only
solution I can think of is to use syslog and
Andrew Dunstan wrote:
Shridhar Daithankar wrote:
Hi,
I checked out the windows port to play with. It compiled file but
'make check' produced attached regression diff.
I am using the nightly snapshot. Is it too early to look at these
failures or did I do something wrong? I was following usual
./
Tom Lane wrote:
Andreas Pflug <[EMAIL PROTECTED]> writes:
Hm, what I missed is that pg_ctl's -l parameter converts to a simple
stderr redirection, and it's hardly possible to find out where it's going.
This could be solved by a file log_destination option or a
freopen(...,stderr) from a guc va
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Tom Lane
> Sent: 07 June 2004 14:30
> To: Andreas Pflug
> Cc: PostgreSQL Development
> Subject: Re: [HACKERS] serverlog function (log_destination file)
>
> Andreas Pflug <[EMAIL PROTECTED]> writes:
Andreas Pflug wrote:
> Tom Lane wrote:
>
> >Andreas Pflug <[EMAIL PROTECTED]> writes:
> >
> >
> >>For adminstrator's convenience, I'd like to see a function that returns
> >>the serverlog.
> >>
> >>
> >
> >What do you mean by "returns the serverlog"? Are you going to magically
> >recover d
Andreas Pflug <[EMAIL PROTECTED]> writes:
> Hm, what I missed is that pg_ctl's -l parameter converts to a simple
> stderr redirection, and it's hardly possible to find out where it's going.
> This could be solved by a file log_destination option or a
> freopen(...,stderr) from a guc variable.
An
Shridhar Daithankar wrote:
Hi,
I checked out the windows port to play with. It compiled file but
'make check' produced attached regression diff.
I am using the nightly snapshot. Is it too early to look at these
failures or did I do something wrong? I was following usual
./configure;make procedu
I tend to agree with you that spurious SYNC's aren't the end of the
world. The idea of using notify to tell the syncThread somthing happened
is probably the right way to do it, but at this time a little invasive.
We need more time to investigate how to avoid notice storms during high
update act
Andreas Pflug wrote:
Tom Lane wrote:
Andreas Pflug <[EMAIL PROTECTED]> writes:
For adminstrator's convenience, I'd like to see a function that
returns the serverlog.
What do you mean by "returns the serverlog"? Are you going to magically
recover data that has gone to stderr or the syslogd
Hi,
I checked out the windows port to play with. It compiled file but 'make check'
produced attached regression diff.
I am using the nightly snapshot. Is it too early to look at these failures or
did I do something wrong? I was following usual ./configure;make procedure after
installing mingw.
On Mon, 23 Feb 2004, Neil Conway wrote:
> Tom Lane <[EMAIL PROTECTED]> writes:
> > So, if you've got any fixes you wanted to get into those branches,
> > time to get on it.
>
> I just wanted to note that IMHO a fix for the PL/PgSQL crash in
> 7.4.1 and HEAD (not sure about 7.3.x) that Chris Campbe
Tom Lane wrote:
"Joshua D. Drake" <[EMAIL PROTECTED]> writes:
Why are you running a vacuum every 45 seconds? Increase your fsm_pages and
run it every hour.
If I understood his description correctly, he's turning over 10% of a
500-row table every minute. So waiting an hour would mean 3000 dead
row
Tom Lane wrote:
Andreas Pflug <[EMAIL PROTECTED]> writes:
For adminstrator's convenience, I'd like to see a function that returns
the serverlog.
What do you mean by "returns the serverlog"? Are you going to magically
recover data that has gone to stderr or the syslogd daemon? If so, how?
Tom Lane <[EMAIL PROTECTED]> writes:
> So, if you've got any fixes you wanted to get into those branches,
> time to get on it.
I just wanted to note that IMHO a fix for the PL/PgSQL crash in
7.4.1 and HEAD (not sure about 7.3.x) that Chris Campbell recently
reported should definitely be included i
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
jihuang wrote:
| May Users forcely assign a table / database / cluster storage in RAM
| purely ?
NO.
| or a in-directly-way , like making a RAM-Disk-Device and assign this
| device as a postgreSQL cluster?
YES.
| I think this feature will push a lot
> We could safely sort on the hash value, but I'm not sure how effective
> that would be, considering that we're talking about values that already
> hashed into the same bucket --- there's likely not to be very many
> distinct hash values there.
I think we can safely put that on the todo list.
Th
Larry Rosenman wrote:
> I had to hack on the code some more for FreeBSD:
> (the realloc call needed the multiplication). I ran this same code
> on UnixWare.
I feel like a moron, having missed that. Probably explains the "bad
file number" error I was getting on AIX, too...
--
Kevin Brown
46 matches
Mail list logo
