1) Today you can do a backup by just calling pg_start_backup('x'); copy
the data directory and
pg_stop_backup(); You do not need to use pg_basebackup to create a
backup. The solution you are proposing would require pg_basebackup to be
used to build backups from standby servers.
YES.
2)
On Jun 23, 2011, at 12:52 AM, Alvaro Herrera wrote:
Excerpts from Joshua D. Drake's message of mié jun 22 15:37:17 -0400 2011:
Per:
http://archives.postgresql.org/pgsql-hackers/2010-11/msg02043.php
It seems we did come up with a use case in the procpid discussion. The
ability to change
On Jun 23, 2011, at 12:52 AM, Alvaro Herrera wrote:
Excerpts from Joshua D. Drake's message of mié jun 22 15:37:17 -0400 2011:
Per:
http://archives.postgresql.org/pgsql-hackers/2010-11/msg02043.php
It seems we did come up with a use case in the procpid discussion. The
ability to change
On Wed, Jun 22, 2011 at 02:31:01PM +0200, Rados??aw Smogura wrote:
I strictly disagree with opinion if there is 1% it's worthless. 1%
here, 1% there, and finally You get 10%, but of course hugepages
will work quite well if will be used in code that require many
random jumps. I think this can
Martijn van Oosterhout klep...@svana.org Thursday 23 of June 2011 09:10:20
On Wed, Jun 22, 2011 at 02:31:01PM +0200, Rados??aw Smogura wrote:
I strictly disagree with opinion if there is 1% it's worthless. 1%
here, 1% there, and finally You get 10%, but of course hugepages
will work quite
I revised my patch based on your there-is-no-try-v2.patch.
It enabled to implement 'missing_ok' support without modification of
orders to solve the object name and relation locking.
Thanks,
2011/6/22 Robert Haas robertmh...@gmail.com:
On Wed, Jun 22, 2011 at 12:51 PM, Alvaro Herrera
2011/6/23 Merlin Moncure mmonc...@gmail.com
On Jun 6 (
http://archives.postgresql.org/pgsql-hackers/2011-06/msg00272.php),
Pavel discovered an issue with PQsetvalue that could cause libpq to
wander off into unallocated memory that was present in 9.0.x. A
fairly uninteresting fix was quickly
Hello, Merlin.
You wrote:
MM On Jun 6
MM (http://archives.postgresql.org/pgsql-hackers/2011-06/msg00272.php),
MM Pavel discovered an issue with PQsetvalue that could cause libpq to
MM wander off into unallocated memory that was present in 9.0.x. A
MM fairly uninteresting fix was quickly
you are creating as you iterate through. This behavior was
unnecessary in terms of what libpqtypes and friends needed and may (as
Tom suggested) come back to bite us at some point. As it turns out,
PQsetvalue's operation on results that weren't created via
PQmakeEmptyResult
On Wed, Jun 22, 2011 at 10:23 PM, Robert Haas robertmh...@gmail.com wrote:
Well, it seems I didn't put nearly enough thought into heap_update().
The fix for the immediate problem looks simple enough - all the code
has been refactored to use the new API, so the calls can be easily be
moved into
2011/6/23 Andrew Chernow a...@esilo.com
you are creating as you iterate through. This behavior was
unnecessary in terms of what libpqtypes and friends needed and may (as
Tom suggested) come back to bite us at some point. As it turns out,
PQsetvalue's operation on results that
On Thu, Jun 23, 2011 at 7:54 AM, Andrew Chernow a...@esilo.com wrote:
you are creating as you iterate through. This behavior was
unnecessary in terms of what libpqtypes and friends needed and may (as
Tom suggested) come back to bite us at some point. As it turns out,
PQsetvalue's
On Thu, Jun 23, 2011 at 5:01 AM, Radosław Smogura
rsmog...@softperience.eu wrote:
I think conclusion from this test was Much more important things are to do,
then 1% benefit - not 1% is worthless.
I will try today hugepages, with random peeks.
I think the real conclusion here is Linux will
On Tue, Jun 21, 2011 at 1:52 PM, David Fetter da...@fetter.org wrote:
Still, I think a pretty clear
way forward here is to try to figure out a way to add some explicit
syntax for range partitions, so that you can say...
foo_a is for all rows where foo starts with 'a'
foo_b is for all rows
On 11-06-23 02:41 AM, Jun Ishiduka wrote:
I receive this mail, so I notice I do wrong recognition to what
Heikki is proposing.
my recognition:
Before:
* I thought Heikki proposes, Execute SQL(pg_start_backup('x'); copy
the data directory and pg_stop_backup();) from the standby
Robert Haas robertmh...@gmail.com wrote:
David Fetter da...@fetter.org wrote:
Does The Standard* have anything to say?
I don't know
I dug around in the standard a bit and didn't find anything. Given
that the standard doesn't even touch the issue of indexes because
that a performance
On Wed, Jun 22, 2011 at 5:43 PM, Florian Pflug f...@phlo.org wrote:
On Jun12, 2011, at 23:39 , Robert Haas wrote:
So, the majority (60%) of the excess spinning appears to be due to
SInvalReadLock. A good chunk are due to ProcArrayLock (25%).
Hm, sizeof(LWLock) is 24 on X86-64, making
On 23.06.2011 18:42, Robert Haas wrote:
ProcArrayLock looks like a tougher nut to crack - there's simply no
way, with the system we have right now, that you can take a snapshot
without locking the list of running processes. I'm not sure what to
do about that, but we're probably going to have to
On Jun23, 2011, at 17:42 , Robert Haas wrote:
On Wed, Jun 22, 2011 at 5:43 PM, Florian Pflug f...@phlo.org wrote:
On Jun12, 2011, at 23:39 , Robert Haas wrote:
So, the majority (60%) of the excess spinning appears to be due to
SInvalReadLock. A good chunk are due to ProcArrayLock (25%).
Gurjeet Singh singh.gurj...@gmail.com wrote:
Instead of just synonyms of columns, why don't we think about
implementing
virtual columns (feature as named in other RDBMS). This is the
ability to
define a column in a table which is derived using an expression
around other
non-virtual columns.
On Thu, Jun 23, 2011 at 12:19 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
On 23.06.2011 18:42, Robert Haas wrote:
ProcArrayLock looks like a tougher nut to crack - there's simply no
way, with the system we have right now, that you can take a snapshot
without locking the
On Thu, Jun 23, 2011 at 1:34 PM, Florian Pflug f...@phlo.org wrote:
On Jun23, 2011, at 17:42 , Robert Haas wrote:
On Wed, Jun 22, 2011 at 5:43 PM, Florian Pflug f...@phlo.org wrote:
On Jun12, 2011, at 23:39 , Robert Haas wrote:
So, the majority (60%) of the excess spinning appears to be due to
On Thu, Jun 23, 2011 at 2:58 PM, Kevin Grittner kevin.gritt...@wicourts.gov
wrote:
Gurjeet Singh singh.gurj...@gmail.com wrote:
Instead of just synonyms of columns, why don't we think about
implementing
virtual columns (feature as named in other RDBMS). This is the
ability to
define a
On Wed, Jun 22, 2011 at 11:26 AM, Simon Riggs si...@2ndquadrant.com wrote:
For people that still think there is still risk, I've added a
parameter called relaxed_ddl_locking which defaults to off. That
way people can use this feature in an informed way without exposing us
to support risks from
On Thu, Jun 23, 2011 at 2:34 PM, Florian Pflug f...@phlo.org wrote:
It seems hard to believe that there isn't some effect of two locks
sharing a cache line. There are architectures (even some of the
Intel architectures, I believe) where cache lines are 32 bit, though -
so measuring this
On Jun23, 2011, at 22:15 , Robert Haas wrote:
On Thu, Jun 23, 2011 at 2:34 PM, Florian Pflug f...@phlo.org wrote:
It seems hard to believe that there isn't some effect of two locks
sharing a cache line. There are architectures (even some of the
Intel architectures, I believe) where cache lines
On Thu, Jun 23, 2011 at 5:35 PM, Florian Pflug f...@phlo.org wrote:
Well, I'm sure there is some effect, but my experiments seem to
indicate that it's not a very important one. Again, please feel free
to provide contrary evidence. I think the basic issue is that - in
the best possible case -
On Wed, Jun 22, 2011 at 3:37 PM, Joshua D. Drake j...@commandprompt.comwrote:
Per:
http://archives.postgresql.**org/pgsql-hackers/2010-11/**msg02043.phphttp://archives.postgresql.org/pgsql-hackers/2010-11/msg02043.php
It seems we did come up with a use case in the procpid discussion. The
On Wed, Jun 22, 2011 at 10:40 PM, Jeff Davis pg...@j-davis.com wrote:
1. Torn pages -- not a problem because it's a single bit and idempotent.
Right.
2. PD_ALL_VISIBLE bit makes it to disk before a WAL record representing
an action that makes the page all-visible. Depending on what action
On Thu, 2011-06-23 at 18:18 -0400, Robert Haas wrote:
Lazy VACUUM is the only thing that makes a page all visible. I don't
understand the part about snapshots.
Lazy VACUUM is the only thing that _marks_ a page with PD_ALL_VISIBLE.
After an INSERT to a new page, and after all snapshots are
Tom Lane wrote:
Christopher Browne cbbro...@gmail.com writes:
On Wed, Jun 15, 2011 at 5:35 PM, Bruce Momjian br...@momjian.us wrote:
[ just recommend using a different port number during pg_upgrade ]
+1... That seems to have lots of nice properties.
Yeah, that seems like an
On Thu, Jun 23, 2011 at 6:40 PM, Jeff Davis pg...@j-davis.com wrote:
On Thu, 2011-06-23 at 18:18 -0400, Robert Haas wrote:
Lazy VACUUM is the only thing that makes a page all visible. I don't
understand the part about snapshots.
Lazy VACUUM is the only thing that _marks_ a page with
On 24 June 2011 03:48, Alvaro Herrera alvhe...@commandprompt.com wrote:
I have touched next_token() and next_token_expand() a bit more, because
it seemed to me that they could be simplified further (the bit about
returning the comma in the token, instead of being a boolean return,
seemed
Dan McGee wrote:
On Wed, Jun 22, 2011 at 8:54 PM, Bruce Momjian br...@momjian.us wrote:
0003 is what I really wanted to solve, which was my failure with
pg_upgrade. The call to pg_ctl didn't succeed because the binaries
didn't match the data directory, thus resulting in this:
The error
What I think he is proposing would not require using pg_stop_backup()
but you could also modify pg_stop_back() to work as well.
What do you think of this idea?
Do you see how the patch can be reworked to accomplish this?
The logic that not use pg_stop_backup() would be difficult,
because
35 matches
Mail list logo
