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 =
On Wed, Dec 29, 2010 at 22:30, Dimitri Fontaine dimi...@2ndquadrant.fr wrote:
Magnus Hagander mag...@hagander.net 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
On Wed, Dec 29, 2010 at 20:19, Gurjeet Singh singh.gurj...@gmail.com wrote:
On Wed, Dec 29, 2010 at 1:42 PM, Robert Haas robertmh...@gmail.com wrote:
On Dec 29, 2010, at 1:01 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Is it really stable enough for bin/? My impression of the state of
affairs
On Wed, Dec 29, 2010 at 19:42, Robert Haas robertmh...@gmail.com wrote:
On Dec 29, 2010, at 1:01 PM, Tom Lane t...@sss.pgh.pa.us 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.
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
alvhe...@commandprompt.com 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 singh.gurj...@gmail.com wrote:
Any specific reason NOREPLICATION_P and REPLICATION_P use the
On Thu, Dec 30, 2010 at 6:41 AM, Magnus Hagander mag...@hagander.net 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
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
On Thu, Dec 30, 2010 at 13:30, Aidan Van Dyk ai...@highrise.ca wrote:
On Thu, Dec 30, 2010 at 6:41 AM, Magnus Hagander mag...@hagander.net 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.
On Thu, Dec 30, 2010 at 3:55 AM, Mark Kirkwood
mark.kirkw...@catalyst.net.nz 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
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
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
alvhe...@commandprompt.com wrote:
Some lexer keywords have a _P prefix because otherwise they'd collide
with some symbol in Windows header files or something like that.
On Tue, Dec 28, 2010 at 16:30, Tom Lane t...@sss.pgh.pa.us wrote:
Alvaro Herrera alvhe...@commandprompt.com 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
On Thu, Dec 30, 2010 at 8:31 AM, Magnus Hagander mag...@hagander.net 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
On Thu, Dec 30, 2010 at 15:28, Robert Haas robertmh...@gmail.com wrote:
On Thu, Dec 30, 2010 at 8:31 AM, Magnus Hagander mag...@hagander.net 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,
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
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
On Dec27, 2010, at 23:49 , Kevin Grittner wrote:
Robert Haas robertmh...@gmail.com 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
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 checksum
On Thu, Dec 30, 2010 at 9:30 AM, Magnus Hagander mag...@hagander.net wrote:
On Thu, Dec 30, 2010 at 15:28, Robert Haas robertmh...@gmail.com wrote:
On Thu, Dec 30, 2010 at 8:31 AM, Magnus Hagander mag...@hagander.net wrote:
Are we ready to drop the old git mirror? The one that's still around
On tor, 2010-12-23 at 17:29 -0500, Tom Lane wrote:
Josh Berkus j...@agliodbs.com 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
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
On Thu, Dec 30, 2010 at 9:54 AM, Peter Eisentraut pete...@gmx.net wrote:
On tor, 2010-12-23 at 17:29 -0500, Tom Lane wrote:
Josh Berkus j...@agliodbs.com 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
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
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
On Wed, Dec 29, 2010 at 5:14 PM, David Fetter da...@fetter.org 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
heikki.linnakan...@enterprisedb.com wrote:
On 29.12.2010 06:54, Robert Haas wrote:
With the patch:
On Thu, Dec 30, 2010 at 10:45 AM, Tom Lane t...@sss.pgh.pa.us 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
Magnus Hagander mag...@hagander.net 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
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 robertmh...@gmail.com writes:
On Thu, Dec 30, 2010 at 9:30 AM, Magnus Hagander mag...@hagander.net wrote:
On Thu, Dec 30, 2010 at 15:28, Robert Haas robertmh...@gmail.com wrote:
I see no reason to drop that ever, or at least not any time soon.
What is it costing us?
Some disk
On Thu, Dec 30, 2010 at 11:00 AM, Alvaro Herrera
alvhe...@commandprompt.com 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:
On Thu, Dec 30, 2010 at 11:02 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Thu, Dec 30, 2010 at 9:30 AM, Magnus Hagander mag...@hagander.net wrote:
On Thu, Dec 30, 2010 at 15:28, Robert Haas robertmh...@gmail.com wrote:
I see no reason to drop that ever,
Robert Haas robertmh...@gmail.com writes:
On Thu, Dec 30, 2010 at 10:45 AM, Tom Lane t...@sss.pgh.pa.us 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
Robert Haas robertmh...@gmail.com 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
On Thu, Dec 30, 2010 at 11:50 PM, Robert Haas robertmh...@gmail.com wrote:
On Thu, Dec 30, 2010 at 10:45 AM, Tom Lane t...@sss.pgh.pa.us 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
(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.
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 would
On Thu, Dec 30, 2010 at 11:49 AM, Tom Lane t...@sss.pgh.pa.us 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
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
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
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 a
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 as
On Thu, Dec 30, 2010 at 12:32 PM, Robert Haas robertmh...@gmail.com wrote:
On Thu, Dec 30, 2010 at 11:49 AM, Tom Lane t...@sss.pgh.pa.us 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
Dne 30.12.2010 15:43, Florian Pflug napsal(a):
On Dec27, 2010, at 23:49 , Kevin Grittner wrote:
Robert Haas robertmh...@gmail.com 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
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 si...@2ndquadrant.com 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
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 si...@2ndquadrant.com wrote:
With synchronous replication options specified at the
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
On Thu, Dec 30, 2010 at 2:13 AM, Joel Jacobson j...@gluefinance.com wrote:
2010/12/29 Dimitri Fontaine dimi...@2ndquadrant.fr
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
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 particular
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
On Thu, Dec 30, 2010 at 3:07 PM, Robert Treat r...@xzilla.net 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
On Thu, Dec 30, 2010 at 3:36 PM, Simon Riggs si...@2ndquadrant.com 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
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 have
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 from any
On 12/29/2010 07:42 PM, Robert Haas wrote:
On Dec 29, 2010, at 1:01 PM, Tom Lanet...@sss.pgh.pa.us 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
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 know
Tom Lane t...@sss.pgh.pa.us 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
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
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
offered by a
On Thu, Dec 30, 2010 at 2:04 PM, Simon Riggs si...@2ndquadrant.com 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
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-date one if
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
On Thu, Dec 30, 2010 at 3:42 PM, Stefan Kaltenbrunner
ste...@kaltenbrunner.cc 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
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
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
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 is
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 be taken to
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
ste...@kaltenbrunner.cc wrote:
synchronous replication for high performance applications. This feature
is unique to PostgreSQL.
that seems to be a bit too much marketing for a
On Thu, Dec 30, 2010 at 12:57:45AM -0500, Robert Haas wrote:
On Thu, Dec 30, 2010 at 12:24 AM, Noah Misch n...@leadboat.com 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
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
indication to the
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
least
Robert Haas robertmh...@gmail.com 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
Alvaro Herrera alvhe...@commandprompt.com 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;
Jeff Davis pg...@j-davis.com 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
On Thu, Dec 30, 2010 at 8:58 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com 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
Robert Haas robertmh...@gmail.com 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
On Thu, Dec 30, 2010 at 9:40 AM, Alvaro Herrera
alvhe...@commandprompt.com 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
On Thu, Dec 30, 2010 at 9:49 AM, Florian Pflug f...@phlo.org 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
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 r...@xzilla.net wrote:
If primary crashes while commits are waiting for acknowledgement, those
transactions will be marked fully committed if the primary database
recovers, no
On Thu, Dec 30, 2010 at 8:57 PM, Simon Riggs si...@2ndquadrant.com 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
On Thu, Dec 30, 2010 at 9:30 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com 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
On Thu, Dec 30, 2010 at 12:56 PM, JotaComm jota.c...@gmail.com 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:
On Thu, Dec 30, 2010 at 8:35 PM, Noah Misch n...@leadboat.com 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
On Fri, Dec 31, 2010 at 12:34:50AM -0500, Robert Haas wrote:
On Thu, Dec 30, 2010 at 8:35 PM, Noah Misch n...@leadboat.com 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
On 30.12.2010 22:27, Robert Haas wrote:
On Thu, Dec 30, 2010 at 2:04 PM, Simon Riggssi...@2ndquadrant.com wrote:
synchronous_replication (boolean)
Specifies whether transaction commit will wait for WAL records
to be replicated before the command returns a success
On 31.12.2010 6:02, Robert Haas wrote:
On Thu, Dec 30, 2010 at 8:57 PM, Simon Riggssi...@2ndquadrant.com 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
90 matches
Mail list logo
