On 06/10/2011 12:19 AM, Alex Hunsaker wrote:
It looks like if you push the remote branch first everything should work nicely:
git checkout master
git push origin origin:refs/heads/REL9_1_STABLE
git fetch # fetch the new branch
git checkout REL9_1_STABLE
This is basically the state of the art ri
On Thu, Jun 9, 2011 at 8:59 PM, Tom Lane wrote:
> David Fetter writes:
>> The nice people at VMware, where I work, have come up with a small
>> patch to allow PITR to create a new timeline. This is useful in cases
>> where you're using filesystem snapshots of $PGDATA which may be old.
>
> Huh?
On Fri, Jun 10, 2011 at 12:43 AM, Magnus Hagander wrote:
> On Fri, Jun 10, 2011 at 06:40, Tom Lane wrote:
>> Joe Abbate writes:
>>> No, it doesn't trash anything. The branch is just an additional
>>> "pointer" to 'master' (at that point in time). I recommend taking a
>>> look at this:
>>
>>> h
On 06/10/2011 12:40 AM, Tom Lane wrote:
> Yes, I was reading exactly that before posting. It talks about pushing
> a branch you've created locally, and it talks about what happens when
> others pull that down, and it's about as clear as mud w/r/t how the
> original pusher sees the remote branch.
On Fri, Jun 10, 2011 at 06:40, Tom Lane wrote:
> Joe Abbate writes:
>> No, it doesn't trash anything. The branch is just an additional
>> "pointer" to 'master' (at that point in time). I recommend taking a
>> look at this:
>
>> http://progit.org/book/ch3-5.html
>
> Yes, I was reading exactly th
Joe Abbate writes:
> No, it doesn't trash anything. The branch is just an additional
> "pointer" to 'master' (at that point in time). I recommend taking a
> look at this:
> http://progit.org/book/ch3-5.html
Yes, I was reading exactly that before posting. It talks about pushing
a branch you've
On Thu, Jun 9, 2011 at 22:02, Tom Lane wrote:
> Alex Hunsaker writes:
>> On Thu, Jun 9, 2011 at 21:05, Tom Lane wrote:
>>> In the next couple of days it's going to be time to branch off
>>> REL9_1_STABLE from master, and I realized that I am pretty foggy on
>>> how to do that in git. I suppose
On 06/10/2011 12:02 AM, Tom Lane wrote:
> Alex Hunsaker writes:
>> On Thu, Jun 9, 2011 at 21:05, Tom Lane wrote:
>>> In the next couple of days it's going to be time to branch off
>>> REL9_1_STABLE from master, and I realized that I am pretty foggy on
>>> how to do that in git. I suppose it's so
Alex Hunsaker writes:
> On Thu, Jun 9, 2011 at 21:05, Tom Lane wrote:
>> In the next couple of days it's going to be time to branch off
>> REL9_1_STABLE from master, and I realized that I am pretty foggy on
>> how to do that in git. I suppose it's some variant of
>>
>> git checkout master
On Thu, Jun 9, 2011 at 21:05, Tom Lane wrote:
> In the next couple of days it's going to be time to branch off
> REL9_1_STABLE from master, and I realized that I am pretty foggy on
> how to do that in git. I suppose it's some variant of
>
> git checkout master # if not there already
>
Tom Lane wrote:
> Robert Haas writes:
> > One other problem I'm realizing: didn't Peter ask Bruce to revert the
> > change to make pg_upgrade ignore case differences in locale names, on
> > the grounds that it was not safe?
>
> There was a hypothesis that it wasn't safe, but no very clear evidenc
In the next couple of days it's going to be time to branch off
REL9_1_STABLE from master, and I realized that I am pretty foggy on
how to do that in git. I suppose it's some variant of
git checkout master # if not there already
git branch REL9_1_STABLE
git push origin REL9_1_STABLE
b
On Wed, Jun 8, 2011 at 6:36 PM, Brar Piening wrote:
> I tried to look at everything and cover everthing but please consider that
> this is my first review so please have a second look at it!
I took a look at this as well, and I didn't encounter any problems
either. The patch is surprisingly small
Thanks... and sorry for sending it to hackers list... I had not read the bug
reporting guides... nor the release notes... it seems.
Again, thanks.
On Thu, Jun 9, 2011 at 9:22 PM, Tom Lane wrote:
> Abel Abraham Camarillo Ojeda writes:
>> Postgres 9.0.4 and postgres9.1beta1 give different line of
Abel Abraham Camarillo Ojeda writes:
> Postgres 9.0.4 and postgres9.1beta1 give different line of error numbers on
> functions that raise runtime errors (it seems).
This is not a bug. See the release notes:
Adjust PL/pgSQL's error line numbering code to be consistent
with other
Postgres 9.0.4 and postgres9.1beta1 give different line of error numbers on
functions that raise runtime errors (it seems).
How to reproduce, given the next SQL file:
$ cat /tmp/sql
begin;
CREATE FUNCTION pg_temp.commchecksql() returns boolean strict language
plpgsql as
$$
begin
-- SQL comment
p
David Fetter writes:
> The nice people at VMware, where I work, have come up with a small
> patch to allow PITR to create a new timeline. This is useful in cases
> where you're using filesystem snapshots of $PGDATA which may be old.
Huh? We already start a new timeline when doing a non-crash-re
I noticed while wrapping 9.1beta2 that plpython tries to build a file
spiexceptions.h to be included in the tarballs, but no such file is
actually appearing therein. The reason is that src/pl/Makefile doesn't
recurse into the plpython subdirectory unless with_python is set.
Which it isn't, because
On 6/9/11 4:51 PM, David Fetter wrote:
> Folks,
>
> The nice people at VMware, where I work, have come up with a small
> patch to allow PITR to create a new timeline. This is useful in cases
> where you're using filesystem snapshots of $PGDATA which may be old.
>
> PFA a patch implementing and d
Folks,
The nice people at VMware, where I work, have come up with a small
patch to allow PITR to create a new timeline. This is useful in cases
where you're using filesystem snapshots of $PGDATA which may be old.
PFA a patch implementing and documenting same :)
Cheers,
David.
--
David Fetter
On Jun8, 2011, at 10:14 , Florian Pflug wrote:
> On Jun6, 2011, at 14:56 , Peter Eisentraut wrote:
>> On tis, 2011-05-31 at 16:19 +0200, Florian Pflug wrote:
>>> If people deem this to be a problem, we could instead add a separate
>>> function XPATH_VALUE() that returns VARCHAR, and make people use
Greg Smith writes:
> That's fair. Anyone who is running into the sort of autovacuum issues
> prompting this discussion would happily pay the overhead to get better
> management of that; it's one of the easiest things to justify more
> per-table stats on IMHO. Surely the per-tuple counters are
On 06/09/2011 05:41 PM, Tom Lane wrote:
As Robert said, we're already seeing scalability problems with the
pg_stats subsystem. I'm not eager to add a bunch more per-table
counters, at least not without some prior work to damp down the ensuing
performance hit.
That's fair. Anyone who is ru
On Jun8, 2011, at 17:46 , Jeff Davis wrote:
> It looks like the type input function may be a problem, because it
> doesn't look like it knows what the collation is yet. In other words,
> PG_GET_COLLATION() is zero for the type input function.
>
> But I need to do a comparison to find out if the ra
From: "Magnus Hagander"
Thanks, sorry about the delay, patch applied. I backpatched it back to
8.3 which is as far as it applied cleanly - I'm not excited enough
about it to bother a manual backpatch to 8.2.
Thank you very much, Magnus. I don't mind 8.2 as >= 8.3 is enough for me.
Regards
MauMa
Excerpts from Tom Lane's message of jue jun 09 17:05:11 -0400 2011:
> Alvaro Herrera writes:
> > Use "transient" files for blind writes
>
> The buildfarm doesn't like this patch at all. Please revert, as we
> do not have time to debug it before beta2.
Already done.
--
Álvaro Herrera
The Post
Excerpts from Tom Lane's message of jue jun 09 17:10:10 -0400 2011:
> Alvaro Herrera writes:
> > Excerpts from Alvaro Herrera's message of jue jun 09 16:34:13 -0400 2011:
> >> I have pushed it now.
>
> > ... and it caused a failure on the buildfarm, so I panicked and reverted
> > it. I think the
Greg Smith writes:
> What we'd probably need to do with those is handle them like the other
> stats in the system: store a total number for visited/cleaned/dead for
> each relation, then increment the total as each vacuum finishes.
As Robert said, we're already seeing scalability problems with
On Fri, Apr 22, 2011 at 11:10:34AM -0400, Noah Misch wrote:
> On Tue, Mar 15, 2011 at 10:22:59PM -0400, Noah Misch wrote:
> > On Mon, Mar 14, 2011 at 01:56:22PM +0200, Heikki Linnakangas wrote:
> > > On 12.03.2011 12:40, Noah Misch wrote:
> > >> The installation that inspired my original report rec
On 06/09/2011 04:43 PM, Bernd Helmle wrote:
I'd go further and expose the info or details issued by VACUUM VERBOSE
into the view, too, at least the number of pages visited and cleaned
(or dead but not yet cleaned). Customers are heavily interested in
these numbers and i've found pgfouine to pro
Alvaro Herrera writes:
> Excerpts from Alvaro Herrera's message of jue jun 09 16:34:13 -0400 2011:
>> I have pushed it now.
> ... and it caused a failure on the buildfarm, so I panicked and reverted
> it. I think the patch below fixes it.
Actually, I think what you want is what closeAllVfds doe
Alvaro Herrera writes:
> Use "transient" files for blind writes
The buildfarm doesn't like this patch at all. Please revert, as we
do not have time to debug it before beta2.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make
Excerpts from Alvaro Herrera's message of jue jun 09 16:34:13 -0400 2011:
> I have pushed it now.
... and it caused a failure on the buildfarm, so I panicked and reverted
it. I think the patch below fixes it. Let me know if you think I
should push the whole thing again.
*** a/src/backend/stora
--On 9. Juni 2011 11:53:22 -0400 Greg Smith wrote:
There are at least four interesting numbers to collect each time autovacuum
runs:
1) This one, when was the threshold crossed. I believe one of the AV workers
would have to pause periodically to update these if they're all busy doing
work.
Alvaro Herrera writes:
> That was pretty weird. I had rm'd the build tree and rebuilt, failure
> still there. I then did a git reset FETCH_HEAD, recompiled, and the
> problem was gone. git reset to my revision, failed. Then git clean
> -dfx, nuked the build tree, redid the whole thing from scr
On Thu, Jun 9, 2011 at 12:48 AM, Pavel Golub wrote:
>>> it's a feature addition I approve of. I think serious consideration
>>> ought to be given to locking down returned results so PQsetvalue refuses
>>> to touch them, instead. Otherwise we're likely to find ourselves unable
>>> to make future
Excerpts from Alvaro Herrera's message of jue jun 09 16:02:14 -0400 2011:
> Excerpts from Tom Lane's message of jue jun 09 14:45:31 -0400 2011:
> > My thought is that it needs some beta testing. Perhaps it'd be sane to
> > push it into beta2 now, and then back-patch sometime after 9.1 final,
> >
Dan Ports wrote:
> On Thu, Jun 09, 2011 at 01:30:27PM -0400, Dan Ports wrote:
>> On Thu, Jun 09, 2011 at 07:06:18AM -0500, Kevin Grittner wrote:
>>> Sounds reasonable, but why did you pass the snapshot to the
>>> PredicateLockPage() call but not the PredicateLockRelation()
>>> call? Oversight?
>>
Excerpts from Tom Lane's message of jue jun 09 14:45:31 -0400 2011:
> Alvaro Herrera writes:
> > Excerpts from Tom Lane's message of mié jun 08 14:28:02 -0400 2011:
> >> Alvaro Herrera writes:
> >>> This customer is running on 8.4 so I started from there; should I
> >>> backpatch this to 8.2, or
Heikki Linnakangas wrote:
> I also fixed the broken warning logic. Please double-check that
> too when you get a chance.
As usual, I like your code better than mine. I don't think my code
was broken in the sense that it would generate different results
than yours, but it was too clever by hal
2011/6/9 Robert Haas :
> On Thu, Jun 9, 2011 at 12:54 PM, Kohei KaiGai wrote:
>> 2011/6/9 Stephen Frost :
>>> * Kohei KaiGai (kai...@kaigai.gr.jp) wrote:
The only modification by this patch to the core routine is a new
syscache for pg_seclabel system catalog. The SECLABELOID enables to
>
Robert Haas writes:
> On Thu, Jun 9, 2011 at 2:58 PM, Tom Lane wrote:
>> Robert Haas writes:
>>> Right. Understood. So let's look at the cases (from git grep
>>> pg_strcasecmp and pg_strncasecmp):
>> Also pg_toupper and pg_tolower. Right offhand, it looks like psql
>> *does* assume it can lo
2011/6/9 Robert Haas :
> On Thu, Jun 9, 2011 at 12:39 PM, Kohei KaiGai wrote:
>> 2011/6/9 Robert Haas :
>>> On Thu, Jun 9, 2011 at 3:59 AM, Kohei KaiGai wrote:
The only modification by this patch to the core routine is a new
syscache for pg_seclabel system catalog. The SECLABELOID enabl
On Thu, Jun 9, 2011 at 3:02 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Thu, Jun 9, 2011 at 2:45 PM, Tom Lane wrote:
>>> My thought is that it needs some beta testing. Perhaps it'd be sane to
>>> push it into beta2 now, and then back-patch sometime after 9.1 final,
>>> if no problems pop up
Robert Haas writes:
> On Thu, Jun 9, 2011 at 2:45 PM, Tom Lane wrote:
>> My thought is that it needs some beta testing. Perhaps it'd be sane to
>> push it into beta2 now, and then back-patch sometime after 9.1 final,
>> if no problems pop up.
> I think it'd be sensible to back-patch it. I'm no
On Thu, Jun 9, 2011 at 2:58 PM, Tom Lane wrote:
> Robert Haas writes:
>> Right. Understood. So let's look at the cases (from git grep
>> pg_strcasecmp and pg_strncasecmp):
>
> Also pg_toupper and pg_tolower. Right offhand, it looks like psql
> *does* assume it can lower-case identifiers this w
Robert Haas writes:
> Right. Understood. So let's look at the cases (from git grep
> pg_strcasecmp and pg_strncasecmp):
Also pg_toupper and pg_tolower. Right offhand, it looks like psql
*does* assume it can lower-case identifiers this way :-(
regards, tom lane
--
Sen
On Thu, Jun 9, 2011 at 2:45 PM, Tom Lane wrote:
> Alvaro Herrera writes:
>> Excerpts from Tom Lane's message of mié jun 08 14:28:02 -0400 2011:
>>> Alvaro Herrera writes:
This customer is running on 8.4 so I started from there; should I
backpatch this to 8.2, or not at all?
>
>>> I'm n
On 09.06.2011 21:15, Kevin Grittner wrote:
Heikki Linnakangas wrote:
I've committed your patch for now.
Thanks!
I don't see it yet on the public git repo, nor on the -commiters
list. I'll keep an eye out for it.
Oh, rats! Forgot to push.. Will do so now.
--
Heikki Linnakangas
Enterp
Alvaro Herrera writes:
> Excerpts from Tom Lane's message of mié jun 08 14:28:02 -0400 2011:
>> Alvaro Herrera writes:
>>> This customer is running on 8.4 so I started from there; should I
>>> backpatch this to 8.2, or not at all?
>> I'm not excited about back-patching it...
> Bummer.
Well, o
Bruce Momjian wrote:
> Tom Lane wrote:
> > Bruce Momjian writes:
> > > Andrew Dunstan wrote:
> > >> On 06/08/2011 02:29 PM, Tom Lane wrote:
> > >>> Should we consider doing $SUBJECT? Given the plan to branch off 9.1
> > >>> after we make the beta release, I think it's now or never for a second
>
Heikki Linnakangas wrote:
> I've committed your patch for now.
Thanks!
I don't see it yet on the public git repo, nor on the -commiters
list. I'll keep an eye out for it.
> as far as I can see it's harmless except for the small waste of
> disk space. We probably want to revisit this late
On Thu, Jun 09, 2011 at 01:30:27PM -0400, Dan Ports wrote:
> On Thu, Jun 09, 2011 at 07:06:18AM -0500, Kevin Grittner wrote:
> > Sounds reasonable, but why did you pass the snapshot to the
> > PredicateLockPage() call but not the PredicateLockRelation() call?
> > Oversight?
>
> Yep, just an overs
On May31, 2011, at 20:50 , Florian Pflug wrote:
> While trying to figure out sensible semantics for XPATH() and scalar-value
> returning XPath expressions, I've stumbled upon a bug in XPATH() that allows
> invalid XML values to be produced. This is a serious problem because should
> such invalid
Excerpts from Tom Lane's message of mié jun 08 14:28:02 -0400 2011:
> Alvaro Herrera writes:
> > Okay, here's a patch implementing this idea. It seems to work quite
> > well, and it solves the problem in a limited testing scenario -- I
> > haven't yet tested on the customer machines.
>
> This se
On Thu, Jun 9, 2011 at 1:22 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Thu, Jun 9, 2011 at 11:17 AM, Tom Lane wrote:
>>> Hmm ... while the above is easy enough to do in the backend, where we
>>> can look at pg_database_encoding_max_length, we have also got instances
>>> of this coding patte
On 09.06.2011 19:24, Tom Lane wrote:
(BTW, while I've not looked at the SLRU code in several years, I'm quite
unconvinced that this is only a matter of filename lengths.)
I don't see anything but the filename length needing adjustment. In
fact, when I hacked predicate.c to ignore the issue and
On 08.06.2011 22:40, Kevin Grittner wrote:
Heikki Linnakangas wrote:
On 08.06.2011 03:28, Kevin Grittner wrote:
We had a report of the subject message during testing a while
back and attempted to address the issue. It can result in a LOG
< level message and the accumulation of files in the
On Thu, Jun 09, 2011 at 07:06:18AM -0500, Kevin Grittner wrote:
> Sounds reasonable, but why did you pass the snapshot to the
> PredicateLockPage() call but not the PredicateLockRelation() call?
> Oversight?
Yep, just an oversight; long day yesterday. I'll fix the patch shortly
(unless you can ge
Hi,
on shdepReassignOwned() we have this message, which is obviously wrong
we are not dropping objects just reassigning them...
"""
ereport(ERROR,
(errcode(ERRCODE_DEPENDENT_OBJECTS_STILL_EXIST),
errmsg("cannot drop objects owned
by %s bec
Robert Haas writes:
> On Thu, Jun 9, 2011 at 11:17 AM, Tom Lane wrote:
>> Hmm ... while the above is easy enough to do in the backend, where we
>> can look at pg_database_encoding_max_length, we have also got instances
>> of this coding pattern in src/port/pgstrcasecmp.c. It's a lot less
>> obvi
Robert Haas wrote:
> On Thu, Jun 9, 2011 at 11:54 AM, Bruce Momjian wrote:
> > Can someone explain why pg_stat_activity has a column named procpid and
> > not simply pid? ?'pid' is that pg_locks uses, and 'procpid' is redundant
> > (proc-process-id). ?A mistake?
>
> Well, we refer to the slots th
On Thu, Jun 9, 2011 at 12:54 PM, Kohei KaiGai wrote:
> 2011/6/9 Stephen Frost :
>> * Kohei KaiGai (kai...@kaigai.gr.jp) wrote:
>>> The only modification by this patch to the core routine is a new
>>> syscache for pg_seclabel system catalog. The SECLABELOID enables to
>>> reference security label o
On Thu, Jun 9, 2011 at 12:39 PM, Kohei KaiGai wrote:
> 2011/6/9 Robert Haas :
>> On Thu, Jun 9, 2011 at 3:59 AM, Kohei KaiGai wrote:
>>> The only modification by this patch to the core routine is a new
>>> syscache for pg_seclabel system catalog. The SECLABELOID enables to
>>> reference security
Excerpts from Tom Lane's message of jue jun 09 12:57:46 -0400 2011:
> Alvaro Herrera writes:
> > I agree with that, though the *dll.def files are ours and probably
> > deserve a global .gitignore entry.
>
> Agreed, and that's done.
Oh, I see ... I haven't gotten the commit message yet.
--
Álva
Tom Lane wrote:
> Bruce Momjian writes:
> > Andrew Dunstan wrote:
> >> On 06/08/2011 02:29 PM, Tom Lane wrote:
> >>> Should we consider doing $SUBJECT? Given the plan to branch off 9.1
> >>> after we make the beta release, I think it's now or never for a second
> >>> pgindent run for 9.1.
>
> >>
On Thu, Jun 9, 2011 at 12:52 PM, Tom Lane wrote:
> Robert Haas writes:
>> [ lots of interesting stuff about WAL optimization snipped ]
>
>> ... Second, they aren't really using locks, unless you count
>> bus locks - they appear to have implemented most or all of it via
>> CAS-based lock-free algo
Bruce Momjian writes:
> Andrew Dunstan wrote:
>> On 06/08/2011 02:29 PM, Tom Lane wrote:
>>> Should we consider doing $SUBJECT? Given the plan to branch off 9.1
>>> after we make the beta release, I think it's now or never for a second
>>> pgindent run for 9.1.
>> OK, I have made sure the list o
Andrew Dunstan wrote:
>
>
> On 06/08/2011 02:29 PM, Tom Lane wrote:
> > Should we consider doing $SUBJECT? Given the plan to branch off 9.1
> > after we make the beta release, I think it's now or never for a second
> > pgindent run for 9.1.
> >
> >
>
> OK, I have made sure
Robert Haas wrote:
> On Wed, Jun 1, 2011 at 7:07 PM, Tom Lane wrote:
> > Alvaro Herrera writes:
> >> Excerpts from Robert Haas's message of mi? jun 01 18:22:56 -0400 2011:
> >>> ISTM that it would be useful to run postgres in a mode where it
> >>> doesn't actually try to start up the database, bu
Alvaro Herrera writes:
> I agree with that, though the *dll.def files are ours and probably
> deserve a global .gitignore entry.
Agreed, and that's done.
> As for executables, I think the local .gitignore files in each subdir
> should be tweaked so that they catch the .exe extension, so
> src/ba
On Thu, Jun 9, 2011 at 12:25 PM, Alvaro Herrera
wrote:
> Excerpts from Tom Lane's message of mié jun 08 21:50:22 -0400 2011:
>> Robert Haas writes:
>> > I think it'd be really useful to expose some more data in this area
>> > though. One random idea is - remember the time at which a table was
>>
On Mon, May 23, 2011 at 16:49, MauMau wrote:
> From: "Kevin Grittner"
>>
>> "MauMau" wrote:
>>>
>>> Make pg_ctl's -s option suppress informational event logging.
>>
>> This will ultimately be up to a committer (and I'm not one), but to
>> me it seems reasonable to back-patch if it is addressed t
Excerpts from Tom Lane's message of jue jun 09 09:42:02 -0400 2011:
> =?UTF-8?Q?Rados=C5=82aw_Smogura?= writes:
> > On Thu, 9 Jun 2011 14:12:59 +0200, Magnus Hagander wrote:
> >> What's "nbproject"?
>
> > Just configuration from some editor. It looks like any move in project
> > creates this
2011/6/9 Stephen Frost :
> * Kohei KaiGai (kai...@kaigai.gr.jp) wrote:
>> The only modification by this patch to the core routine is a new
>> syscache for pg_seclabel system catalog. The SECLABELOID enables to
>> reference security label of the object using syscache interface.
>
> Perhaps I'm missi
Robert Haas writes:
> [ lots of interesting stuff about WAL optimization snipped ]
> ... Second, they aren't really using locks, unless you count
> bus locks - they appear to have implemented most or all of it via
> CAS-based lock-free algorithms, which is probably well-justified
> optimization e
Alvaro Herrera writes:
> In any case, given the "rebalancing" feature of vacuum_cost_delay (which
> increases the delay the more workers there are), the only "solution" to
> the problem of falling behind is reducing the delay parameter. If you
> just add more workers, they start working more slow
On Thu, Jun 9, 2011 at 11:54 AM, Bruce Momjian wrote:
> Can someone explain why pg_stat_activity has a column named procpid and
> not simply pid? 'pid' is that pg_locks uses, and 'procpid' is redundant
> (proc-process-id). A mistake?
Well, we refer to the slots that backends use as "procs" (rea
2011/6/9 Robert Haas :
> On Thu, Jun 9, 2011 at 3:59 AM, Kohei KaiGai wrote:
>> The only modification by this patch to the core routine is a new
>> syscache for pg_seclabel system catalog. The SECLABELOID enables to
>> reference security label of the object using syscache interface.
>
> I believe
On Wed, Jun 8, 2011 at 11:30 PM, Merlin Moncure wrote:
> The heap pages that have been marked this way may or may not have to
> be off limits from the backend other than the one that did the
> marking, and if they have to be off limits logically, there may be no
> realistic path to make them so.
* Kohei KaiGai (kai...@kaigai.gr.jp) wrote:
> The only modification by this patch to the core routine is a new
> syscache for pg_seclabel system catalog. The SECLABELOID enables to
> reference security label of the object using syscache interface.
Perhaps I'm missing it, but.. why is this necessar
Bruce Momjian writes:
> Can someone explain why pg_stat_activity has a column named procpid and
> not simply pid? 'pid' is that pg_locks uses, and 'procpid' is redundant
> (proc-process-id). A mistake?
Mistake or not, it's about half a dozen releases too late to change it.
Excerpts from Tom Lane's message of mié jun 08 21:50:22 -0400 2011:
> Robert Haas writes:
> > I think it'd be really useful to expose some more data in this area
> > though. One random idea is - remember the time at which a table was
> > first observed to need vacuuming. Clear the timestamp when
Heikki Linnakangas writes:
> On 09.06.2011 15:50, Robert Haas wrote:
>> And I would guess that there's a lot more interest in raising BLCKSZ
>> than lowering it. It might not be a bad idea to adopt the fix you
>> propose anyway, but it doesn't seem urgent.
> I guess we could fix pg_subtrans by n
On Thu, Jun 9, 2011 at 16:40, Andrew Dunstan wrote:
>
>
> On 06/09/2011 10:25 AM, Magnus Hagander wrote:
>>
>> Based on this list, a global exclude for "*.exe" and "lib*dll.def"
>> seems reasonable. Andrew, does that seem right to you as well?
>
>
> That plus an entry in src/backend/.gitignore for
On Jun2, 2011, at 01:34 , Florian Pflug wrote:
> On Jun2, 2011, at 00:02 , Noah Misch wrote:
>> On Wed, Jun 01, 2011 at 06:16:21PM +0200, Florian Pflug wrote:
>>> Anyway, I'll try to come up with a patch that replaces
>>> xmlSetGenericErrorFunc() with xmlSetStructuredErrorFunc().
>>
>> Sounds sen
Robert Haas wrote:
> Kevin Grittner wrote:
>> There is this pending patch, without which there are infrequent
>> conditions under which the users could get a LOG level message
>> and accumulate files in pg_serial:
>>
http://archives.postgresql.org/message-id/4dee7be402250003e...@gw.wicour
2011/6/9 Robert Haas :
> On Thu, Jun 9, 2011 at 2:28 AM, Hitoshi Harada wrote:
>> BTW, as I changed title and design from the previous post, should I
>> throw away the old commit fest entry and make the new one?
>
> Nah, just edit the existing entry and change the title.
>
> Also add a link to the
Can someone explain why pg_stat_activity has a column named procpid and
not simply pid? 'pid' is that pg_locks uses, and 'procpid' is redundant
(proc-process-id). A mistake?
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.com
+ It'
Please do not piggyback on an unrelated thread to ask a question.
Start a new thread.
Vinicius Abrahao writes:
> postgres=# CREATE EXTENSION pg_buffercache SCHEMA pg_catalog;
> ERROR: syntax error at or near "NO"
This looks like a syntax error in the pg_buffercache--1.0.sql file ...
have you ta
Robert Haas wrote:
Well, if there are more tables that need vacuuming than there are
workers available at any given time, there will be a delay. We
probably don't keep track of that delay at present, but we could.
There are at least four interesting numbers to collect each time
autovacuum
Vinicius Abrahao wrote:
This is my first post at Hackers, so sorry if I am been a noob here,
but I am pretty confused about
how to create the extension pg_buffercache.
This list is for talking about development of new features, normally on
the latest development version of the software (right
On 09.06.2011 15:50, Robert Haas wrote:
On Thu, Jun 9, 2011 at 7:46 AM, Heikki Linnakangas
wrote:
While reviewing the SLRU code in predicate.c again, I remembered this old
thread:
http://archives.postgresql.org/pgsql-hackers/2010-12/msg02374.php
SLRU has a limit of 64k segment files, because
Magnus Hagander Thursday 09 of June 2011 16:25:07
> On Thu, Jun 9, 2011 at 15:40, Radosław Smogura
wrote:
> > On Thu, 9 Jun 2011 14:12:59 +0200, Magnus Hagander wrote:
> >> On Wed, Jun 8, 2011 at 12:34, Radosław Smogura
> >>
> >> wrote:
> >>> After compilation I got big list of differences abo
Robert Haas writes:
> One other problem I'm realizing: didn't Peter ask Bruce to revert the
> change to make pg_upgrade ignore case differences in locale names, on
> the grounds that it was not safe?
There was a hypothesis that it wasn't safe, but no very clear evidence
either way. And we did ha
On 09.06.2011 17:46, Tom Lane wrote:
"Kevin Grittner" writes:
The other pending patch relates to the false positives serialization
failures and funny-looking pg_lock entries from not ignoring
non-MVCC snapshots in SSI. I don't think Dan had any problem with
the patch I offered, but I wasn't su
On Thu, Jun 9, 2011 at 11:17 AM, Tom Lane wrote:
> Robert Haas writes:
>> On Thu, Jun 9, 2011 at 10:15 AM, Tom Lane wrote:
>>> If we need to work around brain-dead isupper() tests, maybe the best
>>> thing is to implement two versions of the loop:
>>> if (encoding is single byte)
>
>> Tha
Robert Haas writes:
> On Thu, Jun 9, 2011 at 10:15 AM, Tom Lane wrote:
>> If we need to work around brain-dead isupper() tests, maybe the best
>> thing is to implement two versions of the loop:
>>if (encoding is single byte)
> That seems like a clear improvement. It's a long way from pe
On Thu, Jun 9, 2011 at 11:13 AM, Alvaro Herrera
wrote:
> Excerpts from Robert Haas's message of jue jun 09 10:55:45 -0400 2011:
>> On Thu, Jun 9, 2011 at 10:34 AM, Alvaro Herrera
>> wrote:
>
>> > Slower than sleeping? Consider that this doesn't need to be done for
>> > each record insertion, onl
On Thu, Jun 9, 2011 at 3:59 AM, Kohei KaiGai wrote:
> The only modification by this patch to the core routine is a new
> syscache for pg_seclabel system catalog. The SECLABELOID enables to
> reference security label of the object using syscache interface.
I believe we decided against that previou
1 - 100 of 156 matches
Mail list logo
