Tom Lane wrote:
> Jesper Krogh writes:
>> This patch enables users to set TOAST_TUPLES_PER_PAGE with
>> ALTER TABLE SET (tuples_per_page = X); .. currently with 1 <= X
>> <= 32;
>
> It's not clear to me that fiddling with that is useful unless the toast
> tuple size also changes; and unfortunate
Takahiro Itagaki wrote:
> > TRAP: FailedAssertion("!(typeNamespace == typ->typnamespace)", File:
> > "pg_type.c", Line: 658)
It comes from swapping toast relations:
DEBUG: typeNamespace mismatch: 99 (pg_toast) vs. 16386 (pg_toast_temp_2)
AFAICS, the assertion is broken, but the code is corr
>>> The --schema-only with large objects might be unnatural, but the
>>> --data-only with properties of large objects are also unnatural.
>>> Which behavior is more unnatural?
>>
>> I think large object metadata is a kind of row-based access controls.
>> How do we dump and restore ACLs per rows whe
On Mon, Feb 1, 2010 at 7:40 PM, Heikki Linnakangas
wrote:
> So you get those messages when the table is *not* a temporary table. I
> can see now what Fujii was trying to say. His patch seems Ok, though
> perhaps it would be better to move the responsibility of calling
> XLogReportUnloggedStatement
Hi,
On Mon, Feb 1, 2010 at 7:33 PM, Rafael Martinez
wrote:
> The PITR backup history file named
> pg_xlog/00010038.0020.backup included this information:
>
> START WAL LOCATION: 38/20 (file 00010038)
> ST
(2010/02/02 11:44), Robert Haas wrote:
> 2010/2/1 KaiGai Kohei:
>> (2010/02/02 11:31), Robert Haas wrote:
>>> 2010/2/1 KaiGai Kohei:
(2010/02/02 11:09), Tom Lane wrote:
> KaiGai Kohei writes:
>> The attached one also clean up ATPrepAddColumn() and ATExecAddColumn()
>> code,
>
On Mon, Feb 1, 2010 at 03:58, Tim Bunce wrote:
> On Sat, Jan 30, 2010 at 06:38:59PM -0700, Alex Hunsaker wrote:
>
>> plc_safe_ok.pl seems to loose its CVS $PostgreSQL$ keyword.
>Probably a slip-up when I merged the changes from HEAD up through my
>chain of branches.
Can you send an updated patch?
2010/2/1 KaiGai Kohei :
> (2010/02/02 11:31), Robert Haas wrote:
>> 2010/2/1 KaiGai Kohei:
>>> (2010/02/02 11:09), Tom Lane wrote:
KaiGai Kohei writes:
> The attached one also clean up ATPrepAddColumn() and ATExecAddColumn()
> code,
> not only ATPrepAlterColumnType(), according
(2010/02/02 11:31), Robert Haas wrote:
> 2010/2/1 KaiGai Kohei:
>> (2010/02/02 11:09), Tom Lane wrote:
>>> KaiGai Koheiwrites:
The attached one also clean up ATPrepAddColumn() and ATExecAddColumn()
code,
not only ATPrepAlterColumnType(), according to what I mentioned above.
>>>
KaiGai Kohei writes:
> (2010/02/02 11:09), Tom Lane wrote:
>> KaiGai Kohei writes:
>>> The attached one also clean up ATPrepAddColumn() and ATExecAddColumn() code,
>>> not only ATPrepAlterColumnType(), according to what I mentioned above.
>>
>> What exactly do you claim is wrong with the ADD COL
2010/2/1 KaiGai Kohei :
> (2010/02/02 11:09), Tom Lane wrote:
>> KaiGai Kohei writes:
>>> The attached one also clean up ATPrepAddColumn() and ATExecAddColumn() code,
>>> not only ATPrepAlterColumnType(), according to what I mentioned above.
>>
>> What exactly do you claim is wrong with the ADD CO
(2010/02/02 11:09), Tom Lane wrote:
> KaiGai Kohei writes:
>> The attached one also clean up ATPrepAddColumn() and ATExecAddColumn() code,
>> not only ATPrepAlterColumnType(), according to what I mentioned above.
>
> What exactly do you claim is wrong with the ADD COLUMN case?
ADD COLUMN case wo
KaiGai Kohei writes:
> The attached one also clean up ATPrepAddColumn() and ATExecAddColumn() code,
> not only ATPrepAlterColumnType(), according to what I mentioned above.
What exactly do you claim is wrong with the ADD COLUMN case?
regards, tom lane
--
Sent via pgsql-
I am very interested in doing it. However I am new to postgresql. Could you
and anyone here please give me some hint, which way I should, which part of
code I should focus to fix it?
Thanks,
M Z
On Mon, Feb 1, 2010 at 1:23 PM, Robert Haas wrote:
> On Mon, Feb 1, 2010 at 1:20 PM, M Z wrote:
> >
(2010/02/02 9:33), Takahiro Itagaki wrote:
>
> KaiGai Kohei wrote:
>
>>> Can we remove such path and raise an error instead?
>>> Also, even if we support the older servers in the routine,
>>> the new bytea format will be another problem anyway.
>>
>> OK, I'll fix it.
>
> I think we might need t
(2010/02/02 9:48), KaiGai Kohei wrote:
>>> Also, the ALTER COLUMN TYPE case should be also fixed in the 9.1 release
>>> (or 9.0.1?).
>>
>> If the fix is something we could commit for 9.0.1, then we ought to do
>> it now before 9.0 is released. If you want to submit a follow-on
>> patch to address
On Mon, Feb 1, 2010 at 5:23 PM, Andrew Dunstan wrote:
> Robert Haas wrote:
>> (2) add a very, very large warning that this will crash if you do
>> almost anything with it.
>
> I think that's an exaggeration. Certain people are known to be using it
> quite successfully.
Hmm. Well, all I know is t
(2010/02/02 3:01), Robert Haas wrote:
> 2010/1/31 KaiGai Kohei:
>> The attached patch modified find_all_inheritors() to return the list of
>> expected inhcount, if List * pointer is given. And, it focuses on only
>> the bugs in renameatt() case.
>
> I have cleaned up and simplified this patch. At
Simon Riggs wrote:
> TRAP: FailedAssertion("!(typeNamespace == typ->typnamespace)", File:
> "pg_type.c", Line: 658)
>
> Test case attached, repeated, consistent failure on CVS HEAD.
I see the same assertion failure on 8.4.2, too.
I'll investigating it...
-- minimum reproducible pattern
drop t
KaiGai Kohei wrote:
> > Can we remove such path and raise an error instead?
> > Also, even if we support the older servers in the routine,
> > the new bytea format will be another problem anyway.
>
> OK, I'll fix it.
I think we might need to discuss about explicit version checks in pg_restore.
Jesper Krogh writes:
> This patch enables users to set TOAST_TUPLES_PER_PAGE with
> ALTER TABLE SET (tuples_per_page = X); .. currently with 1 <= X
> <= 32;
It's not clear to me that fiddling with that is useful unless the toast
tuple size also changes; and unfortunately changing that is much ha
Simon Riggs writes:
> On Mon, 2010-02-01 at 20:11 -0300, Alvaro Herrera wrote:
>> It'd probably be worth changing the order of the ApplySetting calls so
>> that it doesn't look suspicious.
> Just a comment would be enough I think
Yeah. Changing the order would mean that we'd do extra work apply
On Sun, 31 Jan 2010 22:24:40 +
Mark Cave-Ayland wrote:
> Ivan Sergio Borgonovo wrote:
>
> > Of course I can write a script that can workaround this.
> > It seems that the only thing missing is that pgxs 8.3 used to
> > prefix .so with lib and then rename them at install time, but
> > pgxs 8.
On Mon, 2010-02-01 at 20:11 -0300, Alvaro Herrera wrote:
> It'd probably be worth changing the order of the ApplySetting calls so
> that it doesn't look suspicious.
Just a comment would be enough I think on ApplySetting to make it clear
that it really means ApplySettingIfNotAlreadySet()
--
Sim
Simon Riggs wrote:
> Whereas in process_settings() the sequence is this
>
> ApplySetting(databaseid, roleid, relsetting, PGC_S_DATABASE_USER);
> ApplySetting(InvalidOid, roleid, relsetting, PGC_S_USER);
> ApplySetting(databaseid, InvalidOid, relsetting, PGC_S_DATABASE);
>
> which looks to me lik
On Feb 1, 2010, at 1:23 PM, Nathan Boley wrote:
>> I think it would be great for you to review it... I doubt that will
>> cause it to get committed for 9.0, but my doubt is no reason for you
>> to hold off reviewing it.
>
> I assumed so, but the pretense of a chance will probably help to motivate
In the docs it says
"It is also possible to tie a session default to a specific database
rather than to a role; see ALTER DATABASE. If there is a conflict,
database-role-specific settings override role-specific ones, which in
turn override database-specific ones."
Whereas in process_settings() th
Robert Haas wrote:
(2) add a very, very large warning that this will crash if you do
almost anything with it.
I think that's an exaggeration. Certain people are known to be using it
quite successfully.
cheers
andrew
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.or
On Mon, Feb 1, 2010 at 4:30 PM, Joshua D. Drake wrote:
> On Mon, 2010-02-01 at 16:13 -0500, Bruce Momjian wrote:
>> Alvaro Herrera wrote:
>> > Peter Eisentraut escribi?:
>> > > On m?n, 2010-02-01 at 12:01 -0800, Nathan Boley wrote:
>> > > > I code nearly exclusively in python and C, but I have
>>
On 2/1/10 1:39 PM, Joshua D. Drake wrote:
> On Mon, 2010-02-01 at 16:31 -0500, Bruce Momjian wrote:
>>
I would love to know why PL/Python can't be incrementally improved like
the rest of our code.
>>> It has been. That is exactly what PeterE has been doing.
>>>
>>> However, if you look
On Feb 1, 2010, at 2:13 PM, Bruce Momjian wrote:
> I would love to know why PL/Python can't be incrementally improved like
> the rest of our code.
AFAICT, there are two primary, perhaps identifying, parts to a PL extension:
code management (compilation, execution, etc) and type I/O (conversion in
On Mon, 2010-02-01 at 16:31 -0500, Bruce Momjian wrote:
>
> > > I would love to know why PL/Python can't be incrementally improved like
> > > the rest of our code.
> >
> > It has been. That is exactly what PeterE has been doing.
> >
> > However, if you look at this whole thread, you will see th
Hi
This is my first attempt to hack PostgreSQL (even C actually), so bear
over with obvious mistakes done.
I've had a wish to be able to teach Postgres a bit more about how to
store its data on disk. Our systems is a typical web-based system where
all access more or less can be devided into 2 cat
Joshua D. Drake wrote:
> On Mon, 2010-02-01 at 16:13 -0500, Bruce Momjian wrote:
> > Alvaro Herrera wrote:
> > > Peter Eisentraut escribi?:
> > > > On m?n, 2010-02-01 at 12:01 -0800, Nathan Boley wrote:
> > > > > I code nearly exclusively in python and C, but I have
> > > > > often found pl/python
On Mon, 2010-02-01 at 16:13 -0500, Bruce Momjian wrote:
> Alvaro Herrera wrote:
> > Peter Eisentraut escribi?:
> > > On m?n, 2010-02-01 at 12:01 -0800, Nathan Boley wrote:
> > > > I code nearly exclusively in python and C, but I have
> > > > often found pl/python to be very unwieldy. For this reas
Alvaro Herrera wrote:
> Peter Eisentraut escribi?:
> > On m?n, 2010-02-01 at 12:01 -0800, Nathan Boley wrote:
> > > I code nearly exclusively in python and C, but I have
> > > often found pl/python to be very unwieldy. For this reason I often
> > > use pl/perl or pl/pgsql for problems that, outsid
Peter Eisentraut escribió:
> On mån, 2010-02-01 at 12:01 -0800, Nathan Boley wrote:
> > I code nearly exclusively in python and C, but I have
> > often found pl/python to be very unwieldy. For this reason I often
> > use pl/perl or pl/pgsql for problems that, outside of postgres, I
> > would alway
On Mon, 2010-02-01 at 22:35 +0200, Peter Eisentraut wrote:
> On mån, 2010-02-01 at 12:01 -0800, Nathan Boley wrote:
> > I code nearly exclusively in python and C, but I have
> > often found pl/python to be very unwieldy. For this reason I often
> > use pl/perl or pl/pgsql for problems that, outsid
On mån, 2010-02-01 at 12:01 -0800, Nathan Boley wrote:
> I code nearly exclusively in python and C, but I have
> often found pl/python to be very unwieldy. For this reason I often
> use pl/perl or pl/pgsql for problems that, outside of postgres, I
> would always use python.
I find that curious, b
2010/1/12 Boszormenyi Zoltan :
> Tom Lane írta:
>> Alvaro Herrera writes:
>>
>>> But it would be broken in very obvious ways, no? It's not like it would
>>> be silently broken and thus escape testing ...
>>>
>>
>> Well, if we wanted to adopt that approach, we should add the count to
>> *all* SELE
> I think it would be great for you to review it... I doubt that will
> cause it to get committed for 9.0, but my doubt is no reason for you
> to hold off reviewing it.
I assumed so, but the pretense of a chance will probably help to motivate me :-)
I'll have something by Thursday, and then 'Retu
I wrote:
> The design I sketched doesn't require such an assumption anyway. Once
> the map file is written, the relocation is effective, commit or no.
> As long as we restrict relocations to maintenance operations such as
> VACUUM FULL, which have no transactionally significant results, this
> doe
On Mon, Feb 1, 2010 at 3:01 PM, Nathan Boley wrote:
>> On the basis of all of the foregoing, I don't think we can consider
>> this patch further for this CommitFest and will update
>> commitfest.postgresql.org accordingly.
>
> FWIW, I am very excited about this patch and would be happy to review
>
On Mon, 2010-02-01 at 12:01 -0800, Nathan Boley wrote:
> > On the basis of all of the foregoing, I don't think we can consider
> > this patch further for this CommitFest and will update
> > commitfest.postgresql.org accordingly.
>
> FWIW, I am very excited about this patch and would be happy to re
> On the basis of all of the foregoing, I don't think we can consider
> this patch further for this CommitFest and will update
> commitfest.postgresql.org accordingly.
FWIW, I am very excited about this patch and would be happy to review
it but have been very busy over the past month. If I can pro
On Mon, Feb 1, 2010 at 2:03 PM, Tom Lane wrote:
> Robert Haas writes:
>> Oh, one other thing. Should we backpatch this, or just apply to HEAD?
>
> Just HEAD imo. Without any complaints from the field, I don't think
> it's worth taking any risks for. It's not like multiple inheritance
> is heav
On Fri, 2010-01-29 at 15:01 +, Simon Riggs wrote:
> Putting it back takes time and
> given enough of that rare cloth, it will eventually be put back.
Looks like I'll have time to add the starts-at-shutdown-checkpoint item
back in after all.
I'd appreciate it if you could review the relation-
On Feb 1, 2010, at 11:29 AM, Joshua D. Drake wrote:
> On Mon, 2010-02-01 at 13:20 -0500, Robert Haas wrote:
>
>> On the basis of all of the foregoing, I don't think we can consider
>> this patch further for this CommitFest and will update
>> commitfest.postgresql.org accordingly. If the user com
On Feb 1, 2010, at 10:53 AM, Tom Lane wrote:
> The first thought that comes to mind is "plpythonng", following a
> tradition established by the tcl client rewrite among others ... but
> that double n doesn't read very well.
And without it, you have a thong. Who's going to wear that?
Best,
David
Robert Haas writes:
> Oh, one other thing. Should we backpatch this, or just apply to HEAD?
Just HEAD imo. Without any complaints from the field, I don't think
it's worth taking any risks for. It's not like multiple inheritance
is heavily used ...
regards, tom lane
--
On Jan 31, 2010, at 22:14 , Tom Lane wrote:
The Tcl folk accepted that patch, so I went ahead and applied it to
our code. It would still be a good idea for us to do any testing we
can on it, though.
I applied the patch and ran both the test query I submitted as well as
original problematic
On Mon, Feb 1, 2010 at 2:00 PM, Alvaro Herrera
wrote:
> Tom Lane escribió:
>
>> The first thought that comes to mind is "plpythonng", following a
>> tradition established by the tcl client rewrite among others ... but
>> that double n doesn't read very well.
>
> plpythoNG perhaps?
ROFL. It's a s
Tom Lane escribió:
> The first thought that comes to mind is "plpythonng", following a
> tradition established by the tcl client rewrite among others ... but
> that double n doesn't read very well.
plpythoNG perhaps?
--
Alvaro Herrerahttp://www.CommandPrompt.com/
On Mon, Feb 1, 2010 at 1:40 PM, Robert Haas wrote:
>> Looks sane otherwise.
>
> Thanks for the review.
Oh, one other thing. Should we backpatch this, or just apply to HEAD?
...Robert
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
ht
Robert Haas writes:
> To recap the votes I've seen on this thread and elsewhere:
> - JD is very enthusiastic about this patch
> - So is the OP
> - Josh Berkus and I are both dubious about having two in-core PL/pythons
> - Peter Eisentraut prefers the original implementation
> - Greg Smith thinks
2010/2/1 Robert Haas :
> On Mon, Feb 1, 2010 at 11:41 AM, Tom Lane wrote:
>> Robert Haas writes:
>>> On Mon, Feb 1, 2010 at 11:28 AM, Tom Lane wrote:
* A sends a message
* B replies, cc'ing A and the list
* B's reply to list is delayed by greylisting
On Mon, Feb 1, 2010 at 1:38 PM, Tom Lane wrote:
> Robert Haas writes:
>> My feeling is that if it's as flakey and unreliable as it currently
>> is, we shouldn't ship it. Removing it from CVS doesn't mean "you
>> can't use this any more"; this is open source. It just means people
>> will have to
On Mon, Feb 1, 2010 at 1:31 PM, Tom Lane wrote:
> Robert Haas writes:
>> I have cleaned up and simplified this patch. Attached is the version
>> I intend to commit. Changes:
>
> Minor suggestions:
>
> I think the names like "rel_parents" would read better as
> "rel_numparents" etc. As-is, the
On Mon, Feb 1, 2010 at 1:29 PM, Joshua D. Drake wrote:
> On Mon, 2010-02-01 at 13:20 -0500, Robert Haas wrote:
>> On the basis of all of the foregoing, I don't think we can consider
>> this patch further for this CommitFest and will update
>> commitfest.postgresql.org accordingly. If the user com
Robert Haas writes:
> My feeling is that if it's as flakey and unreliable as it currently
> is, we shouldn't ship it. Removing it from CVS doesn't mean "you
> can't use this any more"; this is open source. It just means people
> will have to go and get an old copy out of CVS and presumably in so
Robert Haas writes:
> I have cleaned up and simplified this patch. Attached is the version
> I intend to commit. Changes:
Minor suggestions:
I think the names like "rel_parents" would read better as
"rel_numparents" etc. As-is, the reader could be forgiven for expecting
that this will be a li
On Mon, 2010-02-01 at 13:20 -0500, Robert Haas wrote:
> On the basis of all of the foregoing, I don't think we can consider
> this patch further for this CommitFest and will update
> commitfest.postgresql.org accordingly. If the user community grows or
> if one of the committers takes an interest
On Thu, Jan 28, 2010 at 5:41 PM, Tom Lane wrote:
> Andrew Dunstan writes:
>> Robert Haas wrote:
>>> I think we need to either (1) fix the bugs and update the
>>> documentation to remove the statement that this will be removed or (2)
>>> actually remove it.
>
>> I agree it's a mess but I don't thi
On Mon, Feb 1, 2010 at 1:20 PM, M Z wrote:
> Is there a way to fix it so that those functions are usable in 8.4 without
> crashing the server?
Nobody seems to be interested enough to figure that out and submit a
patch to fix it. If someone does, I think it would have a good chance
of being accep
On Sat, Jan 23, 2010 at 3:28 PM, James William Pye wrote:
> On Jan 14, 2010, at 7:08 PM, Greg Smith wrote:
>> So more targeted examples like you're considering now would help.
>
> Here's the trigger example which should help reveal some of the advantages of
> "native typing". This is a generic tr
Is there a way to fix it so that those functions are usable in 8.4 without
crashing the server?
Thanks,
M Z
On Mon, Feb 1, 2010 at 10:50 AM, Robert Haas wrote:
> The functions haven't actually been removed in 8.4, in spite of the
> deprecation notice. But it's very easy to use them in a way th
2010/1/31 KaiGai Kohei :
> The attached patch modified find_all_inheritors() to return the list of
> expected inhcount, if List * pointer is given. And, it focuses on only
> the bugs in renameatt() case.
I have cleaned up and simplified this patch. Attached is the version
I intend to commit. Cha
On Mon, Feb 1, 2010 at 12:12 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Mon, Feb 1, 2010 at 11:53 AM, Tom Lane wrote:
>>> This needs to be damped down a bit. It should not print useless
>>> non-information in cases where the plan wasn't actually run.
>>> Please compare show_sort_info.
>
>>
On Mon, 2010-02-01 at 17:50 +0200, Heikki Linnakangas wrote:
> Umm, so why not run the deadlock check immediately in
> max_standby_delay=-1 case as well? Why is that case handled differently
> from max_standby_delay>0 case?
Done, tested, working.
Will commit tomorrow if no further questions or c
On Mon, Feb 01, 2010 at 10:46:10AM -0500, Robert Haas wrote:
> On Mon, Feb 1, 2010 at 5:58 AM, Tim Bunce wrote:
> > p.s. If there is interest in defining a documented API (for DBAs to
> > control what gets loaded into Safe and shared with it) for *9.0*
> > then that could be worked on, once this p
Robert Haas writes:
> On Mon, Feb 1, 2010 at 11:28 AM, Tom Lane wrote:
>>* A sends a message
>>* B replies, cc'ing A and the list
>>* B's reply to list is delayed by greylisting
>>* A replies to B's reply (cc'ing list)
>>* A's reply goes through immediately
On Mon, Feb 1, 2010 at 11:41 AM, Tom Lane wrote:
> Robert Haas writes:
>> On Mon, Feb 1, 2010 at 11:28 AM, Tom Lane wrote:
>>> * A sends a message
>>> * B replies, cc'ing A and the list
>>> * B's reply to list is delayed by greylisting
>>> * A replies to B's reply (cc
On Mon, Feb 1, 2010 at 11:28 AM, Tom Lane wrote:
> Matteo Beccati writes:
>> My main concern is that we'd need to overcomplicate the thread detection
>> algorithm so that it better deals with delayed messages: as it currently
>> works, the replies to a missing message get linked to the
>> "grand-
Matteo Beccati writes:
> My main concern is that we'd need to overcomplicate the thread detection
> algorithm so that it better deals with delayed messages: as it currently
> works, the replies to a missing message get linked to the
> "grand-parent". Injecting the missing message afterwards wil
Magnus Hagander writes:
> Here's what I came up with. Works well on the platforms I've tried,
> but I haven't tried on a non-ipv6 capable one yet (need to find one..)
Hmm, well, I have an ipv6-ignorant HPUX box at hand. I do not have a
radius server though. Are you only concerned about whether
"IP" writes:
> I've got a question related to new feature in 8.5alpha, i.e. "Allow
> parentheses around the query expression that follows a WITH clause". What
> does that mean in fact? I can't see any difference between 8.4.2 and
> 8.5alpha3 on Solaris x86.
That entry should not be in the alph
Fujii Masao writes:
> On Mon, Feb 1, 2010 at 7:27 PM, Heikki Linnakangas
> wrote:
>> Fujii Masao wrote:
>>> The cause of the problem seems to be the new heap created by
>>> rebuild_relation() and copy_heap_data(), i.e., new VACUUM FULL.
>>> Since it's not a temporary heap, its rd_istemp is off. O
On Mon, 2010-02-01 at 17:50 +0200, Heikki Linnakangas wrote:
> Simon Riggs wrote:
> > On Mon, 2010-02-01 at 09:40 +0200, Heikki Linnakangas wrote:
> >> Simon Riggs wrote:
> >>> The way this would work is if Startup waits on a buffer pin we
> >>> immediately send out a request to all backends to can
On Mon, 2010-02-01 at 10:27 -0500, Tom Lane wrote:
> Simon Riggs writes:
> > On Mon, 2010-02-01 at 10:06 -0500, Tom Lane wrote:
> >> the assumption that the file is less than one disk block,
> >> it should be just as atomic as pg_control updates are.
>
> > IIRC there were 173 relations affected b
On Sun, Jan 31, 2010 at 4:00 PM, HX Zheng wrote:
> We have a huge system based on PostgreSQL with xml2 functions. From the
> PostgreSQL 8.4 documentation F.38.1. Deprecation notice, it looks like those
> functions are removed. However, our solution is very huge, and heavily
> depends on them.
The
Simon Riggs wrote:
> On Mon, 2010-02-01 at 09:40 +0200, Heikki Linnakangas wrote:
>> Simon Riggs wrote:
>>> The way this would work is if Startup waits on a buffer pin we
>>> immediately send out a request to all backends to cancel themselves if
>>> they are holding the buffer pin required && waiti
On Mon, Feb 1, 2010 at 5:58 AM, Tim Bunce wrote:
> p.s. If there is interest in defining a documented API (for DBAs to
> control what gets loaded into Safe and shared with it) for *9.0*
> then that could be worked on, once this pach is in, ready for the
> next commitfest.
This is the last CommitF
Heikki Linnakangas writes:
> Tom Lane wrote:
>> The other problem with what you sketch is that it'd require holding the
>> mapfile write lock across commit, because we still have to have strict
>> serialization of updates.
> Why is the strict serialization of updates needed? To avoid overwriting
On Sun, Jan 31, 2010 at 10:29 PM, Takahiro Itagaki
wrote:
> Applied with some editorialization. Please check the docs are good enough.
Looks pretty good. I have committed a couple very minor adjustments.
...Robert
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make c
Tom Lane wrote:
> That seems too fragile to me, as I don't find it a stretch at all to
> think that writing the map file might fail --- just think Windows
> antivirus code :-(. Now, once we have written the WAL record for
> the mapfile change, we can't really afford a failure in my approach
> eith
Simon Riggs writes:
> On Mon, 2010-02-01 at 10:06 -0500, Tom Lane wrote:
>> the assumption that the file is less than one disk block,
>> it should be just as atomic as pg_control updates are.
> IIRC there were 173 relations affected by this. 4 bytes each we would
> have more than 512 bytes.
Wher
On Mon, 2010-02-01 at 10:06 -0500, Tom Lane wrote:
> the assumption that the file is less than one disk block,
> it should be just as atomic as pg_control updates are.
IIRC there were 173 relations affected by this. 4 bytes each we would
have more than 512 bytes.
ISTM you need to treat some of t
Greg Stark writes:
> Does this create a problem combined with the plan to allow the new
> VACUUM FULL to rewrite system tables? From my brief scan it sounds
> like the only reason there's no race condition here is that previously
> the oid of system tables couldn't change out from under
> load_cri
Greg Stark writes:
> On Mon, Feb 1, 2010 at 8:54 AM, Simon Riggs wrote:
>>> Disallow catalog relocation inside subtransactions, to avoid having
>>> to handle subxact abort effects on the local-map-changes state.
>>> This could be implemented if desired, but doesn't seem worth it
>>> at least in f
Heikki Linnakangas writes:
> Tom Lane wrote:
>> Once the updated map file is moved into place, the relocation is effectively
>> committed even if we subsequently abort the transaction. We can make that
>> window pretty narrow but not remove it completely.
> We could include the instructions to u
On Wed, Jan 13, 2010 at 7:27 PM, Tom Lane wrote:
> So basically what this boils down to is that load_critical_index is
> locking an index before locking its underlying relation, which generally
> speaking is against our coding rules. The relcache code has been like
> that since 8.2, so I'm a bit
2010/2/1 Matteo Beccati :
> On 01/02/2010 15:03, Magnus Hagander wrote:
>>
>> 2010/2/1 Matteo Beccati:
>>>
>>> My main concern is that we'd need to overcomplicate the thread detection
>>> algorithm so that it better deals with delayed messages: as it currently
>>> works, the replies to a missing
On 01/02/2010 15:03, Magnus Hagander wrote:
2010/2/1 Matteo Beccati:
My main concern is that we'd need to overcomplicate the thread detection algorithm so
that it better deals with delayed messages: as it currently works, the replies to a
missing message get linked to the "grand-parent". Injec
2010/2/1 Matteo Beccati :
> On 01/02/2010 10:26, Magnus Hagander wrote:
>>
>> Does the MBOX importer support incremental loading? Because majordomo
>> spits out MBOX files for us already.
>
> Unfortunately the aoximport shell command doesn't support incremental loading.
>
>> One option could be to
On 1 February 2010 13:40, Pavel Stehule wrote:
> 2010/2/1 Thom Brown :
> > I noticed that the regression test results don't include the following
> case:
> >
> > select string_agg(a) from (values(null),(null)) g(a);
> >
> > There is one similar where a delimiter is provided.
> >
> > Which leads m
2010/2/1 Thom Brown :
> I noticed that the regression test results don't include the following case:
>
> select string_agg(a) from (values(null),(null)) g(a);
>
> There is one similar where a delimiter is provided.
>
> Which leads me to ask for clarification, would it be safe to assume that
> strin
On 01/02/2010 10:26, Magnus Hagander wrote:
Does the MBOX importer support incremental loading? Because majordomo
spits out MBOX files for us already.
Unfortunately the aoximport shell command doesn't support incremental
loading.
One option could be to use SMTP with a subscription as the pr
2010/1/28 Magnus Hagander :
> On Thu, Jan 28, 2010 at 21:16, Tom Lane wrote:
>> Magnus Hagander writes:
>>> On Thu, Jan 28, 2010 at 17:16, Tom Lane wrote:
However, now that I know the real issue is you're using inet_addr, I
would like to know why you're not using inet_aton instead; or
Magnus Hagander wrote:
Did those two members produce consistent issues? Can you give them a
couple of kicks to get enough buidls out of them to figure out if this
solved the problem?
Not very easily. I am currently travelling. It was happening fairly
consistently on red_bat and seems to
I've got a question related to new feature in 8.5alpha, i.e. "Allow parentheses
around the query expression that follows a WITH clause". What does that mean in
fact? I can't see any difference between 8.4.2 and 8.5alpha3 on Solaris x86.
1 - 100 of 127 matches
Mail list logo
