On Wed, Sep 07, 2011 at 09:02:04PM -0400, Tom Lane wrote:
> daveg 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-p
On Thu, Sep 8, 2011 at 7:05 AM, Fujii Masao wrote:
> On Wed, Sep 7, 2011 at 11:53 PM, Robert Treat wrote:
>> On Tue, Sep 6, 2011 at 10:11 PM, Fujii Masao wrote:
>>> I agree that basically archive_command should not overwrite an existing
>>> file.
>>> But if the size of existing file is less tha
On Wed, Sep 7, 2011 at 9:02 PM, Tom Lane wrote:
> Simon Riggs writes:
>> Please lets not waste effort on refactoring efforts in mid dev cycle.
>
> Say what? When else would you have us do it?
When else would you have us develop?
Major changes happen at start of a dev cycle, after some discussi
On Wed, Sep 7, 2011 at 11:53 PM, Robert Treat wrote:
> On Tue, Sep 6, 2011 at 10:11 PM, Fujii Masao wrote:
>> I agree that basically archive_command should not overwrite an existing file.
>> But if the size of existing file is less than 16MB, it should do that.
>> Otherwise,
>> that WAL file woul
(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 beha
On Wed, Sep 7, 2011 at 6:25 PM, Tom Lane wrote:
> Robert Haas 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
daveg 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 have
>> a
On Wed, Sep 07, 2011 at 07:39:15PM -0400, Tom Lane wrote:
> daveg 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 behav
On 8 September 2011 10:22, Tom Lane 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 "datatype/timestamp.h". If
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 /* == d
On Wed, Sep 7, 2011 at 5:24 PM, Alvaro Herrera
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
>> wrote:
>> > A mishandled encoding conversion could be problematic, so that needs to
>> > be carefully considered (p
daveg 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 what.
BTW ...
daveg 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 safe.)
On Wed, Sep 07, 2011 at 06:25:23PM -0400, Tom Lane wrote:
> Robert Haas 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 fe
On Wed, Sep 07, 2011 at 06:35:08PM -0400, Tom Lane wrote:
> daveg 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_nam
daveg 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 just about an
Robert Haas 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 release locks; we ju
On Wed, Sep 07, 2011 at 04:55:24PM -0400, Tom Lane wrote:
> Robert Haas 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.
>
> Mor
On Wed, Sep 7, 2011 at 4:55 PM, Tom Lane 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 ... could the
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
> wrote:
> > A mishandled encoding conversion could be problematic, so that needs to
> > be carefully considered (perhaps just shut off unconditionally).
>
> Are you referring
Robert Haas writes:
> On Wed, Sep 7, 2011 at 4:15 PM, Tom Lane 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 is otherwise
> extremely boring.
T
Magnus Hagander writes:
> On Tue, Sep 6, 2011 at 23:52, Robert Haas wrote:
>> On Tue, Sep 6, 2011 at 5:16 PM, Tom Lane wrote:
>>> Although there's always more than one way to skin a cat. Consider
>>> this idea:
>>>
>>> 1. The hard-wired default for timezone is always UTC (or something
>>> else
On Wed, Sep 7, 2011 at 22:42, Alvaro Herrera 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 already potentially mixed-enco
Robert Haas 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 error. The only
w
Marti Raudsepp writes:
> On Wed, Sep 7, 2011 at 21:37, Tom Lane 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
On Wed, Sep 7, 2011 at 21:37, Tom Lane 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.
Here's an impr
On Wed, Sep 7, 2011 at 4:15 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Wed, Sep 7, 2011 at 3:42 PM, Alvaro Herrera
>> wrote:
>>> A mishandled encoding conversion could be problematic, so that needs to
>>> be carefully considered (perhaps just shut off unconditionally).
>
>> It's not really
On Wed, Sep 7, 2011 at 4:22 PM, daveg 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 to recover f
On Wed, Sep 07, 2011 at 10:20:24AM -0400, Tom Lane wrote:
> Robert Haas 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
> > LockReleas
Robert Haas writes:
> On Wed, Sep 7, 2011 at 3:42 PM, Alvaro Herrera
> 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 the postmaster if something just plain
> ol
On Wed, Sep 7, 2011 at 4:00 PM, Tom Lane wrote:
> Alvaro Herrera 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
>>> pur
Simon Riggs 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 subscription:
http:/
On Wed, Sep 7, 2011 at 3:42 PM, Alvaro Herrera
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
>> sequence of bytes that mig
Alvaro Herrera 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 to make the code safe
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)
On Wed, Sep 7, 2011 at 7:12 PM, Tom Lane wrote:
> Bruce Momjian 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 m
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 wrote:
> > Robert Haas writes:
> >> On Tue, Sep 6, 2011 at 5:34 PM, Tom Lane wrote:
> >>> And I doubt
> >>> that the goal is worth taking risks for.
> >
> >> I am unable to count the
Alvaro Herrera 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 promote DEBUG3 to LOG in
>
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 (pgsql-hackers@pos
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 c
On Wed, Sep 7, 2011 at 2:21 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Wed, Sep 7, 2011 at 2:05 PM, Tom Lane 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 s
Excerpts from Tom Lane's message of mié sep 07 14:49:45 -0300 2011:
> Alvaro Herrera 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.co
Bruce Momjian wrote:
> Tom Lane wrote:
> > hubert depesz lubaczewski 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 introduced
Marti Raudsepp 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 return '1', afte
Robert Haas writes:
> On Wed, Sep 7, 2011 at 2:05 PM, Tom Lane 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 modules that aren't intended
>> to be
Bruce Momjian 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 refactoring would
On Wed, Sep 7, 2011 at 2:05 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Wed, Sep 7, 2011 at 1:55 PM, Tom Lane 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 i
Robert Haas writes:
> On Wed, Sep 7, 2011 at 1:55 PM, Tom Lane 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, this is a good reason to
>> avoid
On Wed, Sep 7, 2011 at 1:55 PM, Tom Lane wrote:
> Pavel Stehule 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
Pavel Stehule 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 set statement is ok,
Alvaro Herrera 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 DEBUG3, only postmaster use
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 y
On Tue, Sep 6, 2011 at 9:14 PM, Peter Geoghegan wrote:
> On 7 September 2011 01:18, Bruce Momjian 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 - that is
> also Simon and Robert's
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 23:52, Robert Haas wrote:
> On Tue, Sep 6, 2011 at 5:16 PM, Tom Lane wrote:
>> I wrote:
>>> Robert Haas writes:
I am (and, I think, Alvaro is also) of the opinion that the behavior
here is still not really right.
>>
>>> I don't see a practical way to do better un
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 rais
Euler Taveira de Oliveira 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 via pgsql-hac
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 -
Andrew Dunstan 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 whole point
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
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
2011/9/7 Andrew Dunstan :
>> 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 point
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 start
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 know
2011/9/7 Tom Lane :
> Noah Misch 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 c
On Wed, Sep 7, 2011 at 11:32 AM, Tom Lane wrote:
> Dave Cramer 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
Joe Abbate 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" operators
* or
Noah Misch 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 rely on any
On Wed, Sep 07, 2011 at 02:09:15PM +0100, Thom Brown wrote:
> On 24 August 2011 13:38, Kohei Kaigai 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
Dave Cramer 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
configure:3323: ccache g
On Wed, Sep 7, 2011 at 11:16 AM, Tom Lane wrote:
> Dave Cramer 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
Dave Cramer 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 -v, but thi
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:
http://www.postgresql.org/mailpr
Marti Raudsepp 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 case in get_n
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 Momjian wrote:
Hiroshi Saito wrote:
Hi Magnus-san and Bruce-san.
I am sorry in a very late reaction...
Is it enough for a 9
On Tue, Sep 6, 2011 at 10:11 PM, Fujii Masao wrote:
> On Sat, Sep 3, 2011 at 5:10 AM, Kevin Grittner
> wrote:
>> (2) It should copy, not move, with protection against overwriting
>> an existing file.
>
> I agree that basically archive_command should not overwrite an existing file.
> But if the s
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 Wed, Sep 7, 2011 at 16:43, Bruce Momjian 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 ??
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)
On 2011-09-07 16:02, Kevin Grittner wrote:
Robert Haas 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:
http://www.postgresql.o
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 m
2011/9/7 Robert Haas :
> On Wed, Sep 7, 2011 at 9:39 AM, Thom Brown wrote:
>> On 7 September 2011 14:34, Kohei KaiGai wrote:
>>> 2011/9/7 Thom Brown :
>>> > On 24 August 2011 13:38, Kohei Kaigai wrote:
>>> >>
>>> >> The (2) is new stuff from the revision in commit-fest 1st. It enables
>>> >> to
Robert Haas 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 releases all
> user lo
Robert Haas 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
Andy Colson 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 in the config file
On Wed, Sep 7, 2011 at 9:39 AM, Thom Brown wrote:
> On 7 September 2011 14:34, Kohei KaiGai wrote:
>> 2011/9/7 Thom Brown :
>> > On 24 August 2011 13:38, Kohei Kaigai wrote:
>> >>
>> >> The (2) is new stuff from the revision in commit-fest 1st. It enables
>> >> to
>> >> supply "NOLEAKY" option o
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 5:16 AM, daveg wrote:
> On Tue, Aug 23, 2011 at 12:15:23PM -0400, Robert Haas wrote:
>> On Mon, Aug 22, 2011 at 3:31 AM, daveg wrote:
>> > So far I've got:
>> >
>> > - affects system tables
>> > - happens very soon after process startup
>> > - in 8.4.7 and 9.0.4
>> > -
On 7 September 2011 14:34, Kohei KaiGai wrote:
> 2011/9/7 Thom Brown :
> > On 24 August 2011 13:38, Kohei Kaigai 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
> >> allowe
2011/9/7 Thom Brown :
> On 24 August 2011 13:38, Kohei Kaigai 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
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
On 24 August 2011 13:38, Kohei Kaigai 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
> option.
>
"NOLEAKY"
On Wed, Sep 7, 2011 at 9:10 PM, Thom Brown wrote:
> On 7 September 2011 11:56, Simon Riggs 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.
Thanks!
> This appears
On 7 September 2011 11:56, Simon Riggs wrote:
> On Wed, Sep 7, 2011 at 2:44 AM, Fujii Masao wrote:
> > On Wed, Sep 7, 2011 at 5:22 AM, Simon Riggs
> 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
On Tue, Sep 6, 2011 at 9:18 PM, Simon Riggs 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 http://www.2ndQuadran
On Wed, Sep 7, 2011 at 2:44 AM, Fujii Masao wrote:
> On Wed, Sep 7, 2011 at 5:22 AM, Simon Riggs 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 reason passed to the walsender, r
On Wed, Sep 7, 2011 at 03:44, Fujii Masao wrote:
> On Wed, Sep 7, 2011 at 5:22 AM, Simon Riggs 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 reason passed to the walsender, rat
On Tue, Aug 23, 2011 at 12:15:23PM -0400, Robert Haas wrote:
> On Mon, Aug 22, 2011 at 3:31 AM, daveg 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 Tue, Sep 06, 2011 at 09:21:02PM -0400, Bruce Momjian wrote:
> Tom Lane wrote:
> > hubert depesz lubaczewski 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
> > 8eee65c99
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
buf
1 - 100 of 101 matches
Mail list logo
