Sorry folks, my fault ... hit the 'accept' button too fast :(
On Sat, 17 Jun 2006, Wilbur wrote:
Hi there lovely,
I was asearching the net few days ago. I am new to this thing.
and saw your profible. I decided to email you cause I found
you attractive. I maight come down to youra city in fewb
On Sun, Jun 18, 2006 at 11:07:41PM -0400, Tom Lane wrote:
> "Bort, Paul" <[EMAIL PROTECTED]> writes:
> >> Anyone know a variant of this that really works?
>
> > Here's a theory: If the counter is bumped to an odd number before
> > modification, and an even number after it's done, then the reader w
On Sun, Jun 18, 2006 at 05:26:16PM -0400, Tom Lane wrote:
> I wrote:
> > PFC <[EMAIL PROTECTED]> writes:
> >> So, the proposal :
> >> On executing a command, Backend stores the command string, then
> >> overwrites the counter with (counter + 1) and with the timestamp of
> >> command start.
> >>
Hi there lovely,
I was asearching the net few days ago. I am new to this thing.
and saw your profible. I decided to email you cause I found
you attractive. I maight come down to youra city in fewb weeks.
Let me know if we can meet each other in person.
I am attractive girl. I am surea you won't re
"Tom Lane" <[EMAIL PROTECTED]> wrote
>
> "postgres --single" works for me. Maybe you need a "make
> distclean"/rebuild?
>
Sorry, because I forget to say that you need to turn "stats_command_string"
on. When it is off, pgstat_report_activity() will return immediately so
nothing wrong could be obs
"Qingqing Zhou" <[EMAIL PROTECTED]> writes:
> Ooops, guess we forget to handle the single user mode in "current-status
> information in shared memory" patch ...
"postgres --single" works for me. Maybe you need a "make
distclean"/rebuild?
regards, tom lane
---
On CVS tip:
$ postgres --single -Ddata postgres
PostgreSQL stand-alone backend 8.2devel
Segmentation fault (core dumped)
$ gdb -c core.18119
(gdb) bt
#0 pgstat_report_activity (cmd_str=0x67d25e "") at pgstat.c:1484
1484beentry->st_changecount++;
(gdb) bt
#0 pgstat_report_activity (
Sorry I am traveling for EnterpriseDB Wednesday and Thursday so I can't
run the tests right now.
Seeing stats_command_string with almost zero overhead is great news!
Should we remove that setting and just have it enabled all
the time?
As far as pg_stat_activity.query_start, I never suspected tha
Clinging to sanity, [EMAIL PROTECTED] ("Mark Woodward") mumbled into her beard:
> We all know that PostgreSQL suffers performance problems when rows are
> updated frequently prior to a vacuum. The most serious example can be seen
> by using PostgreSQL as a session handler for a busy we site. You ma
Tom Lane said:
> "Dave Page" writes:
>> Yeah - I've been seeing both issues though - Tom's one where it
>> complains that postgres.exe doesn't exist then bombs out of initdb (it
>> does exist btw), and the one above where make check hangs and I end up
>> killing it off.
>
> OK, now that Yoshiyuki-
On Wed, Jun 21, 2006 at 01:21:11PM +0200, Peter Eisentraut wrote:
> Am Mittwoch, 21. Juni 2006 09:32 schrieb John Jawed:
> > Below are links for the patch and binary (image) files for
> > argument handling improvements in ppa. You can view the original
> > concept @ http://jawed.name/pgsql_soc. It
"Dave Page" writes:
> Yeah - I've been seeing both issues though - Tom's one where it
> complains that postgres.exe doesn't exist then bombs out of initdb (it
> does exist btw), and the one above where make check hangs and I end up
> killing it off.
OK, now that Yoshiyuki-san found my silly error
Yoshiyuki Asaba <[EMAIL PROTECTED]> writes:
> cancelConnLock is not initialized (InitializeCriticalSection()) at
> startup.c when psql execute with '-c' option.
Doh! My fault.
> Is the following patch right?
I think we should just move the setup_cancel_handler call up earlier in
startup.c.
> > The installer for 8.1 will let you pick UNICODE encoding
> during setup.
>
> What if he uses initdb directly?
Then it should be a simple "-E UNICODE", just as on unix.
//Magnus
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
Magnus Hagander wrote:
> > > Is there any way to select the UTF-8 as server-side
> > encoding at initdb
> > > time?
> >
> > > This guy reported he wasn't able to do it:
> > >
> > http://archives.postgresql.org/pgsql-hackers-win32/2004-11/msg00062.ph
> > > p
> >
> > That was 8.0. My recollecti
> > Is there any way to select the UTF-8 as server-side
> encoding at initdb
> > time?
>
> > This guy reported he wasn't able to do it:
> >
> http://archives.postgresql.org/pgsql-hackers-win32/2004-11/msg00062.ph
> > p
>
> That was 8.0. My recollection is we fixed it for 8.1. You
> might ha
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Having said that, this may well expose a bug in the MAX-optimization
>> code that has consequences for more useful queries. I'll take a look
>> later today if no one beats me to it.
> I refrain -- tried following it but I don't know
Hi,
From: "Dave Page"
Subject: Re: [HACKERS] CVS HEAD busted on Windows?
Date: Wed, 21 Jun 2006 15:39:34 +0100
>
>
> > -Original Message-
> > From: Tom Lane [mailto:[EMAIL PROTECTED]
> > Sent: 21 June 2006 14:30
> > To: Dave Page
> > Cc: Peter Eisentraut; pgsql-hackers@postgresql.or
We all know that PostgreSQL suffers performance problems when rows are
updated frequently prior to a vacuum. The most serious example can be seen
by using PostgreSQL as a session handler for a busy we site. You may have
thousands or millions of active sessions, each being updated per page hit.
Eac
Greg Stark <[EMAIL PROTECTED]> writes:
>> Can anyone else reproduce this slowdown? It might be only an artifact
>> of these particular builds, but it's a bit too consistent in my x86 data
>> to just ignore.
> You don't perchance have ON_ERROR_ROLLBACK on do you? I did when I tried
> testing it an
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Is there any way to select the UTF-8 as server-side encoding at initdb
> time?
> This guy reported he wasn't able to do it:
> http://archives.postgresql.org/pgsql-hackers-win32/2004-11/msg00062.php
That was 8.0. My recollection is we fixed it for 8.1.
> The bad news is that except in the stats_command_string cases, HEAD
> is noticeably slower than 8.1 on the machine with slow gettimeofday.
> In the single-transaction test this might be blamed on the addition
> of statement_timestamp support (which requires a gettimeofday per
> statement that wa
Is there any way to select the UTF-8 as server-side encoding at initdb
time?
This guy reported he wasn't able to do it:
http://archives.postgresql.org/pgsql-hackers-win32/2004-11/msg00062.php
In pgsql-es-ayuda I have a guy asking how to do it as well:
http://archives.postgresql.org/pgsql-es-ayu
I wrote:
> BTW, according to "top" the CPU usage percentages in these tests are
> on the order of 55% backend, 45% psql. Methinks psql needs a round
> of performance tuning ...
oprofile tells the tale:
CPU: P4 / Xeon with 2 hyper-threads, speed 2793.03 MHz (estimated)
Counted GLOBAL_POWER_EVENTS
"Dave Page" writes:
>> Well, that's pretty clearly a null pointer dereference. Any chance of
>> mapping the instruction address back to something useful?
> Not sure how I would do that. Any hints?
gdb might produce something useful, with something like
x/32i 0x - 16
Failin
> -Original Message-
> From: Tom Lane [mailto:[EMAIL PROTECTED]
> Sent: 21 June 2006 16:08
> To: Dave Page
> Cc: Peter Eisentraut; pgsql-hackers@postgresql.org
> Subject: Re: [HACKERS] CVS HEAD busted on Windows?
>
> "Dave Page" writes:
> > Hmmm, running it more interactively I see w
Tom Lane wrote:
This being a psql-side crash, it couldn't be related to the symptom
we saw before of initdb not finding postgres.exe. I'm starting to
wonder if maybe that machine has suddenly developed an intermittent
memory fault or some such. Have you noticed any other flaky behavior?
I
"Dave Page" writes:
> Hmmm, running it more interactively I see what was probably the hang
> when run from the scheduler:
> ---
> psql.exe - Application Error
> ---
> The instruction at "0x7c8396d0" referenced memory at "0x0014". The
> memory co
I redid my previous measurements after finishing up the weekend's
hacking. The numbers shown below are elapsed time in seconds for
time psql -f testfile.sql postgres >/dev/null
using CVS HEAD and REL8_1_STABLE branch tip, compiled --enable-debug
--disable-cassert, no nondefault options e
> -Original Message-
> From: Tom Lane [mailto:[EMAIL PROTECTED]
> Sent: 21 June 2006 14:30
> To: Dave Page
> Cc: Peter Eisentraut; pgsql-hackers@postgresql.org
> Subject: Re: [HACKERS] CVS HEAD busted on Windows?
>
> "Dave Page" writes:
> > killed it this morning (after 6+ hours of r
"Dave Page" writes:
> killed it this morning (after 6+ hours of runtime) and it reported:
> pg_regress: could not set database default locales
That would be here:
"$bindir/psql" -q -X $psql_options -c "\
alter database \"$dbname\" set lc_messages to 'C';
alter database \"$dbname\" set lc_monetar
Am Mittwoch, 21. Juni 2006 09:32 schrieb John Jawed:
> Below are links for the patch and binary (image) files for argument
> handling improvements in ppa. You can view the original concept @
> http://jawed.name/pgsql_soc. It provides support for both JS and JS
> deficient users.
I think you are wr
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Dave Page
> Sent: 20 June 2006 09:10
> To: Tom Lane; Peter Eisentraut; pgsql-hackers@postgresql.org
> Subject: Re: [HACKERS] CVS HEAD busted on Windows?
>
> As I'm currently running all three builds
unsubscribe
---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings
ubsubscribe
---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings
Below are links for the patch and binary (image) files for argument
handling improvements in ppa. You can view the original concept @
http://jawed.name/pgsql_soc. It provides support for both JS and JS
deficient users.
I tried to keep it within the coding guidelines set forth.
I appreciate and l
36 matches
Mail list logo
