Hi,
Jens-Wolfhard Schicke wrote:
* Does WAL get forced to disk on primary at commit time?
* Does WAL get forced across link to standby at commit time?
* Does WAL get forced to disk on standby at commit time?
* Does WAL get applied [and synced] to disk on standby at commit time?
I think that's
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 about
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 droppi
"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 qualit
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
> -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 fi
"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
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
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, Gregor
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 som
-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 performan
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
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 subscribe
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 ar
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
> transac
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 mec
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 commun
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 t
"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 repositori
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 th
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 b
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.
Ag
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 we
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 I
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 sligh
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 i
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 us
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 proj
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
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
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 don
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
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 co
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;
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 wri
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 i
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
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 n
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
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 foun
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
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, 'c
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.
>
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 inste
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 during
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 ambul
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:
> 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
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 wo
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
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
befor
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
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 th
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
pos
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, b
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 n
On Mon, 2008-07-21 at 23:53 -0400, Owen Hartnett wrote:
> It would generate a schema dump where all the references to
> were replaced by .
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 whether we change the
actua
"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 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. Functio
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])
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 reduct
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
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 m
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])
"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 t
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.
> >
> > C
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 t
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
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 all
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
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
"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 develo
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 production
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 lis
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 fi
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 /usr/postgres/8.3/bin/pltcl
[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
> fo
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 NU
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
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
delete
80 matches
Mail list logo
