2012-04-08 19:38 keltezéssel, Michael Meskes írta:
On Sun, Apr 08, 2012 at 06:35:33PM +0200, Boszormenyi Zoltan wrote:
Do you want me to change this or will you do it? I am on holiday
and will be back to work on wednesday.
I don't think waiting till later this week is a real problem.
OK.
On Monday, April 09, 2012 05:32:43 PM Noah Misch wrote:
> On Mon, Apr 09, 2012 at 03:35:06PM +0200, Andres Freund wrote:
> > On Monday, April 09, 2012 03:25:36 PM Robert Haas wrote:
> > > contrib/xml2 isn't doing us much harm beyond being an ugly wart, but
> > > non- SELECT rules are a land mine fo
> > pgfincore does not use the postgresql buffer manager, it uses the posix
> > calls. It can proceed per block or full relation.
> >
> > Both need POSIX_FADVISE compatible system to be efficient.
> >
> > The main difference between pgfincore and pg_prewarm about full relation
> > warm is that pg
Atri Sharma wrote:
> I submitted a proposal for GSoc 2012.Please review it and let me know
> your comments.
>
> The link is:
>
>
https://google-melange.appspot.com/gsoc/proposal/review/google/gsoc2012/
atrisharma/1001
I think that this is a pretty cool idea.
Have you contacted the developers of
On Tue, Apr 10, 2012 at 5:38 PM, Albe Laurenz wrote:
> Atri Sharma wrote:
>> I submitted a proposal for GSoc 2012.Please review it and let me know
>> your comments.
>>
>> The link is:
>>
>>
> https://google-melange.appspot.com/gsoc/proposal/review/google/gsoc2012/
> atrisharma/1001
>
> I think tha
On Thu, Apr 5, 2012 at 11:45 AM, Robert Haas wrote:
> Meanwhile, pg_stat_statements converts the same data to seconds but
> makes it a double rather than a bigint. I think that was a bad idea
> and we should make it consistent use a bigint and milliseconds while
> we still can.
Hmm. So, on furt
Looking over the remaining patches that still aren't closed in the
January CommitFest:
Foreign keys with arrays - Tom wants to commit this at the beginning
of a release cycle rather than the end, but there's no actual known
problem with it. Therefore I suggest moving it to the first 9.3
CommitFes
On 04/09/2012 01:25 PM, Atri Sharma wrote:
On Mon, Apr 9, 2012 at 10:15 PM, Andrew Dunstan wrote:
On 04/09/2012 12:14 PM, Dave Cramer wrote:
So I'm confused, once they link a file to an FDW can't you just read
it with an normal select ?
What additional functionality will this provide ?
Andres Freund writes:
> Here is what I know and what comes to my mind right now:
> 1. anything but INSTEAD rules are unsafe
How so? I agree that volatile functions are problematic, but unless
there's one of those in the picture I think rules work pretty much as
documented.
> 3. the snapshots b
On Tue, Apr 10, 2012 at 8:42 AM, Andrew Dunstan wrote:
>> I am considering two paths for doing this:
>> The first one takes the help of the SPI(Server Programming Interface)
>> and the second one directly connects through Pl/Java and JNI(Java
>> Native Interface).
>>
>
> I'd say forget SPI - I don
On 04/10/2012 09:40 AM, Robert Haas wrote:
parallel pg_dump - I think this one needs to get moved to the first
9.3 CommitFest. There is more work to be done there than we can
realistically do right now, but I think we can pick it up for the next
cycle.
Yeah, I'm only about 1/4 of the way
Robert Haas writes:
> Hmm. So, on further review, this is not as simple as it seems. I'd
> like some input from other people on what we should do here.
> pg_stat_statements has long exposed a column called "total_time" as a
> float8. It now exposes columns "time_read" and "time_write" which ar
On 10 April 2012 14:33, Robert Haas wrote:
> So, should we make the new columns exposed by pg_stat_statements use
> milliseconds, so that the block read/write timings are everywhere in
> milliseconds, or should we keep them as a float8, so that all the
> times exposed by pg_stat_statements use flo
On 04/10/2012 09:48 AM, Merlin Moncure wrote:
On Tue, Apr 10, 2012 at 8:42 AM, Andrew Dunstan wrote:
I am considering two paths for doing this:
The first one takes the help of the SPI(Server Programming Interface)
and the second one directly connects through Pl/Java and JNI(Java
Native Interf
Robert Haas writes:
> Looking over the remaining patches that still aren't closed in the
> January CommitFest:
> [ all but ECPG readahead and maybe libpq URIs have to go to 9.3 ]
Yeah, I agree. I'm not comfortable with squeezing in the array foreign
keys stuff at this point, and the others are c
On Tue, Apr 10, 2012 at 09:40:58AM -0400, Robert Haas wrote:
> ECPG FETCH readahead - Michael Meskes is going to commit this soon;
> everyone seems to agree it's ready to go.
It still needs a couple minor tweaks but I think it will be done shortly.
Michael
--
Michael Meskes
Michael at Fam-Meskes
Christopher Browne wrote:
> Robert Haas wrote:
>> CommitFests are a time for patches that are done or very nearly
>> done to get committed, and a time for other patches to get
>> reviewed if they haven't been already. If we make it clear that
>> the purpose of the CommitFest is to assess wheth
On Tue, Apr 10, 2012 at 9:15 AM, Andrew Dunstan wrote:
>
>
> On 04/10/2012 09:48 AM, Merlin Moncure wrote:
>>
>> On Tue, Apr 10, 2012 at 8:42 AM, Andrew Dunstan
>> wrote:
I am considering two paths for doing this:
The first one takes the help of the SPI(Server Programming Interface
On Tue, Apr 10, 2012 at 09:35:21AM +0200, Boszormenyi Zoltan wrote:
> So, it's established that a specified READAHEAD N should not
> be overridden. Even an explicit READAHEAD 1.
>
> Only a non-decorated cursor can be overridden, even if
> a different default readahead window size is specified with
On 04/10/2012 10:34 AM, Merlin Moncure wrote:
On Tue, Apr 10, 2012 at 9:15 AM, Andrew Dunstan wrote:
On 04/10/2012 09:48 AM, Merlin Moncure wrote:
On Tue, Apr 10, 2012 at 8:42 AM, Andrew Dunstan
wrote:
I am considering two paths for doing this:
The first one takes the help of the SPI(Ser
On Tue, Apr 10, 2012 at 10:37:22AM -0400, Noah Misch wrote:
> > Only a non-decorated cursor can be overridden, even if
> > a different default readahead window size is specified with
> > e.g. "ecpg -R 8". If ECPGFETCHSZ is not present, 8 will be used,
> > if ECPGFETCHSZ is present, its value will b
On 6 April 2012 01:19, Noah Misch wrote:
> On Thu, Apr 05, 2012 at 02:34:30PM -0400, Robert Haas wrote:
>> On Thu, Apr 5, 2012 at 2:23 PM, Tom Lane wrote:
>> > The FK arrays one I'm kind of queasy about. ?It's a cool-sounding idea
>> > but I'm not convinced that all the corner-case details have b
Excerpts from Robert Haas's message of mar abr 10 10:40:58 -0300 2012:
> URI connection string support for libpq - I'm unclear with Alvaro or
> Peter still intend to try to slip this one in. It's simple enough
> that I think that would be OK if it can be done in the next day or
> two. Otherwise
On Tue, Apr 10, 2012 at 9:47 AM, Andrew Dunstan wrote:
> I don't understand what the heck you're talking about, TBH. From a user
> perspective there is nothing to work out. It will look like any other FDW.
yes, that is correct.
> The implementor of the FDW handler will have to work out the glue
On Tue, Apr 10, 2012 at 7:27 AM, Heikki Linnakangas
wrote:
> I think the way we'd speed up COUNT(*) further would be to implement
> materialized views. Then you could define a materialized view on COUNT(*),
> and essentially get a row counter similar to MyISAM. I think it's fair to
> mark this as
On 10 April 2012 15:26, Kevin Grittner wrote:
> A patch on which the author is continuing to work even in the absence of
> review
> should be considered a WIP "want feedback" submission; it should not
> be allowed to constitute a "placeholder" for inclusion in the
> release.
To be fair, I doubt
Merlin Moncure writes:
> ... We have to invoke java and there
> are two basic ways to tie into the java runtime: one is to jump
> through SPI via the SQL executor. The other is JNI into the pl/java
> jvm which I think you were hinting was the better approach.
Hm? SPI doesn't know anything abou
2012-04-10 16:55 keltezéssel, Michael Meskes írta:
On Tue, Apr 10, 2012 at 10:37:22AM -0400, Noah Misch wrote:
Only a non-decorated cursor can be overridden, even if
a different default readahead window size is specified with
e.g. "ecpg -R 8". If ECPGFETCHSZ is not present, 8 will be used,
if EC
On Tue, Apr 10, 2012 at 11:25 AM, Tom Lane wrote:
> Merlin Moncure writes:
>> ... We have to invoke java and there
>> are two basic ways to tie into the java runtime: one is to jump
>> through SPI via the SQL executor. The other is JNI into the pl/java
>> jvm which I think you were hinting was
On Tue, Apr 10, 2012 at 8:55 PM, Tom Lane wrote:
> Merlin Moncure writes:
>> ... We have to invoke java and there
>> are two basic ways to tie into the java runtime: one is to jump
>> through SPI via the SQL executor. The other is JNI into the pl/java
>> jvm which I think you were hinting was t
On Mon, Apr 9, 2012 at 11:27 PM, Heikki Linnakangas
wrote:
> On 10.04.2012 03:32, Jeff Janes wrote:
>>
>> The To Do wiki says not to add things to the page with discussing here.
...
>
>> sort_support was implemented for plain tuple sorting only, To Do is
>> extend to index-creation sorts (item 2 f
On Tue, Apr 10, 2012 at 05:24:55PM +0200, Boszormenyi Zoltan wrote:
> OK. Next question: now that both patches are intended to be applied,
> should I send a unified single patch that contains the previous functionality
> and the required fixes or a new one that only contains the last required
> fi
Atri Sharma writes:
> On Tue, Apr 10, 2012 at 8:55 PM, Tom Lane wrote:
>> Hm? SPI doesn't know anything about Java either.
> We plan to call SQL through SPI from the FDW,which in turn would call
> the Pl/Java routine.
If you're saying that every Java function that the FDW needs would have
to b
2012-04-10 17:34 keltezéssel, Michael Meskes írta:
On Tue, Apr 10, 2012 at 05:24:55PM +0200, Boszormenyi Zoltan wrote:
OK. Next question: now that both patches are intended to be applied,
should I send a unified single patch that contains the previous functionality
and the required fixes or a ne
On 10.04.2012 18:31, Jeff Janes wrote:
On Mon, Apr 9, 2012 at 11:27 PM, Heikki Linnakangas
wrote:
On 10.04.2012 03:32, Jeff Janes wrote:
The To Do wiki says not to add things to the page with discussing here.
...
sort_support was implemented for plain tuple sorting only, To Do is
extend
On Tue, Apr 10, 2012 at 11:24 AM, Peter Geoghegan wrote:
> On 10 April 2012 15:26, Kevin Grittner wrote:
>> A patch on which the author is continuing to work even in the absence of
>> review
>> should be considered a WIP "want feedback" submission; it should not
>> be allowed to constitute a "pl
On 10 April 2012 16:40, Heikki Linnakangas
wrote:
> On 10.04.2012 18:31, Jeff Janes wrote:
>> If I do "select count(distinct bid) from pgbench_accounts" I get many
>> calls to btint4fastcmp, but if I do "create index on pgbench_accounts
>> (bid)" I instead get many calls to btint4cmp. If the inde
On 04/10/2012 11:36 AM, Tom Lane wrote:
Atri Sharma writes:
On Tue, Apr 10, 2012 at 8:55 PM, Tom Lane wrote:
Hm? SPI doesn't know anything about Java either.
We plan to call SQL through SPI from the FDW,which in turn would call
the Pl/Java routine.
If you're saying that every Java functi
On Tue, Apr 10, 2012 at 10:06 AM, Tom Lane wrote:
> Robert Haas writes:
>> Hmm. So, on further review, this is not as simple as it seems. I'd
>> like some input from other people on what we should do here.
>
>> pg_stat_statements has long exposed a column called "total_time" as a
>> float8. It
On Tue, Apr 10, 2012 at 10:36 AM, Tom Lane wrote:
> Atri Sharma writes:
>> On Tue, Apr 10, 2012 at 8:55 PM, Tom Lane wrote:
>>> Hm? SPI doesn't know anything about Java either.
>
>> We plan to call SQL through SPI from the FDW,which in turn would call
>> the Pl/Java routine.
>
> If you're sayin
Robert Haas writes:
> No matter what we end up doing here it will be consistent with
> something; I am reminded of the phrase "the good thing about standards
> is that there are so many to choose from...".
Well, FWIW I vote for making the new columns be float8 msec. If you
don't want to change t
On Tue, Apr 10, 2012 at 17:58, Robert Haas wrote:
> On Tue, Apr 10, 2012 at 10:06 AM, Tom Lane wrote:
>> Robert Haas writes:
>>> Hmm. So, on further review, this is not as simple as it seems. I'd
>>> like some input from other people on what we should do here.
>>
>>> pg_stat_statements has lon
Magnus Hagander writes:
> On Tue, Apr 10, 2012 at 17:58, Robert Haas wrote:
>> On Tue, Apr 10, 2012 at 10:06 AM, Tom Lane wrote:
>>> Given that we've whacked pg_stat_statements' behavior around rather
>>> thoroughly in this release, maybe we could get away with redefining
>>> total_time as being
On 10 April 2012 16:51, Robert Haas wrote:
> When these things are pointed out to the people who are doing them,
> the response is often either (a) this feature is so important we're
> all going to die if it's not in the release how can you even think
> about bouncing it or (b) I'm not really stil
On Tue, Apr 10, 2012 at 18:27, Tom Lane wrote:
> Magnus Hagander writes:
>> On Tue, Apr 10, 2012 at 17:58, Robert Haas wrote:
>>> On Tue, Apr 10, 2012 at 10:06 AM, Tom Lane wrote:
Given that we've whacked pg_stat_statements' behavior around rather
thoroughly in this release, maybe we
"Kevin Grittner" writes:
> One other sort of mechanical test which I think can and should be
> applied to patches submitted to the last CF is that if *at the start
> of the CF* the patch doesn't apply, compile, pass regression tests,
> and demonstrably provide the functionality claimed for the pat
Robert Haas writes:
> ... It's surprisingly easy to hoodwink even
> experienced contributors into thinking that your patch is really,
> really almost done, honest, it just needs a couple more tweaks when in
> fact it's nowhere close. I try not to attribute to bad faith what can
> be explained by
Tom Lane wrote:
> "Kevin Grittner" writes:
>> One other sort of mechanical test which I think can and should be
>> applied to patches submitted to the last CF is that if *at the
>> start of the CF* the patch doesn't apply, compile, pass
>> regression tests, and demonstrably provide the functional
On 10/04/12 07:35, Jan Urbański wrote:
On 10/04/12 04:20, Tom Lane wrote:
Don't know if anybody noticed bug #6559
http://archives.postgresql.org/pgsql-bugs/2012-03/msg00180.php
I've confirmed that the given test case works in 9.0 but fails in
9.1 and HEAD.
So, I know what's going on, I still
Re: Tom Lane 2012-04-04 <28647.1333558...@sss.pgh.pa.us>
> Now, Scott's comment seems to me to offer a principled way out of this:
> if we define the intended semantics of search_path as being similar
> to the traditional understanding of Unix PATH, then it's not an error
> or even unexpected to ha
On 4/9/12 6:12 PM, Jeff Davis wrote:
On Mon, 2012-04-09 at 17:42 -0500, Jim Nasby wrote:
Dumb question... should operations in the various StrongLock functions
take place in a critical section? Or is that already ensure outside of
these functions?
Do you mean CRITICAL_SECTION() in the postgres
On 04/09/2012 11:12 PM, Christopher Browne wrote:
It seems as though we need to have a "bad guy" that will say, "that
sure isn't ready to COMMIT, so we'd better step back from imagining
that it ought to be completed as part of this COMMITfest."
There's no reward for anyone in the PostgreSQL co
On Tue, Apr 10, 2012 at 12:28 PM, Peter Geoghegan wrote:
> I think that you may be missing the greater point here. The people
> that do this are kind of like the defectors in prisoner's dilemma - at
> a certain point, some people cannot resist the temptation to push
> their own patch forward at th
On Tue, Apr 10, 2012 at 1:27 PM, Greg Smith wrote:
> There's no reward for anyone in the PostgreSQL community to be a bad guy.
> If you're too aggressive about it, submitters get mad; too loose, and you
> get both committers and people worried about the release schedule mad. And
> the community
On Tue, Apr 10, 2012 at 12:11 PM, Tom Lane wrote:
> Robert Haas writes:
>> No matter what we end up doing here it will be consistent with
>> something; I am reminded of the phrase "the good thing about standards
>> is that there are so many to choose from...".
>
> Well, FWIW I vote for making the
On tis, 2012-04-03 at 22:34 -0700, Josh Kupershmidt wrote:
> I noticed psql's tab-completion for 'WITH' is a bit overeager. If you
> try to tab-complete commands like:
> ALTER ROLE jsmith WITH [TAB]
> COPY tbl FROM 'filename' WITH [TAB]
>
> you'll get 'RECURSIVE' unhelpfully filled in. I think
Robert Haas writes:
> On Tue, Apr 10, 2012 at 12:11 PM, Tom Lane wrote:
>> Well, FWIW I vote for making the new columns be float8 msec.
> Ugh. So the three ways of doing timing that we have already aren't
> enough, and we need a fourth one? Ack!
Huh? I understood what you said upthread to be
On Tue, Apr 10, 2012 at 1:44 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Tue, Apr 10, 2012 at 12:11 PM, Tom Lane wrote:
>>> Well, FWIW I vote for making the new columns be float8 msec.
>
>> Ugh. So the three ways of doing timing that we have already aren't
>> enough, and we need a fourth on
Hey,
Just a reminder that the CFP for PgNext in Denver is still open. Let's
get those talks in folks!
https://www.postgresqlconference.org/
Sincerely,
Joshua D. Drake
--
Command Prompt, Inc. - http://www.commandprompt.com/
PostgreSQL Support, Training, Professional Services and Developmen
Hi,
2012-04-10 16:55 keltezéssel, Michael Meskes írta:
On Tue, Apr 10, 2012 at 10:37:22AM -0400, Noah Misch wrote:
Only a non-decorated cursor can be overridden, even if
a different default readahead window size is specified with
e.g. "ecpg -R 8". If ECPGFETCHSZ is not present, 8 will be used,
Robert Haas writes:
> On Tue, Apr 10, 2012 at 1:44 PM, Tom Lane wrote:
>> Huh? I understood what you said upthread to be that we have two ways
>> in existing releases (anything unreleased has zero standing in this
>> discussion): float8 sec in pg_stat_statements.total_time, and
>> int8 msec ever
On Tue, Apr 10, 2012 at 1:58 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Tue, Apr 10, 2012 at 1:44 PM, Tom Lane wrote:
>>> Huh? I understood what you said upthread to be that we have two ways
>>> in existing releases (anything unreleased has zero standing in this
>>> discussion): float8 sec
On Tue, Apr 10, 2012 at 02:01:02PM -0400, Robert Haas wrote:
> On Tue, Apr 10, 2012 at 1:58 PM, Tom Lane wrote:
> > Robert Haas writes:
> >> On Tue, Apr 10, 2012 at 1:44 PM, Tom Lane wrote:
> >>> Huh? I understood what you said upthread to be that we have two ways
> >>> in existing releases (an
Robert Haas writes:
> On Tue, Apr 10, 2012 at 1:58 PM, Tom Lane wrote:
>> The business about underlying microseconds is maybe not so good, but
>> I don't think we want to touch that right now. In the long run
>> I think it would make sense to converge on float8 msec as being the
>> standard for
=?UTF-8?B?SmFuIFVyYmHFhHNraQ==?= writes:
>> On 10/04/12 04:20, Tom Lane wrote:
>>> Don't know if anybody noticed bug #6559
>>> http://archives.postgresql.org/pgsql-bugs/2012-03/msg00180.php
> So, I know what's going on, I still don't know what's the best way to
> handle it.
> The function that
I wrote:
> =?UTF-8?B?SmFuIFVyYmHFhHNraQ==?= writes:
>> Now that I understand what's been going on, I'll try to think of a
>> non-invasive way of fixing that...
> ISTM that conversion of a composite value to Python ought to produce a
> dict, now that the other direction expects a dict. I can see
On 10 April 2012 18:28, Robert Haas wrote:
> If we accept your argument that some
> people simply cannot help themselves, then the only solution is to
> make it cease to be a prisoner's dilemma, and that can only be done by
> changing the incentives, which presumably means handing down
> punishmen
Peter Geoghegan writes:
> On 10 April 2012 18:28, Robert Haas wrote:
>> I don't agree with that. I think that there are a few people who
>> don't now have commit bits who should be given them - in particular,
>> Fujii Masao and Kevin Grittner, both of whom have been doing
>> consistently excelle
On 10/04/12 20:47, Tom Lane wrote:
I wrote:
=?UTF-8?B?SmFuIFVyYmHFhHNraQ==?= writes:
Now that I understand what's been going on, I'll try to think of a
non-invasive way of fixing that...
ISTM that conversion of a composite value to Python ought to produce a
dict, now that the other directio
=?UTF-8?B?SmFuIFVyYmHFhHNraQ==?= writes:
> On 10/04/12 20:47, Tom Lane wrote:
>> On reflection, can't we fix this as follows: if the value coming in from
>> Python is a string, just feed it to record_in, the same as we used to.
>> When I traced through the logic before, it seemed like it was faili
On 10/04/12 21:27, Tom Lane wrote:
=?UTF-8?B?SmFuIFVyYmHFhHNraQ==?= writes:
Yes, that would be ideal, even though not backwards-compatible.
Back-patching is out of the question, but do we want to change trigger
functions to receive dictionaries in NEW?
Hm, I was not thinking of this as being
On Tue, Apr 10, 2012 at 2:49 PM, Peter Geoghegan wrote:
> Well, I was really pointing out that people are somewhat forced into a
> corner by the current state of affairs, because committers are not
> typically able to look at anything in sufficient detail that isn't
> "ready for committer", partic
On Friday, April 6, 2012, Thom Brown wrote:
> Hi,
>
> I've tried out pg_receivexlog and have noticed that when restarting
> the cluster, pg_receivexlog gets cut off... it doesn't keep waiting.
> This is surprising as the DBA would have to remember to start
> pg_receivexlog up again.
>
>
This is in
On Mon, 2012-04-09 at 23:12 -0400, Christopher Browne wrote:
> But there is also a flip side to that, namely that if we do so, there
> ought to be some aspect to the process to help guide those items that
> *aren't* particularly close to being committable.
I have benefited immensely from review of
The new pg_tablespace_location() function added in PG 9.2 to remove the
director location from pg_tablespace returns an odd error for '0', which
is InvalidOID:
test=> select pg_tablespace_location(0);
ERROR: could not read symbolic link "pg_tblspc/0": No such file or
direc
On Tue, Apr 10, 2012 at 11:07 AM, Merlin Moncure wrote:
> I agree that JNI isn't required -- we're going to
> have to study the pl/java system a bit to determine the best way to
> hook in. This could end up getting us into the 'biting of more than
> can chew' territory admittedly, but Atri is en
Christoph Berg writes:
> Re: Tom Lane 2012-04-04 <28647.1333558...@sss.pgh.pa.us>
>> Now, Scott's comment seems to me to offer a principled way out of this:
>> if we define the intended semantics of search_path as being similar
>> to the traditional understanding of Unix PATH, then it's not an err
Bruce Momjian writes:
> The new pg_tablespace_location() function added in PG 9.2 to remove the
> director location from pg_tablespace returns an odd error for '0', which
> is InvalidOID:
Well, it's the same "odd error" you'd get for any other bogus OID.
The way the function is coded, it has no
On 04/10/2012 12:27 PM, Tom Lane wrote:
Changing the column name will definitely break
anything more specific than "select * from pg_stat_statements".
However, it's less clear that changing the units in which the column is
expressed will break things. It seems likely to me that nobody out
there
On Tue, Apr 10, 2012 at 05:43:12PM -0400, Tom Lane wrote:
> Bruce Momjian writes:
> > The new pg_tablespace_location() function added in PG 9.2 to remove the
> > director location from pg_tablespace returns an odd error for '0', which
> > is InvalidOID:
>
> Well, it's the same "odd error" you'd g
On Tue, Apr 10, 2012 at 5:43 PM, Tom Lane wrote:
> Bruce Momjian writes:
>> The new pg_tablespace_location() function added in PG 9.2 to remove the
>> director location from pg_tablespace returns an odd error for '0', which
>> is InvalidOID:
>
> Well, it's the same "odd error" you'd get for any o
On Tue, Apr 10, 2012 at 5:20 PM, Tom Lane wrote:
> Christoph Berg writes:
>> Re: Tom Lane 2012-04-04 <28647.1333558...@sss.pgh.pa.us>
>>> Now, Scott's comment seems to me to offer a principled way out of this:
>>> if we define the intended semantics of search_path as being similar
>>> to the trad
On Tue, Apr 10, 2012 at 06:16:31PM -0400, Robert Haas wrote:
> On Tue, Apr 10, 2012 at 5:43 PM, Tom Lane wrote:
> > Bruce Momjian writes:
> >> The new pg_tablespace_location() function added in PG 9.2 to remove the
> >> director location from pg_tablespace returns an odd error for '0', which
> >>
On 10 April 2012 23:07, Greg Smith wrote:
> On 04/10/2012 12:27 PM, Tom Lane wrote:
> I am doing more sophisticated things with it, so I'll celebrate this as my
> opportunity to say I did something you didn't see coming for 2012.
This is why I requested that we expose the query_id hash value - I
On 04/10/2012 01:33 PM, Robert Haas wrote:
I also think that people were more receptive to my reviews before I
got a commit bit.
That's not true; many people were just as annoyed at you back then.
(Robert knows I'm kidding. I hope.)
--
Greg Smith 2ndQuadrant USg...@2ndquadrant.com
Bruce Momjian writes:
> On Tue, Apr 10, 2012 at 06:16:31PM -0400, Robert Haas wrote:
>> On Tue, Apr 10, 2012 at 5:43 PM, Tom Lane wrote:
>>> The way the function is coded, it has no need to look into pg_tablespace
>>> as such, which is why you don't get something like "no such tablespace".
>> I
Robert Haas writes:
> On Tue, Apr 10, 2012 at 5:20 PM, Tom Lane wrote:
>> I am not sure whether we should consider back-patching this into 9.1,
>> although that would be necessary if we wanted to fix Robert's original
>> complaint against 9.1. Thoughts?
> I guess my feeling would be "no", becau
On Tue, Apr 10, 2012 at 07:09:33PM -0400, Tom Lane wrote:
> Bruce Momjian writes:
> > On Tue, Apr 10, 2012 at 06:16:31PM -0400, Robert Haas wrote:
> >> On Tue, Apr 10, 2012 at 5:43 PM, Tom Lane wrote:
> >>> The way the function is coded, it has no need to look into pg_tablespace
> >>> as such, wh
On Tue, Apr 10, 2012 at 6:32 PM, Peter Geoghegan wrote:
> On 10 April 2012 23:07, Greg Smith wrote:
>> On 04/10/2012 12:27 PM, Tom Lane wrote:
>> I am doing more sophisticated things with it, so I'll celebrate this as my
>> opportunity to say I did something you didn't see coming for 2012.
>
> Th
Peter Geoghegan writes:
> On 10 April 2012 23:07, Greg Smith wrote:
>> On 04/10/2012 12:27 PM, Tom Lane wrote:
>> I am doing more sophisticated things with it, so I'll celebrate this as my
>> opportunity to say I did something you didn't see coming for 2012.
> This is why I requested that we exp
Bruce Momjian writes:
> On Tue, Apr 10, 2012 at 07:09:33PM -0400, Tom Lane wrote:
>> Hm. I have no objection to special-casing zero here, but what behavior
>> do you want? Should it return an empty string as we do for
>> DEFAULTTABLESPACE_OID, or throw a different error?
> I have no idea. The
On 11 April 2012 00:35, Robert Haas wrote:
> If people need something like that, couldn't they create it by hashing
> the normalized query text with an arbitrary algorithm?
That supposes that the normalised query text is perfectly stable. It
may well not be, particularly for things like ad-hoc qu
On Thu, Mar 22, 2012 at 02:55:32PM +0200, Ants Aasma wrote:
> Hi,
>
> while working on a support case I stumbled upon a bug in pg_upgrade.
> Upgrade fails with "No such file or directory" when a database is
> moved to a non-default tablespace and contains a table that is moved
> to pg_default. The
On Tue, Apr 10, 2012 at 07:57:30PM -0400, Tom Lane wrote:
> Bruce Momjian writes:
> > On Tue, Apr 10, 2012 at 07:09:33PM -0400, Tom Lane wrote:
> >> Hm. I have no objection to special-casing zero here, but what behavior
> >> do you want? Should it return an empty string as we do for
> >> DEFAULT
On Tue, Apr 10, 2012 at 11:53:23AM -0500, Kevin Grittner wrote:
> Tom Lane wrote:
> > "Kevin Grittner" writes:
> >> One other sort of mechanical test which I think can and should be
> >> applied to patches submitted to the last CF is that if *at the
> >> start of the CF* the patch doesn't apply,
Peter Geoghegan writes:
> On 11 April 2012 00:35, Robert Haas wrote:
>> If people need something like that, couldn't they create it by hashing
>> the normalized query text with an arbitrary algorithm?
> That supposes that the normalised query text is perfectly stable. It
> may well not be, parti
Bruce Momjian writes:
> On Tue, Apr 10, 2012 at 07:57:30PM -0400, Tom Lane wrote:
>> If we expect this function to mainly be applied to pg_class.reltablespace,
>> then it seems like it ought to understand that zero means "the database
>> default" and substitute the database's default tablespace.
I wrote:
> AFAICS your patch does not avoid the fact that the function will throw
> error on a zero input.
Oh, no, scratch that --- I was thinking that you were applying the
function directly to pg_class.reltablespace, but you're applying it to
pg_tablespace.oid, so the issue should not arise.
On 04/10/2012 01:28 PM, Robert Haas wrote:
The fact is that we have no shortage of committers - there are 19
people who have access to push code into our master git repository. A
handful of those people have basically completely left the project and
their commit rights should probably be revoked
On Tue, Apr 10, 2012 at 08:22:15PM -0400, Tom Lane wrote:
> Bruce Momjian writes:
> > On Tue, Apr 10, 2012 at 07:57:30PM -0400, Tom Lane wrote:
> >> If we expect this function to mainly be applied to pg_class.reltablespace,
> >> then it seems like it ought to understand that zero means "the databa
1 - 100 of 123 matches
Mail list logo
