CommitFest 2009-11 is now closed, having committed 27 patches in 33
days. For comparison sake, 2009-09 committed 20 patches in 29 days,
2009-07 37 patches in 34 days, and 2008-09 29 patches in 30 days. The
much bigger 2008-11 involved 58 patches going on for months, the bulk of
it committed 2
Hi,
I couldn't find lo_import(text, oid) document anywhere in the
PostgreSQL core documents. Unless I'm missing something, I would like
to add description for the function in "31.4. Server-Side Functions"
part.
BTW, why don't lo_creat, lo_create, lo_unlink, lo_import and lo_export
server side fun
Robert Haas wrote:
On Mon, Dec 14, 2009 at 12:38 PM, Greg Smith wrote:
Robert Haas wrote:
I don't think there should be a transition from Returned with Feedback
back to Waiting for review. Granted we might allow that occasionally
as an exceptional case, but normally Returned with Feed
On Fri, Dec 18, 2009 at 11:24 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Fri, Dec 18, 2009 at 10:39 PM, Tom Lane wrote:
>>> The TODO item is terribly underdocumented, but I think what it's on
>>> about is that right now we refuse commands like ALTER COLUMN TYPE if
>>> the column is referenc
Robert Haas writes:
> On Fri, Dec 18, 2009 at 10:39 PM, Tom Lane wrote:
>> The TODO item is terribly underdocumented, but I think what it's on
>> about is that right now we refuse commands like ALTER COLUMN TYPE if
>> the column is referenced in a view. It would be nice to propagate
>> such a ch
On Fri, Dec 18, 2009 at 10:39 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Fri, Dec 18, 2009 at 9:58 PM, suzhiyang wrote:
>>> I'm doing the Todo List's "Allow VIEW/RULE recompilation when the underlying
>>> tables change ".
>
>> I am not sure what this TODO item is supposed to refer to, but s
Robert Haas writes:
> On Fri, Dec 18, 2009 at 9:58 PM, suzhiyang wrote:
>> I'm doing the Todo List's "Allow VIEW/RULE recompilation when the underlying
>> tables change ".
> I am not sure what this TODO item is supposed to refer to, but saving
> the query string and re-executing it is clearly no
Yeah, when a column of the underlying table renamed, this re-executing must be
failed...
2009-12-19
suzhiyang
发件人： Robert Haas
发送时间： 2009-12-19 11:17:44
收件人： suzhiyang
抄送： pgsql-hackers
主题： Re: [HACKERS] About "Allow VIEW/RULE recompilation when theunderlying
tables change"
On F
On Fri, Dec 18, 2009 at 9:58 PM, suzhiyang wrote:
> I'm doing the Todo List's "Allow VIEW/RULE recompilation when the underlying
> tables change ". I've a very simple idea that I save the "create view"
> query_string in systable. When I found that I select from a view, I drop the
> view and recrea
On Fri, Dec 18, 2009 at 9:51 PM, Tom Lane wrote:
> Robert Haas writes:
>> Part of what I'm confused about (and what I think should be documented
>> in a comment somewhere) is why we're using MVCC visibility in some
>> places but not others. In particular, there seem to be some bits of
>> the com
On Fri, Dec 18, 2009 at 9:48 PM, Tom Lane wrote:
> Robert Haas writes:
>> Oh. This is more complicated than it appeared on the surface. It
>> seems that the string "BLOB COMMENTS" actually gets inserted into
>> custom dumps somewhere, so I'm not sure whether we can just change it.
>> Was this
I'm doing the Todo List's "Allow VIEW/RULE recompilation when the underlying
tables change ". I've a very simple idea that I save the "create view"
query_string in systable. When I found that I select from a view, I drop the
view and recreate the view by execute the source query_string. Then go
Robert Haas writes:
> Part of what I'm confused about (and what I think should be documented
> in a comment somewhere) is why we're using MVCC visibility in some
> places but not others. In particular, there seem to be some bits of
> the comment that imply that we do this for read but not for wri
Robert Haas writes:
> Oh. This is more complicated than it appeared on the surface. It
> seems that the string "BLOB COMMENTS" actually gets inserted into
> custom dumps somewhere, so I'm not sure whether we can just change it.
> Was this issue discussed at some point before this was committed?
On Fri, Dec 18, 2009 at 8:32 PM, Simon Riggs wrote:
> Log Message:
> ---
> Allow read only connections during recovery, known as Hot Standby.
>
> Enabled by recovery_connections = on (default) and forcing archive recovery
> using a recovery.conf. Recovery processing now emulates the origi
On Fri, Dec 18, 2009 at 1:48 AM, Takahiro Itagaki
wrote:
>> In both cases, I'm lost. Help?
>
> They might be contrasted with the comments for myLargeObjectExists.
> Since we use MVCC visibility in loread(), metadata for large object
> also should be visible in MVCC rule.
>
> If I understand them,
On Fri, Dec 18, 2009 at 9:00 AM, Robert Haas wrote:
> 2009/12/18 KaiGai Kohei :
>> (2009/12/18 15:48), Takahiro Itagaki wrote:
>>>
>>> Robert Haas wrote:
>>>
In both cases, I'm lost. Help?
>>>
>>> They might be contrasted with the comments for myLargeObjectExists.
>>> Since we use MVCC visi
Joe Conway writes:
> I like this approach overall, but wonder if it would be better to do:
> select pg_migrator_set_next_oid('table', 123456);
> select pg_migrator_set_next_oid('type', 12347);
> select pg_migrator_set_next_oid('toast_table', 123458);
> etc. Later we could easily
Bruce Momjian writes:
> ... The idea I had was to create a global structure:
> struct pg_migrator_oids {
> Oid pg_type;
> Oid pg_type_array;
> ...
> }
> This would initialize to zero as a global structure, and only
> pg_migrator serve
On 12/18/2009 04:09 PM, Tom Lane wrote:
> At the moment it appears that we need the following hacks:
>
> * ability to control the OIDs assigned to user tables and types.
> Because a table also has a rowtype, this means at least two separate
> state variables. And we already knew we had to control
Tom Lane wrote:
> Alvaro Herrera writes:
> > Tom Lane wrote:
> >> select pg_migrator_set_next_table_oid(123456);
> >> select pg_migrator_set_next_type_oid(12347);
> >> select pg_migrator_set_next_toast_table_oid(123458);
> >>
> >> CREATE TABLE ...
>
> > Do we also need a knob for the table type'
Tom Lane wrote:
> The more I think about it the less I want such warts placed in the
> regular SQL syntax for creation commands. As soon as we add a wart like
> that we'll be stuck with supporting it forever. Whatever we do here
> should be off in a little corner that only pg_migrator can get at.
Bruce Momjian wrote:
> > I think the OIDs for user-defined arrays stored in table data are
> > element types, not the array type which is what you're pointing at with
> > the line you quote:
> >
> > > > > array_oid = GetNewOid(pg_type);
> >
> > IMBFOS.
>
> Oh, yea, sorry, I was just showin
Dimitri Fontaine escribió:
> Well I did propose to consider a state machine with clear transition for such
> problems, a while ago, and I think my remarks still do apply:
> http://www.mail-archive.com/pgsql-hackers@postgresql.org/msg131511.html
>
> Sorry for non archives.postgresql.org link, c
Alvaro Herrera writes:
> Tom Lane wrote:
>> select pg_migrator_set_next_table_oid(123456);
>> select pg_migrator_set_next_type_oid(12347);
>> select pg_migrator_set_next_toast_table_oid(123458);
>>
>> CREATE TABLE ...
> Do we also need a knob for the table type's array type?
Well, we wouldn't c
Tom Lane wrote:
At the moment it appears that we need the following hacks:
* ability to control the OIDs assigned to user tables and types.
Because a table also has a rowtype, this means at least two separate
state variables. And we already knew we had to control the OIDs
assigned to toast ta
Tom Lane wrote:
> * ability to control the OIDs assigned to user tables and types.
> Because a table also has a rowtype, this means at least two separate
> state variables. And we already knew we had to control the OIDs
> assigned to toast tables. I'm imagining dump output like
>
> select
On Fri, Dec 18, 2009 at 7:05 PM, Andrew Dunstan wrote:
>> One problem is that there is not a single well-defined mapping between
>> these types. I would say generally that XML and YAML both have more
>> types of constructs than JSON. The obvious ways of translating an
>> arbitrary XML document t
Robert Haas writes:
> On Fri, Dec 18, 2009 at 4:20 PM, Tom Lane wrote:
>> Looks like Peter forgot about the restrictions on links in doc sections
>> that also get made into standalone text files. Will fix.
> I seem to have... forgotten... those as well. Can you enlighten me?
Try "make HISTORY
> Bruce Momjian wrote:
>> Seems I need some help here.
I'm willing to work on this --- it doesn't look particularly fun but
we really need it.
Andrew Dunstan writes:
> I thought there was a suggestion that we would be able to specify the
> oids in the SQL that creates the types, along the lines
Robert Haas wrote:
On Fri, Dec 18, 2009 at 3:00 PM, Tom Lane wrote:
Alvaro Herrera writes:
Tom Lane escribió:
Well, actually, now that you mention it: how much of a json type would
be duplicative of the xml stuff? Would it be sufficient to provide
json <-> xml converters an
On Fri, Dec 18, 2009 at 6:44 PM, Andrew Dunstan wrote:
> I thought there was a suggestion that we would be able to specify the oids
> in the SQL that creates the types, along the lines of:
>
> create type foo as enum ( ...) with oids ( ... );
>
> Is that a non-starter? I imagine it would need to
On Fri, Dec 18, 2009 at 4:20 PM, Tom Lane wrote:
> Looks like Peter forgot about the restrictions on links in doc sections
> that also get made into standalone text files. Will fix.
I seem to have... forgotten... those as well. Can you enlighten me?
...Robert
--
Sent via pgsql-hackers mailin
On Fri, Dec 18, 2009 at 4:39 PM, Peter Eisentraut wrote:
> On fre, 2009-12-18 at 11:51 -0500, Robert Haas wrote:
>> On Fri, Dec 18, 2009 at 11:32 AM, David E. Wheeler
>> wrote:
>> > On Dec 18, 2009, at 4:49 AM, Peter Eisentraut wrote:
>> >
>> >> Should we create a json type before adding all kin
Bruce Momjian wrote:
There are several pg_migrator limitations that appeared late in the 8.4
development cycle and were impossible to fix at that point. I would
like to fix them for Postgres 8.5:
o a user-defined composite data type
o a user-defined array data type
o
Alvaro Herrera wrote:
> Bruce Momjian wrote:
> > Alvaro Herrera wrote:
> > > Bruce Momjian wrote:
> > > > Alvaro Herrera wrote:
>
> > > > > To be more precise, the pg_enum.oid needs to be set for ENUM types;
> > > > > there's no need for setting the pg_type.oid (for ENUM types). I don't
> > > > >
Bruce Momjian wrote:
> Alvaro Herrera wrote:
> > Bruce Momjian wrote:
> > > Alvaro Herrera wrote:
> > > > To be more precise, the pg_enum.oid needs to be set for ENUM types;
> > > > there's no need for setting the pg_type.oid (for ENUM types). I don't
> > > > know about composites but I think the
Alvaro Herrera wrote:
> Bruce Momjian wrote:
> > Alvaro Herrera wrote:
> > > Bruce Momjian wrote:
> > > > There are several pg_migrator limitations that appeared late in the 8.4
> > > > development cycle and were impossible to fix at that point. I would
> > > > like to fix them for Postgres 8.5:
>
Bruce Momjian wrote:
> Alvaro Herrera wrote:
> > Bruce Momjian wrote:
> > > There are several pg_migrator limitations that appeared late in the 8.4
> > > development cycle and were impossible to fix at that point. I would
> > > like to fix them for Postgres 8.5:
> > >
> > > o a user-defi
On fre, 2009-12-18 at 11:51 -0500, Robert Haas wrote:
> On Fri, Dec 18, 2009 at 11:32 AM, David E. Wheeler
> wrote:
> > On Dec 18, 2009, at 4:49 AM, Peter Eisentraut wrote:
> >
> >> Should we create a json type before adding all kinds of json formatted
> >> data? Or are we content with json as t
Bruce Momjian wrote:
> Bruce Momjian wrote:
> > Tom Lane wrote:
> > > Bruce Momjian writes:
> > > > I installed PL/pgSQL by default via initdb with the attached patch. The
> > > > only problem is that pg_dump still dumps out the language creation:
> > > > CREATE PROCEDURAL LANGUAGE plpgsq
Stefan Kaltenbrunner writes:
> openjade:installation.sgml:202:51:X: reference to non-existent ID
> "PLPYTHON-PYTHON23"
> openjade:/usr/local/share/sgml/docbook/dsssl/modular/html/dblink.dsl:203:1:E:
> XRef LinkEnd to missing ID 'PLPYTHON-PYTHON23'
Looks like Peter forgot about the restrictions
+1 for such a feature, simply to avoid the need of
writing a hstore-parser (which wasn't too bad
to write, but it felt unnecessary). Doesn't
matter to me if it's hstore-to-json or hstore-to-xml
or hstore-to-yaml. Just something that parsers are
readily available for.
Heck, I wouldn't mind if hs
On Fri, Dec 18, 2009 at 3:00 PM, Tom Lane wrote:
> Alvaro Herrera writes:
>> Tom Lane escribió:
>>> Well, actually, now that you mention it: how much of a json type would
>>> be duplicative of the xml stuff? Would it be sufficient to provide
>>> json <-> xml converters and let the latter type do
Hi all!
Infrastructure monitoring started to complain a few days ago that we
failed generating new snapshot-tarball for HEAD.
Manual investigation shows that the script dies while building the docs
with:
openjade:installation.sgml:202:51:X: reference to non-existent ID
"PLPYTHON-PYTHON23"
I wrote:
> [for a description of traditional techniques for providing various
> isolation levels, including serializable], Dr. Cahill seemed to
> like (Hellerstein et al., 2007)
If anyone else is interested in this paper, here is additional
information:
Architecture of a Database System. (Jos
Alvaro Herrera wrote:
> Bruce Momjian wrote:
> > There are several pg_migrator limitations that appeared late in the 8.4
> > development cycle and were impossible to fix at that point. I would
> > like to fix them for Postgres 8.5:
> >
> > o a user-defined composite data type
> >
Hi,
Le 18 déc. 2009 à 19:21, Heikki Linnakangas a écrit :
> On Fri, Dec 18, 2009 at 12:22 PM, Florian Pflug
> wrote:
>>> It'd prefer if the slave could automatically fetch a new base backup if it
>>> falls behind too far to catch up with the available logs. That way, old logs
>>> don't start pil
Alvaro Herrera writes:
> Tom Lane escribió:
>> Well, actually, now that you mention it: how much of a json type would
>> be duplicative of the xml stuff? Would it be sufficient to provide
>> json <-> xml converters and let the latter type do all the heavy lifting?
>> (If so, this patch ought to b
Tom Lane escribió:
> Andrew Dunstan writes:
> > Tom Lane wrote:
> >> [ I can already hear somebody insisting on a yaml type :-( ]
>
> > Now that's a case where I think a couple of converter functions at most
> > should meet the need.
>
> Well, actually, now that you mention it: how much of a js
Bruce Momjian wrote:
> There are several pg_migrator limitations that appeared late in the 8.4
> development cycle and were impossible to fix at that point. I would
> like to fix them for Postgres 8.5:
>
> o a user-defined composite data type
> o a user-defined array data type
>
Andrew Dunstan writes:
> Tom Lane wrote:
>> [ I can already hear somebody insisting on a yaml type :-( ]
> Now that's a case where I think a couple of converter functions at most
> should meet the need.
Well, actually, now that you mention it: how much of a json type would
be duplicative of the
Andrew Dunstan wrote:
>
>
> Tom Lane wrote:
> > Andrew Dunstan writes:
> >
> >> You're correct that we don't necessarily need a new type, we could just
> >> make it text and have a bunch of operations, but that seems to violate
> >> the principle of data type abstraction a bit.
> >>
>
Tom Lane wrote:
Andrew Dunstan writes:
You're correct that we don't necessarily need a new type, we could just
make it text and have a bunch of operations, but that seems to violate
the principle of data type abstraction a bit.
I think the relevant precedent is that we have an xml
There are several pg_migrator limitations that appeared late in the 8.4
development cycle and were impossible to fix at that point. I would
like to fix them for Postgres 8.5:
o a user-defined composite data type
o a user-defined array data type
o a user-defined enum dat
Andrew Dunstan writes:
> You're correct that we don't necessarily need a new type, we could just
> make it text and have a bunch of operations, but that seems to violate
> the principle of data type abstraction a bit.
I think the relevant precedent is that we have an xml type. While I
surely d
This is perfect. It fires on both commit and rollback? And I can
determine which? The system I'm interfacing with has 2PC so it should
be a pretty tight fit. Thanks a ton Heikki!
--
Theo Schlossnagle (mobile)
http://omniti.com/is/theo-schlossnagle
On Dec 18, 2009, at 10:34 AM, Heikki Linna
On Tue, Dec 15, 2009 Greg Smith wrote:
Sounds like we just are waiting for Simon to finish up, which is
expected to happen by tomorrow, and for Tom to wrap up working on the
ProcessUtility_hook. That makes the first reasonable date to consider
alpha3 packaging Thursday 12/17 I think.
Update:
Robert Haas wrote:
On Fri, Dec 18, 2009 at 11:32 AM, David E. Wheeler wrote:
On Dec 18, 2009, at 4:49 AM, Peter Eisentraut wrote:
Should we create a json type before adding all kinds of json formatted
data? Or are we content with json as text?
json_data_type++
What w
Theo Schlossnagle wrote:
> I'm trying to implement a function that has some XA like properties.
>
> Is it possible to write a postgres extension function that fires when called
> within a pg transaction... however, the actions it takes need to be later
> committed or rolled back based on the con
Robert Haas wrote:
> On Fri, Dec 18, 2009 at 12:22 PM, Florian Pflug
> wrote:
>> On 18.12.09 17:05 , Robert Haas wrote:
>>> On Fri, Dec 18, 2009 at 11:03 AM, Heikki Linnakangas
>>> wrote:
Or some way for to register the standby with the master so that
the master knows it's out there,
Alvaro Herrera writes:
> I notice that most of the difference is system time ... I imagine we do
> a lot of syscalls to guess the timezone.
Yeah, it seems to be mostly the cost of searching the timezone directory
tree and reading all those small files. I was led to notice this
because Red Hat's
Joshua Tolley writes:
> On Fri, Dec 18, 2009 at 06:20:39PM +0100, Guillaume Lelarge wrote:
>> Le 18/12/2009 18:07, Tom Lane a écrit :
>>> On current Fedora 11, there is a huge difference in initdb time if you
>>> have TZ set versus if you don't: I get about 18 seconds versus less than
>>> four.
>
Florian Weimer wrote:
> * Florian Pflug:
>> On 16.12.09 16:40 , Kevin Grittner wrote:
>>> Nicolas Barbier wrote:
>>>
I am not sure whether the serialization failures that it may
cause are dependent on the plan used.
>>>
>>> They are.
>>
>> But so are failures due to deadlocks even today
Tom Lane wrote:
> On current Fedora 11, there is a huge difference in initdb time if you
> have TZ set versus if you don't: I get about 18 seconds versus less than
> four.
Wow, I can reproduce this (11-12 secs when no TZ versus 5 when TZ is
defined). I'd never noticed because I normally have TZ s
"suzhiyang" writes:
> I just want to distinguish a view and a table while postgres execute
> exec_simple_query(). In the systable of pg_class, a view and a table
> has different relkind ('r' 'v'). But when I print the parsetree and
> the rewrite parsetree, I found that a view and a table has no
>
On Fri, Dec 18, 2009 at 06:20:39PM +0100, Guillaume Lelarge wrote:
> Le 18/12/2009 18:07, Tom Lane a écrit :
> > On current Fedora 11, there is a huge difference in initdb time if you
> > have TZ set versus if you don't: I get about 18 seconds versus less than
> > four.
> I have the exact same issu
On Fri, Dec 18, 2009 at 10:57 AM, suzhiyang wrote:
> Another question is that does postgres save the user's original query_string
> at anywhere(systable etc.)? If I want to save the sourceText in the
> systable, I could add a column to pg_class called query_string. How could I
> insert a line to p
On Fri, Dec 18, 2009 at 12:22 PM, Florian Pflug wrote:
> On 18.12.09 17:05 , Robert Haas wrote:
>>
>> On Fri, Dec 18, 2009 at 11:03 AM, Heikki Linnakangas
>> wrote:
>>>
>>> Or some way for to register the standby with the master so that
>>> the master knows it's out there, and still needs the lo
On 18.12.09 17:05 , Robert Haas wrote:
On Fri, Dec 18, 2009 at 11:03 AM, Heikki Linnakangas
wrote:
Or some way for to register the standby with the master so that
the master knows it's out there, and still needs the logs, even when
it's not connected.
That is the real answer, I think.
It'd
Le 18/12/2009 18:07, Tom Lane a écrit :
> On current Fedora 11, there is a huge difference in initdb time if you
> have TZ set versus if you don't: I get about 18 seconds versus less than
> four.
>
> $ time initdb
> ... blah blah blah ...
>
> real0m17.953s
> user0m6.490s
> sys 0m10.93
On 18.12.09 17:33 , Nicolas Barbier wrote:
I would guess that currently, whether deadlocks can be triggered by
a set of transactions (i.e., sequences of SQL statements) depends on
the plan only marginally*. E.g., if two plans happen to use the same
index, rows may always get locked in the same or
On current Fedora 11, there is a huge difference in initdb time if you
have TZ set versus if you don't: I get about 18 seconds versus less than
four.
$ time initdb
... blah blah blah ...
real0m17.953s
user0m6.490s
sys 0m10.935s
$ rm -rf $PGDATA
$ export TZ=GMT
$ time initdb
... blah b
I'm trying to implement a function that has some XA like properties.
Is it possible to write a postgres extension function that fires when called
within a pg transaction... however, the actions it takes need to be later
committed or rolled back based on the containing transactions commital or n
On Dec 18, 2009, at 8:51 AM, Robert Haas wrote:
> What would that do for us?
>
> I'm not opposed to it, but it seems like the more important thing
> would be to provide functions or operators that can do things like
> extract an array, extract a hash key, identify whether something is a
> hash, l
On 18.12.09 16:42 , Florian Weimer wrote:
* Florian Pflug:
On 16.12.09 16:40 , Kevin Grittner wrote:
Nicolas Barbier wrote:
I am not sure whether the serialization failures that it may cause
are dependent on the plan used.
They are.
But so are failures due to deadlocks even today, no?
On Fri, Dec 18, 2009 at 11:32 AM, David E. Wheeler wrote:
> On Dec 18, 2009, at 4:49 AM, Peter Eisentraut wrote:
>
>> Should we create a json type before adding all kinds of json formatted
>> data? Or are we content with json as text?
>
> json_data_type++
What would that do for us?
I'm not oppo
2009/12/18 suzhiyang
> How could I get the relkind of a table(view) by its name from pg_class?
>
pg_class is (quite logically) UNIQUE on (relname, relnamespace)
SELECT c.relkind from pg_class c, pg_namespace n
where c.relnamespace = n.oid
and c.relname = 'thetable'
and n.nspname = 'theschema'
Hi!
I just want to distinguish a view and a table while postgres execute
exec_simple_query(). In the systable of pg_class, a view and a table has
different relkind ('r' 'v'). But when I print the parsetree and the rewrite
parsetree, I found that a view and a table has no character to distinguish
2009/12/18 Florian Weimer :
> * Florian Pflug:
>
>> On 16.12.09 16:40 , Kevin Grittner wrote:
>>
>>> Nicolas Barbier wrote:
>>>
I am not sure whether the serialization failures that it may cause
are dependent on the plan used.
>>>
>>> They are.
>>
>> But so are failures due to deadlock
On Dec 18, 2009, at 4:49 AM, Peter Eisentraut wrote:
> Should we create a json type before adding all kinds of json formatted
> data? Or are we content with json as text?
json_data_type++
D
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscript
On Fri, Dec 18, 2009 at 11:03 AM, Heikki Linnakangas
wrote:
> Or some way for to register the standby with the master so that
> the master knows it's out there, and still needs the logs, even when
> it's not connected.
That is the real answer, I think.
...Robert
--
Sent via pgsql-hackers maili
Fujii Masao wrote:
> pg_stop_backup deletes the previous backup history file from pg_xlog.
> So replication of a backup history file would fail if just one new
> online-backup is caused after the base-backup for the standby is taken.
> This is too aggressive deletion policy for Streaming Replicatio
* Florian Pflug:
> On 16.12.09 16:40 , Kevin Grittner wrote:
>> Nicolas Barbier wrote:
>>
>>> I am not sure whether the serialization failures that it may cause
>>> are dependent on the plan used.
>>
>> They are.
>
> But so are failures due to deadlocks even today, no?
They are detected. In th
2009/12/18 KaiGai Kohei :
> (2009/12/18 15:48), Takahiro Itagaki wrote:
>>
>> Robert Haas wrote:
>>
>>> In both cases, I'm lost. Help?
>>
>> They might be contrasted with the comments for myLargeObjectExists.
>> Since we use MVCC visibility in loread(), metadata for large object
>> also should be
Pavel Stehule wrote:
2009/12/17 Andrew Dunstan :
Recently there was discussion about allowing a COPY statement to be a SELECT
target, returning a text array, although the syntax wasn't really nailed
down that I recall. I was thinking that we might have
COPY RETURNING ARRAY FROM ...
ins
On ons, 2009-12-16 at 15:42 +, Simon Riggs wrote:
> I suggest we say "smoothed" when checkpoint option is !immediate. So
> we
> will remove the word "immediate" from the message.
The opposite of smooth could be sharp. :)
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
On ons, 2009-12-16 at 11:28 -0800, David E. Wheeler wrote:
> I just realized that this was easy to do, and despite my complete lack of C
> skillz was able to throw this together in a couple of hours. It might be
> handy to some, though the possible downsides are:
>
> * No json_to_hstore().
> * L
>This way we only cancel direct deadlocks.
>
>It doesn't solve general problem of buffer waits, but they may be
>solvable by different mechanism.
>
Following question may be redundant. Just a confirmation.
Deadlock example is catstrophic while it's rather a rare event.
On the other hand, LockBuf
Le vendredi 18 décembre 2009 09:44:40, Takahiro Itagaki a écrit :
> We have infrastructure to count numbers buffer access in 8.5 Alpha 3.
> I'd like to add per-query buffer usage into contrib/pg_stat_statements.
>
> The pg_stat_statements view will have the same contents with
> struct BufferUsage.
(2009/12/18 15:48), Takahiro Itagaki wrote:
>
> Robert Haas wrote:
>
>> In both cases, I'm lost. Help?
>
> They might be contrasted with the comments for myLargeObjectExists.
> Since we use MVCC visibility in loread(), metadata for large object
> also should be visible in MVCC rule.
>
> If I
We have infrastructure to count numbers buffer access in 8.5 Alpha 3.
I'd like to add per-query buffer usage into contrib/pg_stat_statements.
The pg_stat_statements view will have the same contents with
struct BufferUsage. Fields named shared_blks_{hit|read|written},
local_blks_{hit|read|written},
92 matches
Mail list logo
