Jan Wieck wrote:
This is all that is needed for last update wins resolution. And as
said before, the only reason the clock is involved in this is so that
nodes can continue autonomously when they lose connection without
conflict resolution going crazy later on, which it would do if they
were
Bruce Momjian wrote:
Heikki, did this code cleanup get included in your recent btree split
fix?
No.
---
Tom Lane wrote:
Heikki Linnakangas [EMAIL PROTECTED] writes:
In that case, newitemleft would be false, right?
I'm
On Sat, 2007-02-03 at 09:43 -0800, Stephan Szabo wrote:
On Sat, 3 Feb 2007, Simon Riggs wrote:
On Fri, 2007-02-02 at 16:50 -0500, Tom Lane wrote:
No, I don't. I think knowledge of which columns are in a PK is quite a
few levels away from the semantics of row locking. To point out just
Bruce Momjian wrote:
Log Message:
---
Add documentation for Windows on how to set an environment variable.
Backpatch to 8.2.X.
Modified Files:
--
pgsql/doc/src/sgml:
libpq.sgml (r1.224 - r1.225)
On Sat, 2007-02-03 at 20:37 -0500, Bruce Momjian wrote:
Your patch has been added to the PostgreSQL unapplied patches list at:
http://momjian.postgresql.org/cgi-bin/pgpatches
It will be applied as soon as one of the PostgreSQL committers reviews
and approves it.
Tom applied the
have this about PQfreemem():
Frees memory allocated by applicationlibpq/, particularly
functionPQescapeByteaConn/function,
functionPQescapeBytea/function,
functionPQunescapeBytea/function,
and functionPQnotifies/function.
It is needed by Microsoft Windows, which cannot free memory
Magnus Hagander wrote:
Bottom line: do we really want to document for people how to use
Windows?
No, we don't.
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
Magnus Hagander wrote:
Now, there are two options for this. Either we fix it (I can put
together a patch), or we remove it altogether. To me, it seems to be
just an implementation detail and some kind of explanation why we're
doing it - which would live better in a source code comment than in
Peter Eisentraut wrote:
Magnus Hagander wrote:
Now, there are two options for this. Either we fix it (I can put
together a patch), or we remove it altogether. To me, it seems to be
just an implementation detail and some kind of explanation why we're
doing it - which would live better in a
On 2/4/2007 3:16 AM, Peter Eisentraut wrote:
Jan Wieck wrote:
This is all that is needed for last update wins resolution. And as
said before, the only reason the clock is involved in this is so that
nodes can continue autonomously when they lose connection without
conflict resolution going
On Feb 4, 2007, at 10:06 AM, Jan Wieck wrote:
On 2/4/2007 3:16 AM, Peter Eisentraut wrote:
Jan Wieck wrote:
This is all that is needed for last update wins resolution. And as
said before, the only reason the clock is involved in this is so
that
nodes can continue autonomously when they
Theo Schlossnagle [EMAIL PROTECTED] writes:
As the clock must be incremented clusterwide, the need for it to be insync
with
the system clock (on any or all of the systems) is obviated. In fact, as you
can't guarantee the synchronicity means that it can be confusing -- one
expects a
On Sun, Jan 28, 2007 at 02:05:41PM +0100, Magnus Hagander wrote:
Anyway. We hard-code thread-safety to on for Win32, because win32 is a
threaded platform in general - almost everything can be exposed to
threading even if they don't want it. For example a VB program that has
no threading at all
Andrew Dunstan [EMAIL PROTECTED] writes:
oh, good point. OK, I have cut this quick patch that will continue to
accept the legacy syntax in psql in non-inline-query cases, but will
make psql unreservedly emit new style syntax for COPY to the backend.
Does that seem reasonable, or is it too
On 2/4/2007 10:53 AM, Theo Schlossnagle wrote:
As the clock must be incremented clusterwide, the need for it to be
insync with the system clock (on any or all of the systems) is
obviated. In fact, as you can't guarantee the synchronicity means
that it can be confusing -- one expects a
On Feb 4, 2007, at 1:36 PM, Jan Wieck wrote:
On 2/4/2007 10:53 AM, Theo Schlossnagle wrote:
As the clock must be incremented clusterwide, the need for it to
be insync with the system clock (on any or all of the systems)
is obviated. In fact, as you can't guarantee the synchronicity
Markus Schiltknecht [EMAIL PROTECTED] writes:
is there a good reason to print the database system is ready message
in StartupXLOG() in xact.c? It has a) nothing to do with xlog and b)
opens a small race condition: the message gets printed, while it still
take some CPU cycles until the
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
oh, good point. OK, I have cut this quick patch that will continue to
accept the legacy syntax in psql in non-inline-query cases, but will
make psql unreservedly emit new style syntax for COPY to the backend.
Does that seem
Andrew Dunstan [EMAIL PROTECTED] writes:
The consequence will be, though, that psql will accept a syntax for
\copy (query) ... that the corresponding backend command would reject
were we not transforming it. That strikes me as potentially confusing.
Perhaps. What about plan B: remove the
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
The consequence will be, though, that psql will accept a syntax for
\copy (query) ... that the corresponding backend command would reject
were we not transforming it. That strikes me as potentially confusing.
Perhaps. What
Hello,
Is anyone working on a period data type as described in Dr. Richard Snodgrass'
book _Developing Time-Oriented Database Applications in SQL_[1]? I did not
see a relevant project listed in the TODO. I would like to contribute
(possible funding and/or coding) the development of a
On Feb 5, 2007, at 12:47 , Warren Turkal wrote:
Is anyone working on a period data type as described in Dr. Richard
Snodgrass'
book _Developing Time-Oriented Database Applications in SQL_[1]? I
did not
see a relevant project listed in the TODO. I would like to contribute
(possible funding
On Feb 2, 2007, at 1:41 PM, Simon Riggs wrote:
On Thu, 2007-02-01 at 23:57 -0600, Jim Nasby wrote:
Has anyone actually measured the performance overhead of storing
visibility info in indexes? I know the space overhead sounds
daunting, but even if it doubled the size of the index in many cases
There was also mention of having a means to tell pg_dump not to dump
extensions...
On Jan 30, 2007, at 2:49 PM, Andrew Dunstan wrote:
Bruce Momjian wrote:
Joshua D. Drake wrote:
This seems like a good first step in growing a packaging
infrastructure. I'd rather grow it organically than
Hi,
Tom Lane wrote:
I don't think there's any compelling reason for having that log message
in its current form. What about redefining it to mean postmaster is
ready to accept connections --- either with that wording, or keeping
the old wording? Then we could just put it in one place in
Ühel kenal päeval, P, 2007-02-04 kell 22:23, kirjutas Jim Nasby:
On Feb 2, 2007, at 1:41 PM, Simon Riggs wrote:
On Thu, 2007-02-01 at 23:57 -0600, Jim Nasby wrote:
Has anyone actually measured the performance overhead of storing
visibility info in indexes? I know the space overhead sounds
26 matches
Mail list logo
