On Sun, Oct 30, 2011 at 22:12, Eric Ridge eeb...@gmail.com 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
On Wed, Nov 2, 2011 at 2:40 AM, Chris Redekop ch...@replicon.com 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
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 or query_string
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
On Fri, Oct 28, 2011 at 3:42 AM, Chris Redekop ch...@replicon.com 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
On Wed, Nov 2, 2011 at 1:45 AM, Robert Haas robertmh...@gmail.com 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
On Wed, Nov 2, 2011 at 1:11 AM, Josh Berkus j...@agliodbs.com 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.
--
On Wed, Nov 2, 2011 at 1:11 AM, Josh Berkus j...@agliodbs.com 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.
--
On Wed, Nov 2, 2011 at 7:34 AM, Simon Riggs si...@2ndquadrant.com wrote:
On Wed, Nov 2, 2011 at 2:40 AM, Chris Redekop ch...@replicon.com 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
* 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 4:44 AM, Simon Riggs si...@2ndquadrant.com 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
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
On Wed, Nov 2, 2011 at 1:14 PM, Robert Haas robertmh...@gmail.com wrote:
On Wed, Nov 2, 2011 at 4:44 AM, Simon Riggs si...@2ndquadrant.com 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
On Wed, Nov 2, 2011 at 14:33, Simon Riggs si...@2ndquadrant.com wrote:
On Wed, Nov 2, 2011 at 1:14 PM, Robert Haas robertmh...@gmail.com wrote:
On Wed, Nov 2, 2011 at 4:44 AM, Simon Riggs si...@2ndquadrant.com wrote:
Patch removes stuff related to startup process and creates files
under
Andrew Dunstan and...@dunslane.net 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
On 11/02/2011 09:56 AM, Tom Lane wrote:
Andrew Dunstanand...@dunslane.net 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,
On Wed, Nov 2, 2011 at 1:44 PM, Magnus Hagander mag...@hagander.net 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
On Sat, Oct 29, 2011 at 4:07 PM, Robert Haas robertmh...@gmail.com wrote:
On Fri, Oct 28, 2011 at 9:22 PM, Bruce Momjian br...@momjian.us wrote:
OK, the attached, applied patch removes the pg_upgrade dependency on the
'postgres' database existing in the new cluster. However, vacuumdb,
used by
oopsreply-to-all
-- Forwarded message --
From: Chris Redekop ch...@replicon.com
Date: Wed, Nov 2, 2011 at 8:41 AM
Subject: Re: [HACKERS] Hot Standby startup with overflowed snapshots
To: Simon Riggs si...@2ndquadrant.com
Sure, I've got quite a few logs lying around - I've
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
On Wed, Nov 2, 2011 at 12:36 AM, David E. Wheeler da...@kineticode.com 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
On Tue, Nov 1, 2011 at 11:47 PM, Tom Lane t...@sss.pgh.pa.us 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
On Sun, Oct 23, 2011 at 21:39, Tom Lane t...@sss.pgh.pa.us 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
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,
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 si...@2ndquadrant.com wrote:
On Wed, Nov 2, 2011 at 2:40 AM, Chris Redekop
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
On Wed, Nov 2, 2011 at 7:34 AM, Kohei KaiGai kai...@kaigai.gr.jp 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,
On Wed, Nov 2, 2011 at 11:56 AM, Simon Riggs si...@2ndquadrant.com 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
Simon Riggs si...@2ndquadrant.com 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
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
On Wed, Nov 2, 2011 at 4:14 PM, Robert Haas robertmh...@gmail.com wrote:
On Wed, Nov 2, 2011 at 11:56 AM, Simon Riggs si...@2ndquadrant.com 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
On Wed, Nov 2, 2011 at 12:42 PM, Simon Riggs si...@2ndquadrant.com 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,
Dimitri Fontaine dimi...@2ndquadrant.fr 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,
On Wed, Nov 2, 2011 at 5:20 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Dimitri Fontaine dimi...@2ndquadrant.fr 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
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 Experts
2011/11/2 Robert Haas robertmh...@gmail.com:
On Wed, Nov 2, 2011 at 7:34 AM, Kohei KaiGai kai...@kaigai.gr.jp 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
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
On Fri, Sep 23, 2011 at 12:37 PM, Robert Haas robertmh...@gmail.com 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.
On Wed, Nov 2, 2011 at 4:12 AM, Albe Laurenz laurenz.a...@wien.gv.atwrote:
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.
On Wed, Nov 2, 2011 at 2:05 PM, Bruce Momjian br...@momjian.us 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
On Wed, Nov 2, 2011 at 12:34 PM, Simon Riggs si...@2ndquadrant.com wrote:
On Wed, Nov 2, 2011 at 4:15 PM, Robert Haas robertmh...@gmail.com wrote:
On Wed, Nov 2, 2011 at 11:39 AM, Simon Riggs si...@2ndquadrant.com wrote:
Reduce checkpoints and WAL traffic on low activity database server
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
On Wed, Nov 2, 2011 at 2:48 PM, Josh Berkus j...@agliodbs.com 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
Kohei KaiGai kai...@kaigai.gr.jp 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
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 Momjianbr...@momjian.us
wrote:
Is this a TODO?
I think so.
Added to TODO:
Address problem where superusers are assumed to be members
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
Heikki Linnakangas heikki.linnakan...@enterprisedb.com 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
On Wed, Nov 2, 2011 at 6:27 PM, Robert Haas robertmh...@gmail.com 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
On Wed, Nov 2, 2011 at 6:48 PM, Josh Berkus j...@agliodbs.com 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
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
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
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
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 Tue, Jun 7, 2011 at 3:24 PM, Greg Stark gsst...@mit.edu 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
On 10/07/2011 12:51 PM, Alex Hunsaker wrote:
On Wed, Oct 5, 2011 at 20:36, Robert Haasrobertmh...@gmail.com wrote:
On Wed, Oct 5, 2011 at 5:03 PM, Alex Hunsakerbada...@gmail.com wrote:
On Wed, Oct 5, 2011 at 08:18, Robert Haasrobertmh...@gmail.com wrote:
On Wed, Oct 5, 2011 at 3:58 AM,
On Wed, Nov 2, 2011 at 17:12, Andrew Dunstan and...@dunslane.net 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.
On 11/02/2011 05:48 PM, Simon Riggs wrote:
On Wed, Nov 2, 2011 at 6:27 PM, Robert Haasrobertmh...@gmail.com 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 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 using a flag for
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
On Wed, Nov 2, 2011 at 8:31 PM, Bruce Momjian br...@momjian.us 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
this,
On Wed, Nov 2, 2011 at 3:27 PM, Andrew Dunstan and...@dunslane.net 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
Greg Smith g...@2ndquadrant.com 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
62 matches
Mail list logo
