Alvaro Herrera wrote:
> Nope, AFAICS it's harmless; what it means is that on those databases,
> all tuples will be frozen immediately.
>
> I'll try to reproduce the problem here.
No luck :-( It works as expected for me.
--
Alvaro Herrerahttp://www.CommandPrompt
On Tue, Aug 26, 2008 at 09:40:26PM -0400, Alvaro Herrera wrote:
> David Fetter wrote:
> > Folks,
> >
> > It looks to me like there should be more links, maybe even
> > bidirectional ones, between the TODO wiki and commitfest pages.
> > Does mediawiki have a bidirectional link capability?
>
> Huh,
David Fetter wrote:
> Folks,
>
> It looks to me like there should be more links, maybe even
> bidirectional ones, between the TODO wiki and commitfest pages. Does
> mediawiki have a bidirectional link capability?
Huh, what's a bidirectional link in this context?
I think both the Commitfest and
"Stephen R. van den Berg" <[EMAIL PROTECTED]> writes:
> b. Create a function newNode() which is declared as inline, which
>basically gives you the same code as under (a).
I considered that one, but since part of my argument is that inlining
this is a waste of code space, it seems like a better
Tom Lane wrote:
>I happened to be looking at nodes.h and started wondering just how
>sane this coding really is:
>extern PGDLLIMPORT Node *newNodeMacroHolder;
>#define newNode(size, tag) \
>( \
>AssertMacro((size) >= sizeof(Node)),/* need the tag, at least */ \
>newNodeMacroHolder
Folks,
It looks to me like there should be more links, maybe even
bidirectional ones, between the TODO wiki and commitfest pages. Does
mediawiki have a bidirectional link capability?
Cheers,
David.
--
David Fetter <[EMAIL PROTECTED]> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Y
On Tue, Aug 26, 2008 at 1:28 PM, Josh Berkus <[EMAIL PROTECTED]> wrote:
>
> Second, I need to know who's available for round-robin reviewing for this
> commitfest (September 1-15).
let's make a try... count with me for round-robin reviewing...
--
regards,
Jaime Casanova
Soporte y capacitación de
Grant Finnemore escreveu:
> Invoking pg_stat_activity after the SET ROLE is changed will however
> leave the usename unchanged.
>
You're right. Because, as you spotted, usename is synonym of session
usename.
> SET SESSION AUTHORIZATION behaves similarly, although in that case,
> it's documented t
Robert Treat wrote:
I would have thought the place you need this is where you have SA's who set up
a machine, creating a $PGDATA and $PGDATA/xlog on seperate mountpoints where
the postgres user has full rights to use those directories, but not create
directies in those locations. In that scen
On Monday 25 August 2008 14:05:21 Joshua Drake wrote:
> On Mon, 25 Aug 2008 13:56:16 -0400
>
> Andrew Dunstan <[EMAIL PROTECTED]> wrote:
> > > That is what I was suggesting.
> >
> > Why should the xlog directory be treated specially?
>
> Consider the following:
>
> mount /dev/sda1 /var/lib/pgsql
>
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> So we've got two problems: SA_RESTART is preventing some EINTRs from
>> happening when we'd like, and yet it seems we are at risk of unwanted
>> EINTRs anyway.
>>
>> The only really clean solution I can see is to stop using SA_RESTART
Tom Lane wrote:
> So we've got two problems: SA_RESTART is preventing some EINTRs from
> happening when we'd like, and yet it seems we are at risk of unwanted
> EINTRs anyway.
>
> The only really clean solution I can see is to stop using SA_RESTART
> and try to make all our syscalls EINTR-proof.
On Wed, Aug 27, 2008 at 4:23 AM, Josh Berkus <[EMAIL PROTECTED]> wrote:
> Goodness, if only we had some kind of organized repository for these TODO
> items capable of holding multiple categories per item. Maybe something with
> items and attributes, and some kind of "relationship" between the TODO
I happened to be looking at nodes.h and started wondering just how
sane this coding really is:
extern PGDLLIMPORT Node *newNodeMacroHolder;
#define newNode(size, tag) \
( \
AssertMacro((size) >= sizeof(Node)),/* need the tag, at least */ \
newNodeMacroHolder = (Node *) palloc0fast
Folks,
The september commit fest starts in one week. The goal, this time, is
to start reviewing on day 1 of the commit fest and not spend the first 3
days collecting extra patches.
So if your patch isn't on the list *on* September 1, it may get pushed
into November. So get it on the list n
All,
Apart from the management aspect (which is very much a valid concern),
others have expressed a desire to be able to easily search the list
for "easy" Todo items. We got that working by adding the [E] tags to
those items, and it's now very convenient to search for them.
Goodness, if only
Hello,
[ I have not yet had the time to look at code again in response to
some of the points raised raised by several people; but I wanted to
follow-up somewhat still on other bits. ]
> > You would have to test for whether it's time to sleep much more often.
> > Possibly before every ExecProcNode
Dave Cramer wrote:
> On Tue, Aug 26, 2008 at 1:45 PM, Alvaro Herrera
> <[EMAIL PROTECTED]>wrote:
> > My guess is that autovacuum is skipping the database for some reason, so
> > there's no log entry at all.
>
> Seems like a viable explanation, but doesn't advance us any further ?
Nope, it doesn
On Tue, Aug 26, 2008 at 1:45 PM, Alvaro Herrera
<[EMAIL PROTECTED]>wrote:
> Dave Cramer wrote:
> > On Tue, Aug 26, 2008 at 1:33 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
>
> > > Could we first see a cycle of autovac log output with
> > > log_autovacuum_min_duration = 0?
> > > Otherwise we're not goi
Dave Cramer wrote:
> On Tue, Aug 26, 2008 at 1:33 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
> > Could we first see a cycle of autovac log output with
> > log_autovacuum_min_duration = 0?
> > Otherwise we're not going to get closer to understanding why it's
> > not cleaning up template0 for you.
>
>
On Tue, Aug 26, 2008 at 1:33 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > Dave Cramer wrote:
> >> Well, I'm willing to help debug this, however this is a busy production
> >> database and I need to be able to turn it off for a few hours a day.
> Would
>
On Wed, Aug 27, 2008 at 3:31 AM, Tom Lane <[EMAIL PROTECTED]> wrote:
> "Brendan Jurd" <[EMAIL PROTECTED]> writes:
>> The size of the page really isn't something we should be worrying
>> about. As Greg points out, we have the usual wiki per-section edit
>> capability, so in practice we will almost
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Dave Cramer wrote:
>> Well, I'm willing to help debug this, however this is a busy production
>> database and I need to be able to turn it off for a few hours a day. Would
>> changing autovacuum_freeze_max_age be a solution ?
> Yes.
Could we first see
Tom Lane wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > If it doesn't ignore them, then it should be properly vacuuming
> > template0 as any other database. We've changed autovac's behavior on
> > this area back and forth so I may be misremembering what's our rationale
> > du jour.
>
> A
"Brendan Jurd" <[EMAIL PROTECTED]> writes:
> The size of the page really isn't something we should be worrying
> about. As Greg points out, we have the usual wiki per-section edit
> capability, so in practice we will almost never need to edit the whole
> page at once. The only reasons for doing s
Dave Cramer wrote:
> Well, I'm willing to help debug this, however this is a busy production
> database and I need to be able to turn it off for a few hours a day. Would
> changing autovacuum_freeze_max_age be a solution ?
Yes.
--
Alvaro Herrerahttp://www.Command
On Tue, 26 Aug 2008 12:58:59 -0400
"Dave Cramer" <[EMAIL PROTECTED]> wrote:
>
> Well, I'm willing to help debug this, however this is a busy
> production database and I need to be able to turn it off for a few
> hours a day. Would changing autovacuum_freeze_max_age be a solution ?
Populate the t
On Wed, Aug 27, 2008 at 2:48 AM, Tom Lane <[EMAIL PROTECTED]> wrote:
> Certainly true. Okay, let's leave it alone for a little while and see
> if the growth curve flattens out. It'll certainly be easiest to manage
> if it can stay a single page.
>
Apart from the management aspect (which is very
Tom Lane escribió:
> Certainly true. Okay, let's leave it alone for a little while and see
> if the growth curve flattens out. It'll certainly be easiest to manage
> if it can stay a single page.
FWIW most of the growth occured when I changed the archive links to
include the message subject.
I
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> If it doesn't ignore them, then it should be properly vacuuming
> template0 as any other database. We've changed autovac's behavior on
> this area back and forth so I may be misremembering what's our rationale
> du jour.
AFAICS, the only way in which c
On Tue, Aug 26, 2008 at 12:50 PM, Alvaro Herrera <[EMAIL PROTECTED]
> wrote:
> Dave Cramer wrote:
>
> > Yes
> >
> > select * from pg_database where datname='template0';
> > datname | datdba | encoding | datistemplate | datallowconn |
> datconnlimit
> > | datlastsysoid | datfrozenxid | dattable
Dave Cramer wrote:
> Yes
>
> select * from pg_database where datname='template0';
> datname | datdba | encoding | datistemplate | datallowconn | datconnlimit
> | datlastsysoid | datfrozenxid | dattablespace | datconfig |
> datacl
> ---++--+---+-
Greg Smith <[EMAIL PROTECTED]> writes:
> On Tue, 26 Aug 2008, Tom Lane wrote:
>>> WARNING: This page is 106 kilobytes long; some browsers may have
>>> problems editing pages approaching or longer than 32kb.
>> Hmm ... my browser isn't failing, but I do seem to detect a certain lack
>> of snappines
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Dave Cramer wrote:
>> turns out template0 is the culprit, why is autovac not vacuuming this ?
> Hmm ... template0 is not supposed to need vacuuming, because it is
> frozen ... is it marked with datallowconn=false?
8.3's autovac doesn't care about that,
=?UTF-8?B?SmFuIFVyYmHFhHNraQ==?= <[EMAIL PROTECTED]> writes:
> Simon Riggs wrote:
>> put it in a file called selfuncs_ts.c so it is similar to the existing
>> filename?
> I followed the pattern of ts_parse.c, ts_utils.c and so on.
> Also, I see geo_selfuncs.c. No big deal, though, I can move it.
On Tue, Aug 26, 2008 at 12:21 PM, Alvaro Herrera <[EMAIL PROTECTED]
> wrote:
> Dave Cramer wrote:
>
> > Ok, back to why
> >
> > turns out template0 is the culprit, why is autovac not vacuuming this ?
>
> Hmm ... template0 is not supposed to need vacuuming, because it is
> frozen ... is it marked w
Dave Cramer wrote:
> Ok, back to why
>
> turns out template0 is the culprit, why is autovac not vacuuming this ?
Hmm ... template0 is not supposed to need vacuuming, because it is
frozen ... is it marked with datallowconn=false?
--
Alvaro Herrerahttp://www.Comma
On Tue, Aug 26, 2008 at 12:10 PM, Alvaro Herrera <[EMAIL PROTECTED]
> wrote:
> Dave Cramer wrote:
>
>
> > AutoVacuumShmem->av_signal[AutoVacForkFailed] = false;
> > pg_usleep(10L); /* 100ms
> */
> >
> > SendPostmasterSignal(PMSIGNAL_START_AUTOVAC_WOR
Dave Cramer wrote:
> AutoVacuumShmem->av_signal[AutoVacForkFailed] = false;
> pg_usleep(10L); /* 100ms */
>
> SendPostmasterSignal(PMSIGNAL_START_AUTOVAC_WORKER);
> continue;
>
> Do these signals get cleaned up on a
Dave Cramer wrote:
> On Tue, Aug 26, 2008 at 11:41 AM, Alvaro Herrera <[EMAIL PROTECTED]
> > What's the max age(pg_database.datfrozenxid)?
>
> select datfrozenxid from pg_database ;
> datfrozenxid
> --
> 201850617
> 101850961
> 86039359
> 21522712
Well, the first o
On Tue, Aug 26, 2008 at 11:51 AM, Dave Cramer <[EMAIL PROTECTED]> wrote:
>
>
> On Tue, Aug 26, 2008 at 11:41 AM, Alvaro Herrera <
> [EMAIL PROTECTED]> wrote:
>
>> Dave Cramer wrote:
>> > On Tue, Aug 26, 2008 at 10:56 AM, Alvaro Herrera <
>> [EMAIL PROTECTED]
>>
>> > > The only possible explanation
On Tue, Aug 26, 2008 at 11:41 AM, Alvaro Herrera <[EMAIL PROTECTED]
> wrote:
> Dave Cramer wrote:
> > On Tue, Aug 26, 2008 at 10:56 AM, Alvaro Herrera <
> [EMAIL PROTECTED]
>
> > > The only possible explanation for this behavior is that somebody is
> > > signalling the postmaster due to Xid wrapar
Dave Cramer wrote:
> On Tue, Aug 26, 2008 at 10:56 AM, Alvaro Herrera <[EMAIL PROTECTED]
> > The only possible explanation for this behavior is that somebody is
> > signalling the postmaster due to Xid wraparound issues. This is keyed
> > on some GUC vars -- Perhaps you have autovacuum_freeze_max
On Tue, Aug 26, 2008 at 10:56 AM, Alvaro Herrera <[EMAIL PROTECTED]
> wrote:
> Dave Cramer wrote:
> > On Tue, Aug 26, 2008 at 9:59 AM, Dave Cramer <[EMAIL PROTECTED]> wrote:
> >
> > > On Tue, Aug 26, 2008 at 9:37 AM, Alvaro Herrera <
> > > [EMAIL PROTECTED]> wrote:
>
> > >> Certainly not, and that
Dave Cramer wrote:
> On Tue, Aug 26, 2008 at 9:59 AM, Dave Cramer <[EMAIL PROTECTED]> wrote:
>
> > On Tue, Aug 26, 2008 at 9:37 AM, Alvaro Herrera <
> > [EMAIL PROTECTED]> wrote:
> >> Certainly not, and that's not what I see here either. I assume process
> >> 25407 is (was) the postmaster, yes?
On Tue, Aug 26, 2008 at 9:59 AM, Dave Cramer <[EMAIL PROTECTED]> wrote:
>
>
> On Tue, Aug 26, 2008 at 9:37 AM, Alvaro Herrera <
> [EMAIL PROTECTED]> wrote:
>
>> Dave Cramer wrote:
>>
>> > Ok, here are the logs from last night
>> >
>> > 2008-08-26 04:00:02 EDT [25407] LOG: received SIGHUP, reload
On Tue, Aug 26, 2008 at 9:37 AM, Alvaro Herrera
<[EMAIL PROTECTED]>wrote:
> Dave Cramer wrote:
>
> > Ok, here are the logs from last night
> >
> > 2008-08-26 04:00:02 EDT [25407] LOG: received SIGHUP, reloading
> > configuration files
> > 2008-08-26 04:00:02 EDT [22649] LOG: autovacuum launche
Dave Cramer wrote:
> Ok, here are the logs from last night
>
> 2008-08-26 04:00:02 EDT [25407] LOG: received SIGHUP, reloading
> configuration files
> 2008-08-26 04:00:02 EDT [22649] LOG: autovacuum launcher shutting down
> 2008-08-26 04:00:02 EDT [30438] LOG: autovacuum launcher started
>
Hello,
Stephen Frost wrote:
> As I discuss above, it'd be really nice have a --role or similar option
> to ask pg_dump to set role to a particular user before dumping the
> database.
I created a patch to set the role to a specified name just after the db
connection.
Please review it for possibl
On Mon, Aug 25, 2008 at 1:07 PM, Dave Cramer <[EMAIL PROTECTED]> wrote:
>
> On 25-Aug-08, at 10:43 AM, Alvaro Herrera wrote:
>
> Dave Cramer wrote:
>>
>> Well, I go the extra mile and kill any remaing autovac procs
>>>
>>> Here are the logs
>>>
>>> 2008-08-25 04:00:01 EDT [32276] LOG: autovacu
On Mon, 2008-08-25 at 22:39 +0200, Peter Schuller wrote:
> Does this sound vaguely sensible? Is there an obvious show-stopper I
> am missing?
This was a well structured proposal.
The main problem is where you put the delay_point() calls. If you put
them at the top of the executor then you will
Simon Riggs wrote:
On Thu, 2008-08-14 at 22:27 +0200, Jan Urbański wrote:
Jan Urbański wrote:
+ * ts_selfuncs.c
Not sure why this is in its own file
I couldn't decide where to put it, so I came up with this.
put it in a file called selfuncs_ts.c so it is similar to the existing
filenam
On Thu, 2008-08-14 at 22:27 +0200, Jan Urbański wrote:
> Jan Urbański wrote:
> + * ts_selfuncs.c
Not sure why this is in its own file, but if it must be could we please
put it in a file called selfuncs_ts.c so it is similar to the existing
filename?
--
Simon Riggs www.2ndQuadrant.c
On Tue, 2008-08-26 at 19:24 +0900, ITAGAKI Takahiro wrote:
> I'm very interested in the auto-explain feature.
Me too, though must apologise I've had no further time to review this.
--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Services and Support
--
Sent via pgsql-hac
Hi,
I'm very interested in the auto-explain feature.
Are there any plans to re-add it in the next commit-fest?
Dean Rasheed <[EMAIL PROTECTED]> wrote:
> > Please do not export ExplainState --- that's an internal matter for
> > explain.c. Export some wrapper function with a cleaner API than
> > e
On Tue, 26 Aug 2008, Tom Lane wrote:
WARNING: This page is 106 kilobytes long; some browsers may have
problems editing pages approaching or longer than 32kb.
Hmm ... my browser isn't failing, but I do seem to detect a certain lack
of snappiness to the edits.
There haven't been any popular bro
56 matches
Mail list logo
