> a) transformation to common type
>
> + simple - it is one day job - function record_to_array,
> array_to_record, and fieldnames_to_array
> - lost of type info, hidden problems with IO cast - int a := 10.0/2.0
> is a problem
>
> using a plperl, pltcl is same like @a
>
I thinking about some simpl
>>
>> What is solution in your design?
>
> nothing specific. My main interest is in the plan management portion
> (only because of side interest in search_path which is complete mess
> at present). if plpgsql_compile knows that it is trigger function and
> which table fired the trigger, you can
On mån, 2010-11-08 at 15:48 -0500, Andrew Dunstan wrote:
> No, and what is more, it runs counter to the philosophy of the
> buildfarm, which is basically to do by automation what a human would
> do by hand in building and testing Postgres.
Yes, but a human would rarely actually do by hand all the
Josh Berkus writes:
> On 11/8/10 5:04 PM, Tom Lane wrote:
>> The extra copying is a bit annoying, since
>> it would add cycles while accomplishing nothing useful for index
>> expressions with no intermediate results, but I'm thinking this is a
>> must-fix.
> I'd say that performance numbers is wh
I don't think that this is a bug exactly, but it seems inconsistent.
See case below. After the item length gets changed, then when reading
the tuple later you get a t_len that includes padding.
We should document in a comment that t_len can mean multiple things. Or,
we should fix raw_heap_insert(
I have started with the work and am using Eclipse and it helps quite a lot.
I can find the declarations quite easily. Thanks to open Source.
BTW, I am encountering too many (just too many) data types as I try to
understand the backend (specifically the executor). I do think that its
normal because
-- Forwarded message --
From: Vaibhav Kaushal
Date: Tue, Nov 9, 2010 at 8:24 AM
Subject: Re: [HACKERS] Which file does the SELECT?
To: Dimitri Fontaine
I have started with the work and am using Eclipse and it helps quite a lot.
I can find the declarations quite easily. Thanks to
Are there any activities in JSON data types for the next commitfest?
I'd like to help you if you are working on the topic,
or I can make up previous works and discussions by myself.
On Mon, Oct 25, 2010 at 1:36 AM, Terry Laurenzo wrote:
>> Yeah, my concern is not whether the overhead will be zer
Alvaro Herrera writes:
> Excerpts from Tom Lane's message of lun nov 08 22:29:28 -0300 2010:
>> I think we need to re-order the operations there to ensure that the
>> unlink will still happen if the ereport gets interrupted.
> Would it work to put the removal inside a PG_CATCH block?
Well, that
On Mon, Nov 1, 2010 at 7:24 PM, Itagaki Takahiro
wrote:
> 1. warning: '' redeclared without dllimport attribute:
> previous dllimport ignored
I discussed with Hiroshi-san about the dllimport issue, and he pointed
out that __declspec(dllexport) and dllwrap cannot work well together.
So, the most s
Excerpts from Tom Lane's message of lun nov 08 22:29:28 -0300 2010:
> Hmm. If you look at FileClose() in fd.c, you'll discover that that
> "temporary file" log message is emitted immediately before unlink'ing
> the file. It looks pretty safe ... but, scratching around, I notice
> that there's a
Michael Glaesemann writes:
> On Nov 8, 2010, at 16:03 , Tom Lane wrote:
>> That's very peculiar. Do you keep query logs? It would be useful to
>> try to correlate the temp files' PIDs and timestamps with the specific
>> queries that must have created them.
> We don't log all of them, but I chec
On 11/8/10 5:04 PM, Tom Lane wrote:
> The extra copying is a bit annoying, since
> it would add cycles while accomplishing nothing useful for index
> expressions with no intermediate results, but I'm thinking this is a
> must-fix.
I'd say that performance numbers is what to check on this. How muc
I looked into the out-of-memory problem reported by Jakub Ouhrabka here:
http://archives.postgresql.org/pgsql-general/2010-11/msg00353.php
It's pretty simple to reproduce, even in HEAD; what you need is an index
expression that computes a bulky intermediate result. His example is
md5(arr
Excerpts from Charles Pritchard's message of lun nov 08 20:25:21 -0300 2010:
> On 11/8/2010 3:03 PM, Alvaro Herrera wrote:
> > Excerpts from Kevin Grittner's message of lun nov 08 19:30:54 -0300 2010:
> >> David Fetter wrote:
> >>
> >>> That's not proof against a DoS
> >>
> >> What client API is?
On Sun, Nov 7, 2010 at 4:13 PM, Greg Smith wrote:
> Jeff Janes wrote:
>
>> Assuming the ordering is useful, the only way the OS can do as good a
>> job as the checkpoint code can, is if the OS stores the entire
>> checkpoint worth of data as dirty blocks and doesn't start writing
>> until an fsync
On Nov 8, 2010, at 3:12 PM, David E. Wheeler wrote:
> It could output a table like the above. FWIW, The function I've written works
> like this:
>
>SELECT plan('SELECT * FROM bar');
Sorry, that's
SELECT * FROM plan('SELECT * FROM bar');
Best,
David
--
Sent via pgsql-hackers mailin
On Nov 7, 2010, at 5:24 AM, Roberto Mello wrote:
> Yes, but I am wondering whether you should just stick to what would
> come out of a normal explain, for consistency sake. Maybe provide
> another function, or parameter that would cast the results to
> intervals?
I think it's more convenient to h
Excerpts from Kevin Grittner's message of lun nov 08 19:30:54 -0300 2010:
> David Fetter wrote:
>
> > That's not proof against a DoS
>
> What client API is?
This spec gives free rein into every web user's system to webmasters.
If this isn't terminally dangerous, I don't know what is.
--
Álv
This is a reminder that at 8.00 a.m. tomorrow morning, my time, or
2010-11-09 13:00 UTC, the buildfarm database server will be migrating to
a brand new 9.0 installation. It will be unavailable for up to about 6
hours.
cheers
andrew
--
Sent via pgsql-hackers mailing list (pgsql-hackers@post
> The patch which I'm proposing is helpful for you?
> http://archives.postgresql.org/pgsql-hackers/2010-11/msg00167.php
Depends. Is that the timestamp on the master (when it was synced), or
the timestamp on the standby (when it was replayed)? It's only helpful
if it's the former.
--
On 2010-11-08 8:30 PM +0200, Tom Lane wrote:
Marko Tiikkaja writes:
On 2010-11-08 7:26 PM +0200, Tom Lane wrote:
The alternative is to artificially serialize the DML CTEs, which
while it does have some advantages doesn't seem like a win overall.
We've discussed this before and the consensus
David Fetter wrote:
> That's not proof against a DoS
What client API is?
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Mon, Nov 08, 2010 at 10:36:16AM -0800, Charles Pritchard wrote:
> On 11/8/2010 7:55 AM, Alvaro Herrera wrote:
> >Excerpts from Charles Pritchard's message of sáb nov 06 23:20:13 -0300 2010:
> >
> >>Simple async sql sub-set (the spec in trouble):
> >>http://dev.w3.org/html5/webdatabase/
> >This i
Excerpts from Andrew Dunstan's message of lun nov 08 18:17:50 -0300 2010:
> I have no idea what's in the standard, but SQLite should be fairly
> PostgreSQL compatible. Its author has told me he used PostgreSQL as a
> template when implementing his SQL dialect.
Starting from the fact that it doe
On Mon, Nov 8, 2010 at 3:21 PM, Pavel Stehule wrote:
> 2010/11/8 Merlin Moncure :
>> On Mon, Nov 8, 2010 at 3:00 PM, Pavel Stehule
>> wrote:
Most cases of this feature are for dealing with new/old from trigger
function right? Why not build a complete new plan for each specific
tr
On 11/08/2010 04:06 PM, David E. Wheeler wrote:
On Nov 8, 2010, at 10:36 AM, Charles Pritchard wrote:
Because of a lack of "interested implementers", the spec does not put forward a
standard dialect/subset. It simply uses Sqlite
As de-facto standards go, you could do *much* worse.
I have
On Nov 8, 2010, at 10:36 AM, Charles Pritchard wrote:
> Because of a lack of "interested implementers", the spec does not put forward
> a standard dialect/subset. It simply uses Sqlite
As de-facto standards go, you could do *much* worse.
David
--
Sent via pgsql-hackers mailing list (pgsql-ha
On 11/08/2010 03:38 PM, Tom Lane wrote:
Peter Eisentraut writes:
On mån, 2010-11-08 at 15:01 -0500, Andrew Dunstan wrote:
First, the buildfarm doesn't build the docs. That's a deliberate
decision, based on the fact that not every member has the required
software installed. And second these
Peter Eisentraut writes:
> On mån, 2010-11-08 at 15:01 -0500, Andrew Dunstan wrote:
>> First, the buildfarm doesn't build the docs. That's a deliberate
>> decision, based on the fact that not every member has the required
>> software installed. And second these targets only exist for 9.0 and/or
On 11/8/2010 7:55 AM, Alvaro Herrera wrote:
Excerpts from Charles Pritchard's message of sáb nov 06 23:20:13 -0300 2010:
Simple async sql sub-set (the spec in trouble):
http://dev.w3.org/html5/webdatabase/
This is insane. This spec allows the server to run arbitrary SQL
commands on the client
BTW, one other point for the archives, before I forget it: it'd probably
also be wise to change the parser's output representation of set
operations. I think it should create a separate RTE entry corresponding
to each SetOperation node, similar to what we do for explicit JOIN
nodes. Then there is
2010/11/8 Merlin Moncure :
> On Mon, Nov 8, 2010 at 3:00 PM, Pavel Stehule wrote:
>>> Most cases of this feature are for dealing with new/old from trigger
>>> function right? Why not build a complete new plan for each specific
>>> trigger that invokes the function, along with some magic values li
Merlin,
Sorry, I don't clearly understand what the problem here, but I just want to
avoid
conversion from record to hstore with suggested API. I am currently happy
with
hstore API to work with record. From the user's point of view :-).
2010/11/8 Merlin Moncure
> On Mon, Nov 8, 2010 at 3:02 PM,
Hello
2010/11/8 Dmitriy Igrishin :
> Hey Pavel, Tom, Merlin,
>
> As a user, I would like to work with records by using simple API:
>
> -- Returns a number of key/values pairs of record.
> nKeys_ integer := nRecordKeys(NEW);
>
> -- Returns an i-th key.
> key_i text := recordKey(NEW, i);
>
Tom Lane writes:
> But this all looks like a pretty substantial amount of work, and
> given the low level of user demand for improving the performance of
> set operations, it seems to belong fairly far down the to-do list.
Whatever you say, that's your own todo list after all. I just wanted to
ch
On Mon, Nov 8, 2010 at 3:00 PM, Pavel Stehule wrote:
>> Most cases of this feature are for dealing with new/old from trigger
>> function right? Why not build a complete new plan for each specific
>> trigger that invokes the function, along with some magic values like
>> (TG_FIELDNAMES -> text[])
On Mon, Nov 8, 2010 at 3:02 PM, Dmitriy Igrishin wrote:
> Hey Pavel, Tom, Merlin,
>
> As a user, I would like to work with records by using simple API:
>
> -- Returns a number of key/values pairs of record.
> nKeys_ integer := nRecordKeys(NEW);
>
> -- Returns an i-th key.
> key_i text := r
On Mon, Nov 8, 2010 at 3:05 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Mon, Nov 8, 2010 at 1:19 PM, Tom Lane wrote:
>>> But this all looks like a pretty substantial amount of work, and
>>> given the low level of user demand for improving the performance of
>>> set operations, it seems to be
On mån, 2010-11-08 at 15:01 -0500, Andrew Dunstan wrote:
> First, the buildfarm doesn't build the docs. That's a deliberate
> decision, based on the fact that not every member has the required
> software installed. And second these targets only exist for 9.0 and/or
> later.
I'm aware of those is
Robert Haas writes:
> On Mon, Nov 8, 2010 at 1:19 PM, Tom Lane wrote:
>> But this all looks like a pretty substantial amount of work, and
>> given the low level of user demand for improving the performance of
>> set operations, it seems to belong fairly far down the to-do list.
>> So I'm not goin
Hey Pavel, Tom, Merlin,
As a user, I would like to work with records by using simple API:
-- Returns a number of key/values pairs of record.
nKeys_ integer := nRecordKeys(NEW);
-- Returns an i-th key.
key_i text := recordKey(NEW, i);
-- Returns an i-th value.
value1_ text := recordV
On 11/08/2010 02:49 PM, Peter Eisentraut wrote:
On lör, 2010-11-06 at 14:45 -0400, Andrew Dunstan wrote:
Here's the list of tests from a recent run, leaving out stopping and
starting the installed postmaster, and locale specifiers:
SCM-checkout
configure
make
check
ma
2010/11/8 Merlin Moncure :
> On Mon, Nov 8, 2010 at 2:29 PM, Pavel Stehule wrote:
>> 2010/11/8 Tom Lane :
>>> Pavel Stehule writes:
FOR varname OVER [row | rec variable]
LOOP
{{body}}
END LOOP
>>>
this syntax isn't final. The real type of control variable is
speci
On Mon, Nov 8, 2010 at 1:36 PM, Tom Lane wrote:
> Robert Haas writes:
>> You've now vetoed both "using the same snapshot" and "using different
>> snapshots" at different points in time.
>
> Yeah, I did change my mind between 2009-10 and 2010-02. I was not aware
> that I'm not allowed to change m
On Mon, Nov 8, 2010 at 1:19 PM, Tom Lane wrote:
> I wrote:
>> I did some hacking on this and came up with the attached patch, which
>> could use a bit more work on the comments but passes regression tests.
>> However, this just solves the issue of being smart about top-level
>> UNION ALL cases. I
On lör, 2010-11-06 at 14:45 -0400, Andrew Dunstan wrote:
> Here's the list of tests from a recent run, leaving out stopping and
> starting the installed postmaster, and locale specifiers:
>
> SCM-checkout
> configure
> make
> check
> make-contrib
> make-install
> insta
On Mon, Nov 8, 2010 at 2:29 PM, Pavel Stehule wrote:
> 2010/11/8 Tom Lane :
>> Pavel Stehule writes:
>>> FOR varname OVER [row | rec variable]
>>> LOOP
>>> {{body}}
>>> END LOOP
>>
>>> this syntax isn't final. The real type of control variable is
>>> specified in runtime and can be changed bet
On mån, 2010-11-08 at 10:34 +0900, Hitoshi Harada wrote:
> Hmm, this looks very different from our writeable CTEs. And I can see
> many issues like syntax ambiguity and execution order if we support
> it. AFAIK the most significant reason why we are working on CTEs is
> that CTEs are regarded as so
2010/11/8 Tom Lane :
> Pavel Stehule writes:
>> FOR varname OVER [row | rec variable]
>> LOOP
>> {{body}}
>> END LOOP
>
>> this syntax isn't final. The real type of control variable is
>> specified in runtime and can be changed between iterations.
>
> If you don't know the type or even the name
--On 5. November 2010 11:46:08 -0700 Josh Berkus wrote:
I'll work on some tools to make this a bit more palatable, but I
disagree with earlier assertions that we have the replication monitoring
"done". There's still a *lot* of work to do.
While getting familiar with our SR/HS infrastructur
Pavel Stehule writes:
> FOR varname OVER [row | rec variable]
> LOOP
>{{body}}
> END LOOP
> this syntax isn't final. The real type of control variable is
> specified in runtime and can be changed between iterations.
If you don't know the type or even the name of the field that varname
curren
Robert Haas writes:
> You've now vetoed both "using the same snapshot" and "using different
> snapshots" at different points in time.
Yeah, I did change my mind between 2009-10 and 2010-02. I was not aware
that I'm not allowed to change my mind ...
regards, tom lane
--
Marko Tiikkaja writes:
> On 2010-11-08 7:26 PM +0200, Tom Lane wrote:
>> The alternative is to artificially serialize the DML CTEs, which
>> while it does have some advantages doesn't seem like a win overall.
> We've discussed this before and the consensus was that as long as we
> don't change t
I try to take problem of iteration over ROW or RECORD variable from a
different perspective. I would to design a solution where isn't
necessary a conversion from binary value to text (this is a
disadvantage of hstore based solution). This mean so we have to have a
special instance of loop's body fo
I wrote:
> I did some hacking on this and came up with the attached patch, which
> could use a bit more work on the comments but passes regression tests.
> However, this just solves the issue of being smart about top-level
> UNION ALL cases. It might be worth looking into using MergeAppend
> for t
On Mon, Nov 8, 2010 at 12:53 PM, Greg Stark wrote:
> On Mon, Nov 8, 2010 at 5:00 PM, Tom Lane wrote:
>> So maybe Aidan's got a good idea here. It would sure be a lot easier
>> to shoehorn checksum checking in as an optional feature if the checksums
>> were kept someplace else.
>
> Would it? I th
On Mon, Nov 8, 2010 at 12:26 PM, Tom Lane wrote:
> Marko Tiikkaja writes:
>> On 2010-11-08 6:38 PM +0200, Tom Lane wrote:
>>> My opinion is still the same as here:
>>> http://archives.postgresql.org/pgsql-hackers/2010-02/msg00688.php
>>>
>>> namely, that all we should be worrying about is a tuple
On Mon, Nov 8, 2010 at 5:00 PM, Tom Lane wrote:
> So maybe Aidan's got a good idea here. It would sure be a lot easier
> to shoehorn checksum checking in as an optional feature if the checksums
> were kept someplace else.
Would it? I thought the only problem was the hint bits being set
behind th
On 2010-11-08 7:26 PM +0200, Tom Lane wrote:
Marko Tiikkaja writes:
On 2010-11-08 6:38 PM +0200, Tom Lane wrote:
My opinion is still the same as here:
http://archives.postgresql.org/pgsql-hackers/2010-02/msg00688.php
namely, that all we should be worrying about is a tuplestore full of
RETURNI
2010/11/9 Tom Lane :
> Hitoshi Harada writes:
>> 2010/11/9 Tom Lane :
>>> My opinion is still the same as here:
>>> http://archives.postgresql.org/pgsql-hackers/2010-02/msg00688.php
>
>> Current consensus says:
>
>> WITH x AS (SELECT count(*) FROM t), y AS (DELETE FROM t), z AS (SELECT
>> count(*)
On Fri, Nov 5, 2010 at 2:56 PM, Tom Lane wrote:
> It's not cheap :-( ... but it's *necessary*. There's no other way to
> get sane behavior.
>
> If the cost annoys you, you should put some effort into making subxact
> start/stop cheaper overall, rather than trying to avoid having one here.
I woul
Hitoshi Harada writes:
> 2010/11/9 Tom Lane :
>> My opinion is still the same as here:
>> http://archives.postgresql.org/pgsql-hackers/2010-02/msg00688.php
> Current consensus says:
> WITH x AS (SELECT count(*) FROM t), y AS (DELETE FROM t), z AS (SELECT
> count(*) FROM t) SELECT x.count, z.coun
Marko Tiikkaja writes:
> On 2010-11-08 6:38 PM +0200, Tom Lane wrote:
>> My opinion is still the same as here:
>> http://archives.postgresql.org/pgsql-hackers/2010-02/msg00688.php
>>
>> namely, that all we should be worrying about is a tuplestore full of
>> RETURNING tuples. Any other side-effec
2010/11/9 Tom Lane :
> Robert Haas writes:
>> On Sun, Nov 7, 2010 at 1:08 PM, Tom Lane wrote:
>>> I guess I shoulda been paying closer attention :-(. That really, really
>>> seems like fundamentally the wrong direction. What was it that was
>>> unfixable about the other way? If it is unfixable
On 2010-11-08 6:38 PM +0200, Tom Lane wrote:
Robert Haas writes:
On Sun, Nov 7, 2010 at 1:08 PM, Tom Lane wrote:
I guess I shoulda been paying closer attention :-(. That really, really
seems like fundamentally the wrong direction. What was it that was
unfixable about the other way? If it i
I wrote:
> Aidan Van Dyk writes:
>> Getting back to the checksum debate (and this seems like a
>> semi-version of the checksum debate), now that we have forks, could we
>> easily add block checksumming to a fork?
> More generally, this re-opens the question of whether data in secondary
> forks is
Hitoshi Harada writes:
> But reading closer your response, it occurred to me that ModifyTable
> can be the storage to be shared among separated plans instead of newly
> invented DtScan. Are you suggesting embed ModifyTable into the main
> query, that is also on the top of child plans? In this way
Robert Haas writes:
> On Sun, Nov 7, 2010 at 1:08 PM, Tom Lane wrote:
>> I guess I shoulda been paying closer attention :-(. That really, really
>> seems like fundamentally the wrong direction. What was it that was
>> unfixable about the other way? If it is unfixable, should we revert
>> Modif
Gurjeet Singh writes:
> On Sat, Nov 6, 2010 at 11:48 PM, Tom Lane wrote:
>> Um ... and exactly how does that differ from the existing behavior?
> Right now a zero filled page considered valid, and is treated as a new page;
> PageHeaderIsValid()->/* Check all-zeroes case */, and PageIsNew(). This
2010/11/8 Hitoshi Harada :
> 2010/11/9 Hitoshi Harada :
>> 2010/11/8 Pavel Stehule :
>>> 2010/11/8 Hitoshi Harada :
>>
Hmm, this looks very different from our writeable CTEs. And I can see
many issues like syntax ambiguity and execution order if we support
it. AFAIK the most signific
Aidan Van Dyk writes:
> Getting back to the checksum debate (and this seems like a
> semi-version of the checksum debate), now that we have forks, could we
> easily add block checksumming to a fork? IT would mean writing to 2
> files but that shouldn't be a problem, because until the checkpoint i
On Mon, Nov 8, 2010 at 6:00 AM, Fujii Masao wrote:
> On Sat, Nov 6, 2010 at 9:58 AM, Robert Haas wrote:
>> This looks good, but how about adding:
>>
>> if (!RecoveryInProgress())
>> PG_RETURN_NULL();
>>
>> Otherwise, if we're in Hot Standby mode for a while and then enter
>> normal running, wo
On Sun, Nov 7, 2010 at 1:04 AM, Greg Stark wrote:
> It does seem like this is kind of part and parcel of adding checksums
> to blocks. It's arguably kind of silly to add checksums to blocks but
> have an commonly produced bitpattern in corruption cases go
> undetected.
Getting back to the checksu
Excerpts from Charles Pritchard's message of sáb nov 06 23:20:13 -0300 2010:
> Simple async sql sub-set (the spec in trouble):
> http://dev.w3.org/html5/webdatabase/
This is insane. This spec allows the server to run arbitrary SQL
commands on the client, AFAICT. That seems like infinite joy for
umut orhan writes:
> When I pin a single query to an individual core, its execution time is
> observed
> as 111 seconds. This result is my base case. Then, I fire two instances of
> the
> same query concurrently and pin them to two different cores separately.
> However,
> each execution time
On 11/08/2010 10:27 AM, Stefan Kaltenbrunner wrote:
Tom Lane wrote:
Andrew Dunstan writes:
On 11/06/2010 01:07 PM, Tom Lane wrote:
What I *have* occasionally
wished for is that the buildfarm script would act more like make -k
with
respect to the various test stages.
I'm not sure that wo
2010/11/9 Hitoshi Harada :
> 2010/11/8 Pavel Stehule :
>> 2010/11/8 Hitoshi Harada :
>
>>> Hmm, this looks very different from our writeable CTEs. And I can see
>>> many issues like syntax ambiguity and execution order if we support
>>> it. AFAIK the most significant reason why we are working on CT
2010/11/8 Pavel Stehule :
> 2010/11/8 Hitoshi Harada :
>> Hmm, this looks very different from our writeable CTEs. And I can see
>> many issues like syntax ambiguity and execution order if we support
>> it. AFAIK the most significant reason why we are working on CTEs is
>> that CTEs are regarded as
Shigeru HANADA writes:
> How about removing them, ConnectServer and FreeFSConnection, from
> FdwRoutine and leaving the responsibility of resource management to
> each FDW? Each FDW would have to use mechanism such as Virtual File
> and ResourceOwner to manage resources properly, though.
For the
Tom Lane wrote:
Andrew Dunstan writes:
On 11/06/2010 01:07 PM, Tom Lane wrote:
What I *have* occasionally
wished for is that the buildfarm script would act more like make -k with
respect to the various test stages.
I'm not sure that would be a great advance. Certainly, right now I'm
going t
Hi all,
I've collected some interesting results during my experiments which I couldn't
figure out the reason behind them and need your assistance.
I'm running PostgreSQL 9.0 on a quad-core machine having two level on-chip
cache
hierarchy. PostgreSQL has a large and warmed-up buffer
cache thus,
Hey All,
I just noticed that an editor at the w3c seems to have hit a wall with
browser implementers,
as they are all using Sqlite as their backend database, and so there is
no second, independent implementation. (required for the standards process).
At some point, these specs will be used mor
=?UTF-8?B?SmFuIFVyYmHFhHNraQ==?= writes:
> PS: I'm wondering if there's any noticable slowdown from always starting
> a subxact before doing SPI. Plperl users seemed not to notice, so I
> guess I shouldn't worry.
It's not cheap :-( ... but it's *necessary*. There's no other way to
get sane behav
On 02.11.2010 16:40, Heikki Linnakangas wrote:
On 02.11.2010 16:30, Tom Lane wrote:
Heikki Linnakangas writes:
I think we can fix this by requiring that any multi-WAL-record actions
that are in-progress when a checkpoint starts (at the REDO-pointer) must
finish before the checkpoint record is w
On Sat, 6 Nov 2010 16:04:37 +0900
Hitoshi Harada wrote:
> 2010/11/5 Shigeru HANADA :
> > On Fri, 5 Nov 2010 16:27:49 +0900
> > Itagaki Takahiro wrote:
> >> PL/Proxy has a similar functionality with RUN ON ALL to start queries
> >> in parallel. So, I think it's a infrastructure commonly required.
On Sat, Nov 6, 2010 at 3:46 AM, Josh Berkus wrote:
> I'm continuing in my efforts now to document how to deploy and manage
> replication on our wiki. One of the things a DBA needs to do is to use
> pg_current_xlog_location() (and related functions) to check how far
> behind the master the standby
On Sat, Nov 6, 2010 at 9:58 AM, Robert Haas wrote:
> This looks good, but how about adding:
>
> if (!RecoveryInProgress())
> PG_RETURN_NULL();
>
> Otherwise, if we're in Hot Standby mode for a while and then enter
> normal running, wouldn't this still return a (stale) value?
Yes, but isn't tha
88 matches
Mail list logo
