On 6 Feb 2011, at 18:52, Herouth Maoz wrote:
> on 06/02/11 18:16, quoting Tom Lane:
>>
>> Most likely, some other session requested an exclusive lock on the
>> table. Autovacuum will quit to avoid blocking the other query.
>>
> That's strange. During the day, only selects are running on that
Hi, Ahmed!
Thanks for checking this problem.
It is really a bug in Npgsql to convert the bytes value with ASCII encoder.
If we change that line to use the UTF-8 encoder, wouldn't it suffice
to fix this problem?
Also, wouldn't change the AuthenticationSSPI case to use context.Host
instead of Bra
On 02/04/2011 06:57 AM, pasman pasmański wrote:
Mage, add "raise notice" at the begin of your buggy trigger.
There is a little bit of difference between "Your trigger is wrong. You
try to insert the same row twice" and "The trigger will be fired twice."
You stated the first but the second is
Le dimanche 06 février 2011 à 12:27 -0500, Matt a écrit :
>
>
> On Sun, Feb 6, 2011 at 11:14 AM, ray joseph wrote:
> Matt,
>
> When you hand code SQL with Notepad++, how do you launch the
> code?
>
>
>
> There are several ways to launch the code. I u
I had the same issue last week,
I installed the Active Perl 5.10 and all worked ok
Paolo Saudin
Da: pgsql-general-ow...@postgresql.org
[mailto:pgsql-general-ow...@postgresql.org] Per conto di Sachin Srivastava
Inviato: domenica 6 febbraio 2011 18:30
A: Robert Fitzpatrick
Cc: PostgreSQL
on 06/02/11 18:16, quoting Tom Lane:
Most likely, some other session requested an exclusive lock on the
table. Autovacuum will quit to avoid blocking the other query.
That's strange. During the day, only selects are running on that
database, or at worst, temporary tables are being created
I can find the plperl.dll in the lib folder of my installation (Windows 7 32
bit).
How did you installed the postgresql-9.0.3?
On Feb 6, 2011, at 10:38 PM, Robert Fitzpatrick wrote:
> I am upgrading a Windows install for a client of mine from 8.2.x to
> 9.0.3 and understand the pginstaller does
On Sun, Feb 6, 2011 at 11:14 AM, ray joseph wrote:
> Matt,
>
>
>
> Thank you for your insightful view. I do not have a design for any of my
> design opportunities. This is one reason I was looking for a design tool.
> I have many work processes that are inter related, generated by different
>
I am upgrading a Windows install for a client of mine from 8.2.x to
9.0.3 and understand the pginstaller does not provide plperl for this
version. ActivePerl 5.8 was already installed and after uninstalling 8.2
and installing 9.0.3, there is no plperl.dll in the lib folder. I
thought this was due t
Herouth Maoz writes:
> Indeed autovacuum started working on some of the tables. At least one of
> these tables was one that I have trimmed up using CLUSTER. So I was watching
> that autovacuum process carefully. And then suddenly it was gone, after
> working for 20-odd hours. And I had even mor
Matt,
Thank you for your insightful view. I do not have a design for any of my
design opportunities. This is one reason I was looking for a design tool.
I have many work processes that are inter related, generated by different
groups that must transcribe data from each others artifacts. I do
On Saturday, February 05, 2011 6:22:47 pm ray joseph wrote:
>
> Thank you for the clarifications. I would like to address the guiding
> questions you presented:
>
> 1) What OS(s) do I want to deploy on? Windows, right now XP.
> 2) What programming language(s) do I want to work with? Python.
>
I prefer on demand solution, as it reduces latency and I can order vaccum at
night, when I have free CPU resources. At least auto vaccum on flush should be
configurable.
Kind regards,
Radek
pasman pasmański Saturday 05 February 2011 04:29:37
> Hi.
> I propose new feature.
> Before flushing pag
Hi there.
During the weekend I've worked for hours on recovering table bloat. Now I was
hoping that after the tables are properly trimmed, then after the next delete
operation which created dead tuples, autovacuum will go into effect and do its
job properly, and prevent the situation from recu
Adam PAPAI Sunday 06 February 2011 14:13:51
> Radosław Smogura wrote:
> > You need to create database with LC_COLLATE="hu_HU.utf8", e.g.
> >
> > CREATE DATABASE tx2 ENCODING='UTF-8' TEMPLATE=template0
> > LC_COLLATE='pl_PL.utf8';
>
> Are you running it under FreeBSD?
No, Gentoo. But, without cr
Thanks for the detailed answer and explanation.
I am curious if there is another way to force this behaviour. As a part
of my masters thesis I am trying to develop an index which heavily
relies on requesting blocks in parallel. Without knowing the code, do I
have to dive into it and change it manua
Radosław Smogura wrote:
> You need to create database with LC_COLLATE="hu_HU.utf8", e.g.
>
> CREATE DATABASE tx2 ENCODING='UTF-8' TEMPLATE=template0
> LC_COLLATE='pl_PL.utf8';
>
Are you running it under FreeBSD?
--
Adam PAPAI
BSD Support Service
http://www.bsdsupportservice.hu
E-mail: adam.pa
You need to create database with LC_COLLATE="hu_HU.utf8", e.g.
CREATE DATABASE tx2 ENCODING='UTF-8' TEMPLATE=template0
LC_COLLATE='pl_PL.utf8';
Kind regards,
Radosław Smogura
http://www.softperience.eu
Adam PAPAI Sunday 06 February 2011 11:02:25
> Adam PAPAI wrote:
> > Pavel Stehule wrote:
> >
On Sun, Feb 06, 2011 at 11:02:25AM +0100, Adam PAPAI wrote:
> I've tested it with 8.4 and 9.0 with locale=hu_HU.ISO8859-2,
> encoding=LATIN2, It's working correctly.
>
> But not with locale=hu_HU.UTF-8, encoding=UTF-8
>
> Is it related to the FreeBSD team or the PostgreSQL team?
Last I checked *
On Saturday 05 February 2011 18:42:09 John R Pierce wrote:
> On 02/05/11 9:30 AM, ray wrote:
> > I have built a few databases with MS Access and I would like to learn
> > how to use pgsql. I have found some ..
>
> Access really isn't a database, its an application development system
> that ha
Adam PAPAI wrote:
> Pavel Stehule wrote:
>> 2011/2/5 Adam PAPAI :
>
>> your system locales is correct? PostgreSQL uses only system libs
>
> I've tested it with a fresh 8.4 and 9.0.
>
> It's the same.
>
> My FreeBSD 8.1 supports hu_HU.UTF-8, but I don't know why it's not working.
I've tested i
Pavel Stehule wrote:
> 2011/2/5 Adam PAPAI :
> your system locales is correct? PostgreSQL uses only system libs
I've tested it with a fresh 8.4 and 9.0.
It's the same.
My FreeBSD 8.1 supports hu_HU.UTF-8, but I don't know why it's not working.
initdb output:
[root@titanium /usr/home/wooh]# /u
22 matches
Mail list logo