On Mon, Aug 16, 2010 at 10:56 PM, Peter Eisentraut wrote:
> On lör, 2010-08-14 at 02:05 -0500, Jaime Casanova wrote:
>
>> BTW, why the double quotes?
>
> Because the name contains upper case letters?
>
why everything seems so obvious once someone else state it? :)
>> sorry to state the obvious b
Here is a small prototype for a query progress indicator.
Past discussions seemed to indicate that the best place to report this
would be in pg_stat_activity. So that's what this does. You can try it
out with any of the following (on a sufficiently large table): VACUUM
(lazy) (also autovacuum),
(2010/08/17 13:28), Peter Eisentraut wrote:
> On tis, 2010-08-17 at 13:00 +0900, KaiGai Kohei wrote:
>> However, isn't it strange if we stand on the perspective that child
>> table is a part of parent object? It means an object have multiple
>> properties depending on the context.
>
> Such is the
On tis, 2010-08-17 at 13:00 +0900, KaiGai Kohei wrote:
> However, isn't it strange if we stand on the perspective that child
> table is a part of parent object? It means an object have multiple
> properties depending on the context.
Such is the nature of inheritance, isn't it?
--
Sent via pgsql
(2010/08/17 11:58), Tom Lane wrote:
> Stephen Frost writes:
>> * KaiGai Kohei (kai...@ak.jp.nec.com) wrote:
>>> Indeed, PG does not try to handle child table as an independent object
>>> from a parent table. However, if so, it seems to me strange that we can
>>> assign individual ownership and acc
On lör, 2010-08-14 at 02:05 -0500, Jaime Casanova wrote:
> btw, the patch no longer apply cleanly but most are just hunks the
> worst it's in src/backend/catalog/namespace.c because
> FindConversionByName() is now called get_conversion_oid()... so maybe
> this function should be named get_collation
(2010/08/17 11:37), Robert Haas wrote:
>> I might have a reason why the script need to launch in single-user
>> mode, but it is not clear right now, sorry.
>
> Another point here is that I wonder if we really need to label system
> objects at all. Are you applying the same label to all of them?
2010/8/17 Robert Haas :
> On Sun, Aug 15, 2010 at 7:44 AM, Hitoshi Harada wrote:
>> We (Marko, David Fetter and I) discussed on IRC about design of
>> writeable CTEs. It does and will contain not only syntax but also
>> miscellaneous specifications, general rules and restrictions. I hope
>> this w
2010/8/17 David Fetter :
> On Mon, Aug 16, 2010 at 04:34:07PM -0400, Robert Haas wrote:
>> On Mon, Aug 16, 2010 at 3:00 PM, David Fetter wrote:
>> >> There has been previous talk of allowing WITH (COPY ...) and I am
>> >> personally of the opinion that it would be nice to be able to do
>> >> WITH
Stephen Frost writes:
> * KaiGai Kohei (kai...@ak.jp.nec.com) wrote:
>> Indeed, PG does not try to handle child table as an independent object
>> from a parent table. However, if so, it seems to me strange that we can
>> assign individual ownership and access privileges on child tables.
> I tend
Joseph Adams writes:
> Others already mentioned that you can't convert 2 billion byte long
> JSON strings to BSON. Another issue is that BSON cannot encode all
> JSON numbers without precision loss.
As somebody already mentioned, the former isn't likely to be an issue
for us anytime in the fores
Robert Haas writes:
> On Mon, Aug 16, 2010 at 3:48 PM, Tom Lane wrote:
>> I think the problem is you're trying to put this into backend/parser
>> which is not really the right place for it.
> If this isn't parse analysis, then you and I have very different ideas
> of what parse analysis is.
May
2010/8/16 KaiGai Kohei :
>> I don't really see what the advantage of doing this in single-user
>> mode is. If the overhead of permissions-checking is enough to matter,
>> maybe that's a sign we're doing something wrong.
>>
> Hmm... I guess the overhead is not a significant matter, because the
> nu
Robert Haas wrote:
> > Yeah, it's a bit too slow to do on every sync. ?I run it every week or
> > two and keep the output in a text file. ?Usually what I want the history
> > for is stuff that happened awhile ago, so the fact that it's not 100% up
> > to date is seldom a factor.
>
> OK, try this.
(2010/08/17 10:57), Robert Haas wrote:
> 2010/8/16 KaiGai Kohei:
>> (2010/08/17 9:52), Robert Haas wrote:
>>> 2010/8/16 KaiGai Kohei:
(2010/08/16 23:40), Robert Haas wrote:
> 2010/8/16 KaiGai Kohei:
>> Although nobody paid an attention, it seems to me a problem to be fixed.
>>
Tom Lane wrote:
> Magnus Hagander writes:
> > According to the decision at the developer meeting, the migration to
> > git should happen 17-20 Aug. Here's my proposed timeline. This will
> > obviously affect development work some, and since the original
> > timeline called for us having already re
2010/8/16 KaiGai Kohei :
> (2010/08/17 9:52), Robert Haas wrote:
>> 2010/8/16 KaiGai Kohei:
>>> (2010/08/16 23:40), Robert Haas wrote:
2010/8/16 KaiGai Kohei:
> Although nobody paid an attention, it seems to me a problem to be fixed.
>
> The attached patch fixes the problem using a
(2010/08/17 9:52), Robert Haas wrote:
> 2010/8/16 KaiGai Kohei:
>> (2010/08/16 23:40), Robert Haas wrote:
>>> 2010/8/16 KaiGai Kohei:
Although nobody paid an attention, it seems to me a problem to be fixed.
The attached patch fixes the problem using a simple idea which adds
proc
(2010/08/17 9:51), Stephen Frost wrote:
> * KaiGai Kohei (kai...@ak.jp.nec.com) wrote:
>> Ahh, yes, the question is "what is an object", not a "MAC vs DAC".
>>
>> Indeed, PG does not try to handle child table as an independent object
>> from a parent table. However, if so, it seems to me strange th
On Mon, Aug 16, 2010 at 3:48 PM, Tom Lane wrote:
>> 2. I haven't done anything about moving the definition of
>> ObjectAddress elsewhere, as Alvaro suggested, because I'm not sure
>> quite where it ought to go. I still think it's a good idea, though
>> I'm not dead set on it, either. Suggestions
On Mon, Aug 16, 2010 at 8:38 PM, Josh Berkus wrote:
>
>> but BSON pidgenholes numeric values to either double, int32, int64, or
>> a 12-byte MongoDB Object ID. Thus, for people who expect JSON to be
>> able to hold arbitrary-precision numbers (which the JSON data type in
>> my patch can), using B
On Mon, Aug 16, 2010 at 5:08 PM, David Fetter wrote:
> On Mon, Aug 16, 2010 at 04:34:07PM -0400, Robert Haas wrote:
>> On Mon, Aug 16, 2010 at 3:00 PM, David Fetter wrote:
>> >> There has been previous talk of allowing WITH (COPY ...) and I am
>> >> personally of the opinion that it would be nice
2010/8/16 KaiGai Kohei :
> (2010/08/16 23:40), Robert Haas wrote:
>> 2010/8/16 KaiGai Kohei:
>>> Although nobody paid an attention, it seems to me a problem to be fixed.
>>>
>>> The attached patch fixes the problem using a simple idea which adds
>>> process_shared_preload_libraries() at PostgresMai
* KaiGai Kohei (kai...@ak.jp.nec.com) wrote:
> Ahh, yes, the question is "what is an object", not a "MAC vs DAC".
>
> Indeed, PG does not try to handle child table as an independent object
> from a parent table. However, if so, it seems to me strange that we can
> assign individual ownership and a
On Mon, Aug 16, 2010 at 7:01 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Mon, Aug 16, 2010 at 4:33 PM, Tom Lane wrote:
>>> I'd be satisfied with a tool that merges commit reports if they have the
>>> same log message and occur at approximately the same time, which is the
>>> heuristic that c
> but BSON pidgenholes numeric values to either double, int32, int64, or
> a 12-byte MongoDB Object ID. Thus, for people who expect JSON to be
> able to hold arbitrary-precision numbers (which the JSON data type in
> my patch can), using BSON for transfer or storage will violate that
> expectatio
(2010/08/16 22:14), Stephen Frost wrote:
> KaiGai,
>
> * KaiGai Kohei (kai...@ak.jp.nec.com) wrote:
>> The purpose of this restriction is to ensure an access control decision
>> using parent's label being also consistent on child tables.
>
> Robert and I understand the concern that you have. The
> Another idea that comes to mind is that you have vacuum_cost_page_dirty
> set to an unreasonably large value, so that autovac is blocking whenever
> it has to write even one page.
Nope. Default. And total cost was raised to 1000.
--
-- Josh Berkus
(2010/08/17 9:02), Itagaki Takahiro wrote:
> 2010/8/17 KaiGai Kohei:
>> I want to kick this job in single-user mode, not normal processing mode,
>
> Does an explicit LOAD work in single-user mode?
> I think LOAD just after login works as same as it was preloaded,
> unless it allocates shared memor
2010/8/17 KaiGai Kohei :
> I want to kick this job in single-user mode, not normal processing mode,
Does an explicit LOAD work in single-user mode?
I think LOAD just after login works as same as it was preloaded,
unless it allocates shared memory.
--
Itagaki Takahiro
--
Sent via pgsql-hackers
Magnus Hagander writes:
> According to the decision at the developer meeting, the migration to
> git should happen 17-20 Aug. Here's my proposed timeline. This will
> obviously affect development work some, and since the original
> timeline called for us having already released 9.0 buy then ;)
>
(2010/08/16 23:40), Robert Haas wrote:
> 2010/8/16 KaiGai Kohei:
>> Although nobody paid an attention, it seems to me a problem to be fixed.
>>
>> The attached patch fixes the problem using a simple idea which adds
>> process_shared_preload_libraries() at PostgresMain() when we launched
>> it in si
On Mon, Aug 16, 2010 at 7:24 PM, Tom Lane wrote:
>
> Well, if it's not just a binary encoding of JSON, I think we can forget
> about it ... certainly it won't work in the form I was visualizing.
>
> regards, tom lane
I just read the spec, and BSON has a lot of bells and whi
1;2403;0cOn Mon, Aug 16, 2010 at 05:02:47PM -0500, Kevin Grittner wrote:
> Charles Pritchard wrote:
>
> > Storing internally as BSON (if it holds up to its premise) would
> > mean more efficient traversal of internal objects in the future,
> > if we were to have JSON-related functions/selectors.
>
"Kevin Grittner" writes:
> Charles Pritchard wrote:
>> Storing internally as BSON (if it holds up to its premise) would
>> mean more efficient traversal of internal objects in the future,
>> if we were to have JSON-related functions/selectors.
> How about the fact that not all JSON objects can
Alex Hunsaker writes:
> On Mon, Aug 16, 2010 at 14:33, Tom Lane wrote:
>> I'd be satisfied with a tool that merges commit reports if they have the
>> same log message and occur at approximately the same time, which is the
>> heuristic that cvs2cl uses.
> I dont think it would be to hard to code
Robert Haas writes:
> On Mon, Aug 16, 2010 at 4:33 PM, Tom Lane wrote:
>> I'd be satisfied with a tool that merges commit reports if they have the
>> same log message and occur at approximately the same time, which is the
>> heuristic that cvs2cl uses.
> So how do you run cvs2cl? Do you run it
On Mon, Aug 16, 2010 at 14:33, Tom Lane wrote:
> Alex Hunsaker writes:
>> How exactly patches get applied into back branches?
> There was discussion about that before, but I don't know whether we
> really have a solution that will work comfortably.
I don't either, not being a -commiter I don't
Charles Pritchard wrote:
> Storing internally as BSON (if it holds up to its premise) would
> mean more efficient traversal of internal objects in the future,
> if we were to have JSON-related functions/selectors.
How about the fact that not all JSON objects can be represented in
BSON (if the
On 8/15/10 8:47 PM, Andrew Dunstan wrote:
On 08/15/2010 11:03 PM, Tom Lane wrote:
Charles Pritchard writes:
I'd originally sent this to Joseph Adams, as he has been working on
adding a JSON datatype.
I've suggested supporting BSON, as there are many client
implementations
available,
I knew
Excerpts from Alvaro Herrera's message of lun ago 16 16:58:31 -0400 2010:
> I suspect that the problem may lie in the "cost_delay rebalance" code in
> autovacuum.
Hmm, so we have this code:
void
AutoVacuumUpdateDelay(void)
{
if (MyWorkerInfo)
{
VacuumCostDelay = M
On Mon, Aug 16, 2010 at 04:34:07PM -0400, Robert Haas wrote:
> On Mon, Aug 16, 2010 at 3:00 PM, David Fetter wrote:
> >> There has been previous talk of allowing WITH (COPY ...) and I am
> >> personally of the opinion that it would be nice to be able to do
> >> WITH (EXPLAIN ...). DDL seems like
Excerpts from Joe Conway's message of lun ago 16 16:47:19 -0400 2010:
> On 08/16/2010 12:12 PM, Josh Berkus wrote:
> >
> >> I've also recently heard a report of vacuum hanging on 8.3.x on Solaris
> >> Sparc. Any chance you can get a backtrace from a build with debug symbols?
> >
> > The problem i
On 08/16/2010 12:12 PM, Josh Berkus wrote:
>
>> I've also recently heard a report of vacuum hanging on 8.3.x on Solaris
>> Sparc. Any chance you can get a backtrace from a build with debug symbols?
>
> The problem is that we haven't been able to reproduce the bug in
> testing. Like I said, it on
On Mon, Aug 16, 2010 at 4:33 PM, Tom Lane wrote:
> I'd be satisfied with a tool that merges commit reports if they have the
> same log message and occur at approximately the same time, which is the
> heuristic that cvs2cl uses.
So how do you run cvs2cl? Do you run it once in a while and save the
On Mon, Aug 16, 2010 at 3:00 PM, David Fetter wrote:
>> There has been previous talk of allowing WITH (COPY ...) and I am
>> personally of the opinion that it would be nice to be able to do
>> WITH (EXPLAIN ...). DDL seems like a poor idea.
>
> It may be, but I can see use cases for partitioning.
Alex Hunsaker writes:
> How exactly patches get applied into back branches? Has that been
> spelled out somewhere? There are a lot of ways to do it. For
> instance git.git seems to apply the patch to the earliest branch first
> and then merge it on up so that everything can share the same
> com
On Mon, Aug 16, 2010 at 12:45, Tom Lane wrote:
> Magnus Hagander writes:
>> On Mon, Aug 16, 2010 at 20:27, Tom Lane wrote:
>>> Second, does git offer a way to collate matching log entries across
>>> multiple branches?
>
>> But what really is the usecase there?
>
> Generating back-branch update r
Robert Haas writes:
> 5. Since I'm hoping Tom will read this, I ran it through filterdiff. :-)
OK, I looked ;-). It mostly looks good, but of course I've got some
opinions...
> 2. I haven't done anything about moving the definition of
> ObjectAddress elsewhere, as Alvaro suggested, because I'm
Josh Berkus writes:
> This is something I'd swear we fixed around 8.3.2. However, I'm seeing
> it again in production, and was wondering if anyone could remember what
> the root cause was and how we fixed it.
Hmm, I can't find anything in the 8.3-series CVS logs suggesting that
there was a post-8
> I've also recently heard a report of vacuum hanging on 8.3.x on Solaris
> Sparc. Any chance you can get a backtrace from a build with debug symbols?
The problem is that we haven't been able to reproduce the bug in
testing. Like I said, it only seems to happen occasionally ... like
maybe once i
On 08/16/2010 11:24 AM, Josh Berkus wrote:
> All,
>
> This is something I'd swear we fixed around 8.3.2. However, I'm seeing
> it again in production, and was wondering if anyone could remember what
> the root cause was and how we fixed it.
I've also recently heard a report of vacuum hanging on 8
On Mon, Aug 16, 2010 at 02:25:50PM -0400, Robert Haas wrote:
> On Sun, Aug 15, 2010 at 7:44 AM, Hitoshi Harada wrote:
> > We (Marko, David Fetter and I) discussed on IRC about design of
> > writeable CTEs. It does and will contain not only syntax but also
> > miscellaneous specifications, general
Robert Haas writes:
> That sounds good, except for the part about nobody doing anything
> about the 9.0 open issues. Those issues are:
> * Backup procedure is wrong? - Nobody's been able to clearly
> articulate what the problem is, and according to Fujii Masao it's been
> this way since 8.2.
Ju
"Kevin Grittner" writes:
> Nobody responded when I asked about this recently, but shouldn't
> that list include "BUG #5607: memmory leak in ecpg"? We have a
> patch from Zoltán Böszörményi from before this bug report which
> seems to address the issue and which Michael Meskes said "Feel free
> to
Thanks for you answer, Tom!
I've implemented mapping between SQLSTATE codes and C++ exception
classes of my library. And of course, I've resolved the conflict of names
by giving a proper name to my classes.
Regards,
Dmitriy
2010/8/16 Tom Lane
> Dmitriy Igrishin writes:
> > According to
> > ht
On Mon, Aug 16, 2010 at 20:45, Tom Lane wrote:
> Magnus Hagander writes:
>> On Mon, Aug 16, 2010 at 20:27, Tom Lane wrote:
>>> Second, does git offer a way to collate matching log entries across
>>> multiple branches?
>
>> But what really is the usecase there?
>
> Generating back-branch update r
Magnus Hagander writes:
> On Mon, Aug 16, 2010 at 20:27, Tom Lane wrote:
>> Second, does git offer a way to collate matching log entries across
>> multiple branches?
> But what really is the usecase there?
Generating back-branch update release notes, mainly. We usually do that
first for the ne
On 16 August 2010 18:50, Tom Lane wrote:
> Dean Rasheed writes:
>> On 15 August 2010 18:38, Dean Rasheed wrote:
>>> There are still a number of things left todo:
>>> - extend ALTER VIEW with enable/disable trigger commands
>
>> On further reflection, I wonder if the ability to disable VIEW
>> t
Robert Haas wrote:
> That sounds good, except for the part about nobody doing anything
> about the 9.0 open issues. Those issues are:
>
> [four issues listed]
Nobody responded when I asked about this recently, but shouldn't
that list include "BUG #5607: memmory leak in ecpg"? We have a
patc
On Mon, Aug 16, 2010 at 20:27, Tom Lane wrote:
> Magnus Hagander writes:
>> On Mon, Aug 16, 2010 at 20:11, Tom Lane wrote:
>>> The other thing that I'd like to see some data on is the commit log
>>> entries. Can we produce anything comparable to cvs2cl output from
>>> the test repository?
>
>>
Magnus Hagander writes:
> On Mon, Aug 16, 2010 at 20:11, Tom Lane wrote:
>> The other thing that I'd like to see some data on is the commit log
>> entries. Can we produce anything comparable to cvs2cl output from
>> the test repository?
> For a single branch, just do "git log ", e.g. "git log
>
On Sun, Aug 15, 2010 at 7:44 AM, Hitoshi Harada wrote:
> We (Marko, David Fetter and I) discussed on IRC about design of
> writeable CTEs. It does and will contain not only syntax but also
> miscellaneous specifications, general rules and restrictions. I hope
> this will help the patch reviews and
All,
This is something I'd swear we fixed around 8.3.2. However, I'm seeing
it again in production, and was wondering if anyone could remember what
the root cause was and how we fixed it.
The problem is that sometimes (but not the majority of times) autovaccum
with cost_delay is going into a path
On Mon, Aug 16, 2010 at 20:11, Tom Lane wrote:
> Magnus Hagander writes:
>> Attached is a ZIP file with the diffs generated when converting the
>> cvs repo to git based off a cvs snapshot from this morning. It
>> contains a diff file for every branch and every tag present. (If a
>> file is missin
On Mon, Aug 16, 2010 at 1:47 PM, Tom Lane wrote:
> I wrote:
>> Magnus Hagander writes:
>>> According to the decision at the developer meeting, the migration to
>>> git should happen 17-20 Aug. Here's my proposed timeline. This will
>>> obviously affect development work some, and since the origina
Magnus Hagander writes:
> Attached is a ZIP file with the diffs generated when converting the
> cvs repo to git based off a cvs snapshot from this morning. It
> contains a diff file for every branch and every tag present. (If a
> file is missing, that means there were no diffs for that branch/tag)
Dean Rasheed writes:
> On 15 August 2010 18:38, Dean Rasheed wrote:
>> There are still a number of things left todo:
>> - extend ALTER VIEW with enable/disable trigger commands
> On further reflection, I wonder if the ability to disable VIEW
> triggers is needed/wanted at all.
AFAIK the only r
I wrote:
> Magnus Hagander writes:
>> According to the decision at the developer meeting, the migration to
>> git should happen 17-20 Aug. Here's my proposed timeline. This will
>> obviously affect development work some, and since the original
>> timeline called for us having already released 9.0
On 15 August 2010 18:38, Dean Rasheed wrote:
> There are still a number of things left todo:
> - extend ALTER VIEW with enable/disable trigger commands
On further reflection, I wonder if the ability to disable VIEW
triggers is needed/wanted at all. I just noticed that while it is
possible to dis
On 16/08/10 20:17, Joseph Adams wrote:
Also, an idea would be to make json_send and json_recv (binary JSON
send/receive) use BSON rather than JSON-encoded text, as
sending/receiving JSON-encoded text is exactly what text send/receive
do.
The usual reason to use the binary format is performance,
On 16 August 2010 14:45, David Fetter wrote:
> Please add this to the next commitfest :)
>
Done.
Thanks,
Dean
> https://commitfest.postgresql.org/action/commitfest_view?id=7
>
> Cheers,
> David.
> --
> David Fetter http://fetter.org/
> Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
On Sun, Aug 15, 2010 at 11:47 PM, Andrew Dunstan wrote:
>
> If BSON is simply in effect an efficient encoding of JSON, then it's not
> clear to me that we would want another type at all. Rather, we might want to
> consider storing the data in this supposedly more efficient format, and
> maybe also
On Mon, Aug 16, 2010 at 17:20, Itagaki Takahiro
wrote:
> 2010/8/16 Magnus Hagander :
>> If you want to *change* your email address from the one in the list
>> attached here, please let me know *ASAP*. At the latest I need to know
>> this before tuesday evening european time (see separate email abo
On 16/08/10 03:35, Tom Lane wrote:
Heikki Linnakangas writes:
One approach is to handle the conversion from unknown to the right data
type transparently in the backend. Attached patch adds a
coerce-param-hook for fixed params that returns a CoerceViaIO node to
convert the param to the right typ
On 8/16/10 8:40 AM, Christopher Browne wrote:
On Mon, Aug 16, 2010 at 11:21 AM, Robert Haas wrote:
On Mon, Aug 16, 2010 at 11:05 AM, Tom Lane wrote:
Andrew Dunstan writes:
If BSON is simply in effect an efficient encoding of JSON, then it's not
clear to me that we would wa
On 08/16/2010 06:38 AM, Magnus Hagander wrote:
> The current mapping used is the same one as on git.postgresql.org (see
> attached file).
>
> Per discussions earlier on this list, we encourage people to use an
> email address that is permanent and stable, and does not for example
> change if you c
Excerpts from Magnus Hagander's message of lun ago 16 09:38:12 -0400 2010:
> If you want to *change* your email address from the one in the list
> attached here, please let me know *ASAP*. At the latest I need to know
> this before tuesday evening european time (see separate email about
> migratio
Alvaro Herrera writes:
> In that case, maybe consider fsync'ing it.
BTW, I see you already proposed that in the thread at
http://archives.postgresql.org/message-id/e3e180dc0905070719q58136caai23fbb777fd3c0...@mail.gmail.com
I'm not sure how come the idea fell through the cracks, but we should
sur
Excerpts from KaiGai Kohei's message of lun ago 16 00:19:54 -0400 2010:
> (2010/08/16 11:50), Robert Haas wrote:
> When we were developing largeobject access controls, Tom Lane commented
> as follows:
>
> * Re: [HACKERS] [PATCH] Largeobject access controls
> http://marc.info/?l=pgsql-hackers&m=
Alvaro Herrera writes:
> Excerpts from Tom Lane's message of lun ago 16 11:49:51 -0400 2010:
>> The bottom line here is that it's not clear to me whether changing this
>> would be a net reliability improvement or not. Maybe better to leave
>> it alone.
> In that case, maybe consider fsync'ing it
Dmitriy Igrishin writes:
> According to
> http://www.postgresql.org/docs/9.0/static/errcodes-appendix.html
> some error conditions has non-unique *names*. There are:
> modifying_sql_data_not_permitted,
> prohibited_sql_statement_attempted,
> reading_sql_data_not_permitted
> from SQL Routine Except
Excerpts from Tom Lane's message of lun ago 16 11:49:51 -0400 2010:
> The bottom line here is that it's not clear to me whether changing this
> would be a net reliability improvement or not. Maybe better to leave
> it alone.
In that case, maybe consider fsync'ing it.
--
Álvaro Herrera
The Pos
Excerpts from Tom Lane's message of lun ago 16 11:18:32 -0400 2010:
> We could perhaps address that risk another way: after having written
> postmaster.pid, try to read it back to verify that it contains what we
> wrote, and abort if not. Then, if we can't read it during startup,
> it's okay to a
On Mon, 2010-08-16 at 16:19 +0200, Magnus Hagander wrote:
> On Mon, Aug 16, 2010 at 16:15, Tom Lane wrote:
> > Magnus Hagander writes:
> >> On Mon, Aug 16, 2010 at 15:58, Tom Lane wrote:
> >>> I can see the point of wanting to be dead certain the repository isn't
> >>> changing under you during
Robert Haas writes:
> On Mon, Aug 16, 2010 at 11:18 AM, Tom Lane wrote:
>> We could perhaps address that risk another way: after having written
>> postmaster.pid, try to read it back to verify that it contains what we
>> wrote, and abort if not. Then, if we can't read it during startup,
>> it's
On Mon, 2010-08-16 at 11:40 -0400, Christopher Browne wrote:
> On Mon, Aug 16, 2010 at 11:21 AM, Robert Haas wrote:
> > On Mon, Aug 16, 2010 at 11:05 AM, Tom Lane wrote:
> >> Andrew Dunstan writes:
> >>> If BSON is simply in effect an efficient encoding of JSON, then it's not
> >>> clear to me t
On Mon, Aug 16, 2010 at 11:21 AM, Robert Haas wrote:
> On Mon, Aug 16, 2010 at 11:05 AM, Tom Lane wrote:
>> Andrew Dunstan writes:
>>> If BSON is simply in effect an efficient encoding of JSON, then it's not
>>> clear to me that we would want another type at all. Rather, we might
>>> want to con
Hey all,
According to
http://www.postgresql.org/docs/9.0/static/errcodes-appendix.html
some error conditions has non-unique *names*. There are:
modifying_sql_data_not_permitted,
prohibited_sql_statement_attempted,
reading_sql_data_not_permitted
from SQL Routine Exception and External Routine Excep
On Mon, Aug 16, 2010 at 11:18 AM, Tom Lane wrote:
> This complaint:
> http://archives.postgresql.org/pgsql-admin/2010-08/msg00111.php
>
> seems to suggest that this code in CreateLockFile() is not well-thought-out:
>
> if (other_pid <= 0)
> elog(FATAL, "bogus
2010/8/16 Magnus Hagander :
> If you want to *change* your email address from the one in the list
> attached here, please let me know *ASAP*. At the latest I need to know
> this before tuesday evening european time (see separate email about
> migration timeline).
Could you change my address to ita
On Mon, Aug 16, 2010 at 11:05 AM, Tom Lane wrote:
> Andrew Dunstan writes:
>> If BSON is simply in effect an efficient encoding of JSON, then it's not
>> clear to me that we would want another type at all. Rather, we might
>> want to consider storing the data in this supposedly more efficient
>>
This complaint:
http://archives.postgresql.org/pgsql-admin/2010-08/msg00111.php
seems to suggest that this code in CreateLockFile() is not well-thought-out:
if (other_pid <= 0)
elog(FATAL, "bogus data in lock file \"%s\": \"%s\"",
* Kevin Grittner (kevin.gritt...@wicourts.gov) wrote:
> Many of the features KaiGai has discussed would fit nicely with
> court requirements -- and might even be prerequisites for
> considering moving security to the database level. Mandating
> identical security for all tables in a hierarchy woul
Andrew Dunstan writes:
> If BSON is simply in effect an efficient encoding of JSON, then it's not
> clear to me that we would want another type at all. Rather, we might
> want to consider storing the data in this supposedly more efficient
> format, and maybe also some conversion routines.
Hmm,
2010/8/16 KaiGai Kohei :
> Although nobody paid an attention, it seems to me a problem to be fixed.
>
> The attached patch fixes the problem using a simple idea which adds
> process_shared_preload_libraries() at PostgresMain() when we launched
> it in single-user mode.
I have no confidence at all
=?ISO-8859-1?Q?C=E9dric_Villemain?= writes:
> Yes, and you point out another thing. EXECUTE is a way to bypass the
> named prepare statement, to be sure query is replanned each time.
> Unfortunely the current implementation of EXECUTE USING is not working
> this way.
Uh ... what do you base that
On Mon, Aug 16, 2010 at 9:38 AM, Magnus Hagander wrote:
> Attention committers!! ;)
>
> When we migrate to git, we will do a one-time mapping of your old
> username to an email address (as was discussed on the developer
> meeting in Ottawa earlier this year). This is stamped on every commit
> you
On Mon, Aug 16, 2010 at 16:15, Tom Lane wrote:
> Magnus Hagander writes:
>> On Mon, Aug 16, 2010 at 15:58, Tom Lane wrote:
>>> I can see the point of wanting to be dead certain the repository isn't
>>> changing under you during the data migration. Perhaps we need an agreed
>>> window between la
On Mon, Aug 16, 2010 at 10:15 AM, Tom Lane wrote:
> Magnus Hagander writes:
>> On Mon, Aug 16, 2010 at 15:58, Tom Lane wrote:
>>> I can see the point of wanting to be dead certain the repository isn't
>>> changing under you during the data migration. Perhaps we need an agreed
>>> window between
1 - 100 of 125 matches
Mail list logo
