On tis, 2012-04-17 at 19:19 -0400, Andrew Dunstan wrote:
> It was discussed. I think the previous behaviour is a bug. It can't be
> sane to be allowed to do:
>
> initdb -D foo bar
It's debatable whether it should be allowed. I don't see anything wrong
with it. After all, later arguments usu
>> Um ... wasn't that well enough explained already?
Yes, it was well explained and I understood also, but what I wanted to
understand the solution with which you have resolved the problem.
The way I am telling was as below code.
With this extra paths will get generated, but it will as well cons
Robert Haas writes:
> On Tue, Apr 17, 2012 at 1:47 AM, Magnus Hagander wrote:
>> That's probably one reason people aren't jumping on this. Because
>> there is no tracker out there that people actually *like*...
>
> I think this is a point worth serious thought.
I wonder why do people keep comp
On Wed, Apr 18, 2012 at 1:38 AM, Magnus Hagander wrote:
>> At the same time, I think we'd likely be a lot better off squirting this
>> data into bugzilla or another standard tracker, instead of building our
>> own infrastructure.
>
> I'm somewhat doubtful.
Me, too.
It's very tempting to assume t
Peter Eisentraut writes:
> My vote is to revert this altogether and leave it be. In the
> alternative, make it an error.
You mean in HEAD too? I don't agree with that, for sure. What this
patch is accomplishing is to make sure that the less-commonly-used
programs have similar command-line-pars
On tis, 2012-04-10 at 17:48 -0700, Josh Kupershmidt wrote:
> > Hmm, but now you've set it up so that you can complete ALTER ROLE
> foo
> > WITH WITH. Were you aware of that?
>
> D'oh, I overlooked that. Attached is v2: the diff is a tad lengthier
> now, but that should fix it.
Committed.
--
S
On ons, 2012-04-18 at 09:53 -0400, Tom Lane wrote:
> Peter Eisentraut writes:
> > My vote is to revert this altogether and leave it be. In the
> > alternative, make it an error.
>
> You mean in HEAD too? I don't agree with that, for sure. What this
> patch is accomplishing is to make sure that
On tis, 2012-04-17 at 10:52 -0400, Jay Levitt wrote:
> Maybe I'm confused - Magnus et al, are we talking spammy issues/issue
> comments/etc, or are we talking more about exposed email addresses?
My github.com account currently has 4264 notifications in the inbox.
Almost all of those are spam, gro
On Tue, Apr 17, 2012 at 3:29 PM, Fujii Masao wrote:
> Okay, patch attached.
Committed.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://
On ons, 2012-04-18 at 08:28 -0400, Robert Haas wrote:
> It's very tempting to assume that the problem we're trying to solve
> must already have been well-solved by someone else, and therefore we
> ought to use their thing instead of inventing our own. But that
> presumes that our problem is exactl
On ons, 2012-04-18 at 13:33 +0300, Alex Shulgin wrote:
> I wonder why do people keep complaining how their bug tracker of
> choice sucks, instead of doing something about that.
Lack of time, and to some degree a lack of clarity of what they want out
of the thing. (Most people are very clear on wh
On 04/18/2012 10:03 AM, Peter Eisentraut wrote:
On ons, 2012-04-18 at 09:53 -0400, Tom Lane wrote:
Peter Eisentraut writes:
My vote is to revert this altogether and leave it be. In the
alternative, make it an error.
You mean in HEAD too? I don't agree with that, for sure. What this
patch
On Wed, Apr 18, 2012 at 10:15 AM, Peter Eisentraut wrote:
> On ons, 2012-04-18 at 08:28 -0400, Robert Haas wrote:
>> It's very tempting to assume that the problem we're trying to solve
>> must already have been well-solved by someone else, and therefore we
>> ought to use their thing instead of in
On Mon, Apr 16, 2012 at 6:25 AM, Noah Misch wrote:
> I'd suggest backpatching the ReassignOwnedStmt() bits; the wrong code could
> produce crashes. The rest are for master only.
Done, in the manner you suggest.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL
Excerpts from Robert Haas's message of mié abr 18 11:47:37 -0300 2012:
> On Mon, Apr 16, 2012 at 6:25 AM, Noah Misch wrote:
> > I'd suggest backpatching the ReassignOwnedStmt() bits; the wrong code could
> > produce crashes. The rest are for master only.
>
> Done, in the manner you suggest.
Pa
On Mon, Apr 16, 2012 at 4:58 PM, Noah Misch wrote:
> The size hint I chose is fairly arbitrary. Any suggestions for principled
> alternatives?
Based on your test results, it doesn't seem like it matters very much
what you put in there, so I'm inclined to think that num_mcelem is
fine. I thought
On Sun, Apr 15, 2012 at 12:29 PM, Tom Lane wrote:
>> I think it would be a good idea for UPDATE and DELETE to expose
>> a LIMIT option, but I can't really see the virtue in making that
>> functionality available only through SPI.
>
> FWIW, I'm not excited about that. You can get well-defined beha
Peter Eisentraut wrote:
> On ons, 2012-04-18 at 13:33 +0300, Alex Shulgin wrote:
>> I wonder why do people keep complaining how their bug tracker of
>> choice sucks, instead of doing something about that.
>
> Lack of time, and to some degree a lack of clarity of what they
> want out of the thing.
Hackers,
Per bug #6593, REASSIGN OWNED fails when the affected role owns an
extension. This would be trivial to fix if extensions had support code
for ALTER EXTENSION / OWNER, but they don't. So the only back-patchable
fix right now seems to be to throw an error on REASSIGN OWNED when the
user
Hi all,
To satisfy my own curiosity, I was trying to find where 8.4 kicks into a
backwards scan of the data file during (auto-)vacuuming.
This appears to be repair_frag() in backend/commands/vacuum.c, but only appears
to be called by a FULL vacuum. Autovacuum, however, appears to explicitly on
On 04/18/2012 11:29 AM, Kevin Grittner wrote:
Peter Eisentraut wrote:
On ons, 2012-04-18 at 13:33 +0300, Alex Shulgin wrote:
I wonder why do people keep complaining how their bug tracker of
choice sucks, instead of doing something about that.
Lack of time, and to some degree a lack of clari
Hello,
Windows environment, has a problem in installing postgres in the Program
Files folder? I have this doubt because Windows works with locking system to
this folder.
Excerpts from Tom Lanyon's message of mié abr 18 12:44:11 -0300 2012:
> Hi all,
>
> To satisfy my own curiosity, I was trying to find where 8.4 kicks into a
> backwards scan of the data file during (auto-)vacuuming.
>
> This appears to be repair_frag() in backend/commands/vacuum.c, but only
>
On Wed, Apr 18, 2012 at 11:41 AM, Alvaro Herrera
wrote:
> Per bug #6593, REASSIGN OWNED fails when the affected role owns an
> extension. This would be trivial to fix if extensions had support code
> for ALTER EXTENSION / OWNER, but they don't. So the only back-patchable
> fix right now seems to
Hi guys,
I'm one of the nightly sources of 9.2devel. I was trying some simple
queries and I realized something:
stuff=# explain (analyze true, costs true, buffers true, timing true,
verbose true) select count(i) from lot_of_values;
Q
On Wed, Apr 18, 2012 at 12:13 PM, Emanuel Calvo wrote:
> Hi guys,
>
> I'm one of the nightly sources of 9.2devel. I was trying some simple
> queries and I realized something:
>
> stuff=# explain (analyze true, costs true, buffers true, timing true,
> verbose true) select count(i) from lot_of_value
El día 18 de abril de 2012 18:17, Robert Haas escribió:
> On Wed, Apr 18, 2012 at 12:13 PM, Emanuel Calvo
> wrote:
>> Hi guys,
>>
>> I'm one of the nightly sources of 9.2devel. I was trying some simple
>> queries and I realized something:
>>
>> stuff=# explain (analyze true, costs true, buffers
On Wed, Apr 18, 2012 at 12:40 PM, Emanuel Calvo wrote:
>> I'm not sure what you're unhappy about. It seems that the query
>> planner picked the fastest plan (a sequential scan) and then when you
>> disabled that it picked the second-fastest plan (an index-only scan).
>>
>> The index-only scan wou
On Wed, Apr 18, 2012 at 12:52 PM, Robert Haas wrote:
> On Wed, Apr 18, 2012 at 12:40 PM, Emanuel Calvo
> wrote:
>>> I'm not sure what you're unhappy about. It seems that the query
>>> planner picked the fastest plan (a sequential scan) and then when you
>>> disabled that it picked the second-fa
On Wed, Apr 18, 2012 at 10:22 AM, Kyotaro HORIGUCHI
wrote:
> I tried that at first. But I suppose the requirement here is 'if
> reading segments comes via replication stream, enable throttling
> by checkpoint_segments.' and WalRcvInProgress() seems fit to
> check that.
If so, what if replication
Robert, Peter, all:
>>> IME, bug trackers typically work best when used by a tightly
>>> integrated team.
>>
>> Well, very many loosely distributed open-source projects use bug
>> trackers quite successfully.
... most of them, actually.
>> Um, isn't half of the commitfest app about workflow? Pa
All,
We have 2 fairly promising projects for FDW work for this Google Summer
of code. One is for a Firebird FDW, and the more promising one is for a
"document collection" FDW from a previous successful GSOC student.
The problem is, we don't have potential mentors for these. If you are
able to h
On Wed, Apr 18, 2012 at 1:08 PM, Josh Berkus wrote:
>> 3. Otherwise, they drift forever in the bleakness of space.
Seems to me that this line, is pretty close to being T-shirt-worthy.
> wontfix. We don't need a system to help us ignore bug reports; our
>> existing process handles that with admi
On 04/17/2012 11:29 PM, Andrew Dunstan wrote:
>
>
> On 04/17/2012 04:38 PM, Tom Lane wrote:
>> Jay Levitt writes:
>>> Greg Smith wrote:
Tracking when and how a bug is backported to older versions is one
hard part
of the problem here.
>>> That's a great point. Both GitHub and git i
On Wed, Apr 18, 2012 at 1:08 PM, Josh Berkus wrote:
> BTW, given our heavy reliance on email, let me put a word in here for
> RT, which is 100% email-driven. RT has other limitations, but if your
> goal is to never log into a web interface, it's hard to beat.
If your goal is to never log into a
On Tue, Apr 17, 2012 at 5:14 PM, Tom Lane wrote:
> I've been hacking away on a patch to do this, and attached is something
> that I think is pretty close to committable.
I have nothing to add but I just wanted to say thank you for taking
the time to write up this explanation. Even when some of us
2012/4/18 Greg Stark
> On Tue, Apr 17, 2012 at 5:14 PM, Tom Lane wrote:
> > I've been hacking away on a patch to do this, and attached is something
> > that I think is pretty close to committable.
>
> [..]Even when some of us don't
> comment on some of the longer, more technical emails, we're d
On Wed, Apr 18, 2012 at 08:12, Tom Lane wrote:
> Magnus Hagander writes:
>> I think this cleraly outlines that we need to remember that there are
>> *two* different patterns that people are trying tosolve with the
>> bugtracker.
>
> Yeah, remember we drifted to this topic from discussion of manag
On Wed, Apr 18, 2012 at 16:08, Peter Eisentraut wrote:
> On tis, 2012-04-17 at 10:52 -0400, Jay Levitt wrote:
>> Maybe I'm confused - Magnus et al, are we talking spammy issues/issue
>> comments/etc, or are we talking more about exposed email addresses?
>
> My github.com account currently has 4264
On Wed, Apr 18, 2012 at 19:17, Stefan Kaltenbrunner
wrote:
> On 04/17/2012 11:29 PM, Andrew Dunstan wrote:
>>
>>
>> On 04/17/2012 04:38 PM, Tom Lane wrote:
>>> Jay Levitt writes:
Greg Smith wrote:
> Tracking when and how a bug is backported to older versions is one
> hard part
>
Hi team,
i am nagaraj, i am newbi in this database world. i required your help.
2 dyas back i formatted one of my client system. which is having postgresql
8.2 database & that was having data. but i am not taken backup of the data.
1) how to take the data from the formatted harddisk. ?
2) how many
Nagaraj,
> i am nagaraj, i am newbi in this database world. i required your help.
> 2 dyas back i formatted one of my client system. which is having postgresql
> 8.2 database & that was having data. but i am not taken backup of the data.
> 1) how to take the data from the formatted harddisk. ?
> 2
On Wed, Apr 18, 2012 at 12:15 PM, Josh Berkus wrote:
> All,
>
> We have 2 fairly promising projects for FDW work for this Google Summer
> of code. One is for a Firebird FDW, and the more promising one is for a
> "document collection" FDW from a previous successful GSOC student.
>
> The problem is
04/18/2012
PostgreSQL Conference Next 2012, in Denver from Jun 26th - 29th is
cancelled. If you are looking for another conference in this time frame
we suggest:
http://www.pgcon.org/
There are also other conferences coming up in the next 6 months:
http://www.postgresopen.org/
http://www.p
On 4/18/12 11:53 AM, Joshua D. Drake wrote:
> Lastly, there is a Denver PgDay in October. PgDay's are a great way to
> meet locals and enjoy a smaller community setting but still maintain top
> notch content.
Date? Hopefully not the same time as pg.EU?
I'd like to go this year.
--
Josh Berkus
On 04/18/2012 11:56 AM, Josh Berkus wrote:
On 4/18/12 11:53 AM, Joshua D. Drake wrote:
Lastly, there is a Denver PgDay in October. PgDay's are a great way to
meet locals and enjoy a smaller community setting but still maintain top
notch content.
Date? Hopefully not the same time as pg.EU?
On Wed, Apr 18, 2012 at 8:12 PM, Joshua D. Drake wrote:
>
> On 04/18/2012 11:56 AM, Josh Berkus wrote:
>>
>>
>> On 4/18/12 11:53 AM, Joshua D. Drake wrote:
>>>
>>> Lastly, there is a Denver PgDay in October. PgDay's are a great way to
>>> meet locals and enjoy a smaller community setting but still
On 04/18/2012 01:26 PM, Robert Haas wrote:
On Wed, Apr 18, 2012 at 1:08 PM, Josh Berkus wrote:
BTW, given our heavy reliance on email, let me put a word in here for
RT, which is 100% email-driven. RT has other limitations, but if your
goal is to never log into a web interface, it's hard to b
On Wed, Apr 18, 2012 at 1:48 PM, Magnus Hagander wrote:
> The problem I've found with most tools is that they work reasonably
> well if you let them control the entire workflow. But when you want to
> do things your own way, and it doesn't match up with what they were
> originally designed to do,
I discovered when researching the issue of index-only scans and Hot
Standby that there's a bug (for which I'm responsible) in
lazy_scan_heap[1]. Actually, the code has been like this for a long
time, but I needed to change it when I did the crash-safe visibility
map work, and I didn't. The proble
Peter Eisentraut writes:
> On tis, 2012-04-17 at 10:47 -0300, Alvaro Herrera wrote:
>> What's the preferred way to make it automatically tested as much as
>> possible? I know the buildfarm does not run "installcheck-world", so if
>> we want it there, it'd need a bit more code on the client side
Andrew Dunstan writes:
>>> That's one reason for that, but there are probably others in the way of
>>> making this fully portable and automatable.
>
> This test setup also appears to labor under the illusion that we live
> in a Unix-only world. And for no good reason that I can tell. The
> shell
Excerpts from Robert Haas's message of mié abr 18 13:05:03 -0300 2012:
> On Wed, Apr 18, 2012 at 11:41 AM, Alvaro Herrera
> wrote:
> > Per bug #6593, REASSIGN OWNED fails when the affected role owns an
> > extension. This would be trivial to fix if extensions had support code
> > for ALTER EXTENS
On Wed, Apr 18, 2012 at 5:27 PM, Alvaro Herrera
wrote:
> Excerpts from Robert Haas's message of mié abr 18 13:05:03 -0300 2012:
>> On Wed, Apr 18, 2012 at 11:41 AM, Alvaro Herrera
>> wrote:
>> > Per bug #6593, REASSIGN OWNED fails when the affected role owns an
>> > extension. This would be triv
Robert Haas writes:
> On Wed, Apr 18, 2012 at 5:27 PM, Alvaro Herrera
> wrote:
>> Here's a patch for that.
> Looks sane on a quick once-over. I do wonder about the comment,
> though. If we add ALTER EXTENSION .. OWNER, should that try to change
> the ownership of the objects contained inside t
On Wed, Apr 18, 2012 at 7:54 PM, Tom Lane wrote:
> However, ignoring that issue for the moment, this patch is making me
> uncomfortable. I have a vague recollection that we deliberately omitted
> ALTER EXTENSION OWNER because of security or definitional worries.
> (Dimitri, does that ring any bel
So while testing this patch I've found out that there is a pretty nasty
bug in HEAD as well as in my current formulation of the patch. Here
is an example using the regression database:
select count(*) from
(tenk1 a join tenk1 b on a.unique1=b.unique2)
left join tenk1 c on a.unique2 = b.unique
On 17 April 2012 13:19, Greg Stark wrote:
> All in all I think it's handier to have a stable ORDER BY sort than an
> unstable one though. So I'm not necessarily opposed to it even if it
> means we're stuck using a stable sort indefinitely.
I think it might be useful to disguard the stability prop
I convinced that current patch has a problem, and will come up
with the new patch later.
> > I tried that at first. But I suppose the requirement here is 'if
> > reading segments comes via replication stream, enable throttling
> > by checkpoint_segments.' and WalRcvInProgress() seems fit to
>
In function generate_join_implied_equalities_normal(), in which kind of
query it can have all three outer_members, inner_members, new_members set?
There is handling related to that in the same function down which I wanted
to understand.
Hello, this is new version of standby checkpoint_segments patch.
- xlog.c: Make StandbyMode shared.
- checkpointer.c: Use IsStandbyMode() to check if postmaster is
under standby mode.
regards,
--
Kyotaro Horiguchi
NTT Open Source Software Center
== My e-mail address has been changed sin
Amit Kapila writes:
> The way I am telling was as below code.
> With this extra paths will get generated, but it will as well consider for
> joining c and d in query:
> select * from a, b, c, d where a.x = b.y and (a.z = c.c or a.z = d.d)
I think this would just be dead code as of HEAD. With th
On Tue, 2012-04-17 at 14:24 -0400, Robert Haas wrote:
> I thought Jeff was parenthetically complaining about cases like A LEFT
> JOIN (B INNER JOIN C ON b.y = c.y) ON a.x && b.x. That presumably
> would require the parameterized-path stuff to have any chance of doing
> partial index scans over B.
On Mon, Mar 12, 2012 at 10:50:36PM -0400, Tom Lane wrote:
> There is one more (known) stop-ship problem in SPGiST, which I'd kind of
> like to get out of the way now before I let my knowledge of that code
> get swapped out again. This is that SPGiST is unsafe for use by hot
> standby slaves.
I su
64 matches
Mail list logo
