Check http://www.sai.msu.su/~megera/postgres/gist/tsearch/V2/
Oleg
On Wed, 3 Mar 2004, [gb2312] wrote:
hi all
Are there any other docs about tsearch2 except for the 3 docs in
\contrib\tsearch2\docs
i want some tech docs on tsearch2 thank all---(end of
Gavin Sherry wrote:
I'm going to focus on implementing this on the system(s) I'm used to
developing on (ie, those which support symlinks). Once that is done, I'll
talk with the Win32 guys about what, if anything, we can do about getting
this to work on Win32 (and possibly other non-symlink
Bruce Momjian writes:
I just checked from the MinGW console and I see:
[snip]
It accepts ln -s, but does nothing with it.
And even if it had worked, it wouldn't really matter, since we don't
actually want to *run* the system under MinGW/msys, just build it.
I think the idea of implementing
Bruce Momjian said:
Andrew Dunstan wrote:
I haven't had any other feedback on this patch that I posted. However,
I'm a bit dissatisfied with it for a couple of reasons:
. when a connection is logged we don't yet know the user and database,
because we haven't processed the initial packet
For tablespaces on OS's that don't support it, I think we will have to
store the path name in the file and read it via the backend. Somehow we
should cache those lookups.
My feeling is that we need not support tablespaces on OS's without
symlinks.
To create symlinked directories
On Wed, 2004-03-03 at 04:59, Tom Lane wrote:
What might make sense is some sort of marker file in a
tablespace directory that links back to the owning $PGDATA directory.
CREATE TABLESPACE should create this, or reject if it already exists.
It will not be enough for the marker to list the
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Tom Lane wrote:
My feeling is that we need not support tablespaces on OS's without
symlinks.
Agreed, but are we going to support non-tablespace installs? I wasn't
sure that was an option.
A setup containing only the default
Claudio Natoli wrote:
Bruce Momjian writes:
I just checked from the MinGW console and I see:
[snip]
It accepts ln -s, but does nothing with it.
And even if it had worked, it wouldn't really matter, since we don't
actually want to *run* the system under MinGW/msys, just build it.
I
Should I add this to the TODO list?
---
Lee Kindness wrote:
Sort of related, I was thinking about adding some more thread-related
code such that if a connection wasn't explicitely specified then the
last connection SET
I just checked from the MinGW console and I see:
[snip]
It accepts ln -s, but does nothing with it.
And even if it had worked, it wouldn't really matter, since
we don't
actually want to *run* the system under MinGW/msys, just build it.
I think the idea of implementing in
Oh.. By all means..Please do..
The reason I posted it because I didn't wanted to work on it if core is not
going to accept it on account of non-compliance with spec.
Is this fine?
* Allow a 'connection *' pointer to be specified instead of a string to denote
a connection.
I plan to work on
Zeugswetter Andreas SB SD [EMAIL PROTECTED] writes:
My feeling is that we need not support tablespaces on OS's without
symlinks.
To create symlinked directories on Win2k NTFS see:
http://www.sysinternals.com/ntw2k/source/misc.shtml#junction
I think Win2000 or XP would be a reasonable
Oliver Elphick [EMAIL PROTECTED] writes:
It will not be enough for the marker to list the path of the parent
$PGDATA, since that path might get changed by system administration
action. The marker should contain some sort of unique string which
would match the same string somewhere in $PGDATA.
Shridhar Daithankar [EMAIL PROTECTED] writes:
The reason I posted it because I didn't wanted to work on it if core is not
going to accept it on account of non-compliance with spec.
When it comes to ecpg, Michael Meskes is the man you have to convince,
not any of the core committee.
Zeugswetter Andreas SB SD wrote:
To create symlinked directories on Win2k NTFS see:
http://www.sysinternals.com/ntw2k/source/misc.shtml#junction
I don't think we could use this s/w though, unless the author is
prepared to relicense it. I'm sure implementing a clean room version of
To create symlinked directories on Win2k NTFS see:
http://www.sysinternals.com/ntw2k/source/misc.shtml#junction
I don't think we could use this s/w though, unless the author is
prepared to relicense it. I'm sure implementing a clean room
version of
the relevant parts
Tom,
with the since 7.4 deprecated copy support functions in libpq, is there
any define or other way to figure out if compiling against a pre-7.4 or
post-7.4 libpq?
Jan
--
#==#
# It's easier to get forgiveness for being wrong
Jan Wieck [EMAIL PROTECTED] writes:
with the since 7.4 deprecated copy support functions in libpq, is there
any define or other way to figure out if compiling against a pre-7.4 or
post-7.4 libpq?
Hm, don't think so. If you've autoconfiscated your client code, you can
just put in a configure
Bruce Momjian [EMAIL PROTECTED] writes:
Greg Stark wrote:
I am expecting to hear some bleating about this from people whose
preferred platforms don't support symlinks ;-). However, if we don't
Well, one option would be to have the low level filesystem storage (md.c?)
routines
Tom Lane wrote:
Shridhar Daithankar [EMAIL PROTECTED] writes:
The reason I posted it because I didn't wanted to work on it if core is not
going to accept it on account of non-compliance with spec.
When it comes to ecpg, Michael Meskes is the man you have to convince,
not any of the core
Andrew Dunstan wrote:
defaulting to the beginning if not found.
Examples: %T [%P]: (everybody gets timestamp and pid)
%T [%P]: [EMAIL PROTECTED](%C:%S %I line:%L %X%T [%P]: (same
effect
as example under previous point)
- something else I haven't
Greg Stark wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Greg Stark wrote:
I am expecting to hear some bleating about this from people whose
preferred platforms don't support symlinks ;-). However, if we don't
Well, one option would be to have the low level filesystem
Oliver Elphick wrote:
On Wed, 2004-03-03 at 04:59, Tom Lane wrote:
What might make sense is some sort of marker file in a
tablespace directory that links back to the owning $PGDATA directory.
CREATE TABLESPACE should create this, or reject if it already exists.
It will not be enough for the
Jan Wieck [EMAIL PROTECTED] writes:
the point is that PostgreSQL is no GNU product, never has been and if someone
intends to he shall do so after yanking out the contributions I made.
Note that when you released your contributions you did so under a license that
imposed no such conditions. If
Greg Stark wrote:
imposed no such conditions. If Microsoft wanted to release a Microsoft
Postgresql under a completely proprietary license they would be free
to do
I have often wondered, in a completely off-topic and unproductive sort
of way, if exactly that has not already been done by an
Merlin Moncure [EMAIL PROTECTED] wrote:
Greg Stark wrote:
imposed no such conditions. If Microsoft wanted to release a
Microsoft Postgresql under a completely proprietary license they
would be free
to do
I have often wondered, in a completely off-topic and unproductive sort
of way, if exactly
Tom Lane [mailto:[EMAIL PROTECTED]
Joe Conway [EMAIL PROTECTED] writes:
Tom Lane wrote:
Joe Conway [EMAIL PROTECTED] writes:
Maybe specify an archive location (that of course could be on a
separate
partition) that the external archiver should check in addition to
the
normal WAL
In the last few days, a number of issues have come up on [HACKERS] and
[PERFORM] that have made important contribs to the PITR topic. Moreover,
work such as tablespaces has sufficient cross-over with PITR to make it
important to double post things, which defeats the object of having a
separate
Joe Conway [EMAIL PROTECTED] writes:
Simon Riggs wrote:
O... and other dbms will freeze when this situation is hit, rather
than continue and drop archive logs.]
Been there, done that, don't see how it's any better. I hesitate to be
real specific here, but let's just say the end result was
-Original Message-
From: Merlin Moncure [mailto:[EMAIL PROTECTED]
Sent: Wednesday, March 03, 2004 12:28 PM
To: Greg Stark
Cc: [EMAIL PROTECTED]
Subject: Re: [pgsql-hackers-win32] [HACKERS] What's left?
Greg Stark wrote:
imposed no such conditions. If Microsoft wanted to
Simon Riggs wrote:
User-selectable behaviour? OK. That's how we deal with fsync; I can
relate to that. That hadn't been part of my thinking because of the
importance I'd attached to the log files themselves, but I can go with
that, if that's what was meant.
So, if we had a parameter called
Simon Riggs wrote:
Tom Lane [mailto:[EMAIL PROTECTED] That should be user-scriptable
policy, in my worldview.
O... and other dbms will freeze when this situation is hit, rather
than continue and drop archive logs.]
Been there, done that, don't see how it's any better. I hesitate to be
real
Shridhar, want to discuss this off list a bit to work through the various
options and then revent back to the list with a suitable to-do (for
discussion)?
L.
- Original Message -
From: Shridhar Daithankar [EMAIL PROTECTED]
To: Bruce Momjian [EMAIL PROTECTED]
Cc: PostgreSQL-development
Cyril VELTER [EMAIL PROTECTED] writes:
so I've modified libpq to handle the case by adding to functions :
PQexecPreparedPortal(conn,stmtName,portalName,nParams,paramValues,paramlengt
h,paramFormats,resultFormat,maxrows);
and
PQfetchPortal(conn,portalName,maxrows)
On Wed, Mar 03, 2004 at 04:57:28PM -0500, Jan Wieck wrote:
After some substantial progress on the Slony-I engine development, I'd
like to give a little status report and invite everyone who wants to
participate in this project to join the mailing list and the development
team.
Jan, thank
Bruce Momjian wrote:
Greg Stark wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Greg Stark wrote:
I am expecting to hear some bleating about this from people whose
preferred platforms don't support symlinks ;-). However, if we don't
Well, one option would be to
Thomas Swan wrote:
The advantage of symlinks is that an administrator could see how things
are laid out from the command line.
That's a poor reason to require symlinks. The administrator can just as
easily open up psql and query pg_tablespace to see that same
information. Besides,
I have caught up on my email and am working on the 7.4.2 branding now.
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED] | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup.|
Hey Bruce,
I never saw the patch hit the hackers list. Did any of you smart folks take a
look at it?
Cheers,
Rob
When grilled further on (Wed, 3 Mar 2004 13:58:02 -0500 (EST)),
Bruce Momjian [EMAIL PROTECTED] confessed:
Your patch has been added to the PostgreSQL unapplied patches list
Well, it must have hit the lists if I have put it in the patch queue, no?
---
Hey Bruce,
I never saw the patch hit the hackers list. Did any of you smart folks take a
look at it?
Cheers,
Rob
When grilled further on
Followup-To: Slony1-general ML
Alex J. Avriette wrote:
On Wed, Mar 03, 2004 at 04:57:28PM -0500, Jan Wieck wrote:
After some substantial progress on the Slony-I engine development, I'd
like to give a little status report and invite everyone who wants to
participate in this project to join the
On Wednesday 03 March 2004 10:11 pm, Bruce Momjian wrote:
I have caught up on my email and am working on the 7.4.2 branding now.
Ack is it too late to submit a patch to fix the int overflow problem with
pg_autovacuum? I'll send a patch to the patches list shortly, hopefully it
will get
On Wed, 3 Mar 2004, Bruce Momjian wrote:
I have caught up on my email and am working on the 7.4.2 branding now.
Just as a reminder, before ppl panic ... we are aiming for Monday for a
7.4.2 release ...
Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
Email:
Matthew T. O'Connor [EMAIL PROTECTED] writes:
Ack is it too late to submit a patch to fix the int overflow
problem with pg_autovacuum?
No; we're not planning to wrap 7.4.2 till (probably) Sunday. If you can
get the patch in within the next day or so, we can include it.
I thought we'd
On Thursday 04 March 2004 12:04 am, Tom Lane wrote:
I thought we'd fixed that problem already though. Is there another?
Don't know if it's another, but the problem posted by Cott Lang on 1/17
( http://archives.postgresql.org/pgsql-bugs/2004-01/msg00111.php )
has not been resolved.
Tom Lane wrote:
Thomas Swan [EMAIL PROTECTED] writes:
Bruce Momjian wrote:
The advantage of symlinks is that an administrator could see how things
are laid out from the command line.
That's a poor reason to require symlinks. The administrator can just as
easily open up psql
Lee Kindness wrote:
Shridhar, want to discuss this off list a bit to work through the various
options and then revent back to the list with a suitable to-do (for
discussion)?
I don't mind. Just for summary, I am listing the discussion/proposal so far on
this issue..
- Dispose names of
Tom Lane wrote:
I think also that Simon completely misunderstood my intent in saying
that this could be user-scriptable policy. By that I meant that the
*user* could write the code to behave whichever way he liked. Not that
we were going to go into a mad rush of feature invention and try to
Folks,
Today Michael Steil and I have tested PostgreSQL 7.4.1 on Nintendo Game
Cubes.
All regression test (but stats - stats collector was off instead of on)
have passed successfully.
[EMAIL PROTECTED] root]# uname -a
Linux 192.168.0.47 2.6.3 #20 Wed Mar 3 12:22:07 CET 2004 ppc unknown
Neil Conway
Simon Riggs wrote:
Josh Berkus wrote
Simon Riggs wrote
Please set WAL_DEBUG to 1 so we can see a bit more info: thanks.
I'm pretty sure that WAL_DEBUG requires a compile-time option.
I'm surprised, but you are right, the manual does SAY this requires
a
compile time
Simon Riggs [EMAIL PROTECTED] writes:
The behaviour I wish to add is:
Keep wal_debug as a value between 0 and 16.
If =0 then no debug output (default).
Use following bitmasks against the value
Mask 1 = XLOG Checkpoints get logged
Mask 2 = Archive API calls get logged
Mask 4 = Transaction -
Simon Riggs wrote:
On the other hand, I was just about to change the wal_debug behaviour to
allow better debugging of PITR features as they're added.
That's a development activity. Enabling the WAL_DEBUG #ifdef by
default during the 7.5 development cycle would be uncontroversial, I
think.
I
After some substantial progress on the Slony-I engine development, I'd
like to give a little status report and invite everyone who wants to
participate in this project to join the mailing list and the development
team.
The project homepage is here:
53 matches
Mail list logo
