On Tue, Oct 02, 2007 at 09:07:54PM -0400, Alvaro Herrera wrote:
Decibel! wrote:
Hrm... what about adding output to vacuum verbose that indicates how many
pages in a relation have free space? That would allow something like
pgfouine to see how many FSM pages were needed. It would
Hi,
On 10/4/07, Tom Lane [EMAIL PROTECTED] wrote:
At this point the bulk of the work is done, except for SGML markup
prettification.
There is a typo in the contrib part:
# Add GIN support for hstore (Guillaume Smet, Teodor)
# Add GIN support for pg_trgm (Guillaume Smet, Teodor0
* Tom Lane:
I ran into an interesting failure here on HPPA: the code the compiler
generated for copying unaligned toast pointers into aligned local
variables failed, because it was assuming halfword (2-byte) alignment of
the data to be copied! (Instead of a memcpy call it was generating an
On Thu, 2007-10-04 at 09:04 +0200, Guillaume Smet wrote:
There is a typo in the contrib part:
# Add GIN support for hstore (Guillaume Smet, Teodor)
# Add GIN support for pg_trgm (Guillaume Smet, Teodor0
s/Teodor0/Teodor)/
And I didn't participate to the GIN support of hstore, I just added
On Thu, Oct 04, 2007 at 12:47:13AM -0400, Tom Lane wrote:
Buildfarm member brown_bat (cygwin/gcc) still isn't happy:
...
Just committed a patch that hopefully solves this. Kind of surprises me
that this only occurs on cygwin.
Michael
--
Michael Meskes
Email: Michael at Fam-Meskes dot De,
Alvaro Herrera wrote:
I came up with the following patch. What this does is cancel any
ANALYZE started by autovacuum, at the top of ALTER TABLE.
There's a small race condition, autoanalyze could start between the
calls autovac_cancel_analyze and relation_open.
And it doesn't solve the problem
Alvaro,
On 10/4/07, Alvaro Herrera [EMAIL PROTECTED] wrote:
I came up with the following patch. What this does is cancel any
ANALYZE started by autovacuum, at the top of ALTER TABLE.
It doesn't seem to work for me. I still have my ALTER TABLEs waiting:
\_ postgres: postgres cityvox [local]
Michael Meskes wrote:
On Thu, Oct 04, 2007 at 12:47:13AM -0400, Tom Lane wrote:
Buildfarm member brown_bat (cygwin/gcc) still isn't happy:
...
Just committed a patch that hopefully solves this. Kind of surprises me
that this only occurs on cygwin.
It's still not working.
Guillaume Smet escribió:
Alvaro,
On 10/4/07, Alvaro Herrera [EMAIL PROTECTED] wrote:
I came up with the following patch. What this does is cancel any
ANALYZE started by autovacuum, at the top of ALTER TABLE.
It doesn't seem to work for me. I still have my ALTER TABLEs waiting:
\_
There's been a lively discussion on JDBC list recently about how we
handle connection pooling. This has connected a few thoughts in my head.
That's made me think about the PHP interface, which issues a
BEGIN; ROLLBACK;
pair every time somebody connects to the pool.
We should have a
Andrew Dunstan wrote:
Michael Meskes wrote:
On Thu, Oct 04, 2007 at 12:47:13AM -0400, Tom Lane wrote:
Buildfarm member brown_bat (cygwin/gcc) still isn't happy:
...
Just committed a patch that hopefully solves this. Kind of surprises me
that this only occurs on cygwin.
It's
Stephan Szabo wrote:
On Tue, 2 Oct 2007, Jeff Frost wrote:
I expected these numbers to be in sync, but was suprised to see that the
sequence skips a values after every generate series.
CREATE TABLE jefftest ( id serial, num int );
INSERT INTO jefftest (num) values (generate_series(1,10));
Andrew Dunstan [EMAIL PROTECTED] writes:
It's still not working. Don't have time right now to diagnose why.
For now, since Michael doesn't have a windows machine to play with, I
have switched brown_bat's schedule so it runs HEAD 6 times a day (not
exactly every 4 hours, the intervals vary
On Thu, Oct 04, 2007 at 10:04:41AM -0400, Alvaro Herrera wrote:
It looks like dlltool does not like the .def file:
...
Line 3 of that file is unadorned EXPORTS:
echo '; DEF file for MS VC++' libpgtypesdll.def
echo 'LIBRARY LIBPGTYPES' libpgtypesdll.def
echo 'EXPORTS' libpgtypesdll.def
Shane Ambler wrote:
Stephan Szabo wrote:
On Tue, 2 Oct 2007, Jeff Frost wrote:
I expected these numbers to be in sync, but was suprised to see that the
sequence skips a values after every generate series.
CREATE TABLE jefftest ( id serial, num int );
INSERT INTO jefftest (num) values
On Thu, 2007-10-04 at 10:29 -0400, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
As committed, DISCARD ALL does everything but cannot be issued inside a
transaction block.
I'd like to propose that DISCARD ALL also issue a ROLLBACK command if it
is issued from within a
Tom Lane [EMAIL PROTECTED] writes:
The PGBuildfarm member dugong had the following event on branch HEAD:
Status changed from OK to ContribCheck failure
The snapshot timestamp for the build that triggered this notification is:
2007-09-25 20:05:01
This seems to be exactly what we saw two
On Tue, 2007-10-02 at 11:17 -0400, Tom Lane wrote:
In any case, this would still only fix things for pg_restore, and I
remain concerned that people will gripe about autovacuum blocking
locks. The idea of kicking autovac off tables remains probably more
interesting in the long run.
Yes,
Simon Riggs [EMAIL PROTECTED] writes:
As committed, DISCARD ALL does everything but cannot be issued inside a
transaction block.
I'd like to propose that DISCARD ALL also issue a ROLLBACK command if it
is issued from within a transaction block.
That was *intentional* to prevent mistakes.
Simon Riggs [EMAIL PROTECTED] writes:
I'd also like to see vacuum_delay_point() do a test against
CountActiveBackends() to see if anything else is running. If there all
non-autovac processes are idle or waiting, then we should skip the delay
point, this time only. That way a VACUUM can go at
Hi,
I am engaged in a master degree project and i need the answer to the following
question:
How much time the EXECUTOR of PostgreSQL spent during a determined time
interval?
My Scenario is like this:
PostgreSQL 7.4 with the following parameters:
- log_duration = true
- log_pid = true
-
On Thu, 2007-10-04 at 10:43 -0400, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
I'd also like to see vacuum_delay_point() do a test against
CountActiveBackends() to see if anything else is running. If there all
non-autovac processes are idle or waiting, then we should skip the
Alvaro Herrera [EMAIL PROTECTED] writes:
Hmm, it looks like the race condition Heikki mentioned is the culprit.
We need a way to stop future analyzes from starting. Back to the
drawing board ...
A crazy idea I just had -- what if you roll this into the deadlock check? So
after waiting on the
On Thu, 2007-10-04 at 16:07 +0100, Gregory Stark wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
Hmm, it looks like the race condition Heikki mentioned is the culprit.
We need a way to stop future analyzes from starting. Back to the
drawing board ...
A crazy idea I just had -- what if
Alvaro Herrera [EMAIL PROTECTED] writes:
Shane Ambler wrote:
CREATE TABLE jefftest ( id serial, num int );
INSERT INTO jefftest (num) values (generate_series(1,10));
INSERT INTO jefftest (num) values (generate_series(11,20));
INSERT INTO jefftest (num) values (generate_series(21,30));
Don't
Michael Meskes wrote:
On Thu, Oct 04, 2007 at 10:04:41AM -0400, Alvaro Herrera wrote:
It looks like dlltool does not like the .def file:
...
Line 3 of that file is unadorned EXPORTS:
echo '; DEF file for MS VC++' libpgtypesdll.def
echo 'LIBRARY LIBPGTYPES' libpgtypesdll.def
echo
Gregory Stark wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
Hmm, it looks like the race condition Heikki mentioned is the culprit.
We need a way to stop future analyzes from starting. Back to the
drawing board ...
A crazy idea I just had -- what if you roll this into the deadlock
Camilo,
My Scenario is like this:
PostgreSQL 7.4 with the following parameters:
If you're testing performance, why are you using a 4-year-old version of
PostgreSQL?
--
Josh Berkus
PostgreSQL @ Sun
San Francisco
---(end of broadcast)---
TIP
Alvaro Herrera [EMAIL PROTECTED] writes:
Michael Meskes wrote:
These lines are simply copied from libpq/Makefile but ddltool does not
complain while working on libpq. Any idea where they differ?
Newline style perhaps?
There seems to be a blank line at the end of
Hello
I am working on subj. There are two variants:
a) simple C wrapper which can be SQL compatible .. with this wrapper
we don't need any changes in dump files .. but I thinking it's
impossible, because there are conflicts between functio'n names and
table's names.
b) simple SQL wrapper - it
[Camilo Porto]
From: [EMAIL PROTECTED]
To: pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] What does 'elapsed' exact means in PostgreSQL Log
Statistics
Date: Thu, 4 Oct 2007 08:43:24 -0700
CC: [EMAIL PROTECTED]
Camilo,
My Scenario is like this:
PostgreSQL 7.4 with the
Michael Meskes wrote:
On Thu, Oct 04, 2007 at 10:04:41AM -0400, Alvaro Herrera wrote:
It looks like dlltool does not like the .def file:
...
Line 3 of that file is unadorned EXPORTS:
echo '; DEF file for MS VC++' libpgtypesdll.def
echo 'LIBRARY LIBPGTYPES' libpgtypesdll.def
echo
On Thu, 4 Oct 2007, Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
It's still not working. Don't have time right now to diagnose why.
For now, since Michael doesn't have a windows machine to play with, I
have switched brown_bat's schedule so it runs HEAD 6 times a day (not
Gregory Stark escribió:
Alvaro Herrera [EMAIL PROTECTED] writes:
Hmm, it looks like the race condition Heikki mentioned is the culprit.
We need a way to stop future analyzes from starting. Back to the
drawing board ...
A crazy idea I just had -- what if you roll this into the deadlock
Alvaro Herrera [EMAIL PROTECTED] writes:
Gregory Stark escribió:
A crazy idea I just had -- what if you roll this into the deadlock check? So
after waiting on the lock for 1s it wakes up, finds that the holder it's
waiting on is an autovacuum process and cancels it instead of finding no
Michael Meskes wrote:
On Thu, Oct 04, 2007 at 10:04:41AM -0400, Alvaro Herrera wrote:
It looks like dlltool does not like the .def file:
...
Line 3 of that file is unadorned EXPORTS:
echo '; DEF file for MS VC++' libpgtypesdll.def
echo 'LIBRARY LIBPGTYPES' libpgtypesdll.def
echo
On Thu, Oct 04, 2007 at 12:35:29PM -0400, Alvaro Herrera wrote:
The libpq exports.txt has spaces, not tabs, as separators. In fact, if
you see the .def files you notice that the generated files for ecpg are
all wrong.
Right, that's it.
Simplest is to change tabs to spaces ... However I'm
Gregory Stark [EMAIL PROTECTED] writes:
Tom Lane [EMAIL PROTECTED] writes:
This seems to be exactly what we saw two weeks ago, and I just noticed
that in the JIT bgwriter patch, I put an Assert into ForwardFsyncRequest
in exactly the place where one was removed to make icc happy two weeks
Michael Meskes [EMAIL PROTECTED] writes:
On Thu, Oct 04, 2007 at 12:35:29PM -0400, Alvaro Herrera wrote:
The libpq exports.txt has spaces, not tabs, as separators. In fact, if
you see the .def files you notice that the generated files for ecpg are
all wrong.
Right, that's it.
I see that
Tom Lane escribió:
Alvaro Herrera [EMAIL PROTECTED] writes:
Gregory Stark escribi�:
A crazy idea I just had -- what if you roll this into the deadlock check?
So
after waiting on the lock for 1s it wakes up, finds that the holder it's
waiting on is an autovacuum process and cancels it
On Thu, 2007-10-04 at 14:33 -0400, Alvaro Herrera wrote:
Tom Lane escribió:
Alvaro Herrera [EMAIL PROTECTED] writes:
Gregory Stark escribi:
A crazy idea I just had -- what if you roll this into the deadlock
check? So
after waiting on the lock for 1s it wakes up, finds that the
Andrew Dunstan [EMAIL PROTECTED] writes:
One thing I noticed is this:
ifneq ($(PORTNAME), win32)
OBJS += thread.o
DLL_DEFFILE=libecpgdll.def
endif
Why are we defining DLL_DEFFILE for the non-win32 case but not for the
win32 case?
Comparing to the libpq Makefile, this seems definitely
Alvaro Herrera [EMAIL PROTECTED] writes:
I am totally uninclined to mess with this stuff. I am barely aware of
what exactly is it doing; I don't have the slightest idea how to modify
it to cancel autovacs. Furthermore it sounds very much like a layering
violation (what is deadlock.c doing
I noticed that if you create a dump on a database containing a money
column and a certain locale, this dump is not restorable on a database
with a different locale.
Most notably, I tried dumping the regression database (which is created
with --locale=C), and then importing it into a database of
Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
I noticed that if you create a dump on a database containing a money
column and a certain locale, this dump is not restorable on a database
with a different locale.
We've been through this, no?
Hmm, true. I even replied to the
Alvaro Herrera [EMAIL PROTECTED] writes:
I noticed that if you create a dump on a database containing a money
column and a certain locale, this dump is not restorable on a database
with a different locale.
We've been through this, no? If money doesn't print that way, there's
no obvious reason
On Thu, 2007-10-04 at 19:40 +0100, Simon Riggs wrote:
On Thu, 2007-10-04 at 14:33 -0400, Alvaro Herrera wrote:
Tom Lane escribió:
Alvaro Herrera [EMAIL PROTECTED] writes:
Gregory Stark escribi:
A crazy idea I just had -- what if you roll this into the deadlock
check? So
On Thu, 2007-10-04 at 13:03 -0700, Neil Conway wrote:
On Thu, 2007-10-04 at 15:50 +0100, Simon Riggs wrote:
On Thu, 2007-10-04 at 10:29 -0400, Tom Lane wrote:
Somebody who wants the
above behavior can send ROLLBACK; DISCARD ALL.
...which generates an ERROR if no transaction is in
On Thu, 2007-10-04 at 15:50 +0100, Simon Riggs wrote:
On Thu, 2007-10-04 at 10:29 -0400, Tom Lane wrote:
Somebody who wants the
above behavior can send ROLLBACK; DISCARD ALL.
...which generates an ERROR if no transaction is in progress and fills
the log needlessly.
Well, it's a WARNING,
Simon Riggs wrote:
On Thu, 2007-10-04 at 13:03 -0700, Neil Conway wrote:
On Thu, 2007-10-04 at 15:50 +0100, Simon Riggs wrote:
On Thu, 2007-10-04 at 10:29 -0400, Tom Lane wrote:
Somebody who wants the
above behavior can send ROLLBACK; DISCARD ALL.
...which
Simon Riggs wrote:
This is making me think that we should just embed the session pool
inside the server as well and have done with it.
You mean prefork? That would be neat. I don't think it's all that
impossible.
--
Alvaro Herrera
Andrew Dunstan [EMAIL PROTECTED] writes:
Could we maybe have some flavor of ROLLBACK that doesn't issue a warning
if no transaction is in progress? There is precedent for this sort of
facility - DROP ... IF EXISTS.
Something that would actually be doable for 8.3 would be to downgrade
this
dllwrap -o libecpg.dll --dllname libecpg.dll --def libecpgdll.def execute.o typename.o descriptor.o data.o error.o prepare.o memory.o connect.o misc.o path.o strlcpy.o snprintf.o -L../pgtypeslib -L../../../../src/interfaces/libpq -L../../../../src/port -L/mingw/lib -lpgtypes -lpq -lm
Andrew Dunstan [EMAIL PROTECTED] writes:
dllwrap -o libecpg.dll --dllname libecpg.dll --def libecpgdll.def execute.o
typename.o descriptor.o data.o error.o prepare.o memory.o connect.o misc.o
path.o strlcpy.o snprintf.o -L../pgtypeslib
-L../../../../src/interfaces/libpq
This business with having libpq and ecpg pull in src/port modules
manually is getting unmaintainable. I wonder whether we could persuade
src/port to generate three versions of libpgport.a --- backend,
frontend, and frontend-shlib-ready --- and then just -l the appropriate
one in libpq and ecpg.
Simon Riggs escribió:
Seems like we don't need to mess with the deadlock checker itself.
We can rely on the process at the head of the lock wait queue to sort
this out for us. So all we need do is look at the isAutovacuum flag on
the process that is holding the lock we're waiting on. If it
Tom Lane wrote:
This business with having libpq and ecpg pull in src/port modules
manually is getting unmaintainable. I wonder whether we could persuade
src/port to generate three versions of libpgport.a --- backend,
frontend, and frontend-shlib-ready --- and then just -l the appropriate
one
Hi all
I wonder if there is a PostgreSQL code documentation that may help in
understanding the code.
Regards
Islam Hegazy
---(end of broadcast)---
TIP 7: You can help support the PostgreSQL project by donating at
Islam Hegazy escribió:
Hi all
I wonder if there is a PostgreSQL code documentation that may help in
understanding the code.
Yes. There is the developer's FAQ, then there is the internals
chapter in the official docs, then there's the various README's
sprinkled throughout the code, and
On Thursday 04 October 2007 11:52, Pavel Stehule wrote:
Hello
I am working on subj. There are two variants:
a) simple C wrapper which can be SQL compatible .. with this wrapper
we don't need any changes in dump files .. but I thinking it's
impossible, because there are conflicts between
Robert Treat [EMAIL PROTECTED] writes:
On Thursday 04 October 2007 11:52, Pavel Stehule wrote:
a) simple C wrapper which can be SQL compatible .. with this wrapper
we don't need any changes in dump files .. but I thinking it's
impossible, because there are conflicts between functio'n names and
When I run initdb -E EUC_JP --no-locale, I found following in my
postgresql.conf:
default_text_search_config = 'pg_catalog.english'
The manual says:
default_text_search_config (string)
Selects the text search configuration that is used by those
variants of the text search functions
Also Doxygen docs are greatly help. You can generate them yourself for the
latest or obtain them from doxygen.postgresql.org. I found doxygen and the FAQ
internals to be most useful.
Alvaro Herrera [EMAIL PROTECTED] wrote: Islam Hegazy escribi�:
Hi all
I wonder if there is a PostgreSQL
Tatsuo Ishii [EMAIL PROTECTED] writes:
When I run initdb -E EUC_JP --no-locale, I found following in my
postgresql.conf:
default_text_search_config = 'pg_catalog.english'
The manual says:
default_text_search_config (string)
Selects the text search configuration that is used by those
Tatsuo Ishii [EMAIL PROTECTED] writes:
When I run initdb -E EUC_JP --no-locale, I found following in my
postgresql.conf:
default_text_search_config = 'pg_catalog.english'
The manual says:
default_text_search_config (string)
Selects the text search configuration that is
Tatsuo Ishii [EMAIL PROTECTED] writes:
Well, that documentation is correct as far as it goes; what it doesn't
say is that initdb's mapping table explicitly maps C/POSIX locales to
english. It seems like a reasonable default on this side of the water,
but maybe I'm being too
Tatsuo Ishii [EMAIL PROTECTED] writes:
Well, that documentation is correct as far as it goes; what it doesn't
say is that initdb's mapping table explicitly maps C/POSIX locales to
english. It seems like a reasonable default on this side of the water,
but maybe I'm being too
67 matches
Mail list logo
