On 20/12/12 14:57, Josh Kupershmidt wrote:
CREATE TABLE test (id int);
CREATE INDEX test_idx1 ON test (id);
CREATE INDEX test_idx2 ON test (id);
I initially misread your example code, but after I realised my mistake,
I thought of an alternative scenario that might be worth considering.
CREATE
19.12.2012, 21:47, Tom Lane t...@sss.pgh.pa.us:
Kevin Grittner kgri...@mail.com writes:
Groshev Andrey wrote:
Mismatch of relation names: database database, old rel
public.lob.ВерсияВнешнегоДокумента$Документ_pkey, new rel
public.plob.ВерсияВнешнегоДокумента$Документ
There is
On 12/20/2012 12:26 AM, Gavin Flower wrote:
CREATE TABLE test (id int, int sub, text payload);
CREATE INDEX test_idx1 ON test (id, sub);
CREATE INDEX test_idx2 ON test (id);
Nowtest_idx2 is logically included intest_idx1, but if the majority of
transactions only query onid, thentest_idx2
On 20 December 2012 00:24, Robert Haas robertmh...@gmail.com wrote:
On Wed, Dec 19, 2012 at 12:54 PM, Simon Riggs si...@2ndquadrant.com wrote:
I can see a use case for not having security apply for users who have
*only* INSERT privilege. This would allow people to run bulk loads of
data into a
On 20 December 2012 00:43, Robert Haas robertmh...@gmail.com wrote:
On Wed, Dec 19, 2012 at 12:39 PM, Simon Riggs si...@2ndquadrant.com wrote:
The benefit of saying that only UPDATEs clean the block is that this
penalises only the workload making the mess, rather than everybody
cleaning up
On Thu, Dec 20, 2012 at 08:55:16AM +0400, Groshev Andrey wrote:
No, old database not use table plob..
only primary key
--
-- Name: plob.ВерсияВнешнегоДокумента$Документ; Type: CONSTRAINT; Schema:
public; Owner: postgres; Tablespace:
--
-- For binary upgrade, must preserve
On 20 December 2012 00:10, Pavan Deolasee pavan.deola...@gmail.com wrote:
I just thought that we can fairly easily limit the damage if we are
really worried about SELECTs being penalised. What if we set a
configurable limit on *extra* things that a query may do which is
otherwise not very
Due to circumstances beyond my control (blame the power company), the
following buildfarm animals will be down from 27th December until 2nd
January:
baiji
mastodon
protosciurus
castoroides
--
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake
EnterpriseDB UK:
On Wednesday, December 19, 2012 9:30 PM Heikki Linnakangas wrote:
In both checkpointer.c and bgwriter.c, we do this before entering the
main loop:
/*
* Use the recovery target timeline ID during recovery
*/
if (RecoveryInProgress())
20.12.2012, 13:00, Bruce Momjian br...@momjian.us:
On Thu, Dec 20, 2012 at 08:55:16AM +0400, Groshev Andrey wrote:
No, old database not use table plob..
only primary key
--
-- Name: plob.ВерсияВнешнегоДокумента$Документ; Type: CONSTRAINT; Schema:
public; Owner: postgres;
On 2012-12-20 02:54:48 +0100, Tomas Vondra wrote:
On 19.12.2012 02:18, Andres Freund wrote:
On 2012-12-17 00:31:00 +0100, Tomas Vondra wrote:
I think except of the temp buffer issue mentioned below its ready.
-DropRelFileNodeAllBuffers(RelFileNodeBackend rnode)
On Thu, Dec 20, 2012 at 03:19:17PM +0400, Groshev Andrey wrote:
20.12.2012, 13:00, Bruce Momjian br...@momjian.us:
On Thu, Dec 20, 2012 at 08:55:16AM +0400, Groshev Andrey wrote:
No, old database not use table plob..
only primary key
--
-- Name:
On 20.12.2012 12:08, Amit Kapila wrote:
On Wednesday, December 19, 2012 9:30 PM Heikki Linnakangas wrote:
In both checkpointer.c and bgwriter.c, we do this before entering the
main loop:
/*
* Use the recovery target timeline ID during recovery
*/
if
20.12.2012, 11:43, Bruce Momjian br...@momjian.us:
19.12.2012, 21:47, Tom Lane t...@sss.pgh.pa.us:
Kevin Grittner kgri...@mail.com writes:
Groshev Andrey wrote:
Mismatch of relation names: database database, old rel
public.lob.ВерсияВнешнегоДокумента$Документ_pkey, new rel
On Thu, Dec 20, 2012 at 03:41:37PM +0400, Groshev Andrey wrote:
See that 786665369? That is the pg_class.oid of the plob in the old
cluster, and hopefully the new one. Find where the lob*_pkey index is
created and get that oid. Those should match the same names of the
pg_class.oid in
On 13 October 2012 08:54, Amit kapila amit.kap...@huawei.com wrote:
As per the last discussion for this patch, performance data needs to be
provided before this patch's Review can proceed further.
So as per your suggestion and from the discussions about this patch, I have
collected the
Hi List,
This might not be the right place to post, but I've got a minor patch for
pg_top and would like to submit it for review.
Basically, the rpm version in the repositories pg_top92-3.6.2 doesn't work
with Postgres 9.2
#define QUERY_PROCESSES \
SELECT
On Wed, Dec 19, 2012 at 10:19:30PM -0500, Bruce Momjian wrote:
On Wed, Dec 19, 2012 at 12:56:05PM -0500, Kevin Grittner wrote:
Groshev Andrey wrote:
Mismatch of relation names: database database, old rel
public.lob.ВерсияВнешнегоДокумента$Документ_pkey, new rel
On Thursday 20 December 2012, Brett Maton wrote:
Hi List,
This might not be the right place to post, but I've got a minor patch for
pg_top and would like to submit it for review.
This project lies on Github:
https://github.com/markwkm/pg_top/
I think, this commit had fixed the
On 17.12.2012 15:05, Thom Brown wrote:
I just set up 120 chained standbys, and for some reason I'm seeing these
errors:
LOG: replication terminated by primary server
DETAIL: End of WAL reached on timeline 1
LOG: record with zero length at 0/301EC10
LOG: fetching timeline history file for
Ah, I cloned the repository from git://git.postgresql.org/
I'll have a look at Marks repo.
Thanks,
Brett
-Original Message-
From: pgsql-hackers-ow...@postgresql.org
[mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of P. Christeas
Sent: 20 December 2012 12:33
To:
On 2012-12-20 14:45:05 +0200, Heikki Linnakangas wrote:
On 17.12.2012 15:05, Thom Brown wrote:
I just set up 120 chained standbys, and for some reason I'm seeing these
errors:
LOG: replication terminated by primary server
DETAIL: End of WAL reached on timeline 1
LOG: record with zero
On Wed, Dec 19, 2012 at 10:18 PM, Tom Lane t...@sss.pgh.pa.us wrote:
valgrind comes with a tool called cachegrind which can emulate the
cache algorithm on some variants of various cpus and produce reports.
Can it be made to produce a report for a specific block of memory?
I believe that
On Wed, Dec 19, 2012 at 5:14 PM, Joshua Berkus j...@agliodbs.com wrote:
What would such a test look like? It's not obvious to me that there's any
rapid way for a user to detect this situation, without checking each server
individually.
Change something on the master and observe that none of
On Thursday, December 20, 2012 5:12 PM Heikki Linnakangas wrote:
On 20.12.2012 12:08, Amit Kapila wrote:
On Wednesday, December 19, 2012 9:30 PM Heikki Linnakangas wrote:
In both checkpointer.c and bgwriter.c, we do this before entering
the
main loop:
/*
* Use the
On 20 December 2012 13:19, Amit Kapila amit.kap...@huawei.com wrote:
So I think we're good on that front. But I'll add a comment there, and
use 0 explicitly instead of ThisTimeLineID, for clarity.
True, it might not have any functionality effect in RemoveOldXlogFiles().
However it can be
On 2012-12-20 13:32:36 +, Simon Riggs wrote:
On 20 December 2012 13:19, Amit Kapila amit.kap...@huawei.com wrote:
So I think we're good on that front. But I'll add a comment there, and
use 0 explicitly instead of ThisTimeLineID, for clarity.
True, it might not have any functionality
On 12/18/12 5:10 PM, Robert Haas wrote:
I can't help but suspect that the way we handle keywords today is
monumentally inefficient. The unreserved_keyword products, et al,
just seem somehow badly wrong-headed. We take the trouble to
distinguish all of those cases so that we an turn around
On 18 December 2012 22:10, Robert Haas robertmh...@gmail.com wrote:
Well that would be nice, but the problem is that I see no way to
implement it. If, with a unified parser, the parser is 14% of our
source code, then splitting it in two will probably crank that number
up well over 20%,
On Thursday, December 20, 2012 7:03 PM Simon Riggs wrote:
On 20 December 2012 13:19, Amit Kapila amit.kap...@huawei.com wrote:
So I think we're good on that front. But I'll add a comment there,
and
use 0 explicitly instead of ThisTimeLineID, for clarity.
True, it might not have any
On Thu, Dec 20, 2012 at 8:55 AM, Simon Riggs si...@2ndquadrant.com wrote:
On 18 December 2012 22:10, Robert Haas robertmh...@gmail.com wrote:
Well that would be nice, but the problem is that I see no way to
implement it. If, with a unified parser, the parser is 14% of our
source code, then
The recent SET SCHEMA refactoring has changed the error message that
you get when trying to move a function into the schema that already
contains it.
For a table, as ever, you get:
rhaas=# create table foo (a int);
CREATE TABLE
rhaas=# alter table foo set schema public;
ERROR: table foo is
On 2012-12-20 09:11:46 -0500, Robert Haas wrote:
On Thu, Dec 20, 2012 at 8:55 AM, Simon Riggs si...@2ndquadrant.com wrote:
On 18 December 2012 22:10, Robert Haas robertmh...@gmail.com wrote:
Well that would be nice, but the problem is that I see no way to
implement it. If, with a unified
On 2012-12-20 15:45:47 +0100, Andres Freund wrote:
On 2012-12-20 09:11:46 -0500, Robert Haas wrote:
On Thu, Dec 20, 2012 at 8:55 AM, Simon Riggs si...@2ndquadrant.com wrote:
On 18 December 2012 22:10, Robert Haas robertmh...@gmail.com wrote:
Well that would be nice, but the problem is
On Thursday, December 20, 2012 5:46 PM Simon Riggs wrote:
On 13 October 2012 08:54, Amit kapila amit.kap...@huawei.com wrote:
As per the last discussion for this patch, performance data needs to
be
provided before this patch's Review can proceed further.
So as per your suggestion and
On 2012-12-20 15:51:37 +0100, Andres Freund wrote:
On 2012-12-20 15:45:47 +0100, Andres Freund wrote:
On 2012-12-20 09:11:46 -0500, Robert Haas wrote:
On Thu, Dec 20, 2012 at 8:55 AM, Simon Riggs si...@2ndquadrant.com
wrote:
On 18 December 2012 22:10, Robert Haas
On Thu, Dec 20, 2012 at 1:26 AM, Gavin Flower
gavinflo...@archidevsys.co.nz wrote:
On 20/12/12 14:57, Josh Kupershmidt wrote:
CREATE TABLE test (id int);
CREATE INDEX test_idx1 ON test (id);
CREATE INDEX test_idx2 ON test (id);
I initially misread your example code, but after I realised my
On 2012-12-20 16:04:49 +0100, Andres Freund wrote:
On 2012-12-20 15:51:37 +0100, Andres Freund wrote:
When doing a source/assembly annotation in SearchCatCache about half of
the misses are attributed to the memcpy() directly at the beginning.
Using a separate array for storing the arguments
Brendan Jurd dire...@gmail.com writes:
On 20 December 2012 11:51, Tom Lane t...@sss.pgh.pa.us wrote:
While reconsidering the various not-too-satisfactory fixes we thought of
back then, I had a sudden thought. Instead of having a COMMUTATOR or
NEGATOR forward reference create a shell operator
On Wed, Dec 19, 2012 at 11:12 PM, Pavan Deolasee
pavan.deola...@gmail.com wrote:
Yeah, VM buffer contention can become prominent if we break the
invariant that page level bit status implies the vm bit status, at
least when its clear.OTOH IMHO we need some mechanism to address the
issue of
On Thu, Dec 20, 2012 at 4:58 AM, Simon Riggs si...@2ndquadrant.com wrote:
ISTM that if someone spots a block that could use cleanup, they mark
the block as BM_PIN_COUNT_WAITER, but don't set pid. Then when they
unpin the block they send a signal/queue work for a special cleaning
process to
On Thu, Dec 20, 2012 at 10:52 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Brendan Jurd dire...@gmail.com writes:
On 20 December 2012 11:51, Tom Lane t...@sss.pgh.pa.us wrote:
While reconsidering the various not-too-satisfactory fixes we thought of
back then, I had a sudden thought. Instead of
On Thu, Dec 20, 2012 at 3:18 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Greg Stark st...@mit.edu writes:
But I'm not entirely convinced any of this is actually useful. Just
becuase the transition table is large doesn't mean it's inefficient.
That's a fair point. However, I've often noticed
Bruce Momjian br...@momjian.us writes:
As you can see, ALTER INDEX renamed both the pg_constraint and pg_class
names. Is it possible someone manually updated the system table to
rename this primary key? That would cause this error message. The fix
is to just to make sure they match.
Does
On 2012-12-20 15:58:12 +, Greg Stark wrote:
On Thu, Dec 20, 2012 at 3:18 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Greg Stark st...@mit.edu writes:
But I'm not entirely convinced any of this is actually useful. Just
becuase the transition table is large doesn't mean it's inefficient.
On Thu, Dec 20, 2012 at 8:41 PM, Heikki Linnakangas
hlinnakan...@vmware.com wrote:
On 20.12.2012 12:08, Amit Kapila wrote:
On Wednesday, December 19, 2012 9:30 PM Heikki Linnakangas wrote:
In both checkpointer.c and bgwriter.c, we do this before entering the
main loop:
/*
Simon Riggs si...@2ndquadrant.com writes:
PreallocXlogFiles() should have been put to the sword long ago. It's a
performance tweak aimed at people without a performance problem in
this area.
This claim seems remarkably lacking in any supporting evidence.
I'll freely grant that
Robert Haas robertmh...@gmail.com writes:
On Thu, Dec 20, 2012 at 10:52 AM, Tom Lane t...@sss.pgh.pa.us wrote:
I was thinking a NOTICE at most. If it's a WARNING then restoring
perfectly valid pg_dump files will result in lots of scary-looking
chatter. You could make an argument for printing
This looks busted:
rhaas=# create role clerks;
CREATE ROLE
rhaas=# create role bob in role clerks;
CREATE ROLE
rhaas=# create schema foo;
CREATE SCHEMA
rhaas=# grant usage on schema foo to bob, clerks;
GRANT
rhaas=# create aggregate
foo.sum(basetype=text,sfunc=textcat,stype=text,initcond='');
On Tue, Dec 18, 2012 at 04:06:02AM -0500, Greg Smith wrote:
On 12/18/12 3:17 AM, Simon Riggs wrote:
Clearly part of the response could involve pg_dump on the damaged
structure, at some point.
This is the main thing I wanted to try out more, once I have a
decent corruption generation tool.
On 20 December 2012 13:19, Amit Kapila amit.kap...@huawei.com wrote:
True, it might not have any functionality effect in RemoveOldXlogFiles().
However it can be used in PreallocXlogFiles()-XLogFileInit() as well.
Which is never called in recovery because we never write WAL.
--
Simon Riggs
Robert Haas robertmh...@gmail.com writes:
This looks busted:
Between this and your previous example, it's becoming clear that the
recent refactorings of the ALTER code were not ready for prime time.
Perhaps we should just revert those instead of playing bug whack-a-mole.
On Sat, Dec 15, 2012 at 9:36 AM, Fujii Masao masao.fu...@gmail.com wrote:
On Sat, Dec 8, 2012 at 12:51 AM, Heikki Linnakangas
hlinnakan...@vmware.com wrote:
On 06.12.2012 15:39, Amit Kapila wrote:
On Thursday, December 06, 2012 12:53 AM Heikki Linnakangas wrote:
On 05.12.2012 14:32, Amit
On Thu, Dec 20, 2012 at 9:23 PM, Robert Haas robertmh...@gmail.com wrote:
On Wed, Dec 19, 2012 at 11:12 PM, Pavan Deolasee
I'm very reluctant to suggest that we can solve
this my setting aside another page-level bit to track visibility of
tuples for heapscans. Or even have a bit in the tuple
On 20 December 2012 16:21, Tom Lane t...@sss.pgh.pa.us wrote:
Simon Riggs si...@2ndquadrant.com writes:
PreallocXlogFiles() should have been put to the sword long ago. It's a
performance tweak aimed at people without a performance problem in
this area.
This claim seems remarkably lacking in
On Fri, Dec 21, 2012 at 1:46 AM, Simon Riggs si...@2ndquadrant.com wrote:
On 20 December 2012 13:19, Amit Kapila amit.kap...@huawei.com wrote:
True, it might not have any functionality effect in RemoveOldXlogFiles().
However it can be used in PreallocXlogFiles()-XLogFileInit() as well.
Which
On 2012-12-20 16:46:21 +, Simon Riggs wrote:
On 20 December 2012 13:19, Amit Kapila amit.kap...@huawei.com wrote:
True, it might not have any functionality effect in RemoveOldXlogFiles().
However it can be used in PreallocXlogFiles()-XLogFileInit() as well.
Which is never called in
Ronan Dunklau rdunk...@gmail.com writes:
I intentionally did the nestloop_params substitution after calling
GetForeignPlan not before. It's not apparent to me why it would be
useful to do it before, because the FDW is going to have no idea what
those params represent. (Note that they
On Thu, Dec 20, 2012 at 11:46 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
This looks busted:
Between this and your previous example, it's becoming clear that the
recent refactorings of the ALTER code were not ready for prime time.
Perhaps we should just
Pavan Deolasee pavan.deola...@gmail.com writes:
Ok. Will try to read archives to see what was actually suggested and
why it was put on back burner. BTW at the risk of being shot down
again, I wonder if can we push down the freeze operation to HOT prune
also.
Seems unlikely to be a win. We
On Thu, Dec 20, 2012 at 11:49 AM, Pavan Deolasee
pavan.deola...@gmail.com wrote:
I wonder if we should add a flag to heap_page_prune and try to do some
additional work if its being called from lazy vacuum such as setting
the VM bit and the tuple freeze. IIRC I had put something like that in
On 20.12.2012 18:19, Fujii Masao wrote:
InstallXLogFileSegment() also uses ThisTimeLineID. But your recent commit
doesn't take care of it and prevents the standby from recycling the WAL files
properly. Specifically, the standby recycles the WAL file to wrong name.
A-ha, good catch. So that's
On Thu, Dec 20, 2012 at 10:55 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Pavan Deolasee pavan.deola...@gmail.com writes:
Ok. Will try to read archives to see what was actually suggested and
why it was put on back burner. BTW at the risk of being shot down
again, I wonder if can we push down the
On Thu, Dec 20, 2012 at 10:59 PM, Robert Haas robertmh...@gmail.com wrote:
On Thu, Dec 20, 2012 at 11:49 AM, Pavan Deolasee
pavan.deola...@gmail.com wrote:
I wonder if we should add a flag to heap_page_prune and try to do some
additional work if its being called from lazy vacuum such as
On 12/20/2012 4:17 AM, Brett Maton wrote:
It appears that procpid has been renamed to pid at some point, also
the column current_query appears to have been shortened to query.
My patch updates a couple of queries to use the new shorter column names.
IMHO, any such fix should check the
On Thu, Dec 20, 2012 at 11:08:58AM -0500, Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
As you can see, ALTER INDEX renamed both the pg_constraint and pg_class
names. Is it possible someone manually updated the system table to
rename this primary key? That would cause this error
Pavan Deolasee pavan.deola...@gmail.com writes:
On Thu, Dec 20, 2012 at 10:55 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Seems unlikely to be a win. We only care about freezing tuples in the
context of being able to advance a relation-wide relfrozenxid horizon.
Freezing pages retail accomplishes
On Thu, Dec 20, 2012 at 1:30 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Pavan Deolasee pavan.deola...@gmail.com writes:
On Thu, Dec 20, 2012 at 10:55 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Seems unlikely to be a win. We only care about freezing tuples in the
context of being able to advance a
Applied. We can mark this report closed. Groshev, let us know if you
have any further problems.
---
On Thu, Dec 20, 2012 at 07:19:48AM -0500, Bruce Momjian wrote:
On Wed, Dec 19, 2012 at 10:19:30PM -0500, Bruce Momjian
On Wed, Dec 19, 2012 at 07:32:33PM -0500, Robert Haas wrote:
On Wed, Dec 19, 2012 at 5:34 PM, Simon Riggs si...@2ndquadrant.com wrote:
As ever, we spent much energy on debating backwards compatibility
rather than just solving the problem it posed, which is fairly easy to
solve.
I'm still
On Wed, Dec 19, 2012 at 10:34:14PM +, Simon Riggs wrote:
On 19 December 2012 22:19, Joshua Berkus j...@agliodbs.com wrote:
It stalled because the patch author decided not to implement the
request to detect recovery.conf in data directory, which allows
backwards compatibility.
Kevin, all,
* Kevin Grittner (kgri...@mail.com) wrote:
The more secure behavior is to allow entry of data which will not
be visible by the person doing the entry.
wrt this- I'm inclined to agree with Kevin. It's certainly common in
certain environments that you can write to a higher level
On Thu, Dec 20, 2012 at 4:35 AM, Simon Riggs si...@2ndquadrant.com wrote:
Not sure I understand you. You suggested it was a valid use case for a
user to have only INSERT privilege and wish to bypass security checks.
I agreed and suggested it could be special-cased.
That's not really what I
On Thu, Dec 20, 2012 at 02:29:49PM -0500, Bruce Momjian wrote:
Let me also add that I am tired of having recovery.conf improvement
stalled by backward compatibility concerns. At this point, let's just
trash recovery.conf backward compatibility and move on.
And I don't want to hear
2012/12/20 Stephen Frost sfr...@snowman.net:
Kevin, all,
* Kevin Grittner (kgri...@mail.com) wrote:
The more secure behavior is to allow entry of data which will not
be visible by the person doing the entry.
wrt this- I'm inclined to agree with Kevin. It's certainly common in
certain
* Robert Haas (robertmh...@gmail.com) wrote:
* Applies to all commands should not be implemented via triggers.
Complex, slow, unacceptable thing to force upon users. Doing that begs
the question of why we would have the feature at all, since we already
have triggers and barrier views.
I
2012/12/20 Robert Haas robertmh...@gmail.com:
On Thu, Dec 20, 2012 at 4:35 AM, Simon Riggs si...@2ndquadrant.com wrote:
Not sure I understand you. You suggested it was a valid use case for a
user to have only INSERT privilege and wish to bypass security checks.
I agreed and suggested it could
Let me also add that I am tired of having recovery.conf improvement
stalled by backward compatibility concerns. At this point, let's just
trash recovery.conf backward compatibility and move on.
And I don't want to hear complaints about tool breakage either. These are
external tools, not
Robert Haas robertmh...@gmail.com writes:
a separate ALTER OPERATOR COMMUTATOR statement (or something of
the sort) that pg_dump can emit as a separate item. Even a NOTICE in
I like that capability, but it's not helping us in the backward
compatibility section where we will still read
Tom Lane t...@sss.pgh.pa.us writes:
The reason this fails is that you've got a half-megabyte source string,
and each of the 11000 plans that are due to be created from it saves
its own copy of the source string. Hence, 5500 megabytes needed just
for source strings.
We could possibly fix
Kohei KaiGai wrote:
If system ensures writer's permission is always equivalent or
more restrictive than reader's permission, it also eliminates the
problem around asymmetric row-security policy between commands.
I'm not sure we're understanding each other; so far people who
favor asymmetric
As ever, we spent much energy on debating backwards compatibility
rather than just solving the problem it posed, which is fairly easy
to
solve.
Well, IIRC, the debate was primarily of *your* making. Almost everyone else on
the thread was fine with the original patch, and it was nearly done
On 2012-12-18 19:43:09 -0800, Josh Berkus wrote:
We should probably have a function, like pg_replication_master(), which
gives the host address of the current master. This would help DBAs for
large replication clusters a lot. Obviously, this would only work in
streaming.
Do you want the
I just committed a patch that should make the requested WAL segment
00020003 has already been removed errors go away.
The
trick was for walsenders to not switch to the new timeline until at
least one record has been replayed on it. That closes the window
where
the
John R Pierce pie...@hogranch.com writes:
/me tossed another mumbled curse at whomever changed that field name.
The reason for the field name change was that the semantics of the field
changed. You typically ought to look at what the application is
actually doing with the field, not just do
On Thu, Dec 20, 2012 at 4:17 PM, Tom Lane t...@sss.pgh.pa.us wrote:
John R Pierce pie...@hogranch.com writes:
/me tossed another mumbled curse at whomever changed that field name.
The reason for the field name change was that the semantics of the field
changed. You typically ought to look at
Robert,
What would such a test look like? It's not obvious to me that
there's any rapid way for a user to detect this situation, without
checking each server individually.
Change something on the master and observe that none of the supposed
standbys notice?
That doesn't sound like an
Andreas,
Do you want the node one step up or the top-level in the chain?
Because
I don't think we can do the latter without complicating the
replication
protocol noticably.
Well, clearly a whole chain would be nice for the user. But even just one step
up would be very useful.
--Josh
Another way of attack along these lines might be to use the %glr-parser
and then try to cut back on all those redundant rules that were put in
to avoid conflicts. The number of key words categories and such could
perhaps also be reduced that way.
Of course, this is mostly speculation.
On 2012-12-20 23:12:55 +, McDevitt, Charles wrote:
Another way of attack along these lines might be to use the %glr-parser
and then try to cut back on all those redundant rules that were put in
to avoid conflicts. The number of key words categories and such could
perhaps also be
The GLR output from Bison is licensed under the GPL (unlike the LALR
output).
So using Bison's GLR mode isn't an option.
Thats not the case anymore:
http://www.gnu.org/software/bison/manual/html_node/Conditions.html
Sorry! My mistake... I didn't realize they changed the rules.
I'll
On Fri, Dec 21, 2012 at 2:45 AM, Heikki Linnakangas
hlinnakan...@vmware.com wrote:
On 20.12.2012 18:19, Fujii Masao wrote:
InstallXLogFileSegment() also uses ThisTimeLineID. But your recent commit
doesn't take care of it and prevents the standby from recycling the WAL
files
properly.
Andres Freund and...@2ndquadrant.com writes:
On 2012-12-20 23:12:55 +, McDevitt, Charles wrote:
Another way of attack along these lines might be to use the %glr-parser
and then try to cut back on all those redundant rules that were put in
to avoid conflicts. The number of key words
On 20 December 2012 12:45, Heikki Linnakangas hlinnakan...@vmware.comwrote:
On 17.12.2012 15:05, Thom Brown wrote:
I just set up 120 chained standbys, and for some reason I'm seeing these
errors:
LOG: replication terminated by primary server
DETAIL: End of WAL reached on timeline 1
LOG:
On 20 December 2012 21:50, Kevin Grittner kgri...@mail.com wrote:
How about using existing GRANT syntax but allowing a
WHERE clause?
It's a nice feature, but a completely different thing to what is being
discussed here.
Row security adds the ability to enforce a single coherent policy at
On Wednesday, December 19, 2012, Robert Haas wrote:
On Wed, Dec 19, 2012 at 12:26 PM, Pavan Deolasee
pavan.deola...@gmail.com javascript:; wrote:
I would like to run some pgbench tests where we get the system in a
steady state such as all/most updates are HOT updates (not entirely
On Thursday, December 20, 2012, Robert Haas wrote:
IMHO, it's probably fairly hopeless to make a pure pgbench workload
show a benefit from index-only scans. A large table under a very
heavy, completely random write workload is just about the worst
possible case for index-only scans.
On Wed, Feb 16, 2011 at 8:15 AM, Greg Smith g...@2ndquadrant.com wrote:
Tom Lane wrote:
I think that might be a good idea --- it'd reduce the cross-platform
variability of the results quite a bit, I suspect. random() is not
to be trusted everywhere, but I think erand48 is pretty much the
On Thursday, December 20, 2012 11:15 PM Heikki Linnakangas wrote:
On 20.12.2012 18:19, Fujii Masao wrote:
InstallXLogFileSegment() also uses ThisTimeLineID. But your recent
commit
doesn't take care of it and prevents the standby from recycling the
WAL files
properly. Specifically, the
2012/12/20 Kevin Grittner kgri...@mail.com:
Kohei KaiGai wrote:
If system ensures writer's permission is always equivalent or
more restrictive than reader's permission, it also eliminates the
problem around asymmetric row-security policy between commands.
I'm not sure we're understanding
1 - 100 of 101 matches
Mail list logo
