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't break
something that already works. Here are all the variations that
alr
On Tue, Mar 06, 2012 at 11:13:45AM +0900, Kyotaro HORIGUCHI wrote:
> > But it's broken in V3 protocol - getAnotherTuple() will be called
> > only if the packet is fully read. If the packet contents do not
> > agree with packet header, it's protocol error. Only valid EOF
> > return in V3 getAnothe
On Mon, Mar 5, 2012 at 11:29 PM, Josh Berkus wrote:
>
>> 3. Pages with checksums set need to have a version marking to show
>> that they are a later version of the page layout. That version number
>> needs to be extensible to many later versions. Pages of multiple
>> versions need to exist within
Hello
>
> When I try to look on some multicheck form:
>
> a) CHECK FUNCTION ALL ON table_name
> b) CHECK TRIGGER ALL ON table_name
>
> then more natural form is @b (for me). Personally, I can live with
> one, both or second form, although I prefer CHECK TRIGGER.
>
I though some time more.
if som
On Sun, Mar 04, 2012 at 01:02:57PM +, Simon Riggs wrote:
> More detailed thoughts show that the test in heap_beginscan_internal()
> is not right enough, i.e. wrong.
>
> We need a specific XidInMVCCSnapshot test on the relvalidxid, so it
> needs to be a specific xid, not an xmin because otherwi
Shigeru Hanada wrote:
[pgsql_fdw_v12.patch]
I know this is not the latest version, but I played around with it and
tickled a bug.
It seems to have a problem with rolled back subtransactions.
test=> \d+ remote
Foreign table "laurenz.remote"
Column | Type | Modifiers |
On Mon, Mar 05, 2012 at 03:46:16PM -0500, Robert Haas wrote:
> On Mon, Mar 5, 2012 at 2:22 PM, Noah Misch wrote:
> > I can see this strategy applying to many relation-pertinent system catalogs.
> > Do you foresee applications to non-relation catalogs?
>
> Well, in theory, we have similar issues i
On Tue, Mar 06, 2012 at 07:07:41AM +0100, Boszormenyi Zoltan wrote:
> 2012-03-05 19:56 keltez?ssel, Noah Misch ?rta:
> >> Or how about a new feature in the backend, so ECPG can do
> >> UPDATE/DELETE ... WHERE OFFSET N OF cursor
> >> and the offset of computed from the actual cursor position and
On Tue, Mar 6, 2012 at 5:18 PM, Heikki Linnakangas
wrote:
> Remove extra copies of LogwrtResult.
I found one typo. Attached patch fixes that.
Regards,
--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center
*** a/src/backend/access/transam/xlog.c
--- b/src/bac
(2012/03/06 6:19), Tom Lane wrote:
> I've committed the PlanForeignScan API change, with that change and
> some other minor editorialization. The pgsql_fdw patch now needs an
> update, so I set it back to Waiting On Author state.
Thanks.
I've revised pgsql_fdw to catch up to this change, but I'l
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
>>> inner spinlock takes long to
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 lines query
> * There are enhanced checking of SELECT INTO statement
> * I fixed showing details and hints
Oh, I forgot to remove the do_tup_output_slot()
On Tue, Mar 6, 2012 at 7:06 AM, Fujii Masao wrote:
> On Tue, Mar 6, 2012 at 5:18 PM, Heikki Linnakangas
> wrote:
>> Remove extra copies of LogwrtResult.
>
> I found one typo. Attached patch fixes that.
Committed.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQ
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
library has made for 9.1...
How to make library for 9.2?
Thanks,
Misa
Sent from my Windows Phone
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
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
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
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
>>
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 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 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
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
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
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
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 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
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 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
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 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
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
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
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
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 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
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 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
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
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 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
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 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
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 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 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 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 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
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 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,
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 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 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 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: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 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 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.
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 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
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
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
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
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 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
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 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
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
>> 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
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.
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
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 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 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 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
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 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
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 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 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 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();
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
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.
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
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
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
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,
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
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
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
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 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
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 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
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 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
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
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 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
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 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 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
1 - 100 of 114 matches
Mail list logo
