On Wed, Mar 7, 2012 at 2:05 AM, Dan Ports wrote:
> While mucking around in src/backend/utils/time/tqual.c today, I noticed
> the following comment attached to HeapTupleSatisfiesNow:
>
> * mao says 17 march 1993: the tests in this routine are correct;
> * if you think they're not, you'
On Wed, Mar 7, 2012 at 5:32 AM, Tom Lane wrote:
> What I suggest is that it should not be necessary to crawl forward one
> page at a time to figure out how many pages will be needed to store N
> bytes worth of WAL data. You're basically implementing a division
> problem as repeated subtraction.
Hello, this is new version of the patch.
# early_exit.diff is not included for this time and maybe also
# later. The set of the return values of PQrowProcessor looks
# unnatural if the 0 is removed.
> * Convert old EOFs to protocol errors in V3 getAnotherTuple()
done.
> * V2 getAnotherTuple()
Hello
I found one small issue where Query was not forwarded when trigger
record was broken. I had to append "context" forwarding.
Regards
Pavel
2012/3/6 Pavel Stehule :
> Hello
>
> there is new version
>
> * fixed small formatting issues related to drop SPI call
> * long functions was divided
>
Hello
Robert, please, can you comment to this issue? And other, please. I am
able to fix syntax to any form where we will have agreement.
Regards
Pavel
2012/3/6 Pavel Stehule :
> Hello
>
>>
>> When I try to look on some multicheck form:
>>
>> a) CHECK FUNCTION ALL ON table_name
>> b) CHECK TRIG
While mucking around in src/backend/utils/time/tqual.c today, I noticed
the following comment attached to HeapTupleSatisfiesNow:
* mao says 17 march 1993: the tests in this routine are correct;
* if you think they're not, you're wrong, and you should think
* about it again. i k
Hello,
Nevertheless, the problem that exit from parseInput() caused by
non-zero return of getAnotherTuple() results in immediate
re-enter into getAnotherTuple() via parseInput() and no other
side effect is still there. But I will do that in the next patch,
though.
> So now I convinced that the wh
Hello,
> But I don't understand how to secure the rows (or table data)
> fully loaded at the point of getAnotherTuple called...
I found how pqParseInput ensures the entire message is loaded
before getAnotherTuple called.
fe-protocol3.c:107
| avail = conn->inEnd - conn->inCursor;
| if (avail
Shigeru Hanada writes:
> Attached patches also contains changes to catch up to the redesign of
> PlanForeignScan.
I started to look at this patch, which soon led me back to the
prerequisite patch fdw_helper_v5.patch (that is the last version you
posted of that one, right?). I can see the value o
On Tue, Mar 6, 2012 at 3:31 PM, Andrew Dunstan wrote:>
> We don't slavishly need to reproduce every piece of cron. In any case, on my
> Linux machine at least, batch is part of the "at" package, not the "cron"
> package. If you want anything at all done, then I'd suggest starting with a
> simple s
On 03/06/2012 06:12 PM, Christopher Browne wrote:
On Tue, Mar 6, 2012 at 5:01 PM, Alvaro Herrera
wrote:
Why do we need a ticker? Just fetch the time of the task closest in the
future, and sleep till that time or a notify arrives (meaning schedule
change).
Keep in mind that cron functionali
On 6 March 2012 21:18, Thom Brown wrote:
> On 6 March 2012 21:04, Dimitri Fontaine wrote:
[CASCADE will not run the command triggers for cascaded objects]
>>> If these are all expected, does it in any way compromise the
>>> effectiveness of DDL triggers in major use-cases?
>>
>> I don't thin
On Tue, Mar 6, 2012 at 5:01 PM, Alvaro Herrera
wrote:
> Why do we need a ticker? Just fetch the time of the task closest in the
> future, and sleep till that time or a notify arrives (meaning schedule
> change).
Keep in mind that cron functionality also includes "batch", which
means that the pro
Alvaro Herrera writes:
> I was thinking that the connection would be kept open but no query would
> be running. Does this preclude reception of notifies? I mean, you
> don't sleep via "SELECT pg_sleep()" but rather a select/poll in the
> daemon.
No. If you're not inside a transaction, notifies
Excerpts from Merlin Moncure's message of mar mar 06 19:07:51 -0300 2012:
>
> On Tue, Mar 6, 2012 at 4:01 PM, Alvaro Herrera
> wrote:
> > Why do we need a ticker? Just fetch the time of the task closest in the
> > future, and sleep till that time or a notify arrives (meaning schedule
> > change
On Tue, Mar 6, 2012 at 4:01 PM, Alvaro Herrera
wrote:
> Why do we need a ticker? Just fetch the time of the task closest in the
> future, and sleep till that time or a notify arrives (meaning schedule
> change).
Because that can't be done in userland (at least, not without stored
procedures) sin
Excerpts from Dimitri Fontaine's message of mar mar 06 18:44:18 -0300 2012:
> Josh Berkus writes:
> > Activity and discretion beyond that could be defined in PL code,
> > including run/don't run conditions, activities, and dependancies. The
> > only thing Postgres doesn't currently have is a clo
On Tue, Mar 6, 2012 at 3:44 PM, Dimitri Fontaine wrote:
> Josh Berkus writes:
>> Activity and discretion beyond that could be defined in PL code,
>> including run/don't run conditions, activities, and dependancies. The
>> only thing Postgres doesn't currently have is a clock which fires
>> event
Hello
there is new version
* fixed small formatting issues related to drop SPI call
* long functions was divided
* CREATE TRIGGER ALL ON table support
Regards
Pavel
check_function-2012-03-06-3.patch.gz
Description: GNU Zip compressed data
--
Sent via pgsql-hackers mailing list (pgsql-hacker
On Tue, Mar 6, 2012 at 4:35 PM, Jeff Janes wrote:
> I don't think reseting the stats has anything to do with it, it is
> just that the shared_buffers warmed up over time.
Yes.
> On my testing, this dirty-before-evict is because the bgwriter is
> riding too far ahead of the clock sweep, because o
On tis, 2012-03-06 at 16:15 -0500, Robert Haas wrote:
> On Tue, Mar 6, 2012 at 3:28 PM, Peter Eisentraut wrote:
> > On mån, 2012-03-05 at 19:37 -0500, Bruce Momjian wrote:
> >> The exact case is that the user was using plpython2u in PG 9.0, but
> >> the PG 9.1 one-click installer only supplies plp
Josh Berkus writes:
> Activity and discretion beyond that could be defined in PL code,
> including run/don't run conditions, activities, and dependancies. The
> only thing Postgres doesn't currently have is a clock which fires
> events. Anything we try to implement which is more complex than the
On Tue, Mar 6, 2012 at 4:27 PM, Alvaro Herrera
wrote:
> Excerpts from Robert Haas's message of mar mar 06 18:10:16 -0300 2012:
>>
>> Preliminary comment:
>>
>> This README is very helpful.
>
> Thanks. I feel silly that I didn't write it earlier.
>
>> On Tue, Mar 6, 2012 at 2:39 PM, Alvaro Herrera
On Tue, Feb 28, 2012 at 9:49 AM, Robert Haas wrote:
> On Tue, Feb 28, 2012 at 11:46 AM, Robert Haas wrote:
>>
>> This is an interesting hypothesis which I think we can test. I'm
>> thinking of writing a quick patch (just for testing, not for commit)
>> to set a new buffer flag BM_BGWRITER_CLEANE
On Tue, Mar 6, 2012 at 9:10 PM, Robert Haas wrote:
> Preliminary comment:
>
> This README is very helpful.
>
> On Tue, Mar 6, 2012 at 2:39 PM, Alvaro Herrera
> wrote:
>> We provide four levels of tuple locking strength: SELECT FOR KEY UPDATE is
>> super-exclusive locking (used to delete tuples an
Tom Lane writes:
> This might be something to consider in the adjacent thread about command
> triggers, too --- who do they run as, and if it's not the calling user,
> how do they find out who that is?
As of now, calling user (we just calling a function), or another user if
the function is SECURI
On Tue, Mar 6, 2012 at 2:11 PM, Tom Lane wrote:
> Robert Haas writes:
>> I would dismissed this out of hand at this if you said it a year ago,
>> but I'm older and wiser now. At some point this cycle, I did some
>> benchmarking of the subtransaction abort path, since the slowness of
>> things li
Excerpts from Robert Haas's message of mar mar 06 18:10:16 -0300 2012:
>
> Preliminary comment:
>
> This README is very helpful.
Thanks. I feel silly that I didn't write it earlier.
> On Tue, Mar 6, 2012 at 2:39 PM, Alvaro Herrera
> wrote:
> > We provide four levels of tuple locking strength
Marko Kreen writes:
> On Tue, Mar 06, 2012 at 11:10:38AM -0500, Tom Lane wrote:
>> Why would you need to know that? The reason the calculation function
>> is static is that there's no apparent need to expose that information
>> outside the syscache subsystem.
> Because I need to invalidate my ow
Tatsuo Ishii writes:
> I'm working on implementing query cache in pgpool-II. I want to know
> if a table has been modified because pgpool-II has to invalidate cache
> if corresponding table is modified. For DDL/DML it would be doable
> since pgpool-II knows all SQLs sent from clients. Problem is,
On 6 March 2012 21:04, Dimitri Fontaine wrote:
>>> [CASCADE will not run the command triggers for cascaded objects]
>> If these are all expected, does it in any way compromise the
>> effectiveness of DDL triggers in major use-cases?
>
> I don't think so. When replicating the replica will certainl
On Tue, Mar 6, 2012 at 3:28 PM, Peter Eisentraut wrote:
> On mån, 2012-03-05 at 19:37 -0500, Bruce Momjian wrote:
>> The exact case is that the user was using plpython2u in PG 9.0, but
>> the PG 9.1 one-click installer only supplies plpython3u.
>
> That seems like a pretty stupid choice to me, if
Preliminary comment:
This README is very helpful.
On Tue, Mar 6, 2012 at 2:39 PM, Alvaro Herrera
wrote:
> We provide four levels of tuple locking strength: SELECT FOR KEY UPDATE is
> super-exclusive locking (used to delete tuples and more generally to update
> tuples modifying the values of the
Martin Pihlak writes:
> Updated patch attached.
Applied with minor editorialization (mainly just improving the
comments).
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.
Heikki Linnakangas writes:
> On 06.03.2012 17:12, Tom Lane wrote:
>> How long is the current locked code exactly --- does it contain a loop?
> Perhaps best if you take a look for yourself, the function is called
> ReserveXLogInsertLocation() in patch. It calls a helper function called
> Advan
On Tue, Mar 06, 2012 at 07:09:23PM +, Simon Riggs wrote:
> The problem is actually on/off/crash/on in quick succession which is
>> much less likely.
I must be missing something, but how about:
if (!has_checksums && page_loses_checksum_due_to_hint_bit_write)
wal_log_the_hint_bit_write();
On mån, 2012-03-05 at 19:37 -0500, Bruce Momjian wrote:
> The exact case is that the user was using plpython2u in PG 9.0, but
> the PG 9.1 one-click installer only supplies plpython3u.
That seems like a pretty stupid choice to me, if it's true.
That doesn't address your issue, but users shouldn't
On Tue, Mar 6, 2012 at 7:39 PM, Alvaro Herrera
wrote:
> We provide four levels of tuple locking strength: SELECT FOR KEY UPDATE is
> super-exclusive locking (used to delete tuples and more generally to update
> tuples modifying the values of the columns that make up the key of the tuple);
> SELEC
On Tue, Mar 6, 2012 at 12:50 PM, Bruce Momjian wrote:
> I think the "turning checksums on/off/on/off" is really a killer
> problem, and obviously many of the actions needed to make it safe make
> the checksum feature itself less useful.
>
> One crazy idea would be to have a checksum _version_ numb
On Mon, Mar 5, 2012 at 8:35 PM, Simon Riggs wrote:
>>> * Why do we need multixact to be persistent? Do we need every page of
>>> multixact to be persistent, or just particular pages in certain
>>> circumstances?
>>
>> Any page that contains at least one multi with an update as a member
>> must pe
Excerpts from Simon Riggs's message of lun mar 05 16:34:10 -0300 2012:
> It does however, illustrate my next review comment which is that the
> comments and README items are sorely lacking here. It's quite hard to
> see how it works, let along comment on major design decisions. It
> would help my
On Tue, Mar 06, 2012 at 11:10:38AM -0500, Tom Lane wrote:
> Marko Kreen writes:
> > So my question is that after doing generic SearchSysCache() like:
>
> >tup = SearchSysCache(USERMAPPINGUSERSERVER,
> > ObjectIdGetDatum(user_mapping->userid),
> > ObjectIdGetDatum(foreign_serve
On 06.03.2012 17:12, Tom Lane wrote:
Heikki Linnakangas writes:
On 06.03.2012 14:52, Fujii Masao wrote:
This also strikes me that the usage of the spinlock insertpos_lck might
not be OK in ReserveXLogInsertLocation() because a few dozen instructions
can be performed while holding the spinlock.
On Tue, Mar 06, 2012 at 07:09:23PM +, Simon Riggs wrote:
> On Tue, Mar 6, 2012 at 5:56 PM, Bruce Momjian wrote:
> > On Mon, Mar 05, 2012 at 03:03:18PM +, Simon Riggs wrote:
> >> To avoid any confusion as to where this proposed feature is now, I'd
> >> like to summarise my understanding, ma
On Tue, Mar 06, 2012 at 01:52:31PM -0500, Bruce Momjian wrote:
> On Tue, Mar 06, 2012 at 06:00:13PM +, Simon Riggs wrote:
> > On Tue, Mar 6, 2012 at 5:50 PM, Bruce Momjian wrote:
> >
> > > One crazy idea would be to have a checksum _version_ number somewhere on
> > > the page and in pg_contro
On Tue, Mar 6, 2012 at 5:56 PM, Bruce Momjian wrote:
> On Mon, Mar 05, 2012 at 03:03:18PM +, Simon Riggs wrote:
>> To avoid any confusion as to where this proposed feature is now, I'd
>> like to summarise my understanding, make proposals and also request
>> clear feedback on them.
>>
>> Checks
Robert Haas writes:
> I would dismissed this out of hand at this if you said it a year ago,
> but I'm older and wiser now. At some point this cycle, I did some
> benchmarking of the subtransaction abort path, since the slowness of
> things like EXCEPTION blocks in PL/pgsql is a known sore point.
>> It seems to me that the only thing that needs core support is the
>> ability to start up the daemon when postmaster is ready to accept
>> queries, and shut the daemon down when postmaster kills backends (either
>> because one crashed, or because it's shutting down).
I think this could be addre
Hi,
I've noticed a locale-specific bug in regression tests, I discovered
thanks to the new "magpie" buildfarm member (testing "cs_CZ" locale).
The problem is in "foreign_data" where the output is sorted by a column,
and "cs_CZ" behaves differently from "C" and "en_US".
More precisely, in "C" it's
On Tue, Mar 06, 2012 at 06:00:13PM +, Simon Riggs wrote:
> On Tue, Mar 6, 2012 at 5:50 PM, Bruce Momjian wrote:
>
> > One crazy idea would be to have a checksum _version_ number somewhere on
> > the page and in pg_controldata. When you turn on checksums, you
> > increment that value, and all
Peter Eisentraut writes:
> On tor, 2012-03-01 at 20:56 +0900, Shigeru Hanada wrote:
>> How about moving postgresql_fdw_validator into dblink,
> That's probably a good move. If this were C++, we might try to subclass
> this whole thing a bit, to avoid code duplication, but I don't see an
> easy w
On Tue, Mar 6, 2012 at 1:14 PM, Alvaro Herrera
wrote:
>
> It seems to me that the only thing that needs core support is the
> ability to start up the daemon when postmaster is ready to accept
> queries, and shut the daemon down when postmaster kills backends (either
> because one crashed, or becau
On Tue, Mar 6, 2012 at 12:47 PM, Robert Haas wrote:
> And also some interface. It'd be useful to have background jobs that
> executed either immediately or at a certain time or after a certain
> delay, as well as repeating jobs that execute at a certain interval or
> on a certain schedule. Figur
On Tue, Mar 6, 2012 at 9:37 AM, Robert Haas wrote:
>> But having said that, it's not apparent to me why such a thing would
>> need to live "inside the database" at all. It's very easy to visualize
>> a task scheduler that runs as a client and requires nothing new from the
>> core code. Approachi
Excerpts from Pavel Stehule's message of mar mar 06 14:57:30 -0300 2012:
> 2012/3/6 Robert Haas :
> > On Tue, Mar 6, 2012 at 12:37 PM, Christopher Browne
> > wrote:
> >> On Tue, Mar 6, 2012 at 12:20 PM, Artur Litwinowicz wrote:
> >>> Algorithm for first loop:
> >>> check jobs exists and is time
Robert Haas writes:
> That's not why I want to leave that field alone, though: I want to
> leave that field alone for backward and forward compatibility, so that
> any version of community PostgreSQL ever released - and any page
> inspection tools, current or future - can look at the low-order byt
On Tue, Mar 6, 2012 at 5:50 PM, Bruce Momjian wrote:
> One crazy idea would be to have a checksum _version_ number somewhere on
> the page and in pg_controldata. When you turn on checksums, you
> increment that value, and all new checksum pages get that checksum
> version; if you turn off check
2012/3/6 Robert Haas :
> On Tue, Mar 6, 2012 at 12:37 PM, Christopher Browne
> wrote:
>> On Tue, Mar 6, 2012 at 12:20 PM, Artur Litwinowicz wrote:
>>> Algorithm for first loop:
>>> check jobs exists and is time to run it
>>> run job as other sql statements (some validity check may be done)
>>>
On Mon, Mar 05, 2012 at 03:03:18PM +, Simon Riggs wrote:
> To avoid any confusion as to where this proposed feature is now, I'd
> like to summarise my understanding, make proposals and also request
> clear feedback on them.
>
> Checksums have a number of objections to them outstanding.
>
> 1.
On Tue, Mar 06, 2012 at 09:25:17AM -0500, Robert Haas wrote:
> > 2. Turning checksums on/off/on/off in rapid succession can cause false
> > positive reports of checksum failure if crashes occur and are ignored.
> > That may lead to the feature and PostgreSQL being held in disrepute.
>
> This I do
On Tue, Mar 6, 2012 at 12:37 PM, Christopher Browne wrote:
> On Tue, Mar 6, 2012 at 12:20 PM, Artur Litwinowicz wrote:
>> Algorithm for first loop:
>> check jobs exists and is time to run it
>> run job as other sql statements (some validity check may be done)
>> get next job
>> no jobs - dela
On Tue, Mar 6, 2012 at 12:23 PM, Simon Riggs wrote:
> On Tue, Mar 6, 2012 at 5:14 PM, Robert Haas wrote:
>>> Options
>>>
>>> (1) Recovery ignores checksums until db in consistent state
>>>
>>> (2) Recovery ignores checksums until all databases are enabled, when
>>> we set flag in pg_control
>>>
>
On Tue, Mar 6, 2012 at 12:20 PM, Artur Litwinowicz wrote:
> Algorithm for first loop:
> check jobs exists and is time to run it
> run job as other sql statements (some validity check may be done)
> get next job
> no jobs - delay
There are crucial things missing here, namely the need to establ
On tis, 2012-03-06 at 10:11 +0200, Alexander Shulgin wrote:
> On 03/06/2012 01:09 AM, Peter Eisentraut wrote:
> >
> > On ons, 2012-02-22 at 12:26 -0500, Greg Smith wrote:
> >> I started collecting up all the variants that do work as an
> >> initial shell script regression test, so that changes don'
On Tue, Mar 6, 2012 at 5:14 PM, Robert Haas wrote:
>> Options
>>
>> (1) Recovery ignores checksums until db in consistent state
>>
>> (2) Recovery ignores checksums until all databases are enabled, when
>> we set flag in pg_control
>>
>> (3) Recovery checks blocks marked as having a checksum, no
On Tue, Mar 6, 2012 at 5:14 PM, Heikki Linnakangas
wrote:
>> Has EDB or anybody else you know of has used the pd_pagesize_version
>> field for something else, so you'd rather I didn't touch that?
>
>
> The EDB page format is exactly the same as the community one. Thanks for
> asking.
No problem,
With all the respect to all into this Community...
I have no experience enough rich with C or C++ to say yes I can do that
alone. I do not know the internals of PostgreSQL at all. But I have
quite long experience with other languages.
I imagine if you have a piece of code which can run function lik
On Tue, Mar 6, 2012 at 11:50 AM, Simon Riggs wrote:
> On Tue, Mar 6, 2012 at 4:06 PM, Simon Riggs wrote:
>> On Tue, Mar 6, 2012 at 3:31 PM, Simon Riggs wrote:
>>
>>> I'll keep an open mind for now about database/table level. I'm not
>>> sure how possible/desirable each is.
>>
>> Table level soun
On 06.03.2012 19:00, Simon Riggs wrote:
On Tue, Mar 6, 2012 at 4:42 PM, Robert Haas wrote:
As to whether we should increment pd_pagesize_version, I'm not sure
quite what you were saying about that (I think you may have an extra
or missing word there), but I don't think it's necessary here.
I
On Tue, Mar 6, 2012 at 12:00 PM, Simon Riggs wrote:
> On Tue, Mar 6, 2012 at 4:42 PM, Robert Haas wrote:
>
>> As to whether we should increment pd_pagesize_version, I'm not sure
>> quite what you were saying about that (I think you may have an extra
>> or missing word there), but I don't think it
On Tue, Mar 6, 2012 at 4:42 PM, Robert Haas wrote:
> As to whether we should increment pd_pagesize_version, I'm not sure
> quite what you were saying about that (I think you may have an extra
> or missing word there), but I don't think it's necessary here.
I said this...
On Tue, Mar 6, 2012 at
On Tue, Mar 6, 2012 at 4:06 PM, Simon Riggs wrote:
> On Tue, Mar 6, 2012 at 3:31 PM, Simon Riggs wrote:
>
>> I'll keep an open mind for now about database/table level. I'm not
>> sure how possible/desirable each is.
>
> Table level sounds great, but how will it work with recovery? We don't
> have
On Tue, Mar 6, 2012 at 10:40 AM, Simon Riggs wrote:
> On Tue, Mar 6, 2012 at 2:25 PM, Robert Haas wrote:
>> For the reasons stated above, I believe pd_tli is less useful than
>> pd_pagesize_version. I fear that if we repurpose pd_pagesize_version,
>> we're going to make things very difficult for
Excerpts from Tom Lane's message of mar mar 06 12:47:46 -0300 2012:
> Robert Haas writes:
> > But since you brought it up, I think there is a lot of value to having
> > a scheduler that's integrated with the database. There are many
> > things that the database does which could also be done out
On Tue, Mar 06, 2012 at 10:38:31AM -0500, Tom Lane wrote:
> Bruce Momjian writes:
> > On Mon, Mar 05, 2012 at 11:38:33PM -0500, Tom Lane wrote:
> >> Well, yeah. The language depends on the support functions, not the
> >> other way around.
>
> > Well, if CREATE LANGUAGE created those functions, i
Marko Kreen writes:
> So my question is that after doing generic SearchSysCache() like:
>tup = SearchSysCache(USERMAPPINGUSERSERVER,
> ObjectIdGetDatum(user_mapping->userid),
> ObjectIdGetDatum(foreign_server->serverid),
> 0, 0);
> what is the proper way to calculate
On Tue, Mar 6, 2012 at 10:31 AM, Simon Riggs wrote:
> On Tue, Mar 6, 2012 at 2:25 PM, Robert Haas wrote:
>> 4. Checksums are being removed, but some blocks may still have them.
>> Thus, it's not an error for a block to have no checksum, but any
>> still-remaining checksums should be correct (thou
On Tue, Mar 6, 2012 at 3:31 PM, Simon Riggs wrote:
> I'll keep an open mind for now about database/table level. I'm not
> sure how possible/desirable each is.
Table level sounds great, but how will it work with recovery? We don't
have a relcache in Startup process.
So either database or tablesp
Robert Haas writes:
> On Tue, Mar 6, 2012 at 10:21 AM, Tom Lane wrote:
>> But having said that, it's not apparent to me why such a thing would
>> need to live "inside the database" at all. It's very easy to visualize
>> a task scheduler that runs as a client and requires nothing new from the
>>
On Tue, Mar 6, 2012 at 2:25 PM, Robert Haas wrote:
> For the reasons stated above, I believe pd_tli is less useful than
> pd_pagesize_version. I fear that if we repurpose pd_pagesize_version,
> we're going to make things very difficult for people who want to write
> block-inspection tools, like
Bruce Momjian writes:
> On Mon, Mar 05, 2012 at 11:38:33PM -0500, Tom Lane wrote:
>> Well, yeah. The language depends on the support functions, not the
>> other way around.
> Well, if CREATE LANGUAGE created those functions, it seems logical that
> DROP FUNCTION removes them. Why is that not a
On Tue, Mar 6, 2012 at 10:21 AM, Tom Lane wrote:
> Robert Haas writes:
>> On Mon, Mar 5, 2012 at 5:03 PM, Artur Litwinowicz wrote:
>>> Regarding a functional area I can help... but I can not understand why
>>> this idea is so unappreciated?
>
>> I think it's a bit unfair to say that this idea is
2012/3/6 Tom Lane :
> Robert Haas writes:
>> On Mon, Mar 5, 2012 at 5:03 PM, Artur Litwinowicz wrote:
>>> Regarding a functional area I can help... but I can not understand why
>>> this idea is so unappreciated?
>
>> I think it's a bit unfair to say that this idea is unappreciated.
>
> Well, ther
Commit b5282aa893:
"Revise sinval code to remove no-longer-used tuple TID from inval messages."
dropped ItemPointer from callbacks and replaced it with "hashValue".
There seems to be 2 ways that new backend code calculates it:
- hashoid(oid), which seems to assume too much?
- CatalogCacheComput
On Tue, Mar 6, 2012 at 2:25 PM, Robert Haas wrote:
> 4. Checksums are being removed, but some blocks may still have them.
> Thus, it's not an error for a block to have no checksum, but any
> still-remaining checksums should be correct (though possibly we ought
> not to complain if they aren't, to
Robert Haas writes:
> On Mon, Mar 5, 2012 at 5:03 PM, Artur Litwinowicz wrote:
>> Regarding a functional area I can help... but I can not understand why
>> this idea is so unappreciated?
> I think it's a bit unfair to say that this idea is unappreciated.
Well, there is the question of why we sh
On Mon, Mar 05, 2012 at 11:38:33PM -0500, Tom Lane wrote:
> Bruce Momjian writes:
> > By doing a DROP CASCADE on plpython2, you drop the user functions, but
> > not the support functions.
>
> Well, yeah. The language depends on the support functions, not the
> other way around.
>
> > This certa
Heikki Linnakangas writes:
> On 06.03.2012 14:52, Fujii Masao wrote:
>> This also strikes me that the usage of the spinlock insertpos_lck might
>> not be OK in ReserveXLogInsertLocation() because a few dozen instructions
>> can be performed while holding the spinlock
> I admit that block is l
On Tue, Mar 6, 2012 at 10:07 AM, Heikki Linnakangas
wrote:
> I admit that block is longer than any of our existing spinlock blocks.
> However, it's important for performance. I tried using a lwlock earlier, and
> that negated the gains. So if that's a serious objection, then let's resolve
> that n
On 06.03.2012 14:52, Fujii Masao wrote:
On Tue, Mar 6, 2012 at 2:17 AM, Tom Lane wrote:
Heikki Linnakangas writes:
On 21.02.2012 13:19, Fujii Masao wrote:
In some places, the spinlock "insertpos_lck" is taken while another
spinlock "info_lck" is being held. Is this OK? What if unfortunately
On Mon, Mar 5, 2012 at 5:03 PM, Artur Litwinowicz wrote:
> Regarding a functional area I can help... but I can not understand why
> this idea is so unappreciated?
I think it's a bit unfair to say that this idea is unappreciated.
There are LOTS of good features that we don't have yet simply becaus
OK, I have removed all *.o and all *.so files - and extension is
succesfully deployed on 9.2
Thanks,
Misa
2012/3/6 Misa Simic
> Hi,
>
> I have made some pg extension for Pg 9.1 and want to deploy it on Pg
> 9.2dev...
>
> When i try create extension it shows error version mismatch server is 9.2
Shigeru Hanada wrote:
>Connection should be closed only when the trigger is a
> top level transaction and it's aborting, but isTopLevel flag was not
> checked. I fixed the bug and added regression tests for such cases.
I wondered about that - is it really necessary to close the re
On Mon, Mar 5, 2012 at 4:40 PM, Larry Rosenman wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Is there any way to get more info out of CLUSTER VERBOSE so it says
> what index it's working on AFTER the table re-write?
>
> INFO: clustering "public.values" using sequential scan and sor
On Mon, Mar 5, 2012 at 5:20 PM, Tomas Vondra wrote:
>> The idea is that buildfarm systems that are known to have a) reasonable
>> hardware and b) no other concurrent work going on could also do
>> performance tests. The main benefit of this approach is it avoids
>> duplicating all of the system m
On Mon, Mar 5, 2012 at 10:03 AM, Simon Riggs wrote:
> 1. We don't need them because there will be something better in a
> later release. I don't think anybody disagrees that a better solution
> is possible in the future; doubts have been expressed as to what will
> be required and when that is lik
On Tue, Mar 6, 2012 at 1:50 AM, Heikki Linnakangas
wrote:
>> + * An xlog-switch record consumes all the remaining space on the
>> + * WAL segment. We have already reserved it for us, but we still
>> need
>> + * to make sure it's been allocated and zeroed in the WAL buffers
>>
Hi, Yeb.
Thanks for your reviewing and patch updates.
(and sorry my delayed response...)
I'd like to point out a case when plabel->label is NULL.
In case of sepgsql_setcon() being invoked with null argument
to reset security label of the client, but not committed yet,
the last item of the client
2012/3/6 Alvaro Herrera :
>
> Excerpts from Pavel Stehule's message of mar mar 06 10:44:09 -0300 2012:
>>
>> 2012/3/6 Alvaro Herrera :
>> >
>> > Excerpts from Pavel Stehule's message of mar mar 06 03:43:06 -0300 2012:
>> >> Hello
>> >>
>> >> * I refreshed regress tests and appended tests for multi
On Tue, Mar 6, 2012 at 5:43 AM, Noah Misch wrote:
>> Now, maybe we're never going to fix those kinds of anomalies anyway,
>> but if we go with this architecture, then I think the chances of it
>> ever being palatable to try are pretty low.
>
> Why?
Because it'll require at least one XID column in
1 - 100 of 114 matches
Mail list logo
