On Tue, 2004-12-14 at 13:30, Neil Conway wrote:
> In recent discussion[1] with Simon Riggs, there has been some talk of
> making some changes to the bgwriter. To summarize the problem, the
> bgwriter currently scans the entire T1+T2 buffer lists and returns a
> list of all the currently dirty bu
On 12/12/2004 5:08 PM, Simon Riggs wrote:
On Sun, 2004-12-12 at 05:46, Neil Conway wrote:
Simon Riggs wrote:
> If the bgwriter_percent = 100, then we should actually do the sensible
> thing and prepare the list that we need, i.e. limit
> StrategyDirtyBufferList to finding at most bgwriter_maxpages.
On 12/12/2004 9:43 PM, Neil Conway wrote:
On Sun, 2004-12-12 at 22:08 +, Simon Riggs wrote:
> On Sun, 2004-12-12 at 05:46, Neil Conway wrote:
> Is the plan to make bgwriter_percent = 100 the default setting?
Hmm...must confess that my only plan is:
i) discover dynamic behaviour of bgwriter
ii)
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 ...
Before running pg_resetxlog, a couple of questions:
1.
On 12/14/2004 2:40 PM, 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 redefine the meaning of bg
That driver should work, however you might have something else
misconfigured.
What error are you getting ?
You should post this to the jdbc list
Dave
ElayaRaja S wrote:
Hi,
I am using postgresql-7.4.5. I nee to use the jdbc connection So i
downloaded 4 versions of driver( pg74.215.jdbc1.jar,
p
Joe Conway <[EMAIL PROTECTED]> writes:
> I don't trust it at all. So does that imply that I should override next
> transaction id and WAL starting address per the manpage?
Yes, override everything there's a switch for. Also check that the
other values shown by pg_controldata look reasonable (the
Tom Lane <[EMAIL PROTECTED]> writes:
> > 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 admin that there was a problem with the network card on restart,
> > so the nfs mount most probabl
Josh Berkus <[EMAIL PROTECTED]> wrote on 15.12.2004, 18:36:53:
> Hmmm, I've not seen this. For example, with people who are having trouble
> with checkpoint spikes on Linux, I've taken to recommending that they call
> sync() (via cron) every 5-10 seconds (thanks, Bruce, for suggestion!).
> B
Tom Lane wrote:
Joe Conway <[EMAIL PROTECTED]> writes:
I don't trust it at all. So does that imply that I should override
next transaction id and WAL starting address per the manpage?
Yes, override everything there's a switch for. Also check that the
other values shown by pg_controldata look reas
I asked this on general, but didn't receive any responses. Is it possible
via SQL to identify the time of the last stat reset (or pg_stat_reset()
call)? This is what I'm lacking to be able to measure query activity
volume over time via SQL. Maybe a function similar to the fictitious
pg_stat
> "Merlin Moncure" <[EMAIL PROTECTED]> writes:
> > 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.
>
> The attached patch fixes the problem for me.
>
> regar
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> I have seen this failure several times, but not consistently, on the
> buildfarm member otter (Debian/MIPS) and possible on others, and am
> wondering if it indicates a possible race condition on DROP SCHEMA CASCADE.
Hard to see what, considering that
Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
Has anyone got any idea on why I see things like this from time to time?
It seems to be intermittent, which is odd.
I have a suspicion that the unexpected result occurs when the client
encoding is UTF8, because psql/mbprint.c's uc
Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
Has anyone got any idea on why I see things like this from time to time?
It seems to be intermittent, which is odd.
I have a suspicion that the unexpected result occurs when the client
encoding is UTF8,
In fact, I was
Greg Stark wrote:
Tom Lane <[EMAIL PROTECTED]> writes:
I've always felt that running a database across NFS was a Bad Idea ;-)
Well not that I disagree with that sentiment, but NFS was specifically
designed to handle this particular scenario. *UNLESS* you use the "soft"
option. As popular as it is,
> Andrew Dunstan <[EMAIL PROTECTED]> writes:
>> Has anyone got any idea on why I see things like this from time to time?
>> It seems to be intermittent, which is odd.
> I have a suspicion that the unexpected result occurs when the client
> encoding is UTF8,
In fact, I was able to duplicate the f
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> On Wed, Dec 15, 2004 at 05:20:28PM -0500, Andrew Dunstan wrote:
>> Our emails just crossed. You got it. I will have buildfarm force SQL_ASCII.
> But then you will lose reports using other encodings ...
"make check" forces C locale anyway. It's only th
Matthias Schmidt wrote:
> Hi Tom,
>
> after beeing offline because of a chrashed box, I able to mail again.
> I would like to volunteer for the uptime() function. Is that OK?
Sure.
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED] | (610) 3
"Merlin Moncure" <[EMAIL PROTECTED]> writes:
> Anyways, it would be nice to be able to use the sql row constructor to
> do equality/comparison...wouldn't get caught writing such silly sql
> statements :)
You mean like this?
regression=# select row(1,2,3) = row(1,2,3);
?column?
--
t
(1 r
Hi!
I'm using Postgresql on FreeBSD, and would like to get "order by" to work
with unicode. The OS does have collation implemented for unicode (UTF-8)
locales. Some freebsd people point me towards IBM:s ICU kit.
How much effort would be required to get postgresql to sort properly,
mainly using
Tom Lane wrote:
Alvaro Herrera <[EMAIL PROTECTED]> writes:
On Wed, Dec 15, 2004 at 05:20:28PM -0500, Andrew Dunstan wrote:
Our emails just crossed. You got it. I will have buildfarm force SQL_ASCII.
But then you will lose reports using other encodings ...
"make check" forces
On Wed, 2004-12-15 at 21:33 -0500, Andrew Dunstan wrote:
> Also, currently buildfarm just runs postgres' own test suites. I'm not
> averse to supporting a more extensive test suite just for farm members,
> if people think that's a good idea.
I think you'd get more mileage out of expanding the ex
> > > 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
> > defined by reference to the total number of dirty pages, and that can't
> > be known without collecting them all.
Zeugswetter Andreas DAZ SD <[EMAIL PROTECTED]> wrote on
15.12.2004, 11:39:44:
>
> > > > 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
> > > defined by reference t
> The two alternative algorithms are similar, but have these
> differences:
> The former (option (2)) finds a constant number of dirty pages, though
> has varying search time.
This has the disadvantage of converging against 0 dirty pages.
A system that has less than maxpages dirty will write eve
On Tue, Dec 14, 2004 at 09:22:42PM -0800, Joe Conway wrote:
> # pg_controldata /replica/pgdata
> Current log file ID: 0
> Next log file segment:1
> Latest checkpoint location: 0/9B0B8C
> Prior checkpoint location:0/9AA1B4
> Latest checkpoint'
Zeugswetter Andreas DAZ SD <[EMAIL PROTECTED]> wrote on
15.12.2004, 15:33:16:
>
> > The two alternative algorithms are similar, but have these
> > differences:
> > The former (option (2)) finds a constant number of dirty pages, though
> > has varying search time.
>
> This has the disadvantage o
Has anyone got any idea on why I see things like this from time to time?
It seems to be intermittent, which is odd.
You can see it on occasional ContribCheck failures on buildfarm.
cheers
andrew
= pgsql.2428/contrib/tsearch2/regression.diffs
===
*** ./expected/tse
Joe Conway <[EMAIL PROTECTED]> writes:
> Before running pg_resetxlog, a couple of questions:
> 1. Since it appears that pg_control is suspect, should I force it to be
> rebuilt, and if so, how?
pg_resetxlog will rebuild it in any case. However it will re-use the
existing contents as much as
Jan Wieck <[EMAIL PROTECTED]> writes:
> Still, we need to avoid scanning over all the clean blocks of a large
> buffer pool, so there is need for a separate dirty-LRU.
That's not happening, unless you want to undo the cntxDirty stuff,
with unknown implications for performance and deadlock safety.
Tom Lane wrote:
pg_resetxlog will rebuild it in any case. However it will re-use the
existing contents as much as it can (if you don't use any of the command
line options to override values). Given Alvaro's observation that the
existing file looks suspiciously close to a freshly-initdb'd one, I
d
On 12/15/2004 12:10 PM, Tom Lane wrote:
Jan Wieck <[EMAIL PROTECTED]> writes:
Still, we need to avoid scanning over all the clean blocks of a large
buffer pool, so there is need for a separate dirty-LRU.
That's not happening, unless you want to undo the cntxDirty stuff,
with unknown implications f
Jan,
> I too don't think that this approach will retain the checkpoing smooting
> effect, the current implementation has.
>
> The real problem is that the "cleaner" the buffer pool is, the longer
> the scan for dirty buffers will take because the dirty blocks tend to be
> at the very end of the sc
Folks,
> To allow DBT2 to be used for real bgwriter benchmarking, Mark would need to
> change the following:
>
> 1) Randomize the timing of the commits, so that sometimes there is only 30
> writes/minute, and other times there is 300. A timing pattern that would
> produce a "sine wave" with occa
Simon,
> Clearly, OSDL-DBT2 is not a real world test! That is its benefit, since
> it is heavily instrumented and we are able to re-run it many times
> without different parameter settings. The application is well known and
> doesn't suffer that badly from factors that would allow certain effects
"Merlin Moncure" <[EMAIL PROTECTED]> writes:
> 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.
The attached patch fixes the problem for me.
regards, tom lane
Hi Tom,
after beeing offline because of a chrashed box, I able to mail again.
I would like to volunteer for the uptime() function. Is that OK?
cheers,
Matthias
Am 13.12.2004 um 03:31 schrieb Bruce Momjian:
Matthias Schmidt wrote:
Am 07.12.2004 um 19:24 schrieb Tom Lane:
Matthias Schmidt <[EMAIL PR
Tom Lane wrote:
Yes, override everything there's a switch for. Also check that the
other values shown by pg_controldata look reasonable (the locale
settings are probably the only ones you might get burned on).
What if anything have you got in $PGDATA/pg_xlog?
-rw--- 1 postgres postgres 16777
I have seen this failure several times, but not consistently, on the
buildfarm member otter (Debian/MIPS) and possible on others, and am
wondering if it indicates a possible race condition on DROP SCHEMA CASCADE.
== pgsql.30167/src/test/regress/regression.diffs
=
On Wed, Dec 15, 2004 at 11:41:02AM -0800, Joe Conway wrote:
> Just wanted to close the loop for the sake of the list archives. With
> Tom's xlog dump tool I was able (with a bunch of his help off-list) to
> identify the needed parameters for pg_resetxlog. Running pg_resetxlog
> got us back a ru
Simon Riggs wrote:
100pct.patch (SR)
Test results to date:
1. Mark Kirkwood ([HACKERS] [Testperf-general] BufferSync and bgwriter)
pgbench 1xCPU 1xDisk shared_buffers=1
showed 8.0RC1 had regressed compared with 7.4.6, but patch improved
performance significantly against 8.0RC1
It occurs to
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> Has anyone got any idea on why I see things like this from time to time?
> It seems to be intermittent, which is odd.
I have a suspicion that the unexpected result occurs when the client
encoding is UTF8, because psql/mbprint.c's ucs_wcwidth() function
On Wed, Dec 15, 2004 at 05:20:28PM -0500, Andrew Dunstan wrote:
> Our emails just crossed. You got it. I will have buildfarm force SQL_ASCII.
But then you will lose reports using other encodings ...
--
Alvaro Herrera (<[EMAIL PROTECTED]>)
"Cuando mañana llegue pelearemos segun lo que mañana exi
Palle Girgensohn <[EMAIL PROTECTED]> writes:
> I'm using Postgresql on FreeBSD, and would like to get "order by" to work
> with unicode.
What makes you think it doesn't? Use the right locale and you're set.
regards, tom lane
---(end of broadcast)
--On onsdag, december 15, 2004 23.21.13 -0500 Tom Lane <[EMAIL PROTECTED]>
wrote:
Palle Girgensohn <[EMAIL PROTECTED]> writes:
I'm using Postgresql on FreeBSD, and would like to get "order by" to
work with unicode.
What makes you think it doesn't? Use the right locale and you're set.
Not on Fre
46 matches
Mail list logo
