On Wed, Sep 7, 2011 at 8:28 AM, Andy Colson a...@squeakycode.net wrote:
On 08/22/2011 01:22 AM, Pavan Deolasee wrote:
Hi Pavan, I tried to apply your patch to git master (as of just now) and it
failed. I assume that's what I should be checking out, right?
Yeah, seems like it bit-rotted.
I wanted to clarify my understanding and have some doubts.
What I'm thinking about instead is using a ring buffer with three pointers:
a start pointer, a stop pointer, and a write pointer. When a transaction
ends, we
advance the write pointer, write the XIDs or a whole new snapshot into the
On Tue, Sep 06, 2011 at 09:21:02PM -0400, Bruce Momjian wrote:
Tom Lane wrote:
hubert depesz lubaczewski dep...@depesz.com writes:
Worked a bit to get the ltree problem down to smallest possible,
repeatable, situation.
I looked at this again and verified that indeed, commit
On Tue, Aug 23, 2011 at 12:15:23PM -0400, Robert Haas wrote:
On Mon, Aug 22, 2011 at 3:31 AM, daveg da...@sonic.net wrote:
So far I've got:
- affects system tables
- happens very soon after process startup
- in 8.4.7 and 9.0.4
- not likely to be hardware or OS related
- happens
On Wed, Sep 7, 2011 at 03:44, Fujii Masao masao.fu...@gmail.com wrote:
On Wed, Sep 7, 2011 at 5:22 AM, Simon Riggs si...@2ndquadrant.com wrote:
Fujii - the original goal here was to avoid having a unexplained
disconnection in the logs. The only way to do this cleanly is to have
a disconnection
On Wed, Sep 7, 2011 at 2:44 AM, Fujii Masao masao.fu...@gmail.com wrote:
On Wed, Sep 7, 2011 at 5:22 AM, Simon Riggs si...@2ndquadrant.com wrote:
Fujii - the original goal here was to avoid having a unexplained
disconnection in the logs. The only way to do this cleanly is to have
a
On Tue, Sep 6, 2011 at 9:18 PM, Simon Riggs si...@2ndquadrant.com wrote:
I'm back now and will act as advertised.
I've revoked the performance aspect. The difference between release
and commit has been maintained since it makes the code easier to
understand.
--
Simon Riggs
On 7 September 2011 11:56, Simon Riggs si...@2ndquadrant.com wrote:
On Wed, Sep 7, 2011 at 2:44 AM, Fujii Masao masao.fu...@gmail.com wrote:
On Wed, Sep 7, 2011 at 5:22 AM, Simon Riggs si...@2ndquadrant.com
wrote:
Fujii - the original goal here was to avoid having a unexplained
On Wed, Sep 7, 2011 at 9:10 PM, Thom Brown t...@linux.com wrote:
On 7 September 2011 11:56, Simon Riggs si...@2ndquadrant.com wrote:
That's an idea. But what about the patch that I proposed before?
http://archives.postgresql.org/pgsql-hackers/2011-08/msg00816.php
Thanks for that. Committed.
On 24 August 2011 13:38, Kohei Kaigai kohei.kai...@emea.nec.com wrote:
The (2) is new stuff from the revision in commit-fest 1st. It enables to
supply NOLEAKY option on CREATE FUNCTION statement, then the function is
allowed to distribute across security barrier. Only superuser can set this
Hi Magnus-san and Bruce-san.
I am sorry in a very late reaction...
Is it enough for a 9.1release?
libpq of bcc32 and win32 has a problem.
== error of nmake ==
ライブラリ .\Release\libpqdll.lib とオブジェクト
.\Release\libpqdll.exp を作成中
libpq.lib(fe-connect.obj) : error LNK2019: 未解決の外部シンボル
_inet_net_ntop
2011/9/7 Thom Brown t...@linux.com:
On 24 August 2011 13:38, Kohei Kaigai kohei.kai...@emea.nec.com wrote:
The (2) is new stuff from the revision in commit-fest 1st. It enables to
supply NOLEAKY option on CREATE FUNCTION statement, then the function is
allowed to distribute across security
On 7 September 2011 14:34, Kohei KaiGai kai...@kaigai.gr.jp wrote:
2011/9/7 Thom Brown t...@linux.com:
On 24 August 2011 13:38, Kohei Kaigai kohei.kai...@emea.nec.com wrote:
The (2) is new stuff from the revision in commit-fest 1st. It enables to
supply NOLEAKY option on CREATE FUNCTION
On Wed, Sep 7, 2011 at 5:16 AM, daveg da...@sonic.net wrote:
On Tue, Aug 23, 2011 at 12:15:23PM -0400, Robert Haas wrote:
On Mon, Aug 22, 2011 at 3:31 AM, daveg da...@sonic.net wrote:
So far I've got:
- affects system tables
- happens very soon after process startup
- in 8.4.7 and
Applied, with a function rename. The only odd case we have left is:
test= select to_date('079', 'YYY');
to_date
1979-01-01
(1 row)
(Note the zero is ignored.) I can't see an easy way to fix this and
continue to be easily documented.
On Wed, Sep 7, 2011 at 9:39 AM, Thom Brown t...@linux.com wrote:
On 7 September 2011 14:34, Kohei KaiGai kai...@kaigai.gr.jp wrote:
2011/9/7 Thom Brown t...@linux.com:
On 24 August 2011 13:38, Kohei Kaigai kohei.kai...@emea.nec.com wrote:
The (2) is new stuff from the revision in
Andy Colson a...@squeakycode.net writes:
Where did the other warnings go? Its right though, line 570 is bad. It also
seems to have killed the server. I have not gotten through the history of
messages regarding this patch, but is it supposed to kill the server if there
is a syntax error
Robert Haas robertmh...@gmail.com wrote:
Anyone else want to bikeshed?
I'm not sure they beat TRUSTED, but:
SECURE
OPAQUE
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Robert Haas robertmh...@gmail.com writes:
After spending some time staring at the code, I do have one idea as to
what might be going on here. When a backend is terminated,
ShutdownPostgres() calls AbortOutOfAnyTransaction() and then
LockReleaseAll(USER_LOCKMETHOD, true). The second call
2011/9/7 Robert Haas robertmh...@gmail.com:
On Wed, Sep 7, 2011 at 9:39 AM, Thom Brown t...@linux.com wrote:
On 7 September 2011 14:34, Kohei KaiGai kai...@kaigai.gr.jp wrote:
2011/9/7 Thom Brown t...@linux.com:
On 24 August 2011 13:38, Kohei Kaigai kohei.kai...@emea.nec.com wrote:
The
Hi list,
It seems I have found a regression in PostgreSQL 9.1rc1 (from 9.0).
In many cases, running the following query fails:
db=# EXPLAIN select * from information_schema.key_column_usage;
ERROR: record type has not been registered
However, this is not always reproducible. It seems to occur
On 2011-09-07 16:02, Kevin Grittner wrote:
Robert Haasrobertmh...@gmail.com wrote:
Anyone else want to bikeshed?
I'm not sure they beat TRUSTED, but:
SECURE
OPAQUE
SAVE
-- Yeb
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
Hiroshi Saito wrote:
Hi Magnus-san and Bruce-san.
I am sorry in a very late reaction...
Is it enough for a 9.1release?
libpq of bcc32 and win32 has a problem.
== error of nmake ==
? .\Release\libpqdll.lib ???
.\Release\libpqdll.exp
libpq.lib(fe-connect.obj) : error
On Wed, Sep 7, 2011 at 16:43, Bruce Momjian br...@momjian.us wrote:
Hiroshi Saito wrote:
Hi Magnus-san and Bruce-san.
I am sorry in a very late reaction...
Is it enough for a 9.1release?
libpq of bcc32 and win32 has a problem.
== error of nmake ==
? .\Release\libpqdll.lib ???
Get the following error
configure:3274: ccache gcc -V 5
llvm-gcc-4.2: argument to `-V' is missing
should be
ccache gcc -v 5
Dave
Dave Cramer
dave.cramer(at)credativ(dot)ca
http://www.credativ.ca
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
On Tue, Sep 6, 2011 at 10:11 PM, Fujii Masao masao.fu...@gmail.com wrote:
On Sat, Sep 3, 2011 at 5:10 AM, Kevin Grittner
kevin.gritt...@wicourts.gov wrote:
(2) It should copy, not move, with protection against overwriting
an existing file.
I agree that basically archive_command should not
Hi.
We are looking forward to the great release.
thanks again!!
Regards,
Hiroshi Saito
(2011/09/07 23:46), Magnus Hagander wrote:
On Wed, Sep 7, 2011 at 16:43, Bruce Momjianbr...@momjian.us wrote:
Hiroshi Saito wrote:
Hi Magnus-san and Bruce-san.
I am sorry in a very late reaction...
Is
Marti Raudsepp ma...@juffo.org writes:
It seems I have found a regression in PostgreSQL 9.1rc1 (from 9.0).
In many cases, running the following query fails:
db=# EXPLAIN select * from information_schema.key_column_usage;
ERROR: record type has not been registered
Looks like I overlooked a
Hi,
If a basic operator family is created, e.g.,
create operator family of1 using btree;
shouldn't pg_dump include this in its output? If not, why?
Joe
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
Dave Cramer p...@fastcrypt.com writes:
Get the following error
configure:3274: ccache gcc -V 5
llvm-gcc-4.2: argument to `-V' is missing
should be
ccache gcc -v 5
That's not an error, that's normal behavior.
Mind you, I have no idea why autoconf chooses to do this when it's
already tried
On Wed, Sep 7, 2011 at 11:16 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Dave Cramer p...@fastcrypt.com writes:
Get the following error
configure:3274: ccache gcc -V 5
llvm-gcc-4.2: argument to `-V' is missing
should be
ccache gcc -v 5
That's not an error, that's normal behavior.
Mind you, I
Dave Cramer p...@fastcrypt.com writes:
Well the problem is that buildfarm can't build HEAD on OS X 10.7.1
HEAD builds fine on my 10.7.1 laptop. If you're referring to orangutan,
it's not failing on that, it's failing here:
configure:3301: checking for C compiler default output file name
On Wed, Sep 07, 2011 at 02:09:15PM +0100, Thom Brown wrote:
On 24 August 2011 13:38, Kohei Kaigai kohei.kai...@emea.nec.com wrote:
The (2) is new stuff from the revision in commit-fest 1st. It enables to
supply NOLEAKY option on CREATE FUNCTION statement, then the function is
allowed to
Noah Misch n...@leadboat.com writes:
I liked NOLEAKY for its semantics, though I probably would have spelled it
LEAKPROOF. PostgreSQL will trust the function to implement a specific,
relatively-unintuitive security policy. We want the function implementers to
read that policy closely and not
Joe Abbate j...@freedomcircle.com writes:
If a basic operator family is created, e.g.,
create operator family of1 using btree;
shouldn't pg_dump include this in its output? If not, why?
Quoting from the pg_dump source code:
* We want to dump the opfamily only if (1) it contains loose
On Wed, Sep 7, 2011 at 11:32 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Dave Cramer p...@fastcrypt.com writes:
Well the problem is that buildfarm can't build HEAD on OS X 10.7.1
HEAD builds fine on my 10.7.1 laptop. If you're referring to orangutan,
it's not failing on that, it's failing here:
2011/9/7 Tom Lane t...@sss.pgh.pa.us:
Noah Misch n...@leadboat.com writes:
I liked NOLEAKY for its semantics, though I probably would have spelled it
LEAKPROOF. PostgreSQL will trust the function to implement a specific,
relatively-unintuitive security policy. We want the function
On 09/07/2011 12:05 PM, Tom Lane wrote:
I agree that TRUSTED is a pretty bad choice here because of the high
probability that people will think it means something else than what
it really means.
Agreed.
LEAKPROOF isn't too bad.
It's fairly opaque unless you
On 09/07/2011 12:10 PM, Tom Lane wrote:
I guess if it contains no opclasses and no operators either, this code
won't dump it, but isn't it rather useless in such a case?
Yes, I think it's useless, like a book cover without the contents, but
ISTM it should still be dumped (perhaps someone
2011/9/7 Andrew Dunstan and...@dunslane.net:
LEAKPROOF isn't too bad.
It's fairly opaque unless you know the context, although that might be said
of some of our other terms too. Someone coming across it is going to think
What would it leak?
It is introduced in the documentation. I'll add a
Hi,
While updating the translation I noticed a typo in
src/backend/commands/collationcmds.c circa line 126.
parameter \lc_collate\ parameter must be specified
--
Euler Taveira de Oliveira - Timbira http://www.timbira.com.br/
PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e
I have fixed a bug introduced by pgrminclude. It turns out that
CppAsString2() will expand any symbol, even one that is undefined, so
pgrminclude thought that catalog/catversion was not needed. This is
illustrated in the attached C file that outputs 1 and y.
I have bumped the catalog version to
Andrew Dunstan and...@dunslane.net writes:
On 09/07/2011 12:05 PM, Tom Lane wrote:
LEAKPROOF isn't too bad.
It's fairly opaque unless you know the context, although that might be
said of some of our other terms too. Someone coming across it is going
to think What would it leak?
Well, the
Hello
Andy Colson found a bug in GUC implementation.
When we have a custom SUSET variable, like plpgsql.variable_conflikt,
then setting this variable before plpgsql initalisation raises a
exception, but it raise a exception when some plpgsql function is
created. Try to execute a attached script
Euler Taveira de Oliveira eu...@timbira.com writes:
While updating the translation I noticed a typo in
src/backend/commands/collationcmds.c circa line 126.
parameter \lc_collate\ parameter must be specified
Will fix, thanks for spotting it.
regards, tom lane
--
Sent
Excerpts from Pavel Stehule's message of mié sep 07 14:23:43 -0300 2011:
Hello
Andy Colson found a bug in GUC implementation.
When we have a custom SUSET variable, like plpgsql.variable_conflikt,
then setting this variable before plpgsql initalisation raises a
exception, but it raise a
On Tue, Sep 6, 2011 at 23:52, Robert Haas robertmh...@gmail.com wrote:
On Tue, Sep 6, 2011 at 5:16 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I wrote:
Robert Haas robertmh...@gmail.com writes:
I am (and, I think, Alvaro is also) of the opinion that the behavior
here is still not really right.
I
Hi,
This patch fixes an edge case bug in the numeric to_char() function.
When the numeric to_char format used fillmode (FM), didn't contain 0s
and had a trailing dot, the integer part of the number was truncated in
error.
to_char(10, 'FM99.') used to return '1', after this patch it will return
On Tue, Sep 6, 2011 at 9:14 PM, Peter Geoghegan pe...@2ndquadrant.com wrote:
On 7 September 2011 01:18, Bruce Momjian br...@momjian.us wrote:
I am confused how moving a function from one C file to another could
cause breakage?
I'm really concerned about silent breakage, however unlikely -
Robert Haas wrote:
IMHO, when manipulating code at this sort of macro scale, it's good to
be paranoid and exhaustive, particularly when it doesn't cost you
anything anyway. Unlike when writing or fixing a bit of code at a
time, which we're all used to, if the compiler doesn't tell you
Alvaro Herrera alvhe...@commandprompt.com writes:
Another thing we detected some days ago is that a custom variable in a
module not loaded by postmaster, does not seem to get reported
appropriately when an invalid value is set on postgresql.conf and
reloaded: backends report problems with
Pavel Stehule pavel.steh...@gmail.com writes:
When we have a custom SUSET variable, like plpgsql.variable_conflikt,
then setting this variable before plpgsql initalisation raises a
exception, but it raise a exception when some plpgsql function is
created. Try to execute a attached script - a
On Wed, Sep 7, 2011 at 1:55 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Pavel Stehule pavel.steh...@gmail.com writes:
When we have a custom SUSET variable, like plpgsql.variable_conflikt,
then setting this variable before plpgsql initalisation raises a
exception, but it raise a exception when some
Robert Haas robertmh...@gmail.com writes:
On Wed, Sep 7, 2011 at 1:55 PM, Tom Lane t...@sss.pgh.pa.us wrote:
You can't set a custom SUSET variable in advance of loading the module,
because the system has no way to know it should enforce superuser
restrictions on setting it. For the most part,
On Wed, Sep 7, 2011 at 2:05 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Wed, Sep 7, 2011 at 1:55 PM, Tom Lane t...@sss.pgh.pa.us wrote:
You can't set a custom SUSET variable in advance of loading the module,
because the system has no way to know it
Bruce Momjian br...@momjian.us writes:
Robert Haas wrote:
I was less concerned about the breakage that might be caused by
variables acquiring unintended referents - which should be unlikely
anyway given reasonable variable naming conventions - and more
concerned that the associated
Robert Haas robertmh...@gmail.com writes:
On Wed, Sep 7, 2011 at 2:05 PM, Tom Lane t...@sss.pgh.pa.us wrote:
The ones in auto_explain and pg_stat_statements aren't too problematic
because those modules are designed to be preloaded by the postmaster.
We've avoided adding such variables in
Marti Raudsepp ma...@juffo.org writes:
This patch fixes an edge case bug in the numeric to_char() function.
When the numeric to_char format used fillmode (FM), didn't contain 0s
and had a trailing dot, the integer part of the number was truncated in
error.
to_char(10, 'FM99.') used to
Bruce Momjian wrote:
Tom Lane wrote:
hubert depesz lubaczewski dep...@depesz.com writes:
Worked a bit to get the ltree problem down to smallest possible,
repeatable, situation.
I looked at this again and verified that indeed, commit
8eee65c996048848c20f6637c1d12b319a4ce244
Excerpts from Tom Lane's message of mié sep 07 14:49:45 -0300 2011:
Alvaro Herrera alvhe...@commandprompt.com writes:
Another thing we detected some days ago is that a custom variable in a
module not loaded by postmaster, does not seem to get reported
appropriately when an invalid value is
On Wed, Sep 7, 2011 at 2:21 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Wed, Sep 7, 2011 at 2:05 PM, Tom Lane t...@sss.pgh.pa.us wrote:
The ones in auto_explain and pg_stat_statements aren't too problematic
because those modules are designed to be
Excerpts from Gan Jiadong's message of vie feb 18 03:42:02 -0300 2011:
Hi,
Thanks for your reply.
Of course, we will think about whether 4 relations dropping is
reasonable. In fact, this happens in a very special scenario .
But when we analyzed this issue, we found the PG code
On 09/07/2011 03:18 PM, Robert Haas wrote:
Yeah, I guess we don't have many good short-term options. I continue
to think that this whole facility is mis-designed, though.
I agree. I have tripped over it several times.
cheers
andrew
--
Sent via pgsql-hackers mailing list
Alvaro Herrera alvhe...@commandprompt.com writes:
Excerpts from Tom Lane's message of mié sep 07 14:49:45 -0300 2011:
I don't think we can just s/DEBUG3/LOG/, because of the
log clutter that will result when they all think there's a problem.
I was thinking that the solution would be to
Excerpts from Robert Haas's message of mar sep 06 19:57:07 -0300 2011:
On Tue, Sep 6, 2011 at 6:05 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Tue, Sep 6, 2011 at 5:34 PM, Tom Lane t...@sss.pgh.pa.us wrote:
And I doubt
that the goal is worth taking
On Wed, Sep 7, 2011 at 7:12 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Bruce Momjian br...@momjian.us writes:
Robert Haas wrote:
I was less concerned about the breakage that might be caused by
variables acquiring unintended referents - which should be unlikely
anyway given reasonable variable
Hiroshi Saito wrote:
Hi Magnus-san and Bruce-san.
I am sorry in a very late reaction...
Is it enough for a 9.1release?
libpq of bcc32 and win32 has a problem.
== error of nmake ==
? .\Release\libpqdll.lib ???
.\Release\libpqdll.exp
libpq.lib(fe-connect.obj) : error
Alvaro Herrera alvhe...@commandprompt.com writes:
Excerpts from Robert Haas's message of mar sep 06 19:57:07 -0300 2011:
TBH, I'm very unclear what could cause the postmaster to go belly-up
copying a bounded amount of data out of shared memory for logging
purposes only. It's surely possible
On Wed, Sep 7, 2011 at 3:42 PM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
TBH, I'm very unclear what could cause the postmaster to go belly-up
copying a bounded amount of data out of shared memory for logging
purposes only. It's surely possible to make the code safe against any
Simon Riggs si...@2ndquadrant.com writes:
Please lets not waste effort on refactoring efforts in mid dev cycle.
Say what? When else would you have us do it?
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
On Wed, Sep 7, 2011 at 4:00 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Alvaro Herrera alvhe...@commandprompt.com writes:
Excerpts from Robert Haas's message of mar sep 06 19:57:07 -0300 2011:
TBH, I'm very unclear what could cause the postmaster to go belly-up
copying a bounded amount of data out
Robert Haas robertmh...@gmail.com writes:
On Wed, Sep 7, 2011 at 3:42 PM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
A mishandled encoding conversion could be problematic, so that needs to
be carefully considered (perhaps just shut off unconditionally).
It's not really a problem for
On Wed, Sep 07, 2011 at 10:20:24AM -0400, Tom Lane wrote:
Robert Haas robertmh...@gmail.com writes:
After spending some time staring at the code, I do have one idea as to
what might be going on here. When a backend is terminated,
ShutdownPostgres() calls AbortOutOfAnyTransaction() and then
On Wed, Sep 7, 2011 at 4:22 PM, daveg da...@sonic.net wrote:
Yes, we make extensive use of advisory locks. That was my thought too when
Robert mentioned session level locks.
I'm happy to add any additional instrumentation, but my client would be
happier to actually run it if there was a way
On Wed, Sep 7, 2011 at 4:15 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Wed, Sep 7, 2011 at 3:42 PM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
A mishandled encoding conversion could be problematic, so that needs to
be carefully considered
On Wed, Sep 7, 2011 at 21:37, Tom Lane t...@sss.pgh.pa.us wrote:
Hmm. I agree that this is a bug, but the proposed fix seems like a bit
of a kluge. Wouldn't it be better to make get_last_relevant_decnum
honor its contract, that is not delete any relevant digits?
You're right, it was a kludge.
Marti Raudsepp ma...@juffo.org writes:
On Wed, Sep 7, 2011 at 21:37, Tom Lane t...@sss.pgh.pa.us wrote:
Hmm. I agree that this is a bug, but the proposed fix seems like a bit
of a kluge. Wouldn't it be better to make get_last_relevant_decnum
honor its contract, that is not delete any relevant
Robert Haas robertmh...@gmail.com writes:
Tom's right to be skeptical of my theory, because it would require a
CHECK_FOR_INTERRUPTS() outside of a transaction block in one of the
pathways that use session-level locks, and I can't find one.
More to the point: session-level locks are released on
On Wed, Sep 7, 2011 at 22:42, Alvaro Herrera alvhe...@commandprompt.com wrote:
A mishandled encoding conversion could be problematic, so that needs to
be carefully considered (perhaps just shut off unconditionally).
Are you referring to log file encoding or something else? The log file
is
Magnus Hagander mag...@hagander.net writes:
On Tue, Sep 6, 2011 at 23:52, Robert Haas robertmh...@gmail.com wrote:
On Tue, Sep 6, 2011 at 5:16 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Although there's always more than one way to skin a cat. Consider
this idea:
1. The hard-wired default for
Robert Haas robertmh...@gmail.com writes:
On Wed, Sep 7, 2011 at 4:15 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Keep in mind that in the postmaster, elog(ERROR) *is* a crash.
Right... but a function that returns -1 to indicate that something
didn't work should be OK, as long as whatever it does
Excerpts from Marti Raudsepp's message of mié sep 07 18:09:32 -0300 2011:
On Wed, Sep 7, 2011 at 22:42, Alvaro Herrera alvhe...@commandprompt.com
wrote:
A mishandled encoding conversion could be problematic, so that needs to
be carefully considered (perhaps just shut off unconditionally).
On Wed, Sep 7, 2011 at 4:55 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Yeah, and for that matter it seems to let VACUUM off the hook too.
If we assume that the reported object ID is non-corrupt (and if it's
always the same, that seems like the way to bet) then this is a lock
on pg_authid.
Hmmm
On Wed, Sep 07, 2011 at 04:55:24PM -0400, Tom Lane wrote:
Robert Haas robertmh...@gmail.com writes:
Tom's right to be skeptical of my theory, because it would require a
CHECK_FOR_INTERRUPTS() outside of a transaction block in one of the
pathways that use session-level locks, and I can't
Robert Haas robertmh...@gmail.com writes:
I thought about an error exit from client authentication, and that's a
somewhat appealing explanation, but I can't quite see why we wouldn't
clean up there the same as anywhere else. The whole mechanism feels a
bit rickety to me - we don't actually
daveg da...@sonic.net writes:
It does not seem restricted to pg_authid:
2011-08-24 18:35:57.445 24987 c23 apps ERROR: lock AccessShareLock on
object 16403/2615/0
And I think I've seen it on other tables too.
Hmm. 2615 = pg_namespace, which most likely is the first catalog
accessed by
On Wed, Sep 07, 2011 at 06:35:08PM -0400, Tom Lane wrote:
daveg da...@sonic.net writes:
It does not seem restricted to pg_authid:
2011-08-24 18:35:57.445 24987 c23 apps ERROR: lock AccessShareLock on
object 16403/2615/0
And I think I've seen it on other tables too.
Hmm. 2615 =
On Wed, Sep 07, 2011 at 06:25:23PM -0400, Tom Lane wrote:
Robert Haas robertmh...@gmail.com writes:
I thought about an error exit from client authentication, and that's a
somewhat appealing explanation, but I can't quite see why we wouldn't
clean up there the same as anywhere else. The
daveg da...@sonic.net writes:
On Wed, Sep 07, 2011 at 06:25:23PM -0400, Tom Lane wrote:
... But maybe it'd be interesting for Dave to stick a
LockReleaseAll call into ProcKill() and see if that makes things better.
(Dave: test that before you put it in production, I'm not totally sure
it's
daveg da...@sonic.net writes:
Also, this is very intermittant, we have seen it only in recent months
on both 8.4.7 and 9.0.4 after years of no problems. Lately we see it what
feels like a few times a month. Possibly some new application behaviour
is provoking it, but I have no guesses as to
On Wed, Sep 7, 2011 at 5:24 PM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
Excerpts from Marti Raudsepp's message of mié sep 07 18:09:32 -0300 2011:
On Wed, Sep 7, 2011 at 22:42, Alvaro Herrera alvhe...@commandprompt.com
wrote:
A mishandled encoding conversion could be problematic, so
In connection with doing this:
http://archives.postgresql.org/message-id/22214.1315343...@sss.pgh.pa.us
I've run into the problem that tz_acceptable(), which needs to be
available to frontend-ish code if initdb is to use it, depends on these
symbols:
#define UNIX_EPOCH_JDATE2440588 /* ==
On 8 September 2011 10:22, Tom Lane t...@sss.pgh.pa.us wrote:
If you believe the idea I suggested a few days ago that we ought to try
to push basic typedefs into a separate set of headers, then this could
be the first instance of that, which would lead to naming it something
like
On Wed, Sep 07, 2011 at 07:39:15PM -0400, Tom Lane wrote:
daveg da...@sonic.net writes:
Also, this is very intermittant, we have seen it only in recent months
on both 8.4.7 and 9.0.4 after years of no problems. Lately we see it what
feels like a few times a month. Possibly some new
daveg da...@sonic.net writes:
On Wed, Sep 07, 2011 at 07:39:15PM -0400, Tom Lane wrote:
BTW ... what were the last versions you were running on which you had
*not* seen the problem? (Just wondering about the possibility that we
back-patched some fix that broke things. It would be good to
On Wed, Sep 7, 2011 at 6:25 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
I thought about an error exit from client authentication, and that's a
somewhat appealing explanation, but I can't quite see why we wouldn't
clean up there the same as anywhere else.
(2011/09/05 22:05), Kohei Kaigai wrote:
In my usual environment that test passed, but finally I've reproduced the
failure with setting
$LC_COLLATE to es_ES.UTF-8. Do you have set any $LC_COLLATE in your test
environment?
It is not set in my environment.
I checked the behavior of ORDER
97 matches
Mail list logo
