This is my first post/reply on this list, but I have been listening for a
while now (I mostly read the replication ones ;-). I am interested in
what developers/users are looking for in a replication/sync solution in
postgresql, and contributing to that effort.
I'm trying to centralize data in
Helo,
On Thu, 31 May 2001 [EMAIL PROTECTED] wrote:
Questions:
1) What is the connection between small and big Dbs? (LAN/WAN)
2) Is there a consistent connection between systems?
3) Are you looking for synchronous (before the insert commits)
or asynchronous
On Thu, May 31, 2001 at 10:07:36AM -0400, Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
What got me thinking about this is that I don't think my gram.y fix
would be accepted given the current review process,
Not to put too fine a point on it: the project has advanced a long way
On Wed, May 30, 2001 at 03:00:53PM -0300, Roberto Abalde wrote:
Hi,
I need to implement a cache for query plans as part of my BSc thesis. Does
anybody know what happened to Karel Zak's patch?
Hi,
my patch is on my ftp and nobody works on it, but I mean it's good
begin for some next
Teodor Sigaev [EMAIL PROTECTED] writes:
The point was that in gist_tuple_replacekey (called from
gistPageAddItem) key may be replaced by null value, but flag
itup-t_info INDEX_NULL_MASK is not set.
Ah. That's certainly a bug.
regards, tom lane
Kovacs Zoltan [EMAIL PROTECTED] writes:
Starting pg_dump, this error occured (there is no output dump,
unfortunately). Getting closer, I got this:
tir=# SELECT pg_get_viewdef(c.relname) AS definition FROM pg_class c
offset 441 limit 1;
ERROR: cache lookup for proc 4303134 failed
I think
Bruce Momjian [EMAIL PROTECTED] writes:
What got me thinking about this is that I don't think my gram.y fix
would be accepted given the current review process,
Not to put too fine a point on it: the project has advanced a long way
since you did that code. Our standards *should* be higher than
Oleg Bartunov [EMAIL PROTECTED] writes:
New version of contrib-intarray for postgresql version 7.1 and above
is available from http://www.sai.msu.su/~megera/postgres/gist/
I'm going to be making commits later today that clean up the char*
that should be Datum ugliness in GiST. I think the
On Thu, 31 May 2001, Tom Lane wrote:
Indeed. You're looking at the aftermath of an imperfect fix to add
foreign keys. With all due respect to Jan and Stephan, who did a great
job adding the feature at all, there are still a lot of things that need
to be fixed in that area. The trouble
Kovacs Zoltan [EMAIL PROTECTED] writes:
It means that the 21st line of the result is problematic, because writing
20 instead of 21 I got no problem.
I think not. The current implementation of LIMIT fetches one more row
than is really needed, IIRC.
regards, tom lane
Lamar Owen [EMAIL PROTECTED] writes:
Looking through the archives Ifind some details, such as the function
locale_is_like_safe() , and I see other details -- but a concise picture of
what one can expect operating in a non-locale_is_like_safe() (which
currently includes ONLY the C and
Jan Wieck [EMAIL PROTECTED] writes:
In the next couple of hours (at least tomorrow) I would be
ready to commit the backend changes for table-/index-access
statistics and current backend activity views.
Should I apply the patches or provide a separate patch for
Oleg Bartunov [EMAIL PROTECTED] writes:
We have implemented multi-key index support for GiST. Patch is available
from
http://www.sai.msu.su/~megera/postgres/gist/code/7.1.2/patch_multikeygist.7.1.2.gz
I have committed these changes, along with your leak patch of 5/30.
1. initdb is
Oleg Bartunov [EMAIL PROTECTED] writes:
Full implementation of R-Tree using GiST is available from
http://www.sai.msu.su/~megera/postgres/gist/
Committed as a contrib module.
At some point we'll probably want to move this into the mainframe,
but I left it as a separate package for now.
14 matches
Mail list logo
