Greg Smith writes:
> On 11/02/2011 05:48 PM, Simon Riggs wrote:
>> You're missing the point that it never was like that. I've not altered
>> the situation.
> Robert's point is more that the existing docs are already broken; this
> new patch can just increase how bad the drift between reality and
On Wed, Nov 2, 2011 at 3:27 PM, Andrew Dunstan wrote:
> Patch with a small docs addition also. Adding to Nov commitfest.
I have reviewed this and it looks good to me. Marking Ready for Committer.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Se
On Wed, Nov 2, 2011 at 8:31 PM, Bruce Momjian wrote:
> Robert Haas wrote:
>> >> > If nobody objects, I'll go do that. ?Hopefully that should be enough
>> >> > to put this problem to bed more or less permanently.
>> >>
>> >> All right, I've worked up a (rather boring and tedious) patch to do
>> >>
Simon,
> Everyone has their own set of requirements. I've tried hard to fuse
> those together into a useful proposal, listening to all. Please bear
> in mind that I make my living in exactly the same way you do, so you
> must surely be aware I do this solely in the common interest.
Thank you for
Robert Haas wrote:
> >> > If nobody objects, I'll go do that. ?Hopefully that should be enough
> >> > to put this problem to bed more or less permanently.
> >>
> >> All right, I've worked up a (rather boring and tedious) patch to do
> >> this, which is attached.
> >
> > I wonder if we should bother
On 11/02/2011 05:48 PM, Simon Riggs wrote:
On Wed, Nov 2, 2011 at 6:27 PM, Robert Haas wrote:
Again, it's no longer the maximum time between automatic checkpoints.
You're missing the point that it never was like that. I've not altered
the situation.
Robert's point is more that
On Wed, Nov 2, 2011 at 17:12, Andrew Dunstan wrote:
>>> Considering that the issue appears to have been ignored from
>>> mid-February until early October, I don't see why it should now get to
>>> jump to the head of the queue. Other people may have different
>>> opinions, of course.
>>
>> Added.
On 10/07/2011 12:51 PM, Alex Hunsaker wrote:
On Wed, Oct 5, 2011 at 20:36, Robert Haas wrote:
On Wed, Oct 5, 2011 at 5:03 PM, Alex Hunsaker wrote:
On Wed, Oct 5, 2011 at 08:18, Robert Haas wrote:
On Wed, Oct 5, 2011 at 3:58 AM, Amit Khandekar
wrote:
I have no more issues with the patch
On Tue, Jun 7, 2011 at 3:24 PM, Greg Stark wrote:
> Well it's super-exclusive-vacuum-lock avoidance techniques. Why
> shouldn't it make more sense to try to reduce the frequency and impact
> of the single-purpose outlier in a non-critical-path instead of
> burdening every other data reader with ex
On 09/02/2011 03:15 PM, Josh Berkus wrote:
OK, this seems to have some pluses and no negative comments, so it seems
worth going forward. Do we want an equivalent pg_restore option?
I'm not sure it's *as* important for pg_restore, since I can easily use
a manifest to avoid restoring data for
On 09/26/2011 05:16 PM, Andrew Dunstan wrote:
On 09/26/2011 05:07 PM, Jeff Janes wrote:
But in any case, considering that we are both wondering if it works on
Windows, I think that argues that an automatic regression test would
be very handy.
I think an automated test should be possible
On 02.11.2011 22:59, Heikki Linnakangas wrote:
I'll dig deeper into this tomorrow...
Forgot to mention: I have pushed what I have done this far to my git
repository at git://git.postgresql.org/git/users/heikki/postgres.git, if
you want to take a look. Nothing major, just garden-variety cleanu
On 01.11.2011 06:33, Jeff Davis wrote:
On Mon, 2011-10-24 at 15:05 +0400, Alexander Korotkov wrote:
I think implementing subtype_diff for each datatype is ok. We could
implement some universal function based on minus operator and casting
to double precision. But such solution might be unaccept
On Wed, Nov 2, 2011 at 6:48 PM, Josh Berkus wrote:
> Well, as someone who sets up and admins replication for a bunch of
> clients, here's what I'd like to see:
Everyone has their own set of requirements. I've tried hard to fuse
those together into a useful proposal, listening to all. Please bear
On Wed, Nov 2, 2011 at 6:27 PM, Robert Haas wrote:
> Again, it's no longer the maximum time between automatic checkpoints.
You're missing the point that it never was like that. I've not altered
the situation.
And it doesn't matter either, so I will ignore.
If you see a need to correct those do
Heikki Linnakangas writes:
> On 01.11.2011 06:33, Jeff Davis wrote:
>> + else if (lower1.infinite || upper1.infinite)
>> + length1 = 1.0/0.0;
> That seems wrong. I take it that the point is to set length1 to infinity?
Please use get_float[48]_infinity() or get_float[48]_nan()
On 01.11.2011 06:33, Jeff Davis wrote:
On Mon, 2011-10-24 at 15:05 +0400, Alexander Korotkov wrote:
I think implementing subtype_diff for each datatype is ok. We could
implement some universal function based on minus operator and casting
to double precision. But such solution might be unaccept
On 09/11/2011 09:40 PM, Andrew Dunstan wrote:
On 09/09/2011 11:34 PM, Bruce Momjian wrote:
Robert Haas wrote:
On Sat, May 7, 2011 at 11:42 PM, Bruce Momjian
wrote:
Is this a TODO?
I think so.
Added to TODO:
Address problem where superusers are assumed to be members of all
groups
Kohei KaiGai writes:
> The reason why I redefined the relid of RangeTblEntry is to avoid
> the problem when security_barrier attribute get changed by concurrent
> transactions between rewriter and planenr stage.
This is complete nonsense. If the information is being injected into
the querytree b
On Wed, Nov 2, 2011 at 2:48 PM, Josh Berkus wrote:
> Is anyone working on SET PERSISTENT? I thought that got bike-shedded to
> death.
I think we had a fairly good sketch of how it could work mapped out,
mostly based around adding a postgresql.auto file. I could dig up the
old discussions, if ne
RH, Simon,
> I think that might have some possibilities. But how does that work in
> detail? If you set it to empty, then the recovery_* parameters are
> just GUCs, I suppose: which seems fine. But if you set it to a
> non-empty value then what happens, exactly? The recovery.conf
> settings cl
On Wed, Nov 2, 2011 at 12:34 PM, Simon Riggs wrote:
> On Wed, Nov 2, 2011 at 4:15 PM, Robert Haas wrote:
>> On Wed, Nov 2, 2011 at 11:39 AM, Simon Riggs wrote:
>>> Reduce checkpoints and WAL traffic on low activity database server
>>> Previously, we skipped a checkpoint if no WAL had been writte
On Wed, Nov 2, 2011 at 2:05 PM, Bruce Momjian wrote:
> Robert Haas wrote:
>> > However, we need to rethink the flag to be used for this: pg_dumpall
>> > uses -l, but many of the other utilities already use that for some
>> > other purpose, and it's not exactly mnemonic anyway. ?"-d" for
>> > datab
On Wed, Nov 2, 2011 at 4:12 AM, Albe Laurenz wrote:
> Andrew Dunstan wrote:
> > On 11/01/2011 09:52 AM, Tom Lane wrote:
> >> I'm for just redefining the query field as "current or last
> >> query".
> >
> > +1
> >
> >> I could go either way on whether to rename it.
> >
> > Rename it please. "curren
On Fri, Sep 23, 2011 at 12:37 PM, Robert Haas wrote:
> I'm still not really comfortable with the handling of vacuum
> generation numbers.
Pavan and I spent a bit of time today talking about how many vacuum
generation numbers we need to have in order for this scheme to work.
Before my memory fades
Robert Haas wrote:
> > However, we need to rethink the flag to be used for this: pg_dumpall
> > uses -l, but many of the other utilities already use that for some
> > other purpose, and it's not exactly mnemonic anyway. ?"-d" for
> > database could work, but that's also in use in some places, and
>
2011/11/2 Robert Haas :
> On Wed, Nov 2, 2011 at 7:34 AM, Kohei KaiGai wrote:
>> [ new patch, with example query plans ]
>
> I like the look of those query plans.
>
> Redefining the RangeTblEntry's relid field to be valid for either a
> table or a subquery that originated from a view seems problem
On 11/2/11 8:25 AM, Greg Smith wrote:
> On 10/14/2011 01:48 PM, Bruce Momjian wrote:
>> Is this going to be done for 9.2?
>>
>
> Refreshing this patch is on my list of things to finish before the next
> CommitFest starts later this month.
Put me down as reviewer.
--
Josh Berkus
PostgreSQL
On Wed, Nov 2, 2011 at 5:20 PM, Tom Lane wrote:
> Dimitri Fontaine writes:
>> The only part of your proposal that I don't like is the process name,
>> that "deArchiver" thing. "wal restore process" or something like that
>> would be better. We already have "wal writer process" and "wal sender
>
Dimitri Fontaine writes:
> The only part of your proposal that I don't like is the process name,
> that "deArchiver" thing. "wal restore process" or something like that
> would be better. We already have "wal writer process" and "wal sender
> process" and "wal receiver process".
+1, "restore" s
On Wed, Nov 2, 2011 at 12:42 PM, Simon Riggs wrote:
> Any standby can now become a sender node, so the meaning in that case
> would be the same. That takes a little time to get your head around,
> and I'm not used to it myself yet.
I think a new parameter will be more clear, even if in practice t
On Wed, Nov 2, 2011 at 4:14 PM, Robert Haas wrote:
> On Wed, Nov 2, 2011 at 11:56 AM, Simon Riggs wrote:
>> My solution is to create a new process called the DeArchiver. This
>> will run restore_command in a tight loop until the number of files
>> would exceed wal_keep_files, then sleep. Each tim
The following comment - or at least the last sentence thereof -
appears to be out of date.
/*
* XXX Should we update the FSM information of this page ?
*
* There are two schools of thought here. We may not want to update FSM
* information so that the pag
Simon Riggs writes:
> My solution is to create a new process called the DeArchiver. This
> will run restore_command in a tight loop until the number of files
> would exceed wal_keep_files, then sleep. Each time the DeArchiver
> executes restore_command it will set the return code and if rc=0 the
>
On Wed, Nov 2, 2011 at 11:56 AM, Simon Riggs wrote:
> My solution is to create a new process called the DeArchiver. This
> will run restore_command in a tight loop until the number of files
> would exceed wal_keep_files, then sleep. Each time the DeArchiver
> executes restore_command it will set t
On Wed, Nov 2, 2011 at 7:34 AM, Kohei KaiGai wrote:
> [ new patch, with example query plans ]
I like the look of those query plans.
Redefining the RangeTblEntry's relid field to be valid for either a
table or a subquery that originated from a view seems problematic to
me, though. For one thing,
Currently, the Startup process is responsible for running
restore_command. So when the Startup process is busy or waiting, then
no new WAL files arrive.
That has these effects
* Recovery must wait while the Startup process requests next WAL file.
This reduces performance of archive recovery.
* If
okay, sorry I'm a little confused then. Should I be able to apply both the
v2 patch as well as the v3 patch? or is it expected that I'd have to
manually do the merge?
On Wed, Nov 2, 2011 at 1:34 AM, Simon Riggs wrote:
> On Wed, Nov 2, 2011 at 2:40 AM, Chris Redekop wrote:
>
> > looks like th
On 10/14/2011 01:48 PM, Bruce Momjian wrote:
Is this going to be done for 9.2?
Refreshing this patch is on my list of things to finish before the next
CommitFest starts later this month.
--
Greg Smith 2ndQuadrant USg...@2ndquadrant.com Baltimore, MD
PostgreSQL Training, Services,
On Sun, Oct 23, 2011 at 21:39, Tom Lane wrote:
>> I will try to come up with a new patch in a few days (haven't had too
>> much time lately).
>
> Oh, I did it already.
Cool.
I noticed now that you didn't add a regression test for this fix.
Perhaps you could reuse the test from my patch, which al
On Tue, Nov 1, 2011 at 11:47 PM, Tom Lane wrote:
> Doesn't mean anything, I think --- the SQL standard seems to exclude it.
> It's fairly hard to prevent it at the grammar level, since we regard
> "foo.*" as a type of primitive expression, but I suspect it might be a
> good idea for transformTarg
On Wed, Nov 2, 2011 at 12:36 AM, David E. Wheeler wrote:
> On Nov 1, 2011, at 11:19 AM, Robert Haas wrote:
>>> Fair enough.
>>
>> So, I tried to work up a patch for this, but I'm actually a bit
>> confused about what needs to be done here. I'll attach what I've got
>> so far as a starting point f
Hi.
Is possible to use Mingw Developer Studio to
compile parts of postgres (file_fdw) ?
Anybody tried it ?
pasman
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
oopsreply-to-all
-- Forwarded message --
From: Chris Redekop
Date: Wed, Nov 2, 2011 at 8:41 AM
Subject: Re: [HACKERS] Hot Standby startup with overflowed snapshots
To: Simon Riggs
Sure, I've got quite a few logs lying around - I've attached 3 of 'em...let
me know if there a
On Sat, Oct 29, 2011 at 4:07 PM, Robert Haas wrote:
> On Fri, Oct 28, 2011 at 9:22 PM, Bruce Momjian wrote:
>> OK, the attached, applied patch removes the pg_upgrade dependency on the
>> 'postgres' database existing in the new cluster. However, vacuumdb,
>> used by pg_upgrade, still has this dep
On Wed, Nov 2, 2011 at 1:44 PM, Magnus Hagander wrote:
> Double prototypes seems to me like it's a cure worse than the disease to me...
Doubling them was just a mistake. Anyway, thats gone now.
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support,
On 11/02/2011 09:56 AM, Tom Lane wrote:
Andrew Dunstan writes:
On 11/02/2011 03:16 AM, Valentine Gogichashvili wrote:
Putting aside arguments like "it is not a good idea to use * because
it generates not sustainable code especially in case when you extend
table structure", I think this cons
Andrew Dunstan writes:
> On 11/02/2011 03:16 AM, Valentine Gogichashvili wrote:
>> Putting aside arguments like "it is not a good idea to use * because
>> it generates not sustainable code especially in case when you extend
>> table structure", I think this construct would be really nice for
>
On Wed, Nov 2, 2011 at 14:33, Simon Riggs wrote:
> On Wed, Nov 2, 2011 at 1:14 PM, Robert Haas wrote:
>> On Wed, Nov 2, 2011 at 4:44 AM, Simon Riggs wrote:
>>> Patch removes stuff related to "startup process" and creates files
>>> under src/$DIR/postmaster for this code.
>>>
>>> This makes start
On Wed, Nov 2, 2011 at 1:14 PM, Robert Haas wrote:
> On Wed, Nov 2, 2011 at 4:44 AM, Simon Riggs wrote:
>> Patch removes stuff related to "startup process" and creates files
>> under src/$DIR/postmaster for this code.
>>
>> This makes startup process look more like bgwriter, walwriter etc..
>
> I
On 11/02/2011 03:16 AM, Valentine Gogichashvili wrote:
Putting aside arguments like "it is not a good idea to use * because
it generates not sustainable code especially in case when you extend
table structure", I think this construct would be really nice for
building ROWs, for example in p
On Wed, Nov 2, 2011 at 4:44 AM, Simon Riggs wrote:
> Patch removes stuff related to "startup process" and creates files
> under src/$DIR/postmaster for this code.
>
> This makes startup process look more like bgwriter, walwriter etc..
In general, +1.
But I don't think we want duplicate function
* Pavel Stehule (pavel.steh...@gmail.com) wrote:
> I understand it, it is really bad idea use a star in export queries
It's not how I'd want to automate things, but I hardly see it being a
"really bad idea" for ad-hoc COPY usage..
Stephen
signature.asc
Description: Digital signature
On Wed, Nov 2, 2011 at 7:34 AM, Simon Riggs wrote:
> On Wed, Nov 2, 2011 at 2:40 AM, Chris Redekop wrote:
>
>> looks like the v3 patch re-introduces the pg_subtrans issue...
>
> No, I just separated the patches to be clearer about the individual changes.
3 bug fixes committed and back patched.
On Wed, Nov 2, 2011 at 1:11 AM, Josh Berkus wrote:
> There is no way we're getting distro packagers to switch from pg_ctl
> start. Also, a lot of distros use the "postgres" command rather than
> pg_ctl anything.
So backwards compatibility is important for downstream software.
--
Simon Riggs
On Wed, Nov 2, 2011 at 1:11 AM, Josh Berkus wrote:
> There is no way we're getting distro packagers to switch from pg_ctl
> start. Also, a lot of distros use the "postgres" command rather than
> pg_ctl anything.
So backwards compatibility is important for downstream software.
--
Simon Riggs
On Wed, Nov 2, 2011 at 1:45 AM, Robert Haas wrote:
> I think that might have some possibilities. But how does that work in
> detail?
My thoughts also. I want to see the detail on an alternate proposal so
we can decide things sensibly.
--
Simon Riggs http://www.2ndQuadrant.c
On Fri, Oct 28, 2011 at 3:42 AM, Chris Redekop wrote:
> On a side note I am sporadically seeing another error on hotstandby startup.
> I'm not terribly concerned about it as it is pretty rare and it will work
> on a retry so it's not a big deal. The error is "FATAL: out-of-order XID
> insertio
Patch removes stuff related to "startup process" and creates files
under src/$DIR/postmaster for this code.
This makes startup process look more like bgwriter, walwriter etc..
Other refactoring patches to follow, chipping away at xlog.c.
--
Simon Riggs http://www.2ndQuadrant.
Andrew Dunstan wrote:
> On 11/01/2011 09:52 AM, Tom Lane wrote:
>> I'm for just redefining the query field as "current or last
>> query".
>
> +1
>
>> I could go either way on whether to rename it.
>
> Rename it please. "current_query" will just be wrong. I'd be inclined
> just to call it "query"
On Wed, Nov 2, 2011 at 2:40 AM, Chris Redekop wrote:
> looks like the v3 patch re-introduces the pg_subtrans issue...
No, I just separated the patches to be clearer about the individual changes.
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support
On Sun, Oct 30, 2011 at 22:12, Eric Ridge wrote:
>
> Yes. It's basically a modifier to the star that immediately precedes
> it. In order to support excluding multiple columns, it needs parens:
> SELECT foo.* EXCLUDING (foo.x, foo.y), bar.* EXCLUDING (bar.y),
> baz.z, (a+b) AS c
>
> but yes,
62 matches
Mail list logo
