On Jun 23, 2010, at 5:36 PM, Mark Wong wrote:
> On Jun 22, 2010, at 1:34 AM, Simon Riggs wrote:
>
>> On Mon, 2010-06-21 at 20:53 -0400, Robert Haas wrote:
>>> On Mon, Jun 21, 2010 at 7:51 PM, gabrielle wrote:
On Thu, 2010-06-17 at 14:50 -0400, Alvaro Herrera asked:
> How does it play wi
On Tue, Jun 22, 2010 at 12:32 PM, Magnus Hagander wrote:
> I looked around quickly earlier when we chatted about this, and I
> think I found an API call to change them for a socket as well - but a
> Windows specific one, not the ones you'd find on Unix...
Magnus - or anyone who knows Windows -
N
On Jun 22, 2010, at 1:34 AM, Simon Riggs wrote:
> On Mon, 2010-06-21 at 20:53 -0400, Robert Haas wrote:
>> On Mon, Jun 21, 2010 at 7:51 PM, gabrielle wrote:
>>> On Thu, 2010-06-17 at 14:50 -0400, Alvaro Herrera asked:
How does it play with ON_ERROR_STOP/ROLLBACK?
>>>
>>> With ON_ERROR_STOP=
Tom Lane wrote:
Bruce Momjian writes:
Well, we don't need the enum value to map into the entire oid range.
Can't we just add one to the top-most value and see if there is a
conflict?
If you don't use the OID counter to generate the new value, you're going
to have problems with race
Bruce Momjian writes:
> Well, we don't need the enum value to map into the entire oid range.
> Can't we just add one to the top-most value and see if there is a
> conflict?
If you don't use the OID counter to generate the new value, you're going
to have problems with race conditions. There's al
Tom Lane wrote:
> Bruce Momjian writes:
> > Sorry to be commenting late, but don't most people want to add to the
> > end or beginning of the enum list, rather than in the middle, and can't
> > we support that already?
>
> We could allow adding a value, but we couldn't guarantee where it would
>
Bruce Momjian writes:
> Sorry to be commenting late, but don't most people want to add to the
> end or beginning of the enum list, rather than in the middle, and can't
> we support that already?
We could allow adding a value, but we couldn't guarantee where it would
appear in the type's sort orde
Tom Lane wrote:
> Andrew Dunstan writes:
> > Robert Haas wrote:
> >> I like the idea of being able to modify enums on the fly, but I'm
> >> skeptical of an implementation that won't always work. Maybe it's
> >> still better than what we have now, but it seems grotty.
>
> > I'd be perfectly happy
Le 23/06/2010 22:54, Tom Lane a écrit :
> Robert Haas writes:
>> On Mon, Jun 21, 2010 at 12:46 PM, Guillaume Lelarge
>> wrote:
>>> I added a CHECK_FOR_INTERRUPTS call in the copy_relation_data(),
>>> copy_dir(), and copy_file() functions. Works for me on ALTER TABLE ...
>>> SET TABLESPACE and ALT
On Wed, Jun 23, 2010 at 4:56 PM, Tom Lane wrote:
> Fujii Masao writes:
>> On Wed, Jun 23, 2010 at 5:32 AM, Robert Haas wrote:
>>> OK, here's a new version with several fewer bugs.
>
>> Since valid values for keepalives parameter are 0 and 1, its field size
>> should
>> be 1 rather than 10.
>
>
Fujii Masao writes:
> On Wed, Jun 23, 2010 at 5:32 AM, Robert Haas wrote:
>> OK, here's a new version with several fewer bugs.
> Since valid values for keepalives parameter are 0 and 1, its field size should
> be 1 rather than 10.
Right ... although maybe it should be considered a boolean and n
Robert Haas writes:
> On Mon, Jun 21, 2010 at 12:46 PM, Guillaume Lelarge
> wrote:
>> I added a CHECK_FOR_INTERRUPTS call in the copy_relation_data(),
>> copy_dir(), and copy_file() functions. Works for me on ALTER TABLE ...
>> SET TABLESPACE and ALTER DATABASE ... SET TABLESPACE, in 9.0 and 8.4.
Boszormenyi Zoltan wrote:
> Hi,
>
> we improved ECPG quite a lot in 9.0 because we worked and
> still working with an Informix to PostgreSQL migration project.
>
> We came across a pretty big performance problem that can be seen in
> every "naive" application that uses only FETCH 1, FETCH RELATIV
On Mon, Jun 21, 2010 at 7:50 PM, Heikki Linnakangas
wrote:
> On 15/06/10 10:31, Heikki Linnakangas wrote:
>>
>> You could avoid changing the meaning of fn_expr by putting the check in
>> the parse analysis phase, into transformFuncCall(). That would feel
>> safer at least for back-branches.
>
> He
Heikki Linnakangas writes:
> On 23/06/10 18:17, Leonardo F wrote:
>> I'm not getting it: am I supposed to use the "disk page format" when
>> writing an index access method, or it's just a "good practice" because
>> it makes the handling easier? Given the docs it looks "recommended",
>> but the com
On Wed, Jun 23, 2010 at 10:41 AM, Kevin Grittner
wrote:
>
> It should have been. Neither the reviewer nor the author updated
> the CF web page (as they should have done). I've just made the
> entries to bring the patch it up to date in the web app.
>
Yeah! sorry i got bussy with other things...
Andy Balholm wrote:
> On Jun 21, 2010, at 11:47 AM, Kevin Grittner wrote:
>> The only issue is with the general guideline to make the new code
>> blend in with existing code:
> I deleted the excess comments and moved some lines around. Here it
> is with the changes.
I ran pgindent to standar
Hitoshi Harada wrote:
> 2010/6/18 Takahiro Itagaki :
>> I attached an updated patch set for partitioning syntax.
>
> Isn't this linked from the RF web app??
It should have been. Neither the reviewer nor the author updated
the CF web page (as they should have done). I've just made the
entri
On 23/06/10 18:17, Leonardo F wrote:
in bufpage.h:
"all blocks written out by an access method must be disk pages"
but in
http://www.postgresql.org/docs/8.4/static/storage-page-layout.html
"Actually, index access methods need not use this page format. All the
existing index methods do use this
2010/6/18 Takahiro Itagaki :
>
> Jaime Casanova wrote:
>
>> This one, doesn't apply to head anymore... please update
>
> Thank you for reviewing my patch!
>
> I attached an updated patch set for partitioning syntax.
Isn't this linked from the RF web app??
Regards,
--
Hitoshi Harada
--
Sent v
in bufpage.h:
"all blocks written out by an access method must be disk pages"
but in
http://www.postgresql.org/docs/8.4/static/storage-page-layout.html
"Actually, index access methods need not use this page format. All the
existing index methods do use this basic format, but the data kept on
i
On Wed, Jun 23, 2010 at 10:30 AM, Tom Lane wrote:
> Robert Haas writes:
>> I can reproduce this, here. The problem seems to be that plpython
>> only build either plpython2.so or plython3.so, but both languages
>> expect a call handler called plython_call_handler. So once we load
>> the shared l
Robert Haas writes:
> I can reproduce this, here. The problem seems to be that plpython
> only build either plpython2.so or plython3.so, but both languages
> expect a call handler called plython_call_handler. So once we load
> the shared library for one language, the other language just grabs th
On Wed, Jun 23, 2010 at 9:17 AM, gabrielle wrote:
> On Mon, Jun 21, 2010 at 6:16 PM, Robert Haas wrote:
>> Well, that might be a good idea, too, but my expectation is that:
>>
>> psql -f one -f two -f three
>>
>> ought to behave in a manner fairly similar to:
>>
>> cat one two three > all
>> psql
On Mon, Jun 21, 2010 at 6:16 PM, Robert Haas wrote:
> Well, that might be a good idea, too, but my expectation is that:
>
> psql -f one -f two -f three
>
> ought to behave in a manner fairly similar to:
>
> cat one two three > all
> psql -f all
>
> and it sounds like with this patch that's far fro
On Mon, Jun 21, 2010 at 12:46 PM, Guillaume Lelarge
wrote:
> Today, I tried to cancel the change of a tablespace for a table (ALTER
> TABLE ... SET TABLESPACE). I got the "Cancel request sent" but the query
> continued and finally succeed. It was a big issue for my customer, and I
> wanted to look
On Tue, Jun 22, 2010 at 10:41 PM, Chris wrote:
> I received two errors (described below) in installing 9.0beta2 on Kubuntu
> 10.04 , RhodiumToad on IRC recommended I post them here.
> I did not have a 2.x or 3.x python dev installed, but I was really only
> interested in python3 via plython3u.
> S
On Wed, Jun 23, 2010 at 2:26 AM, Tom Lane wrote:
> Uh, that doesn't fix anything: if you can't seek, a TOC at the end of
> the file is useless. And the cases where the writer can't seek are
> likely to be identically the ones where the reader can't seek, viz
> pg_dump piped to pg_restore (perhaps
On Wed, Jun 23, 2010 at 03:26, Tom Lane wrote:
> Andrew Dunstan writes:
>>> 4. Is there any value in back-porting the Windows FSEEKO support into
>>> 8.3 and 8.2? Arguably, not writing the data offsets is a performance
>>> bug. However a back-port won't do anything for people who are dumping
>>
29 matches
Mail list logo
