On Mon, 2012-04-09 at 22:47 -0700, Jeff Davis wrote:
but other similar paths do:
if (!proclock)
{
AbortStrongLockAcquire();
I don't think it's necessary outside of LockErrorCleanup(), right?
I take that back, it's necessary for the dontwait case, too.
Regards,
Jeff Davis
I cannot see your task manager, may be you can send it as .bmp attached with
this mail.
As there is only one postgres process, it seems your postgres server itself
is not started.
For the second I have little experience with computers, you could help me
write the correct command.
a.Go
On 10.04.2012 03:32, Jeff Janes wrote:
The To Do wiki says not to add things to the page with discussing here.
So here are some things to discuss. Assuming the discussion is a
brief yup or nope, it seems to make sense to lump them into one email:
Vacuuming a table with a large GIN index is
2012-04-09 19:32 keltezéssel, Robert Haas írta:
On Sun, Apr 8, 2012 at 9:37 PM, Robert Haasrobertmh...@gmail.com wrote:
Robert, the Assert triggering with the above procedure
is in your fast path locking code with current GIT.
Yes, that sure looks like a bug. It seems that if the top-level
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 for the
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 pgfincore will
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 laurenz.a...@wien.gv.at 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
On Thu, Apr 5, 2012 at 11:45 AM, Robert Haas robertmh...@gmail.com 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.
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
On 04/09/2012 01:25 PM, Atri Sharma wrote:
On Mon, Apr 9, 2012 at 10:15 PM, Andrew Dunstanand...@dunslane.net 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
Andres Freund and...@2ndquadrant.com 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.
On Tue, Apr 10, 2012 at 8:42 AM, Andrew Dunstan and...@dunslane.net 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
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 robertmh...@gmail.com 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
On 10 April 2012 14:33, Robert Haas robertmh...@gmail.com 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
On 04/10/2012 09:48 AM, Merlin Moncure wrote:
On Tue, Apr 10, 2012 at 8:42 AM, Andrew Dunstanand...@dunslane.net 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
Robert Haas robertmh...@gmail.com 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,
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 cbbro...@gmail.com wrote:
Robert Haas robertmh...@gmail.com 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
On Tue, Apr 10, 2012 at 9:15 AM, Andrew Dunstan and...@dunslane.net wrote:
On 04/10/2012 09:48 AM, Merlin Moncure wrote:
On Tue, Apr 10, 2012 at 8:42 AM, Andrew Dunstanand...@dunslane.net
wrote:
I am considering two paths for doing this:
The first one takes the help of the SPI(Server
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 Dunstanand...@dunslane.net wrote:
On 04/10/2012 09:48 AM, Merlin Moncure wrote:
On Tue, Apr 10, 2012 at 8:42 AM, Andrew Dunstanand...@dunslane.net
wrote:
I am considering two paths for doing this:
The
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 be used.
On 6 April 2012 01:19, Noah Misch n...@leadboat.com 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 t...@sss.pgh.pa.us 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
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 and...@dunslane.net 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
On Tue, Apr 10, 2012 at 7:27 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com 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
On 10 April 2012 15:26, Kevin Grittner kevin.gritt...@wicourts.gov 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.
Merlin Moncure mmonc...@gmail.com 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
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
On Tue, Apr 10, 2012 at 11:25 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Merlin Moncure mmonc...@gmail.com 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
On Tue, Apr 10, 2012 at 8:55 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Merlin Moncure mmonc...@gmail.com 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
On Mon, Apr 9, 2012 at 11:27 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com 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
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
Atri Sharma atri.j...@gmail.com writes:
On Tue, Apr 10, 2012 at 8:55 PM, Tom Lane t...@sss.pgh.pa.us 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
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
On 10.04.2012 18:31, Jeff Janes wrote:
On Mon, Apr 9, 2012 at 11:27 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com 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
On Tue, Apr 10, 2012 at 11:24 AM, Peter Geoghegan pe...@2ndquadrant.com wrote:
On 10 April 2012 15:26, Kevin Grittner kevin.gritt...@wicourts.gov 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
On 10 April 2012 16:40, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com 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
On 04/10/2012 11:36 AM, Tom Lane wrote:
Atri Sharmaatri.j...@gmail.com writes:
On Tue, Apr 10, 2012 at 8:55 PM, Tom Lanet...@sss.pgh.pa.us 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.
On Tue, Apr 10, 2012 at 10:06 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com 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
On Tue, Apr 10, 2012 at 10:36 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Atri Sharma atri.j...@gmail.com writes:
On Tue, Apr 10, 2012 at 8:55 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Hm? SPI doesn't know anything about Java either.
We plan to call SQL through SPI from the FDW,which in turn would
Robert Haas robertmh...@gmail.com 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
On Tue, Apr 10, 2012 at 17:58, Robert Haas robertmh...@gmail.com wrote:
On Tue, Apr 10, 2012 at 10:06 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
Hmm. So, on further review, this is not as simple as it seems. I'd
like some input from other people on what
Magnus Hagander mag...@hagander.net writes:
On Tue, Apr 10, 2012 at 17:58, Robert Haas robertmh...@gmail.com wrote:
On Tue, Apr 10, 2012 at 10:06 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Given that we've whacked pg_stat_statements' behavior around rather
thoroughly in this release, maybe we
On 10 April 2012 16:51, Robert Haas robertmh...@gmail.com 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)
On Tue, Apr 10, 2012 at 18:27, Tom Lane t...@sss.pgh.pa.us wrote:
Magnus Hagander mag...@hagander.net writes:
On Tue, Apr 10, 2012 at 17:58, Robert Haas robertmh...@gmail.com wrote:
On Tue, Apr 10, 2012 at 10:06 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Given that we've whacked
Kevin Grittner kevin.gritt...@wicourts.gov 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
Robert Haas robertmh...@gmail.com 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
Tom Lane t...@sss.pgh.pa.us wrote:
Kevin Grittner kevin.gritt...@wicourts.gov 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
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 have
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
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
On Tue, Apr 10, 2012 at 12:28 PM, Peter Geoghegan pe...@2ndquadrant.com 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
On Tue, Apr 10, 2012 at 1:27 PM, Greg Smith g...@2ndquadrant.com 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.
On Tue, Apr 10, 2012 at 12:11 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com 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
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 robertmh...@gmail.com writes:
On Tue, Apr 10, 2012 at 12:11 PM, Tom Lane t...@sss.pgh.pa.us 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
On Tue, Apr 10, 2012 at 1:44 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Tue, Apr 10, 2012 at 12:11 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Well, FWIW I vote for making the new columns be float8 msec.
Ugh. So the three ways of doing timing that we have
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
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 robertmh...@gmail.com writes:
On Tue, Apr 10, 2012 at 1:44 PM, Tom Lane t...@sss.pgh.pa.us 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
On Tue, Apr 10, 2012 at 1:58 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Tue, Apr 10, 2012 at 1:44 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Huh? I understood what you said upthread to be that we have two ways
in existing releases (anything unreleased has
On Tue, Apr 10, 2012 at 02:01:02PM -0400, Robert Haas wrote:
On Tue, Apr 10, 2012 at 1:58 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Tue, Apr 10, 2012 at 1:44 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Huh? I understood what you said upthread to be that
Robert Haas robertmh...@gmail.com writes:
On Tue, Apr 10, 2012 at 1:58 PM, Tom Lane t...@sss.pgh.pa.us 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
=?UTF-8?B?SmFuIFVyYmHFhHNraQ==?= wulc...@wulczer.org 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
I wrote:
=?UTF-8?B?SmFuIFVyYmHFhHNraQ==?= wulc...@wulczer.org 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
On 10 April 2012 18:28, Robert Haas robertmh...@gmail.com 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
Peter Geoghegan pe...@2ndquadrant.com writes:
On 10 April 2012 18:28, Robert Haas robertmh...@gmail.com 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
On 10/04/12 20:47, Tom Lane wrote:
I wrote:
=?UTF-8?B?SmFuIFVyYmHFhHNraQ==?=wulc...@wulczer.org 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
=?UTF-8?B?SmFuIFVyYmHFhHNraQ==?= wulc...@wulczer.org 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
On 10/04/12 21:27, Tom Lane wrote:
=?UTF-8?B?SmFuIFVyYmHFhHNraQ==?=wulc...@wulczer.org 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
On Tue, Apr 10, 2012 at 2:49 PM, Peter Geoghegan pe...@2ndquadrant.com 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
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
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
On Tue, Apr 10, 2012 at 11:07 AM, Merlin Moncure mmonc...@gmail.com 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,
Christoph Berg c...@df7cb.de 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
Bruce Momjian br...@momjian.us 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
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 br...@momjian.us 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
On Tue, Apr 10, 2012 at 5:43 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Bruce Momjian br...@momjian.us 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
On Tue, Apr 10, 2012 at 5:20 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Christoph Berg c...@df7cb.de 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
On Tue, Apr 10, 2012 at 06:16:31PM -0400, Robert Haas wrote:
On Tue, Apr 10, 2012 at 5:43 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Bruce Momjian br...@momjian.us writes:
The new pg_tablespace_location() function added in PG 9.2 to remove the
director location from pg_tablespace returns an odd
On 10 April 2012 23:07, Greg Smith g...@2ndquadrant.com 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
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 br...@momjian.us 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 t...@sss.pgh.pa.us 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
Robert Haas robertmh...@gmail.com writes:
On Tue, Apr 10, 2012 at 5:20 PM, Tom Lane t...@sss.pgh.pa.us 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
On Tue, Apr 10, 2012 at 07:09:33PM -0400, Tom Lane wrote:
Bruce Momjian br...@momjian.us 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 t...@sss.pgh.pa.us wrote:
The way the function is coded, it has no need to look into
On Tue, Apr 10, 2012 at 6:32 PM, Peter Geoghegan pe...@2ndquadrant.com wrote:
On 10 April 2012 23:07, Greg Smith g...@2ndquadrant.com 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
Peter Geoghegan pe...@2ndquadrant.com writes:
On 10 April 2012 23:07, Greg Smith g...@2ndquadrant.com 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.
Bruce Momjian br...@momjian.us 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
On 11 April 2012 00:35, Robert Haas robertmh...@gmail.com 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
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 cause
On Tue, Apr 10, 2012 at 07:57:30PM -0400, Tom Lane wrote:
Bruce Momjian br...@momjian.us 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
On Tue, Apr 10, 2012 at 11:53:23AM -0500, Kevin Grittner wrote:
Tom Lane t...@sss.pgh.pa.us wrote:
Kevin Grittner kevin.gritt...@wicourts.gov 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
Peter Geoghegan pe...@2ndquadrant.com writes:
On 11 April 2012 00:35, Robert Haas robertmh...@gmail.com 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
1 - 100 of 124 matches
Mail list logo
