Well, it is none of the things I considered.
The problem seems to be due to use of "--delete" in the base backup
rsync (see diff attached). In fact I can now reproduce the
uninitialized pages using the "bare bones" method:
primary:
$ grep archive_command postgresql.conf
archive_command = 'r
On Wed, Dec 29, 2010 at 22:30, Dimitri Fontaine wrote:
> Magnus Hagander writes:
Would people be interested in putting pg_streamrecv
(http://github.com/mhagander/pg_streamrecv) in bin/ or contrib/ for
9.1? I think it would make sense to do so.
>
> +1 for having that in core, only a
On Wed, Dec 29, 2010 at 20:19, Gurjeet Singh wrote:
> On Wed, Dec 29, 2010 at 1:42 PM, Robert Haas wrote:
>>
>> On Dec 29, 2010, at 1:01 PM, Tom Lane wrote:
>> > Is it really stable enough for bin/? My impression of the state of
>> > affairs is that there is nothing whatsoever about replication
On Wed, Dec 29, 2010 at 19:42, Robert Haas wrote:
> On Dec 29, 2010, at 1:01 PM, Tom Lane wrote:
>> Is it really stable enough for bin/? My impression of the state of
>> affairs is that there is nothing whatsoever about replication that
>> is really stable yet.
>
> Well, that's not stopping us f
On 2010-12-30 9:02 AM +0200, Greg Smith wrote:
Marko Tiikkaja wrote:
I have no idea why it worked in the past, but the patch was never
designed to work for UPSERT. This has been discussed in the past and
some people thought that that's not a huge deal.
It takes an excessively large lock when
On Wed, Dec 29, 2010 at 20:12, Alvaro Herrera
wrote:
> Excerpts from Magnus Hagander's message of mié dic 29 11:40:34 -0300 2010:
>> On Wed, Dec 29, 2010 at 15:05, Gurjeet Singh wrote:
>
>> > Any specific reason NOREPLICATION_P and REPLICATION_P use the _P suffix?
>>
>> Um, I just copied it off a
On Thu, Dec 30, 2010 at 6:41 AM, Magnus Hagander wrote:
>> As the README says that is not self-contained (for no fault of its own) and
>> one should typically set archive_command to guarantee zero WAL loss.
>
> Yes. Though you can combine it fine with wal_keep_segments if you
> think that's safe
The snapshot synchronization discussion from the parallel pg_dump
patch somehow ended without a clear way to go forward.
Let me sum up what has been brought up and propose a short- and
longterm solution.
Summary:
Passing snapshot sync information can be done either:
a) by returning complete sna
On Thu, Dec 30, 2010 at 13:30, Aidan Van Dyk wrote:
> On Thu, Dec 30, 2010 at 6:41 AM, Magnus Hagander wrote:
>
>>> As the README says that is not self-contained (for no fault of its own) and
>>> one should typically set archive_command to guarantee zero WAL loss.
>>
>> Yes. Though you can combin
On Thu, Dec 30, 2010 at 3:55 AM, Mark Kirkwood
wrote:
> Well, it is none of the things I considered.
>
> The problem seems to be due to use of "--delete" in the base backup rsync
> (see diff attached). In fact I can now reproduce the uninitialized pages
> using the "bare bones" method:
Any time
Hi!
Are we ready to drop the old git mirror? The one that's still around
(as postgresql-old.git) from before we migrated the main repository to
git, and thus has the old hashes around.
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
--
Sent via pgsql-hac
Excerpts from Magnus Hagander's message of jue dic 30 08:57:09 -0300 2010:
> On Wed, Dec 29, 2010 at 20:12, Alvaro Herrera
> wrote:
> > Some lexer keywords have a _P prefix because otherwise they'd collide
> > with some symbol in Windows header files or something like that. It's
> > old stuff, b
On Tue, Dec 28, 2010 at 16:30, Tom Lane wrote:
> Alvaro Herrera writes:
>> Excerpts from Magnus Hagander's message of mar dic 28 10:46:31 -0300 2010:
>>> Well, yeah, that was obvious ;) The question is, how much do we prefer
>>> the more elegant method? ;)
>
>> If we go the new type route, do we
On Thu, Dec 30, 2010 at 8:31 AM, Magnus Hagander wrote:
> Are we ready to drop the old git mirror? The one that's still around
> (as postgresql-old.git) from before we migrated the main repository to
> git, and thus has the old hashes around.
I see no reason to drop that ever, or at least not any
On Thu, Dec 30, 2010 at 15:28, Robert Haas wrote:
> On Thu, Dec 30, 2010 at 8:31 AM, Magnus Hagander wrote:
>> Are we ready to drop the old git mirror? The one that's still around
>> (as postgresql-old.git) from before we migrated the main repository to
>> git, and thus has the old hashes around.
On 12/30/2010 02:02 AM, Greg Smith wrote:
Marko Tiikkaja wrote:
I have no idea why it worked in the past, but the patch was never
designed to work for UPSERT. This has been discussed in the past and
some people thought that that's not a huge deal.
It takes an excessively large lock when do
Excerpts from Joachim Wieland's message of jue dic 30 09:31:47 -0300 2010:
> Advantage of b: No validation necessary, as soon as the transaction
> that publishes the snapshot loses that snapshot, it will also revoke
> the snapshot information (either by removing a temp file or deleting
> it from s
On Dec27, 2010, at 23:49 , Kevin Grittner wrote:
> Robert Haas wrote:
>
>> With respect to (b), I think I'd need to see a much more detailed
>> design for how you intend to make this work. Off the top of my
>> head there seems to be some pretty serious feasibility problems.
>
> I had one random
On Dec30, 2010, at 13:31 , Joachim Wieland wrote:
> We return snapshot information as a chunk of data to the client. At
> the same time however, we set a checksum in shared memory to protect
> against modification of the snapshot. A publishing backend can revoke
> its snapshot by deleting the check
On Thu, Dec 30, 2010 at 9:30 AM, Magnus Hagander wrote:
> On Thu, Dec 30, 2010 at 15:28, Robert Haas wrote:
>> On Thu, Dec 30, 2010 at 8:31 AM, Magnus Hagander wrote:
>>> Are we ready to drop the old git mirror? The one that's still around
>>> (as postgresql-old.git) from before we migrated the
On tor, 2010-12-23 at 17:29 -0500, Tom Lane wrote:
> Josh Berkus writes:
> > On 12/23/10 2:21 PM, Tom Lane wrote:
> >> Well, that's one laudable goal here, but "secure by default" is another
> >> one that ought to be taken into consideration.
>
> > I don't see how *not* granting the superuser rep
On ons, 2010-12-29 at 11:09 +0100, Magnus Hagander wrote:
> I've applied this version (with some minor typo-fixes).
This page is now somewhat invalidated:
http://developer.postgresql.org/pgdocs/postgres/role-attributes.html
First, it doesn't mention the replication privilege, and second it
conti
On Thu, Dec 30, 2010 at 9:54 AM, Peter Eisentraut wrote:
> On tor, 2010-12-23 at 17:29 -0500, Tom Lane wrote:
>> Josh Berkus writes:
>> > On 12/23/10 2:21 PM, Tom Lane wrote:
>> >> Well, that's one laudable goal here, but "secure by default" is another
>> >> one that ought to be taken into consid
Excerpts from Kevin Grittner's message of mié dic 29 20:46:55 -0300 2010:
> Attached is a small patch to avoid putting an opaque structure into
> the slru.h file and using it in an external function call where
> external callers must always specify NULL.
Thanks, committed.
--
Álvaro Herrera
The
I had an epiphany about this topic, or actually two of them.
1. Whether or not you think there's a significant performance reason
to support hash right joins, there's a functionality reason. The
infrastructure for right join could just as easily do full joins.
And AFAICS, a hash full join would o
On Wed, Dec 29, 2010 at 5:14 PM, David Fetter wrote:
> On Wed, Dec 29, 2010 at 04:53:47PM -0500, Robert Haas wrote:
>> On Wed, Dec 29, 2010 at 4:09 AM, Heikki Linnakangas
>> wrote:
>> > On 29.12.2010 06:54, Robert Haas wrote:
>> >>
>> >> With the patch:
>> >>
>> >> rhaas=# cluster v;
>> >> ERROR
On Thu, Dec 30, 2010 at 10:45 AM, Tom Lane wrote:
> I had an epiphany about this topic, or actually two of them.
>
> 1. Whether or not you think there's a significant performance reason
> to support hash right joins, there's a functionality reason. The
> infrastructure for right join could just a
Magnus Hagander writes:
> But yes, I see in commit 12c942383296bd626131241c012c2ab81b081738 the
> comment "convert some keywords.c symbols to KEYWORD_P to prevent
> conflict".
> Based on that, I should probably change it back, right? I just tried a
> patch for it and it compiles and checks just f
Excerpts from Robert Haas's message of jue dic 30 12:47:42 -0300 2010:
> After further thought, I think it makes sense to change this around a
> bit and create a family of functions that can be invoked like this:
>
> void check_relation_for_FEATURE_support(Relation rel);
>
> ...where FEATURE is
Robert Haas writes:
> On Thu, Dec 30, 2010 at 9:30 AM, Magnus Hagander wrote:
>> On Thu, Dec 30, 2010 at 15:28, Robert Haas wrote:
>>> I see no reason to drop that ever, or at least not any time soon.
>>> What is it costing us?
>> Some disk space, so almost nothing. And the potential that peopl
On Thu, Dec 30, 2010 at 11:00 AM, Alvaro Herrera
wrote:
> Excerpts from Robert Haas's message of jue dic 30 12:47:42 -0300 2010:
>
>> After further thought, I think it makes sense to change this around a
>> bit and create a family of functions that can be invoked like this:
>>
>> void check_relati
On Thu, Dec 30, 2010 at 11:02 AM, Tom Lane wrote:
> Robert Haas writes:
>> On Thu, Dec 30, 2010 at 9:30 AM, Magnus Hagander wrote:
>>> On Thu, Dec 30, 2010 at 15:28, Robert Haas wrote:
I see no reason to drop that ever, or at least not any time soon.
What is it costing us?
>
>>> Some
Robert Haas writes:
> On Thu, Dec 30, 2010 at 10:45 AM, Tom Lane wrote:
>> ... But we only need one bit, so what about commandeering
>> an infomask bit in the tuple itself? For the initial implementation
>> I'd be inclined to take one of the free bits in t_infomask2. We could
>> actually get aw
Robert Haas writes:
> After further thought, I think it makes sense to change this around a
> bit and create a family of functions that can be invoked like this:
> void check_relation_for_FEATURE_support(Relation rel);
That seems like a reasonable idea, but ...
> ... The error message will be of
On Thu, Dec 30, 2010 at 11:50 PM, Robert Haas wrote:
> On Thu, Dec 30, 2010 at 10:45 AM, Tom Lane wrote:
> > I had an epiphany about this topic, or actually two of them.
> >
> > 1. Whether or not you think there's a significant performance reason
> > to support hash right joins, there's a functi
(continuing the flurry of patches)
Here's a patch that stops PL/Python from removing the function's
arguments from its globals dict after calling it. It's
an incremental patch on top of the plpython-refactor patch sent in
http://archives.postgresql.org/message-id/4d135170.3080...@wulczer.org.
Git
Excerpts from Tom Lane's message of jue dic 30 13:49:20 -0300 2010:
> One possibility is to break it down like this:
>
> ERROR: foo is a sequence
> DETAIL: Triggers can only be used on tables and views.
>
> This could still be emitted by a function such as you suggest, and
> indeed that
On Thu, Dec 30, 2010 at 11:49 AM, Tom Lane wrote:
> One possibility is to break it down like this:
>
> ERROR: foo is a sequence
> DETAIL: Triggers can only be used on tables and views.
>
> This could still be emitted by a function such as you suggest, and
> indeed that would be the m
On 12/30/2010 06:26 PM, Simon Riggs wrote:
I've mulled over the design for sync rep for awhile now, and have come
up with a feature set that includes the final detailed feedback from
Fujii Masao, Aidan Van Dyk, Josh Berkus and others.
The design also draws from MySQL concepts to make the two in
Hello,
Last week I had a serious problem with my PostgreSQL database. My autovacuum
is OFF, but in September it started to prevent the transaction wraparoud;
however last week the following message appeared continuously in my log:
WARNING: database "production" must be vacuumed within 4827083 tra
On Dec 29, 2010, at 10:14 PM, Robert Haas wrote:
> +1 for trying to optimize these cases (but maybe after we optimize the
> varchar -> text and varchar(less) -> varchar(more) cases to skip the
> scan altogether).
+1 on getting the obvious cases of varchar and numeric done first; we run into
those
On Thu, 2010-12-30 at 18:42 +0100, Stefan Kaltenbrunner wrote:
> it would help if this would just be a simple text-only description of
> the design that people can actually comment on inline. I don't think
> sending technical design proposals as a pdf (which seems to be written
> in doc-style a
On Thu, Dec 30, 2010 at 12:32 PM, Robert Haas wrote:
> On Thu, Dec 30, 2010 at 11:49 AM, Tom Lane wrote:
>> One possibility is to break it down like this:
>>
>> ERROR: foo is a sequence
>> DETAIL: Triggers can only be used on tables and views.
>>
>> This could still be emitted by a
Dne 30.12.2010 15:43, Florian Pflug napsal(a):
> On Dec27, 2010, at 23:49 , Kevin Grittner wrote:
>> Robert Haas wrote:
>>
>>> With respect to (b), I think I'd need to see a much more detailed
>>> design for how you intend to make this work. Off the top of my
>>> head there seems to be some prett
pete...@gmx.net (Peter Eisentraut) writes:
> On mån, 2010-12-27 at 12:33 -0500, Andrew Dunstan wrote:
>> On a more general point, it would be useful to have some
>> infrastructure for running quality checks like this and publishing
>> the results. We should be way beyond the point where we rely on
On Thu, Dec 30, 2010 at 2:04 PM, Simon Riggs wrote:
> On Thu, 2010-12-30 at 18:42 +0100, Stefan Kaltenbrunner wrote:
>
> > it would help if this would just be a simple text-only description of
> > the design that people can actually comment on inline. I don't think
> > sending technical design pr
Most of your doc uses the terms "primary" and "standby", but a few
instances of "master" and "slave" have slipped in. I think it's better
to stick to consistent terminology.
On Thu, Dec 30, 2010 at 21:04, Simon Riggs wrote:
> With synchronous replication options specified at the application level
Excerpts from Tomas Vondra's message of jue dic 30 16:38:03 -0300 2010:
> > Since the need to regularly VACUUM tables hit by updated or deleted
> > won't go away any time soon, we could piggy-back the bit field
> > rebuilding onto VACUUM to avoid a second scan.
>
> Well, I guess it's a bit more c
On Thu, Dec 30, 2010 at 2:13 AM, Joel Jacobson wrote:
> 2010/12/29 Dimitri Fontaine
>
> Please have a look at getddl:
>>
>> https://github.com/dimitri/getddl
>>
>>
> Nice! Looks like a nifty tool.
> When I tried it, "./getddl.py -f -F /crypt/funcs -d glue", I got the error
> "No such file or di
On Thu, 2010-12-30 at 15:07 -0500, Robert Treat wrote:
> > If more than one standby server specifies synchronous_replication,
> then
> > whichever standby replies first will release waiting commits.
> I don't want you to think I am setting an expectation, but I'm curious
> about the possibility of
On Thu, 2010-12-30 at 15:07 -0500, Robert Treat wrote:
> > We use a single parameter to enable synchronous replication, set in
> > postgresql.conf on both primary and standby servers:
> >
> > synchronous_replication = off (default) | on
> >
> > On the primary, synchronous_replication can be set for
On 12/30/2010 08:04 PM, Simon Riggs wrote:
On Thu, 2010-12-30 at 18:42 +0100, Stefan Kaltenbrunner wrote:
it would help if this would just be a simple text-only description of
the design that people can actually comment on inline. I don't think
sending technical design proposals as a pdf (which
On Thu, Dec 30, 2010 at 3:07 PM, Robert Treat wrote:
>> If primary crashes while commits are waiting for acknowledgement, those
>> transactions will be marked fully committed if the primary database
>> recovers, no matter how allow_standalone_primary is set.
>
> This seems backwards; if you are w
On Thu, Dec 30, 2010 at 3:36 PM, Simon Riggs wrote:
>
> On Thu, 2010-12-30 at 15:07 -0500, Robert Treat wrote:
> > > If more than one standby server specifies synchronous_replication,
> > then
> > > whichever standby replies first will release waiting commits.
>
> > I don't want you to think I am
On Thu, 2010-12-30 at 11:02 -0500, Tom Lane wrote:
> I'm with Magnus on this: the risk of confusion seems to greatly
> outweigh any possible benefit from keeping it. There is no reason for
> anyone to use that old repo unless they are still working with a local
> clone of it, and even if they do h
On Thu, 2010-12-30 at 15:07 -0500, Robert Treat wrote:
> > When allow_standalone_primary is set, a user will stop waiting once
> the
> > replication_timeout has been reached for their specific session.
> Users
> > are not waiting for a specific standby to reply, they are waiting
> for a
> > reply f
On 12/29/2010 07:42 PM, Robert Haas wrote:
On Dec 29, 2010, at 1:01 PM, Tom Lane wrote:
Is it really stable enough for bin/? My impression of the state of
affairs is that there is nothing whatsoever about replication that
is really stable yet.
Well, that's not stopping us from shipping a cor
On Thu, 2010-12-30 at 15:51 -0500, Robert Treat wrote:
> Still, one thing that has me concerned is that in the case of two
> slaves, you don't know which one is the more up-to-date one if you
> need to failover. It'd be nice if you could just guarantee they both
> are...
Regrettably, nobody can k
Tom Lane writes:
> I can't get all *that* excited about complicating hash joins as
> proposed. The query is still fundamentally going to be slow because
> you won't get out of having to seqscan the large table. The only way
> to make it really fast is to not read all of the large table, and
> ne
On 12/30/2010 10:01 PM, Simon Riggs wrote:
On Thu, 2010-12-30 at 15:51 -0500, Robert Treat wrote:
Still, one thing that has me concerned is that in the case of two
slaves, you don't know which one is the more up-to-date one if you
need to failover. It'd be nice if you could just guarantee they
On Thu, 2010-12-30 at 22:11 +0200, Marti Raudsepp wrote:
> I think a comment about the "head-of-line blocking" nature of
> streaming repliaction is in order. If you execute massive writes in
> async mode and then run a transaction in sync mode, its commit will be
> delayed until all the async tran
On Thu, 2010-12-30 at 21:42 +0100, Stefan Kaltenbrunner wrote:
> >
> > Synchronous replication offers the ability to guarantee that all changes
> > made by a transaction have been transferred to at least one remote
> > standby server. This is an extension to the standard level of durability
> > off
On Thu, Dec 30, 2010 at 2:04 PM, Simon Riggs wrote:
> We use a single parameter to enable synchronous replication, set in
> postgresql.conf on both primary and standby servers:
>
> synchronous_replication = off (default) | on
>
> On the primary, synchronous_replication can be set for particular us
On Thu, 2010-12-30 at 22:08 +0100, Stefan Kaltenbrunner wrote:
> On 12/30/2010 10:01 PM, Simon Riggs wrote:
> > On Thu, 2010-12-30 at 15:51 -0500, Robert Treat wrote:
> >
> >> Still, one thing that has me concerned is that in the case of two
> >> slaves, you don't know which one is the more up-to-d
On 30.12.2010 16:49, Florian Pflug wrote:
On Dec30, 2010, at 13:31 , Joachim Wieland wrote:
We return snapshot information as a chunk of data to the client. At
the same time however, we set a checksum in shared memory to protect
against modification of the snapshot. A publishing backend can revo
On Thu, Dec 30, 2010 at 3:42 PM, Stefan Kaltenbrunner
wrote:
>> synchronous replication for high performance applications. This feature
>> is unique to PostgreSQL.
>
> that seems to be a bit too much marketing for a reference level document
+1.
> It also does not address the more general (not sy
On 30.12.2010 10:55, Mark Kirkwood wrote:
Removing the offending
--delete --exclude=backup_label
options from the base backup step makes everything work properly again.
I don't see why --delete would make any difference, but you shouldn't
exclude backup_label from the base backup. The backup
On 31/12/10 11:01, Heikki Linnakangas wrote:
On 30.12.2010 10:55, Mark Kirkwood wrote:
Removing the offending
--delete --exclude=backup_label
options from the base backup step makes everything work properly again.
I don't see why --delete would make any difference, but you shouldn't
exclude
On 31/12/10 11:11, Mark Kirkwood wrote:
Yes, you (and Robert) are entirely correct, I was confused in my
understanding of the "--delete --exclude=backup_label" and thought it
to mean "exclude the backup label from the delete". Yeah the --delete
is harmless, it is the exclude backup_label that
On Dec 30, 2010, at 3:27 PM, Robert Haas wrote:
>> synchronous_replication (boolean)
>>Specifies whether transaction commit will wait for WAL records
>>to be replicated before the command returns a "success"
>>indication to the client.
>
> The word "replicated" here could b
On Thu, 2010-12-30 at 16:27 -0500, Robert Haas wrote:
> I think it's a bad idea to use the same parameter to mean different
> things on the master and standby.
Obviously if you phrase it like that, nobody would disagree. I would say
I have used the same parameter on both sides in a balanced way
On Thu, 2010-12-30 at 16:47 -0500, Robert Haas wrote:
> On Thu, Dec 30, 2010 at 3:42 PM, Stefan Kaltenbrunner
> wrote:
> >> synchronous replication for high performance applications. This feature
> >> is unique to PostgreSQL.
> >
> > that seems to be a bit too much marketing for a reference level
On Thu, Dec 30, 2010 at 12:57:45AM -0500, Robert Haas wrote:
> On Thu, Dec 30, 2010 at 12:24 AM, Noah Misch wrote:
> > On Wed, Dec 29, 2010 at 11:14:37PM -0500, Robert Haas wrote:
> >> I think for any pair of types (T1, T2) we should first determine
> >> whether we can skip the scan altogether. ?I
On Thu, 2010-12-30 at 18:47 -0600, Jim Nasby wrote:
> On Dec 30, 2010, at 3:27 PM, Robert Haas wrote:
> >> synchronous_replication (boolean)
> >>Specifies whether transaction commit will wait for WAL records
> >>to be replicated before the command returns a "success"
> >>ind
On Thu, 2010-12-30 at 16:47 -0500, Robert Haas wrote:
> > It also does not address the more general (not sync rep specific) problem of
> > how to deal with max_keep_segments which is a wart and I was hoping we could
> > get rid of in 9.1 - but it would require a real standby registration or at
> >
Robert Haas writes:
> On further reflection, this can still turn into a laundry list in certain
> cases.
> DETAIL: You can only comment on columns of tables, views, and composite types.
> seems less helpful than:
> DETAIL: Comments on relations with system-generated column names are
> not supp
Alvaro Herrera writes:
> I was thinking that we could have two different ANALYZE modes, one
> "full" and one "incremental"; autovacuum could be modified to use one or
> the other depending on how many changes there are (of course, the user
> could request one or the other, too; not sure what shoul
Jeff Davis writes:
> Personally, my utility for the old repo is not much (if it was anything
> important, I wouldn't have relied on the unofficial repo). But we should
> probably give a little bit of warning for folks that might want to
> rebase or translate some old notes.
Well, I guess the ques
On Thu, Dec 30, 2010 at 8:58 PM, Tom Lane wrote:
> Robert Haas writes:
>> On further reflection, this can still turn into a laundry list in certain
>> cases.
>
>> DETAIL: You can only comment on columns of tables, views, and composite
>> types.
>
>> seems less helpful than:
>
>> DETAIL: Comment
Robert Haas writes:
> I think this thread has worked itself around to where it's entirely
> pointless.
I understand your frustration, but it's not clear to me that there *is*
any simple solution to this problem. Fundamentally, adding new relkinds
to the system is always going to require running
On Thu, Dec 30, 2010 at 9:40 AM, Alvaro Herrera
wrote:
>> Disadvantage of b: It doesn't allow a snapshot to be installed on a
>> different server. It requires a serializable open transaction to hold
>> the snapshot.
>
> Why does it require a serializable transaction? You could simply
> register t
On Thu, Dec 30, 2010 at 9:49 AM, Florian Pflug wrote:
> On Dec30, 2010, at 13:31 , Joachim Wieland wrote:
>> We return snapshot information as a chunk of data to the client. At
>> the same time however, we set a checksum in shared memory to protect
>> against modification of the snapshot. A publis
On Thu, Dec 30, 2010 at 03:24:09PM -0500, Aidan Van Dyk wrote:
> On Thu, Dec 30, 2010 at 3:07 PM, Robert Treat wrote:
>
> >> If primary crashes while commits are waiting for acknowledgement, those
> >> transactions will be marked fully committed if the primary database
> >> recovers, no matter ho
On Thu, Dec 30, 2010 at 8:57 PM, Simon Riggs wrote:
> I'm not very clear what your response has to do with Stefan's comments.
>
> My general perspective is that MySQL released a simple design a year
> ahead of us, which should be to our collective shame. I will be working
> towards delivering some
On Thu, Dec 30, 2010 at 9:30 PM, Tom Lane wrote:
> Robert Haas writes:
>> I think this thread has worked itself around to where it's entirely
>> pointless.
>
> I understand your frustration, but it's not clear to me that there *is*
> any simple solution to this problem. Fundamentally, adding new
On Thu, Dec 30, 2010 at 12:56 PM, JotaComm wrote:
> Last week I had a serious problem with my PostgreSQL database. My autovacuum
> is OFF, but in September it started to prevent the transaction wraparoud;
> however last week the following message appeared continuously in my log:
>
> WARNING: datab
On Thu, Dec 30, 2010 at 8:35 PM, Noah Misch wrote:
> 4. A FuncExpr node has answers given by the bitwise-AND of its funcexempt
> field
> and the answers from its first argument.
Why its first argument?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
On Fri, Dec 31, 2010 at 12:34:50AM -0500, Robert Haas wrote:
> On Thu, Dec 30, 2010 at 8:35 PM, Noah Misch wrote:
> > 4. A FuncExpr node has answers given by the bitwise-AND of its funcexempt
> > field
> > and the answers from its first argument.
>
> Why its first argument?
funcexempt would onl
On 30.12.2010 22:27, Robert Haas wrote:
On Thu, Dec 30, 2010 at 2:04 PM, Simon Riggs wrote:
synchronous_replication (boolean)
Specifies whether transaction commit will wait for WAL records
to be replicated before the command returns a "success"
indication to the client.
On 31.12.2010 6:02, Robert Haas wrote:
On Thu, Dec 30, 2010 at 8:57 PM, Simon Riggs wrote:
I'm not very clear what your response has to do with Stefan's comments.
My general perspective is that MySQL released a simple design a year
ahead of us, which should be to our collective shame. I will b
90 matches
Mail list logo
