On Sat, Dec 18, 2010 at 20:29, David E. Wheeler wrote:
> On Dec 17, 2010, at 9:32 PM, David Christensen wrote:
> latin=# SELECT * FROM perlgets('“hello”');
> length │ is_utf8
> ┼─
> 11 │ f
>
> (Yes I used Latin-1 curly quotes in that last example).
Erm, latin1 do
folks,
Does postgres make an effort to create a file with physically continuous
blocks?
Thanks!
On 18/12/2010 1:13 AM, Magnus Hagander wrote:
On Fri, Dec 17, 2010 at 17:42, Magnus Hagander wrote:
On Fri, Dec 17, 2010 at 17:24, Craig Ringer wrote:
On 17/12/2010 7:17 PM, Magnus Hagander wrote:
Now, that's annoying. So clearly we can't use that function to
determine which version we're on
hi, folks!
I see that shared cache is implemented by system v shared memory. I wonder
whether data in this area can be swapped out to disk.
Isn't it bad that we read data from disk, put data in shared cache, and
finally data in shared cache is swapped to disk again!
Why not use shmctl(..SHM_LOCK.
On 17/12/2010 11:17 PM, Tom Lane wrote:
So I'd be happy to have it enabled - given that we want a default.
There is absolutely nothing more frustrating than having a crash dump
that hasn't got the information you need. Please turn it on by default.
There have to be limits to that, though. d
On Wed, Dec 15, 2010 at 9:20 AM, Florian Pflug wrote:
> On Dec14, 2010, at 15:01 , Robert Haas wrote:
>> On Tue, Dec 14, 2010 at 7:51 AM, Florian Pflug wrote:
- serializable lock consistency - I am fairly certain this needs
rebasing. I don't have time to deal with it right away. That
On Sat, Dec 18, 2010 at 10:43 PM, Itagaki Takahiro
wrote:
> On Sun, Dec 19, 2010 at 12:18, Robert Haas wrote:
>> I'm sort of suspicious of the fact that BeginCopyTo() is a shell
>> around BeginCopy() while BeginCopyFrom() does a whole bunch of other
>> stuff. I haven't grokked what the code is d
On Sat, Dec 18, 2010 at 10:04 PM, Robert Haas wrote:
> - Has the issue of changing custom_variable_classes from PGC_SIGHUP to
> PGC_SUSET been discussed? I am not sure whether that's an OK thing to
> do. If it is OK, then the documentation also needs updating.
>
> - This comment looks like lefto
On Sun, Dec 19, 2010 at 12:18, Robert Haas wrote:
> I'm sort of suspicious of the fact that BeginCopyTo() is a shell
> around BeginCopy() while BeginCopyFrom() does a whole bunch of other
> stuff. I haven't grokked what the code is doing here well enough to
> have a concrete proposal though...
I
On Dec 18, 2010, at 7:04 PM, Robert Haas wrote:
> - Did we decide to ditch the encoding parameter for extension scripts
> and mandate UTF-8?
+1
It was certainly suggested. I think it's a good idea, at least with a first cut.
Best,
David
--
Sent via pgsql-hackers mailing list (pgsql-hackers@p
On Dec 17, 2010, at 9:32 PM, David Christensen wrote:
> +1 on the original sentiment, but only for the case that we're dealing with
> data that is passed in/out as arguments. In the case that the
> server_encoding is UTF-8, this is as trivial as a few macros on the
> underlying SVs for text-li
On Fri, Dec 17, 2010 at 11:01 PM, Itagaki Takahiro
wrote:
> On Fri, Dec 17, 2010 at 11:49, Shigeru HANADA
> wrote:
>> I've just moved permission check and read-only check from BeginCopy()
>> to DoCopy(). Please see attached patch.
>
> Thanks!
>
> Are there any objections for the change? If acce
On Sat, Dec 18, 2010 at 2:39 PM, Dimitri Fontaine
wrote:
> Here it is, attached. The problem was of course due to git branches and
> missing local pulling and merging. Going gradually from 7 to 2 branches
> causes that, sometimes.
I spent a little time looking at this tonight. I'm going to give
Tomas Vondra writes:
> I've done several small changes to the patch, namely
> - added docs for the functions (in SGML)
> - added the same thing for background writer
> So I think now it's 'complete' and I'll add it to the commit fest in a
> few minutes.
Please split this into separate patches f
Dne 12.12.2010 03:47, Robert Haas napsal(a):
> On Sat, Dec 11, 2010 at 4:40 PM, wrote:
>>> Hello
>>>
>>> you have to respect pg coding style:
>>>
>>> a) not too long lines
>>> b) not C++ line comments
>>
>> OK, thanks for the notice. I've fixed those two problems.
>
> Please add this to the curr
On Dec 17, 2010, at 10:46 PM, Alex Hunsaker wrote:
>> But that's a separate issue from the, erm, inconsistency with which PL/Perl
>> treats encoding and decoding of its inputs and outputs.
>
> Yay! So I think we can finally agree that for Oleg's original test
> case postgres was getting right.
Andrew Dunstan wrote:
>
>
> On 12/18/2010 06:23 PM, Bruce Momjian wrote:
> >
> >> If you really think that pulling a port number out of the pid file is an
> >> improvement over what pg_ctl does now, then you need to start by storing
> >> the port number, as such, in the pid file. Not something t
On 12/18/2010 06:23 PM, Bruce Momjian wrote:
If you really think that pulling a port number out of the pid file is an
improvement over what pg_ctl does now, then you need to start by storing
the port number, as such, in the pid file. Not something that might or
might not be related to the po
Tom Lane wrote:
> Bruce Momjian writes:
> > Tom Lane wrote:
> >> Bruce Momjian writes:
> >>> pg_ctl already knows the data directory. If the file is missing, the
> >>> server is not running. If the file exists, the first number on the last
> >>> line, divided by 1000, is the port number.
>
> >
Bruce Momjian writes:
> Tom Lane wrote:
>> Bruce Momjian writes:
>>> pg_ctl already knows the data directory. If the file is missing, the
>>> server is not running. If the file exists, the first number on the last
>>> line, divided by 1000, is the port number.
>> That's somewhere between fragi
Tom Lane wrote:
> Bruce Momjian writes:
> > pg_ctl.c::test_postmaster_connection() has some fragile code that tries
> > to detect the server port number by looking in the pg_ctl -o string,
>
> It may be fragile, but it works; or at least I've not heard complaints
> about it lately.
True.
> > I
Bruce Momjian writes:
> pg_ctl.c::test_postmaster_connection() has some fragile code that tries
> to detect the server port number by looking in the pg_ctl -o string,
It may be fragile, but it works; or at least I've not heard complaints
about it lately.
> I think a simpler solution would be to
On Sat, Dec 18, 2010 at 12:27 PM, Kevin Grittner
wrote:
> Robert Haas wrote:
>
>> If there's any third-party code out there that is checking
>> rd_istemp, it likely also needs to be revised to check whether
>> WAL-logging is needed, not whether the relation is temp. The way
>> I've coded it, such
On 18/12/10 18:56, Jan Urbański wrote:
> I'm not a Python 3 expert, but I nicked some code from the Internet and
> came up with this patch (passes regression tests on both Python 2 and 3).
I tried to be too cute with the regression test, it fails with Python
2.3.7 (the latest 2.3 release).
Attach
pg_ctl.c::test_postmaster_connection() has some fragile code that tries
to detect the server port number by looking in the pg_ctl -o string,
postgresql.conf, the PGPORT environment variable, and finally using the
default port number.
I think a simpler solution would be to look in postmaster.pid:
Hi,
there seems to be a problem in the way we add exceptions to the plpy
module in PL/Python compiled with Python 3k.
Try this: DO $$ plpy.SPIError $$ language plpython3u;
I'm not a Python 3 expert, but I nicked some code from the Internet and
came up with this patch (passes regression tests on
Itagaki Takahiro writes:
> You probably compared wrong versions of source trees. The patch contains
> many diffs not related to EXTENSION. It cannot be applied cleanly.
Ouch, sorry about that, will revise soon'ish. Meanwhile the git repo is
still available here:
http://git.postgresql.org/git
Robert Haas wrote:
> If there's any third-party code out there that is checking
> rd_istemp, it likely also needs to be revised to check whether
> WAL-logging is needed, not whether the relation is temp. The way
> I've coded it, such code will fail to compile, and can be very
> easily fixed by s
Dne 18.12.2010 16:59, Florian Pflug napsal(a):
> On Dec18, 2010, at 08:10 , t...@fuzzy.cz wrote:
>
>>> On Dec17, 2010, at 23:12 , Tomas Vondra wrote:
Well, not really - I haven't done any experiments with it. For two
columns selectivity equation is
(dist(A) * sel(A) + dist(
bruce wrote:
> Magnus Hagander wrote:
> > I get a crash on win32 when connecting to a server that's not started.
> > In fe-connect.c, we have:
> >
> > display_host_addr = (conn->pghostaddr == NULL) &&
> > (strcmp(conn->pghost, host_addr) != 0);
> >
> > In my case,
On Dec18, 2010, at 08:10 , t...@fuzzy.cz wrote:
>> On Dec17, 2010, at 23:12 , Tomas Vondra wrote:
>>> Well, not really - I haven't done any experiments with it. For two
>>> columns selectivity equation is
>>>
>>> (dist(A) * sel(A) + dist(B) * sel(B)) / (2 * dist(A,B))
>>>
>>> where A and B a
31 matches
Mail list logo
