As it turns out Mark Wong's pg_top project / branch
https://github.com/markwkm/pg_top/ has been patched and looks like it will
cope with the current column names and their previous incarnation.
I don't think I would ever have found it unless P. Christeas had pointed it
out. I cloned the source fr
2012/12/20 Kevin Grittner :
> 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 othe
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,
On Wed, Feb 16, 2011 at 8:15 AM, Greg Smith 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 same
>> whereve
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. In
On Wednesday, December 19, 2012, Robert Haas wrote:
> On Wed, Dec 19, 2012 at 12:26 PM, Pavan Deolasee
> > 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
> > unlikely scenario for many real li
On 20 December 2012 21:50, Kevin Grittner 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
table level. It mig
On 20 December 2012 12:45, 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 w
Andres Freund 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 categories and such
On Fri, Dec 21, 2012 at 2:45 AM, 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 st
> >
> > 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 ru
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 a
>
> 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 speculati
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
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
On Thu, Dec 20, 2012 at 4:17 PM, Tom Lane wrote:
> John R Pierce 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
> actua
John R Pierce 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 s/current_query/query/
> 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
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
> 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 d
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
Tom Lane 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 this by inventin
Robert Haas 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 commutator declarations
> 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,
2012/12/20 Robert Haas :
> On Thu, Dec 20, 2012 at 4:35 AM, Simon Riggs 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 rea
* 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 vi
2012/12/20 Stephen Frost :
> 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
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 co
On Thu, Dec 20, 2012 at 4:35 AM, Simon Riggs 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 intended to suggest.
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 th
On Wed, Dec 19, 2012 at 10:34:14PM +, Simon Riggs wrote:
> On 19 December 2012 22:19, Joshua Berkus wrote:
> >
> >> It stalled because the patch author decided not to implement the
> >> request to detect recovery.conf in data directory, which allows
> >> backwards compatibility.
> >
> > Well,
On Wed, Dec 19, 2012 at 07:32:33PM -0500, Robert Haas wrote:
> On Wed, Dec 19, 2012 at 5:34 PM, Simon Riggs 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 of the opini
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 w
On Thu, Dec 20, 2012 at 1:30 PM, Tom Lane wrote:
> Pavan Deolasee writes:
>> On Thu, Dec 20, 2012 at 10:55 PM, Tom Lane 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
Pavan Deolasee writes:
> On Thu, Dec 20, 2012 at 10:55 PM, Tom Lane 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 nothing whatsoever towards that goal
On Thu, Dec 20, 2012 at 11:08:58AM -0500, Tom Lane wrote:
> Bruce Momjian 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.
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 ver
On Thu, Dec 20, 2012 at 10:59 PM, Robert Haas wrote:
> On Thu, Dec 20, 2012 at 11:49 AM, Pavan Deolasee
> 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. II
On Thu, Dec 20, 2012 at 10:55 PM, Tom Lane wrote:
> Pavan Deolasee 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.
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 ac
On Thu, Dec 20, 2012 at 11:49 AM, Pavan Deolasee
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
> the early patches, but
Pavan Deolasee 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 only care about freezin
On Thu, Dec 20, 2012 at 11:46 AM, Tom Lane wrote:
> Robert Haas 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 bu
Ronan Dunklau 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 represent values c
On 2012-12-20 16:46:21 +, Simon Riggs wrote:
> On 20 December 2012 13:19, Amit Kapila 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
On Fri, Dec 21, 2012 at 1:46 AM, Simon Riggs wrote:
> On 20 December 2012 13:19, Amit Kapila 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 becaus
On 20 December 2012 16:21, Tom Lane wrote:
> Simon Riggs 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'
On Thu, Dec 20, 2012 at 9:23 PM, Robert Haas 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 header itsel
On Sat, Dec 15, 2012 at 9:36 AM, Fujii Masao wrote:
> On Sat, Dec 8, 2012 at 12:51 AM, Heikki Linnakangas
> 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 Kapila wrote:
>
> On
Robert Haas 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.
regards, tom lane
On 20 December 2012 13:19, Amit Kapila 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 htt
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
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='');
CREA
Robert Haas writes:
> On Thu, Dec 20, 2012 at 10:52 AM, Tom Lane 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 nothing at all,
>> but that woul
Simon Riggs 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 PreallocXlogFiles could stand to b
On Thu, Dec 20, 2012 at 8:41 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:
>>>
>>> /*
>>>
On 2012-12-20 15:58:12 +, Greg Stark wrote:
> On Thu, Dec 20, 2012 at 3:18 AM, Tom Lane wrote:
> > Greg Stark 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.
Bruce Momjian 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 pg_upgrade n
On Thu, Dec 20, 2012 at 3:18 AM, Tom Lane wrote:
> Greg Stark 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 base_yyparse() showing
> up ra
On Thu, Dec 20, 2012 at 10:52 AM, Tom Lane wrote:
> Brendan Jurd writes:
>> On 20 December 2012 11:51, Tom Lane 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 refere
On Thu, Dec 20, 2012 at 4:58 AM, Simon Riggs 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 come in and do the wo
On Wed, Dec 19, 2012 at 11:12 PM, Pavan Deolasee
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 aggressive clearing of th
Brendan Jurd writes:
> On 20 December 2012 11:51, Tom Lane 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 and link to it,
>> why not
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
On Thu, Dec 20, 2012 at 1:26 AM, Gavin Flower
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 mistake, I
> thought of
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
> > > wrote:
> > > > On 18 December 2012 22:10, Robert Haas wrote:
> > > >> Well that wo
On Thursday, December 20, 2012 5:46 PM Simon Riggs wrote:
> On 13 October 2012 08:54, Amit kapila 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 disc
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 wrote:
> > > On 18 December 2012 22:10, Robert Haas wrote:
> > >> Well that would be nice, but the problem is that I see no way to
> > >> implemen
On 2012-12-20 09:11:46 -0500, Robert Haas wrote:
> On Thu, Dec 20, 2012 at 8:55 AM, Simon Riggs wrote:
> > On 18 December 2012 22:10, Robert Haas 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
>
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 alrea
On Thu, Dec 20, 2012 at 8:55 AM, Simon Riggs wrote:
> On 18 December 2012 22:10, Robert Haas 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 cran
On Thursday, December 20, 2012 7:03 PM Simon Riggs wrote:
> On 20 December 2012 13:19, Amit Kapila 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 18 December 2012 22:10, Robert Haas 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%, because there will be d
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 2012-12-20 13:32:36 +, Simon Riggs wrote:
> On 20 December 2012 13:19, Amit Kapila 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 R
On 20 December 2012 13:19, Amit Kapila 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 used in PreallocXlo
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:
> >>
> >> /*
> >>
On Wed, Dec 19, 2012 at 5:14 PM, Joshua Berkus 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 the supposed
s
On Wed, Dec 19, 2012 at 10:18 PM, Tom Lane 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 oprofile can be
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
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: pgsql-hackers@post
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 tim
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 t
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 r
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 procpid\
On 13 October 2012 08:54, Amit kapila 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 performance data as bel
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.oi
20.12.2012, 11:43, "Bruce Momjian" :
>> 19.12.2012, 21:47, "Tom Lane" :
>>> "Kevin Grittner" writes:
Groshev Andrey wrote:
Mismatch of relation names: database "database", old rel
public.lob.ВерсияВнешнегоДокумента$Документ_pkey, new rel
public.plob.ВерсияВнешнегоДо
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 (Rec
On Thu, Dec 20, 2012 at 03:19:17PM +0400, Groshev Andrey wrote:
>
>
> 20.12.2012, 13:00, "Bruce Momjian" :
> > 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.ВерсияВнешнег
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)
> >> +DropRelF
20.12.2012, 13:00, "Bruce Momjian" :
> 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; Tablespa
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())
>
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: http://www.enterprisedb.c
On 20 December 2012 00:10, Pavan Deolasee 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 useful for the query its
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 preser
On 20 December 2012 00:43, Robert Haas wrote:
> On Wed, Dec 19, 2012 at 12:39 PM, Simon Riggs 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 repeatedly over one messy guy.
>
> Righ
On 20 December 2012 00:24, Robert Haas wrote:
> On Wed, Dec 19, 2012 at 12:54 PM, Simon Riggs 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 table with row security. We should
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 wou
> 19.12.2012, 21:47, "Tom Lane" :
> > "Kevin Grittner" writes:
> >
> >> Groshev Andrey wrote:
> >> Mismatch of relation names: database "database", old rel
> >> public.lob.ВерсияВнешнегоДокумента$Документ_pkey, new rel
> >> public.plob.ВерсияВнешнегоДокумента$Документ
> >> There is a limit
1 - 100 of 101 matches
Mail list logo
