On fre, 2010-06-11 at 08:15 -0400, Stephen Frost wrote:
> * Pr, Solaiyappan (NSN - IN/Bangalore) (solaiyappan...@nsn.com) wrote:
> > I understand this is very early to ask this.. but, is there any tentative
> > timeline has been planned / available for the PostgreSQL 9.1 release, like
> > for the
Andrew Dunstan wrote:
>
> Why does pg_upgrade create its output directory in the user's home
> directory (or TMP on Windows)? I should have thought that the current
> working directory would be a more suitable choice. At the very least
> there should be an option for where to create it. Also,
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hello
I am testing HS + SR in a system running 9.0beta2. What I am doing is
just trying all kind of crazy combinations and see how the system
handles them.
One of the test I knew was going to fail was to create a tablespace in
the master node with th
Robert Haas wrote:
> > If my streaming replication stops working, I want to know about it as
> > soon as possible. WARNING just doesn't cut it.
> >
> > This needs some better thought.
> >
> > If we PANIC, then surely it will PANIC again when we restart unless we
> > do something. So we can't do tha
> Hm, but then Robert's failure case is real, and streaming replication might
> break due to an OS-level crash of the master. Or am I missing something?
Well, in the failover case this isn't a problem, it's a benefit: the
standby gets a transaction which you would have lost off the master.
Howev
On Fri, Jun 11, 2010 at 5:23 PM, Tom Lane wrote:
> Joseph Adams writes:
>> To repeat an earlier question (which was in turn repeating an earlier
>> question), would it be possible to do one of these, yielding '
>> "key"=>"this", "key2"=>"that" '::hstore :
>
>> hstore(key := 'this', key2 := 'that
On Jun 11, 2010, at 16:31 , Tom Lane wrote:
> Fujii Masao writes:
>> In 9.0, walsender reads WAL always from the disk and sends it to the standby.
>> That is, we cannot send WAL until it has been written (and flushed) to the
>> disk.
>
> I believe the above statement to be incorrect: walsender d
Josh Berkus writes:
>> Looks like someone accidentally deleted the -Z option from vacuumdb.
Forgot to add it in the first place, looks like.
>> Patch attached, one character. ;-)
> Make that 3 characters; Jan pointed out that we ought to have the
> command-string in the same order as the switc
On 6/11/10 3:44 PM, Josh Berkus wrote:
> Folks,
>
> Looks like someone accidentally deleted the -Z option from vacuumdb.
> Patch attached, one character. ;-)
Make that 3 characters; Jan pointed out that we ought to have the
command-string in the same order as the switch options.
--
Folks,
Looks like someone accidentally deleted the -Z option from vacuumdb.
Patch attached, one character. ;-)
(thanks Gabrielle, and Jan Urbanski)
--
-- Josh Berkus
PostgreSQL Experts Inc.
> Well, we're already not waiting for fsync, which is the slowest part.
> If there's a performance problem, it may be because FADVISE_DONTNEED
> disables kernel buffering so that we're forced to actually read the data
> back from disk before sending it on down the wire.
Well, that's fairly direct
Joseph Adams writes:
> To repeat an earlier question (which was in turn repeating an earlier
> question), would it be possible to do one of these, yielding '
> "key"=>"this", "key2"=>"that" '::hstore :
> hstore(key := 'this', key2 := 'that')
> hstore(key => 'this', key2 => 'that')
> hstore(row('
On Fri, Jun 11, 2010 at 10:59 AM, Tom Lane wrote:
> Peter Eisentraut writes:
>> How about no operator at all? It won't be as cool to read, but
>> consider, the arguments are text and text, not involving any hstore type
>> at all, so whatever operator you choose is in practice blocked from
>> eve
Heikki Linnakangas writes:
> So to clean up all WAL files older than those needed by that base backup,
> you would simply copy-paste that location and call pg_cleanuparchive:
>
> pg_cleanuparchive /walarchive/ 0001002F
Ok, idle though: what about having a superuser-only SRF doing
On Fri, Jun 11, 2010 at 19:12, Andres Freund wrote:
> On Thursday 10 June 2010 19:30:00 Magnus Hagander wrote:
>> On Thu, Jun 10, 2010 at 18:20, Stephen Frost wrote:
>> > * Andrew Dunstan (and...@dunslane.net) wrote:
>> >> I don't see why not. Buildfarm members are going to have to reset their
>>
On Thursday 10 June 2010 19:30:00 Magnus Hagander wrote:
> On Thu, Jun 10, 2010 at 18:20, Stephen Frost wrote:
> > * Andrew Dunstan (and...@dunslane.net) wrote:
> >> I don't see why not. Buildfarm members are going to have to reset their
> >> repos when we finally cut over in a few months. Luckily
On Jun 11, 2010, at 9:58 AM, Tom Lane wrote:
>> That would make it so that the use of => in hstore strings would be less
>> consistent. Makes sense to me.
>
> Less inconsistent, ITYM? But yeah, then we would have no reason to
> fiddle with hstore_in, which is good.
Yes, sorry.
David
--
Sen
"David E. Wheeler" writes:
> On Jun 11, 2010, at 7:59 AM, Tom Lane wrote:
>> Yeah, that's a good point. Maybe we should just deprecate the operator
>> altogether.
> That would make it so that the use of => in hstore strings would be less
> consistent. Makes sense to me.
Less inconsistent, ITYM
* Andrew Dunstan (and...@dunslane.net) wrote:
> Luxenberg, Scott I. wrote:
> >I have been trying to create/run a build farm as part of a project I am
> >working on.
>
> That seems an odd thing to do since we have one ...
To clarify, he's setting up a build farm *member*. :)
> >However, I have no
On Jun 11, 2010, at 7:59 AM, Tom Lane wrote:
>> How about no operator at all? It won't be as cool to read, but
>> consider, the arguments are text and text, not involving any hstore type
>> at all, so whatever operator you choose is in practice blocked from
>> everyone everywhere. No one could e
Takahiro Itagaki writes:
> Peter Eisentraut wrote:
>> max_locks_per_xact != max_locks_per_xact)
>>
>> Looks like a bug.
> Ah, it should be compared with the same name field in ControlFile.
Yeah, obvious typo, please commit.
regards, tom lane
--
Sent via pgsql-hackers
On 06/11/2010 04:47 PM, Tom Lane wrote:
Stefan Kaltenbrunner writes:
hmm not sure that is what fujii tried to say - I think his point was
that in the original case we would have serialized all the operations
(first write+sync on the master, network afterwards and write+sync on
the slave) and no
Peter Eisentraut writes:
> How about no operator at all? It won't be as cool to read, but
> consider, the arguments are text and text, not involving any hstore type
> at all, so whatever operator you choose is in practice blocked from
> everyone everywhere. No one could ever implement another ke
Hi,
per $SUBJECT.
Cheers,
Jan
diff --git a/src/test/regress/pg_regress.c b/src/test/regress/pg_regress.c
index 9de4189..ebdf812 100644
--- a/src/test/regress/pg_regress.c
+++ b/src/test/regress/pg_regress.c
@@ -1870,6 +1870,7 @@ help(void)
printf(_("(can be used mult
Peter Eisentraut writes:
>>> Btw., the SQL standard also defines -> for something else, so if you
>>> wanted to be really visionary, you could deprecate that one as an
>>> operator at the same time.
>>
>> Ouch. What does it define it to mean?
> Similar to C: Dereferencing a reference and access
Stefan Kaltenbrunner writes:
> hmm not sure that is what fujii tried to say - I think his point was
> that in the original case we would have serialized all the operations
> (first write+sync on the master, network afterwards and write+sync on
> the slave) and now we could try parallelizing by
On 06/11/2010 04:31 PM, Tom Lane wrote:
Fujii Masao writes:
In 9.0, walsender reads WAL always from the disk and sends it to the standby.
That is, we cannot send WAL until it has been written (and flushed) to the disk.
I believe the above statement to be incorrect: walsender does *not* wait
f
Fujii Masao writes:
> In 9.0, walsender reads WAL always from the disk and sends it to the standby.
> That is, we cannot send WAL until it has been written (and flushed) to the
> disk.
I believe the above statement to be incorrect: walsender does *not* wait
for an fsync to occur.
I agree with t
On Fri, Jun 11, 2010 at 9:57 AM, Fujii Masao wrote:
> On Fri, Jun 11, 2010 at 10:22 PM, Robert Haas wrote:
>> On Fri, Jun 11, 2010 at 9:14 AM, Fujii Masao wrote:
>>> Thought? Comment? Objection?
>>
>> What happens if the WAL is streamed to the standby and then the master
>> crashes without writi
On Fri, Jun 11, 2010 at 10:22 PM, Robert Haas wrote:
> On Fri, Jun 11, 2010 at 9:14 AM, Fujii Masao wrote:
>> Thought? Comment? Objection?
>
> What happens if the WAL is streamed to the standby and then the master
> crashes without writing that WAL to disk?
What are you concerned about?
I think
On Fri, Jun 11, 2010 at 9:43 AM, Simon Riggs wrote:
> On Thu, 2010-06-10 at 19:01 +0300, Heikki Linnakangas wrote:
>> >
>> > What "warning message" are we talking about? All the error cases I can
>> > think of in WAL-application are ERROR, or likely even PANIC.
>>
>> We're talking about a corrupt
Why does pg_upgrade create its output directory in the user's home
directory (or TMP on Windows)? I should have thought that the current
working directory would be a more suitable choice. At the very least
there should be an option for where to create it. Also, this location
doesn't seem to
On Thu, 2010-06-10 at 19:01 +0300, Heikki Linnakangas wrote:
> >
> > What "warning message" are we talking about? All the error cases I can
> > think of in WAL-application are ERROR, or likely even PANIC.
>
> We're talking about a corrupt record (incorrect CRC, incorrect backlink
> etc.), not er
On Fri, Jun 11, 2010 at 9:32 PM, Heikki Linnakangas
wrote:
> Hmm, right now it doesn't even reconnect when it sees a corrupt record
> streamed from the master. It's really pointless to retry in that case,
> reapplying the exact same piece of WAL surely won't work. I think it should
> disconnect, a
On Fri, Jun 11, 2010 at 9:14 AM, Fujii Masao wrote:
> Thought? Comment? Objection?
What happens if the WAL is streamed to the standby and then the master
crashes without writing that WAL to disk?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company
--
Sent
On Fri, Jun 11, 2010 at 7:25 PM, Heikki Linnakangas
wrote:
> Yeah, there's clearly a mismatch. I think "Hot Standby" is the right place,
> altough you could argue that it should be together with
> vacuum_freeze_min_age and vacuum_freeze_table_age too.
>
> We seem to be missing an entry for "Write-
On Fri, Jun 11, 2010 at 8:19 AM, Simon Riggs wrote:
> On Thu, 2010-06-10 at 09:57 -0400, Robert Haas wrote:
>> On Mon, Jun 7, 2010 at 9:21 AM, Fujii Masao
>> wrote:
>> > When an error is found in the WAL streamed from the master, a
>> warning
>> > message is repeated without interval forever in t
Hi,
In 9.0, walsender reads WAL always from the disk and sends it to the standby.
That is, we cannot send WAL until it has been written (and flushed) to the disk.
This degrades the performance of synchronous replication very much since a
transaction commit must wait for the WAL write time *plus* t
On 06/11/2010 02:25 PM, Devrim GÜNDÜZ wrote:
On Fri, 2010-06-11 at 19:56 +0800, Pr, Solaiyappan (NSN - IN/Bangalore)
wrote:
Also, is there any synchronous replication patch planned for the
PostgreSQL 9.0 version?
Cybertec announced new version of Cybercluster, which includes sync
replication -
On Fri, Jun 11, 2010 at 7:14 PM, Heikki Linnakangas
wrote:
> On 09/06/10 08:24, Fujii Masao wrote:
>>
>> On Wed, Jun 9, 2010 at 12:52 PM, Andrew Dunstan
>> wrote:
>>>
>>> There is precedent for .pgpass being a bit ambiguous. See the way
>>> "localhost" is used.
>>
>> OK. The attached patch allows
Devrim GÜNDÜZ wrote:
On Fri, 2010-06-11 at 19:56 +0800, Pr, Solaiyappan (NSN - IN/Bangalore)
wrote:
Also, is there any synchronous replication patch planned for the
PostgreSQL 9.0 version?
Cybertec announced new version of Cybercluster, which includes sync
replication -- I haven't tested it th
On 11/06/10 07:18, Fujii Masao wrote:
On Fri, Jun 11, 2010 at 1:01 AM, Heikki Linnakangas
wrote:
We're talking about a corrupt record (incorrect CRC, incorrect backlink
etc.), not errors within redo functions. During crash recovery, a corrupt
record means you've reached end of WAL. In standby
On Fri, 2010-06-11 at 19:56 +0800, Pr, Solaiyappan (NSN - IN/Bangalore)
wrote:
> Also, is there any synchronous replication patch planned for the
> PostgreSQL 9.0 version?
Cybertec announced new version of Cybercluster, which includes sync
replication -- I haven't tested it though.
--
Devrim GÜND
On Thu, 2010-06-10 at 09:57 -0400, Robert Haas wrote:
> On Mon, Jun 7, 2010 at 9:21 AM, Fujii Masao
> wrote:
> > When an error is found in the WAL streamed from the master, a
> warning
> > message is repeated without interval forever in the standby. This
> > consumes CPU load very much, and would
* Pr, Solaiyappan (NSN - IN/Bangalore) (solaiyappan...@nsn.com) wrote:
> I understand this is very early to ask this.. but, is there any tentative
> timeline has been planned / available for the PostgreSQL 9.1 release, like
> for the alpha or beta releases before the general release?
The tentati
* Magnus Hagander (mag...@hagander.net) wrote:
> On Fri, Jun 11, 2010 at 14:07, Stephen Frost wrote:
> > I definitely like the idea but I dislike requiring the user to do
> > something to implement it. Thinking about how packagers might want to
> > use it, could we make it possible to build it de
Hi,
I understand this is very early to ask this.. but, is there any tentative
timeline has been planned / available for the PostgreSQL 9.1 release, like for
the alpha or beta releases before the general release?
Also, is there any synchronous replication patch planned for the PostgreSQL 9.0
ve
On Fri, Jun 11, 2010 at 14:07, Stephen Frost wrote:
> * Peter Eisentraut (pete...@gmx.net) wrote:
>> The patch needs some portability work and possible refactoring because
>> of that, but before I embark on that, comments on the concept?
>
> I definitely like the idea but I dislike requiring the u
* Peter Eisentraut (pete...@gmx.net) wrote:
> The patch needs some portability work and possible refactoring because
> of that, but before I embark on that, comments on the concept?
I definitely like the idea but I dislike requiring the user to do
something to implement it. Thinking about how pac
On tis, 2010-06-08 at 10:05 -0400, Tom Lane wrote:
> Perhaps the correct fix would be to mark stored query trees as having
> a
> dependency on the index, so that dropping the index/constraint would
> force a drop of the rule too. Just pushing the check to plan time, as
> I suggested yesterday, isn
On tis, 2010-06-08 at 10:21 -0400, Tom Lane wrote:
> The question is why bother to recognize *any* cases of this form.
> I find it really semantically ugly to have the parser effectively
> doing one deduction of this form when the main engine for that type
> of deduction is elsewhere; so unless the
On Sun, May 30, 2010 at 13:00, Peter Eisentraut wrote:
> It has been discussed several times in the past that there is no way for
> a client to authenticate a server over Unix-domain sockets. So
> depending on circumstances, a local user could easily insert his own
> server and collect passwords
On Sun, May 30, 2010 at 13:00, Peter Eisentraut wrote:
> It has been discussed several times in the past that there is no way for
> a client to authenticate a server over Unix-domain sockets. So
> depending on circumstances, a local user could easily insert his own
> server and collect passwords
On tis, 2010-06-08 at 15:38 -0400, Robert Haas wrote:
> I'm happy to do whatever the consensus is. I thought it would be
> easier to remember if the two operators were spelled at least somewhat
> similarly, but I just work here.
How about no operator at all? It won't be as cool to read, but
cons
On fre, 2010-06-11 at 07:10 -0400, Robert Haas wrote:
> On Fri, Jun 11, 2010 at 2:51 AM, Peter Eisentraut wrote:
> > On tis, 2010-06-08 at 16:17 -0400, Robert Haas wrote:
> >> > Perhaps
> >> > ->
> >>
> >> That's already in use to mean something else.
> >
> > Btw., the SQL standard also defines ->
On Fri, Jun 11, 2010 at 2:51 AM, Peter Eisentraut wrote:
> On tis, 2010-06-08 at 16:17 -0400, Robert Haas wrote:
>> > Perhaps
>> > ->
>>
>> That's already in use to mean something else.
>
> Btw., the SQL standard also defines -> for something else, so if you
> wanted to be really visionary, you co
On 11/06/10 05:36, Fujii Masao wrote:
vacuum_defer_cleanup_age is categorized as "Statement Behavior"
parameter in the document. On the other hand, it's categorized
as "Hot Standby" one in postgresql.conf. Why do we need to do so?
Yeah, there's clearly a mismatch. I think "Hot Standby" is the r
On 09/06/10 08:24, Fujii Masao wrote:
On Wed, Jun 9, 2010 at 12:52 PM, Andrew Dunstan wrote:
There is precedent for .pgpass being a bit ambiguous. See the way
"localhost" is used.
OK. The attached patch allows us to use "replication" in the database
field of the .pgpass file, for the replicat
> Why are you cloning over http?
Me too I've used http, since I'm behind a proxy and I couldn't
find a "simple" way of having the git:// method working behind
a proxy...
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.pos
59 matches
Mail list logo
