On Mon, Jul 21, 2008 at 03:15:56AM +0200, Radek Strnad wrote:
I was trying to sort out the problem with not creating new catalog for
character sets and I came up following ideas. Correct me if my ideas are
wrong.
Since collation has to have a defined character set.
Not really. AIUI at least
Hi,
yesterday, I promised to outline the requirements of Postgres-R for
tuple serialization, which we have been talking about before. There are
basically three types of how to serialize tuple changes, depending on
whether they originate from an INSERT, UPDATE or DELETE. For updates and
Am Monday, 21. July 2008 schrieb Tom Lane:
So my feeling is that we should not accept either of these patches.
My feeling as well.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Grzegorz Jaśkiewicz [EMAIL PROTECTED] writes:
Tom Lane pisze:
The reason we don't automatically translate OVERLAPS is that the spec's
definition of OVERLAPS is too weird for that to work; in particular
it demands a true result for some cases in which one of the four
endpoints is NULL,
[EMAIL PROTECTED] (Markus Wanner) writes:
chris wrote:
I agree with you that tables are *supposed* to have primary keys;
that's proper design, and if tables are missing them, then something
is definitely broken.
Ah, I see, so you are not concerned about tables with a PRIMARY KEY
for which
Commands pltcl_listmod, pltcl_delmod, pltcl_loadmod does not work on Solaris 10,
because there is not present tclsh. Unfortunately build process substitute path
to shell with empty string which invokes infinite loop.
See diff between S10 and Nevada:
bash-3.00# head
On Tue, Jul 22, 2008 at 12:31 AM, Matthew T. O'Connor [EMAIL PROTECTED] wrote:
Is DSM going to be in 8.4? The last I had heard, DSM+related
improvements weren't close to being guaranteed for this release. If
it doesn't make it, waiting another year and a half for something
easily fixed would
Zdenek Kotala napsal(a):
Commands pltcl_listmod, pltcl_delmod, pltcl_loadmod does not work on
Solaris 10, because there is not present tclsh.
I found that tclsh is available on solaris 10 in /usr/sfw/bin and its name is
tclsh8.3.
Zdenek
--
Sent via pgsql-hackers mailing
Hi,
chris wrote:
I'll describe a scenario to suggest where it might happen.
- A system is implemented, using the database, and, for some reason,
no PRIMARY KEY is defined for a table. Someone forgot; it got
misconfigured; a mistake was probably made.
- The system then goes into
Tom Lane [EMAIL PROTECTED] writes:
From a project-management point of view, it's insanity to set a presumption
that pgfoundry is just a proving ground for code that should eventually get
into core once it's mature enough or popular enough or whatever. We *have
to* encourage the development
On Tue, Jul 22, 2008 at 2:39 PM, Gregory Stark [EMAIL PROTECTED] wrote:
Tom Lane [EMAIL PROTECTED] writes:
From a project-management point of view, it's insanity to set a presumption
that pgfoundry is just a proving ground for code that should eventually get
into core once it's mature enough
Zdenek Kotala [EMAIL PROTECTED] writes:
Commands pltcl_listmod, pltcl_delmod, pltcl_loadmod does not work on Solaris
10,
because there is not present tclsh.
Shouldn't this bug be filed against Solaris' clearly-broken tcl
installation?
regards, tom lane
--
Sent via
Martijn van Oosterhout napsal(a):
On Sat, Jul 12, 2008 at 10:02:24AM +0200, Zdenek Kotala wrote:
Background:
We specify encoding in initdb phase. ANSI specify repertoire, charset,
encoding and collation. If I understand it correctly, then charset is
subset of repertoire and specify list of
On Mon, Jul 21, 2008 at 09:32:57PM -0400, Tom Lane wrote:
Marko Kreen [EMAIL PROTECTED] writes:
2. If cluster connection strings do not have 'user=' key,
' user=' || current_username() is appended to it.
Cool, I missed that. At minimum the documentation has to explain this
point
Tom Lane napsal(a):
Zdenek Kotala [EMAIL PROTECTED] writes:
Commands pltcl_listmod, pltcl_delmod, pltcl_loadmod does not work on Solaris 10,
because there is not present tclsh.
Shouldn't this bug be filed against Solaris' clearly-broken tcl
installation?
I'm not able to make decision if
On 7/22/08, Andrew Sullivan [EMAIL PROTECTED] wrote:
On Mon, Jul 21, 2008 at 09:32:57PM -0400, Tom Lane wrote:
Marko Kreen [EMAIL PROTECTED] writes:
2. If cluster connection strings do not have 'user=' key,
' user=' || current_username() is appended to it.
Cool, I missed
Dave Page [EMAIL PROTECTED] writes:
On Tue, Jul 22, 2008 at 2:39 PM, Gregory Stark [EMAIL PROTECTED] wrote:
Tom Lane [EMAIL PROTECTED] writes:
From a project-management point of view, it's insanity to set a presumption
that pgfoundry is just a proving ground for code that should eventually
Zdenek Kotala [EMAIL PROTECTED] writes:
But problem is also in configure which does not fail when tclsh is not
found.
Yes it does ...
if test $[#] -eq 0; then
test -z $TCLSH AC_MSG_ERROR([unable to locate tclConfig.sh because
no Tcl shell was found])
Andrew Sullivan [EMAIL PROTECTED] writes:
On Mon, Jul 21, 2008 at 09:32:57PM -0400, Tom Lane wrote:
Marko Kreen [EMAIL PROTECTED] writes:
2. If cluster connection strings do not have 'user=' key,
' user=' || current_username() is appended to it.
Cool, I missed that. At minimum the
Markus Wanner [EMAIL PROTECTED] writes:
Thinking about index creation time doesn't make sense, as long as we
still need a dump/restore cycle to setup replication. And even then,
that operational issue has nothing to do with the question of
I'm looking at shortlisting things that I'll be working on for 8.4. I've
thrown out a few small patches I had, but now am looking at these
projects:
* Hot Standby
* Logical replication via transaction log
* Integration with synchronous replication
* Join removal
* stats hooks
* DDL locking
Tom Lane napsal(a):
Zdenek Kotala [EMAIL PROTECTED] writes:
But problem is also in configure which does not fail when tclsh is not
found.
Yes it does ...
if test $[#] -eq 0; then
test -z $TCLSH AC_MSG_ERROR([unable to locate tclConfig.sh because
no Tcl shell was found])
On 7/22/08, Tom Lane [EMAIL PROTECTED] wrote:
Marko Kreen [EMAIL PROTECTED] writes:
On 7/21/08, Tom Lane [EMAIL PROTECTED] wrote:
I looked through this a bit, and my principal reaction was what are
the security implications?
There are 2 aspects to it:
1. Function can be created only
Marko Kreen [EMAIL PROTECTED] writes:
And user can execute only pre-determines queries/functions on system2.
If that were actually the case then the security issue wouldn't loom
quite so large, but the dynamic_query example in the plproxy regression
tests provides a perfect example of how to
On Mon, 2008-07-21 at 23:53 -0400, Owen Hartnett wrote:
It would generate a schema dump where all the references to
schema_name were replaced by masquerade_name.
Good idea, can I tweak that a bit?
No need to specify the name at pg_dump time.
For text files, just use an option to specify
Hi,
Christopher Browne wrote:
Markus Wanner [EMAIL PROTECTED] writes:
Thinking about index creation time doesn't make sense, as long as we
still need a dump/restore cycle to setup replication. And even then,
that operational issue has
Teodor Sigaev [EMAIL PROTECTED] writes:
Updated: http://www.sigaev.ru/misc/fast_insert_gin-0.9.gz
I still havn't clearness of acceptability for suggested aminsertcleanup
calling.
I started to look at this. I don't understand why VACUUM does an insert
cleanup before starting to vacuum, but
1. What is the meaning of such a query operator?
foo #5 bar - true if the document has word foo followed by bar at
5th position.
foo #5 bar - true if document has word foo followed by bar with in
5 positions
foo #5 bar - true if document has word foo followed by bar after 5
positions
Sounds
Dave Cramer wrote:
On 21-Jul-08, at 4:28 PM, Andrew Sullivan wrote:
On Mon, Jul 21, 2008 at 01:17:39PM -0700, David E. Wheeler wrote:
pgFoundry ain't the CPAN, alas.
Maybe that's the problem that really needs solving?
One of the big Postgres features is its extensibility. I agree
that
One of the cool features of 8.3 was the ability to control at the
transaction level whether we would use synchronous or asynchronous
commit.
We're planning to add integrated replication features to 8.4, and I
think it will be possible to extend the concept of asynchronous commit
to a more general
I started to look at this. I don't understand why VACUUM does an insert
cleanup before starting to vacuum, but VACUUM FULL doesn't?
Hmm. May be I missed something, but I don't understand where and what... I tried
to track all places of ambultdelete call. aminsertcleanup should be called
Markus Wanner wrote:
Ideally, we'd take an outage and add the primary key. But suppose we
can't afford to do so?
You are assuming that one doesn't need to take an outage to start
replication in the first place. As Postgres-R comes with system catalog
changes, that's not the case. You
Simon Riggs [EMAIL PROTECTED] writes:
No need to specify the name at pg_dump time.
For text files, just use an option to specify whether we change the
actual schema name and replace it with the text :PGDUMPSCHEMA.
pg_restore is in even worse position than pg_dump to make this happen;
it would
Teodor Sigaev [EMAIL PROTECTED] writes:
That's close to trivial to revert this piece to add cleanup call to
ginbulkdelete/ginvacuumcleanup. Early variants used this variant.
Yeah, I think we should do it that way.
On reflection I don't think you even need the amvacuumstartup call,
because it
Tom Lane napsal(a):
Zdenek Kotala [EMAIL PROTECTED] writes:
I think if we support UTF8 encoding, than it make sense to create own charsets,
because system locales could have defined collation for that.
Say what? I cannot imagine a scenario in which a user-defined encoding
would be useful.
Teodor Sigaev [EMAIL PROTECTED] writes:
I started to look at this. I don't understand why VACUUM does an insert
cleanup before starting to vacuum, but VACUUM FULL doesn't?
Hmm. May be I missed something, but I don't understand where and what... I
tried
to track all places of ambultdelete
Well, if that is required to be true then this whole design is pretty
broken, because VACUUM doesn't hold any lock that would guarantee that
no insert happens between the two calls. If we fold the two AM calls
into one call then it'd be okay for the index AM to take such a lock
transiently
Hi,
Simon Riggs wrote:
* Logical replication via transaction log
* Integration with synchronous replication
I'm curious on what you mean by these two points. AFAIK you are speaking
of logical replication for methods which don't rely on the internal
storage format of the database, but
On Tue, 2008-07-22 at 16:58 +0100, Simon Riggs wrote:
On Mon, 2008-07-21 at 23:53 -0400, Owen Hartnett wrote:
No need to specify the name at pg_dump time.
For text files, just use an option to specify whether we change the
actual schema name and replace it with the text :PGDUMPSCHEMA.
On Tue, 2008-07-22 at 10:23 -0700, David E. Wheeler wrote:
On Jul 22, 2008, at 08:35, Simon Riggs wrote:
* Hot Standby
* Logical replication via transaction log
* Integration with synchronous replication
Getting these in 8.4 would so rock.
Agreed. Thank me when its done, 'cos it
Le mardi 22 juillet 2008, Christopher Browne a écrit :
A most pointed case where that will cause heartburn of the I refuse
to use this sort is if that disruption needs to take place when
recovering from the failure of a node. That sort of disruption is
certainly counterproductive to the usual
Tom Lane wrote:
Zdenek Kotala [EMAIL PROTECTED] writes:
But problem is also in configure which does not fail when tclsh is not
found.
Yes it does ...
if test $[#] -eq 0; then
test -z $TCLSH AC_MSG_ERROR([unable to locate tclConfig.sh because
no Tcl shell was found])
On Tue, 2008-07-22 at 18:37 +0200, Markus Wanner wrote:
Simon Riggs wrote:
* Logical replication via transaction log
* Integration with synchronous replication
I'm curious on what you mean by these two points. AFAIK you are speaking
of logical replication for methods which don't rely
Hi,
Dimitri Fontaine wrote:
This part of Markus's mail makes me think the need may change if Postgres-R is
ever integrated into -core:
Yes, in that case, you'd have replication already compiled in and
distributed with standard Postgres. However, ATM that's pipe dreaming
and I'm pretty sure
Martijn van Oosterhout napsal(a):
On Mon, Jul 21, 2008 at 03:15:56AM +0200, Radek Strnad wrote:
I was trying to sort out the problem with not creating new catalog for
character sets and I came up following ideas. Correct me if my ideas are
wrong.
Since collation has to have a defined character
On Tue, 2008-07-22 at 13:35 -0400, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
No need to specify the name at pg_dump time.
For text files, just use an option to specify whether we change the
actual schema name and replace it with the text :PGDUMPSCHEMA.
pg_restore is in even
On Mon, 2008-07-21 at 15:43 -0400, Tom Lane wrote:
From a maintenance point of view there seems little need
for either project to get integrated: they don't appear to have much
of any code that is tightly tied to backend innards.
This is a slightly circular argument. They have had to be
Dimitri Fontaine [EMAIL PROTECTED] writes:
Note that while slony doesn't require a dump/restore to get activated, it
seems to me (as a non user of it) that it still plays with catalog,
preventing normal usage of pg_dump...
FYI, that will no longer be the case in version 2.0 of Slony-I; with
Zdenek Kotala [EMAIL PROTECTED] writes:
Yeah, I looked deeply on our solaris build script and problem is with
following
configure setup:
./configure --prefix=/tmp/pg --with-tcl --with-tclconfig=/usr/sfw/lib
It found tclconfig, but not tclsh
Ah. So actually there is a bug in our
On Jul 22, 2008, at 08:35, Simon Riggs wrote:
* Hot Standby
* Logical replication via transaction log
* Integration with synchronous replication
Getting these in 8.4 would so rock. Thank you!
David
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
On Jul 22, 2008, at 12:51, Simon Riggs wrote:
I think we should return them with comments that if you integrate them
more with core *and* can justify having done so, then we might include
those features later
I believe I've done both these things for citext, though if there is
more to be
Dimitri Fontaine [EMAIL PROTECTED] writes:
Note that while slony doesn't require a dump/restore to get activated, it
seems to me (as a non user of it) that it still plays with catalog,
preventing normal usage of pg_dump...
As of 8.3 there are some new trigger features in core that were put
On Jul 18, 2008, at 01:39, Michael Paesold wrote:
Calling regex functions with the case-insensitivity option would be
great. It should also be possible to rewrite replace() into
regexp_replace() by first escaping the regex meta characters.
Actually re-implementing those functions in a case
Simon Riggs [EMAIL PROTECTED] writes:
On Tue, 2008-07-22 at 18:37 +0200, Markus Wanner wrote:
What is it you
are talking about?
Reconstructing SQL from WAL, allowing logical apply.
...
I'm proposing to put the mechanisms in place to allow WAL to be used by
other replication projects.
Tom, Simon, etc.:
Of the several things which PostgreSQL could learn from MySQL which we
covered at pgCon was that the requirement to hunt hither and yon for
popular add-ins is one of the primary reasons for developers not using
PostgreSQL.
Further, one of the main reasons why people do use
Hi,
Simon Riggs wrote:
Reconstructing SQL from WAL, allowing logical apply. So yes, you're
right, the actual replication of the data from one node to another is
physical - its the final apply of the changes that is logical. So this
fits neatly with our commitment to put synchronous replication
Simon Riggs [EMAIL PROTECTED] writes:
On Mon, 2008-07-21 at 15:43 -0400, Tom Lane wrote:
From a maintenance point of view there seems little need
for either project to get integrated: they don't appear to have much
of any code that is tightly tied to backend innards.
This is a slightly
On Jul 22, 2008, at 3:04 AM, Markus Wanner wrote:
yesterday, I promised to outline the requirements of Postgres-R for
tuple serialization, which we have been talking about before. There
are basically three types of how to serialize tuple changes,
depending on whether they originate from an
Hi,
very nice proposal and thoughts. Allow me to compare against Postgres-R
again.
Simon Riggs wrote:
Asynchronous commit controls whether we go to disk at time of commit, or
whether we defer this slightly. We have the same options with
replication: do we replicate at time of commit, or do
Josh Berkus [EMAIL PROTECTED] writes:
Tom, Simon, etc.:
Of the several things which PostgreSQL could learn from MySQL which we
covered at pgCon was that the requirement to hunt hither and yon for
popular add-ins is one of the primary reasons for developers not using
PostgreSQL.
Agreed,
Hi,
Decibel! wrote:
ISTM that both londiste and Slony would be able to make use of these
improvements as well. A modular replication system should be able to use
a variety of methods for logging data changes and then applying them on
a subscriber, so long as some kind of common transport can
On Tue, 2008-07-22 at 17:36 -0400, Tom Lane wrote:
Josh Berkus [EMAIL PROTECTED] writes:
Tom, Simon, etc.:
Of the several things which PostgreSQL could learn from MySQL which we
covered at pgCon was that the requirement to hunt hither and yon for
popular add-ins is one of the primary
Joshua D. Drake [EMAIL PROTECTED] writes:
On Tue, 2008-07-22 at 17:36 -0400, Tom Lane wrote:
Agreed, but I think the best response to that is something CPAN-like
for people to easily get hold of recognized extensions,
It seems to me a better solution is to have appropriate repositories for
On Tue, 2008-07-22 at 17:54 -0400, Tom Lane wrote:
Joshua D. Drake [EMAIL PROTECTED] writes:
It seems to me a better solution is to have appropriate repositories for
distributions that have them than some cpan style thing that is going to
break package dependencies.
Better than CPAN is
On Tue, 2008-07-22 at 14:06 -0700, Josh Berkus wrote:
Minimalism isn't its own reward. Obviously Tom has reason to worry
about the overall maintenance effort for the PostgreSQL code. But we
need to balance that against the need to add features that users want
and will keep our community
On Tue, 2008-07-22 at 16:54 -0400, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
On Tue, 2008-07-22 at 18:37 +0200, Markus Wanner wrote:
What is it you
are talking about?
Reconstructing SQL from WAL, allowing logical apply.
...
I'm proposing to put the mechanisms in place
On 7/22/08, Simon Riggs [EMAIL PROTECTED] wrote:
We could represent this with 3 parameters:
synchronous_commit = on | off
synchronous_standby_transfer = on | off
synchronous_standby_wal_fsync = on | off
If we are able to define these robustness characteristics for each
transaction
On Wed, 2008-07-23 at 01:39 +0300, Marko Kreen wrote:
On 7/22/08, Simon Riggs [EMAIL PROTECTED] wrote:
We could represent this with 3 parameters:
synchronous_commit = on | off
synchronous_standby_transfer = on | off
synchronous_standby_wal_fsync = on | off
If we are able to
On Jul 22, 2008, at 4:43 PM, Markus Wanner wrote:
Decibel! wrote:
ISTM that both londiste and Slony would be able to make use of
these improvements as well. A modular replication system should be
able to use a variety of methods for logging data changes and then
applying them on a
Below my comments on the CommitFest patch:
pg_standby minor changes for Windows
Simon, I'm sorry you got me, a Postgres newbie, signed up for
reviewing your patch ;)
To start with, I'm not quite sure of the status of this patch
since Bruce's last comment on the -patches alias:
Bruce Momjian
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Simon Riggs wrote:
Asynchronous commit controls whether we go to disk at time of commit, or
whether we defer this slightly. We have the same options with
replication: do we replicate at time of commit, or do we defer this
slightly for performance
I'm sorry for delay reply. I couldn't get access to the internet these
days for some reason.
I do apologize for my rough work and very bad readability. I posted it
in a hurry and I didn't mean to cause the reader so much
inconvenience.
I'll NEVER make such a mistake again.
Currently, I've made
Well, I'll do it after I finish my second patch.
Hash index should be more efficient than btree when N is big enough.
It seems meaningful to find how big N is in an experiment way.
On Fri, Jul 18, 2008 at 6:35 PM, Simon Riggs [EMAIL PROTECTED] wrote:
On Fri, 2008-07-18 at 11:07 +0100, Gregory
On Tue, 2008-07-22 at 17:54 -0400, Tom Lane wrote:
apt-get install postgresql-plproxy
portinstall (I think that is the command) postgresql-plproxy
I believe Devrim already has a yum repository up and running for
RPM-based distros, though I'm not sure he's got anything but the core
Joshua D. Drake [EMAIL PROTECTED] writes:
On Tue, 2008-07-22 at 17:54 -0400, Tom Lane wrote:
I believe Devrim already has a yum repository up and running for
RPM-based distros, though I'm not sure he's got anything but the core
packages in it (yet).
Well that was certainly part of my point.
-Original Message-
From: [EMAIL PROTECTED] [mailto:pgsql-hackers-
[EMAIL PROTECTED] On Behalf Of Xiao Meng
Sent: Tuesday, July 22, 2008 7:57 PM
To: Simon Riggs
Cc: pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] [PATCH]-hash index improving
Well, I'll do it after I finish my
On Tue, 2008-07-22 at 23:29 -0400, Tom Lane wrote:
Joshua D. Drake [EMAIL PROTECTED] writes:
On Tue, 2008-07-22 at 17:54 -0400, Tom Lane wrote:
I believe Devrim already has a yum repository up and running for
RPM-based distros, though I'm not sure he's got anything but the core
packages
Joshua D. Drake [EMAIL PROTECTED] writes:
On Tue, 2008-07-22 at 23:29 -0400, Tom Lane wrote:
There's a limit to how far you can go there, because just about any
distro (other than maybe Gentoo) is going to be resistant to dropping in
bleeding-edge versions.
We could have a quality
On Wed, 2008-07-23 at 00:01 -0400, Tom Lane wrote:
Joshua D. Drake [EMAIL PROTECTED] writes:
On Tue, 2008-07-22 at 23:29 -0400, Tom Lane wrote:
There's a limit to how far you can go there, because just about any
distro (other than maybe Gentoo) is going to be resistant to dropping in
Hi,
Decibel! wrote:
Currently, londiste triggers are per-row, not deferred. IIRC, londiste
is the same. ISTM it'd be much better if we had per-statement triggers
that could see what data had changed; that'd likely be a lot more
efficient than doing stuff per-row.
Well, now that I think
80 matches
Mail list logo
