Tatsuo Ishii <[EMAIL PROTECTED]> wrote:
> For me the idea that a text-search configuration maps to a
> locale/language seems to be totally wrong. IMO an encoding/charset
> could include several languages and a text-search configuration should
> be mapped to an encoding/charset, rather than a lang
> 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 North-Ame
> 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 configu
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
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 PostgreS
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 that
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 n
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 betwe
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
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
http://www.po
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 i
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 -L../../../..
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
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. T
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
thi
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 -lshfolder
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 generat
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 Herrerahttp://www.CommandPrompt.co
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 transa
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
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
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
> > >
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 re
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 my
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 doi
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,
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
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 defin
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 s
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'
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 tw
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 'EX
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 n
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
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
exac
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' >> libpgtyp
[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
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 n
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 d
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
interfaces/ecpg/pgtype
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
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' >> libpgtyp
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
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 h
"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 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
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
- log
"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 w
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
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 (n
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' >> libpgt
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
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
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, 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));
INSE
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 singl
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 v
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
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. Don't
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
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]
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 proble
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, Mic
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
* 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 a
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
s/Teodor0/T
67 matches
Mail list logo
