Hi hackers,
In the process of trying to unify the various text/cstring conversions
in the backend, I came across some stuff that seemed weird in
pg_convert().
>From src/backend/utils/mb/mbutils.c:345:
Datum
pg_convert(PG_FUNCTION_ARGS)
{
bytea *string = PG_GETARG_TEXT_P(0);
Is this
Tom Lane wrote:
> Idle thought here: did anything get done with the idea of decoupling
> main-table vacuum decisions from toast-table vacuum decisions? vacuum.c
> comments
>
> * Get a session-level lock too. This will protect our access to the
> * relation across multiple transactions,
On Mon, 24 Sep 2007, Jonah H. Harris wrote:
I agree. I'd prefer to know exactly what's going on in the atomic
code (rather than having the compiler take care of it for me).
Similarly, it's pretty rare to use GCC on anything but Linux and the
*BSDs as each proprietary UNIX vendor has their own c
Darcy Buskermolen wrote:
> On September 14, 2007 06:36 am, Alvaro Herrera wrote:
> > Darcy, please also apply the following patch and see if it reduces the
> > CPU consumption to a reasonable level.
>
> This is looking much better now too, it's brought the AVL down to near 0% CPU
> usage.
Tha
On 9/23/07, Tom Lane <[EMAIL PROTECTED]> wrote:
> It doesn't seem very interesting given that (a) we already have working
> code for this area, and (b) gcc is not our only target compiler.
I agree. I'd prefer to know exactly what's going on in the atomic
code (rather than having the compiler take
"Florian G. Pflug" <[EMAIL PROTECTED]> writes:
> When reading Tom's comment about the bug in my "use latestCompletedXid
> to slightly speed up TransactionIdIsInProgress" patch, I remembered that
> I recently stumbled across GCC builtins for atomic test-and-test and
> read/write reordering barrier
Chuck McDevitt wrote:
I was trying out the msvc support, and ran into a minor problem in the
install.bat/install.pl
If any files that are going to be installed are marked read-only, they
carry the read-only attribute with them when they get copied to the
install dir.
Then, if you try to
It seems like there isn't any good reason the perl scripts for the MSVC
build don't support readline
Readline for windows is available as part of the GnuWin32 project.
http://gnuwin32.sourceforge.net/packages/readline.htm
It normally installs to "c:\Program Files\GnuWin32"
I'd upda
I was trying out the msvc support, and ran into a minor problem in the
install.bat/install.pl
If any files that are going to be installed are marked read-only, they
carry the read-only attribute with them when they get copied to the
install dir.
Then, if you try to run install again, the ne
Hi
When reading Tom's comment about the bug in my "use latestCompletedXid
to slightly speed up TransactionIdIsInProgress" patch, I remembered that
I recently stumbled across GCC builtins for atomic test-and-test and
read/write reordering barriers...
Has anyone looked into those? It seems that
Hannes Eder wrote:
(a) use the current dir "." instead of "../.." for the *.sample files,
since there are the chdir's to ../../.. resp. to ../../../.. in line
28 resp. 29. Using ../.. would traverse a too large part of the
directory structure.
Actually, it should be restricted more, to sr
Magnus Hagander schrieb:
Tom Lane wrote:
Magnus Hagander <[EMAIL PROTECTED]> writes:
Andrew Dunstan wrote:
I have committed a fix that is somewhat similar to this. The Install.pm
module needs some love, but that will have to wait till the next cycle.
Thanks, Andrew!
"Tom Lane" <[EMAIL PROTECTED]> writes:
> Gregory Stark <[EMAIL PROTECTED]> writes:
>
> (It might be interesting to make textin produce a packed result when
> possible, just to see what breaks; but I would be afraid to try to do
> that for production...)
>
>> This all brings up the question of what
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Actually ... does stats_reset_on_server_start have a reason to live
>> at all?
> We also have a stats reset after recovery, and a function to reset it at
> the user's whim, so I agree that there doesn't seem to be any reason to
> keep
Am Sonntag, 23. September 2007 schrieb Tom Lane:
> Actually ... does stats_reset_on_server_start have a reason to live
> at all?
Kill it. It never made much sense to me anyway.
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
---(end of broadcast)---
On Sunday 23 September 2007 10:44, ஆமாச்சு wrote:
> On Sunday 23 Sep 2007 7:51:40 pm you wrote:
> > I believe both the pgAdmin III and phpPgAdmin projects (and probably
> > others) would also welcome any translation contributions you can give.
>
> That ought to be done.
>
> Hope they aren't there a
Tom Lane wrote:
Magnus Hagander <[EMAIL PROTECTED]> writes:
Andrew Dunstan wrote:
I have committed a fix that is somewhat similar to this. The Install.pm
module needs some love, but that will have to wait till the next cycle.
Thanks, Andrew!
Guys, would you comment
Tom Lane wrote:
> I wrote:
> > There wasn't any discussion of renaming stats_reset_on_server_start,
> > though logical consistency would seem to require this if we choose
> > a name not starting with stats_ for $merged_var.
>
> Actually ... does stats_reset_on_server_start have a reason to live
>
I wrote:
> There wasn't any discussion of renaming stats_reset_on_server_start,
> though logical consistency would seem to require this if we choose
> a name not starting with stats_ for $merged_var.
Actually ... does stats_reset_on_server_start have a reason to live
at all? It hardly seems like
Tom Lane wrote:
> Magnus Hagander <[EMAIL PROTECTED]> writes:
>> Andrew Dunstan wrote:
>>> I have committed a fix that is somewhat similar to this. The Install.pm
>>> module needs some love, but that will have to wait till the next cycle.
>
>> Thanks, Andrew!
>
> Guys, would you comment on whethe
Magnus Hagander <[EMAIL PROTECTED]> writes:
> Andrew Dunstan wrote:
>> I have committed a fix that is somewhat similar to this. The Install.pm
>> module needs some love, but that will have to wait till the next cycle.
> Thanks, Andrew!
Guys, would you comment on whether this patch closes all the
[ just when you thought it was safe to go back in the water ]
In threads starting here and here:
http://archives.postgresql.org/pgsql-hackers/2007-07/msg00874.php
http://archives.postgresql.org/pgsql-hackers/2007-08/msg00043.php
I believe we had reached consensus on the following points:
* log_au
Andrew Dunstan wrote:
> Hannes Eder wrote:
>> Magnus Hagander wrote:
>> >Hannes Eder wrote:
>> >> Is it worth doing this the "Perl-way" and using File::Find? If so,
>> I can
>> >> work an a patch for that.
>> >>
>> > It's certainly cleaner that way, but I don't find it a major issue.
>> But I'd
>>
Gregory Stark <[EMAIL PROTECTED]> writes:
> This may have been a misdiagnosis of the buildfarm failures but it looks like
> a correct bug fix to me. That is, it looks like regexp_split_to_array() was
> capable of passing a packed varlena to setup_regexp_matches which wasn't
> expecting it. But this
Robert Treat <[EMAIL PROTECTED]> writes:
> Just curious, but does this apply to subtransactions that are the result of
> plpgsql try...exception blocks?
Only if they changed the database; else they won't have XIDs.
regards, tom lane
---(end of bro
On Sunday 23 Sep 2007 7:51:40 pm you wrote:
> I believe both the pgAdmin III and phpPgAdmin projects (and probably
> others) would also welcome any translation contributions you can give.
That ought to be done.
Hope they aren't there at,
http://pgtranslation.projects.postgresql.org/status.html
On Friday 21 September 2007 05:47, Heikki Linnakangas wrote:
> ஆமாச்சு wrote:
> > I am Sri Ramadoss from, Chennai, India interested in forming & taking up
> > the responsibility of Localising Postgre into my native language Tamil.
> >
> > I am also interested in forming a Community for Postgre in T
On Friday 21 September 2007 13:02, Tom Lane wrote:
> I wrote:
> > Dunno about "more general", but your idea reduces the runtime of this
> > example by about 50% (22.2s to 10.5s) for me. I'm worried though that
> > it would be a net negative in more typical situations, especially if
> > you've got
Gregory Stark wrote:
"Tom Lane" <[EMAIL PROTECTED]> writes:
Gregory Stark <[EMAIL PROTECTED]> writes:
Ok, this removes what should be most if not all of the call sites where we're
detoasting text or byteas. In particular it gets all the regexp/like functions
and all the trim/pad func
"Tom Lane" <[EMAIL PROTECTED]> writes:
> Gregory Stark <[EMAIL PROTECTED]> writes:
>> Ok, this removes what should be most if not all of the call sites where we're
>> detoasting text or byteas. In particular it gets all the regexp/like
>> functions
>> and all the trim/pad functions. It also gets
30 matches
Mail list logo
