The following bug has been logged online:
Bug reference: 2379
Logged by: Philip Warner
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.0.7
Operating system: FreeBSD
Description:Duplicate pkeys in table
Details:
We have an intermittent bug that occurs on a tab
""Brock Peabody"" <[EMAIL PROTECTED]> wrote
>
> Do you think this is a Windows only problem?
>
I am afraid so. We have received 3 reports of this (or quite similar)
problem, all in 8.1/windows. I just noticed that yours is actually an EAGAIN
error, so the loop patch in semctl() doesn't work I gue
On Wed, 5 Apr 2006, Tom Lane wrote:
"Bjoern A. Zeeb" <[EMAIL PROTECTED]> writes:
A datagram socket (SOCK_DGRAM) is called "UDP Socket" when it
assumes IP (AF_INET) or IPv6 (AF_INET6) as it's underlying
protocol.
But you can always use SOCK_DGRAM over AF_LOCAL.
I'm unconvinced that that has th
> On Behalf Of Tom Lane
> Perhaps you could whittle down your app into a testbed that just sends
> dummy data with about the same timing as the real app?
I think I'm starting to get a better understanding of problem. It looks
like one of the threads is trying to insert a pathological (~1,800,00
"Bjoern A. Zeeb" <[EMAIL PROTECTED]> writes:
> A datagram socket (SOCK_DGRAM) is called "UDP Socket" when it
> assumes IP (AF_INET) or IPv6 (AF_INET6) as it's underlying
> protocol.
> But you can always use SOCK_DGRAM over AF_LOCAL.
I'm unconvinced that that has the same semantics on all platforms
On Wed, 5 Apr 2006, Tom Lane wrote:
Hi,
"Bjoern A. Zeeb" <[EMAIL PROTECTED]> writes:
Is there any reason why you explicitly disallow a posix local socket
at that point in backend/postmaster/pgstat.c:pgstat_init:
Because we want UDP, not a Unix socket.
what you are giving there as hints is
"Qingqing Zhou" <[EMAIL PROTECTED]> writes:
> AFAICS, int32 and int are exactly the same thing in PostgreSQL. For the
> machine int is not 32 bits long, PostgreSQL won't even run.
Ideally we should operate correctly if "int" is 64 bits. In practice
I agree that making contrib work would be mighty
"Bjoern A. Zeeb" <[EMAIL PROTECTED]> writes:
> Is there any reason why you explicitly disallow a posix local socket
> at that point in backend/postmaster/pgstat.c:pgstat_init:
Because we want UDP, not a Unix socket.
regards, tom lane
---(end of bro
"Brock Peabody" <[EMAIL PROTECTED]> writes:
>> Can you reliablly reproduce the problem?
> I can here :). I'm trying to figure out a way for someone to repeat it
> outside my environment but I'm afraid it's got something to do with
> timing. I have 50 threads that are collecting data. If I give
On Fri, 7 Jun 2002, Bruce Momjian wrote:
Hi,
it's been some months so I left the fullquote attached.
Well, you are the first to report that 127.0.0.1 doesn't work for stats.
Unless someone else has a problem, I think we will leave it unchanged.
The last years this problem was disucced sever
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:pgsql-bugs-
> [EMAIL PROTECTED] On Behalf Of Qingqing Zhou
> Sent: Wednesday, April 05, 2006 6:33 AM
> To: pgsql-bugs@postgresql.org
> Subject: Re: [BUGS] BUG #2371: database crashes with semctl failed
> error
> Can you reliablly rep
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:pgsql-bugs-
> [EMAIL PROTECTED] On Behalf Of Qingqing Zhou
> Sent: Wednesday, April 05, 2006 6:33 AM
> To: pgsql-bugs@postgresql.org
> Subject: Re: [BUGS] BUG #2371: database crashes with semctl failed
error
>
>
> ""Brock Pe
Tom Lane wrote:
> I'm far from an expert on this, but the gettext documentation
> indicates that it tries to translate the .po file contents into
> whatever encoding is implied by LC_CTYPE.
Correct. That is just one more reason to have server encoding,
LC_COLLATE, and LC_CTYPE matching. In prac
Euler Taveira de Oliveira wrote:
> Tom Lane wrote:
>
> >It seems to me that there basically is no graceful solution to this sort
> >of mismatch. It might be possible to kluge things so that we disable
> >NLS once we've recursed too many times in error processing, but that's
> >surely pretty ugly.
<[EMAIL PROTECTED]> wrote
> In "g_int_compress" :
>
>
> int*dr;
> ...
> memmove((void *) &dr[cand - 1], (void *) &dr[cand + 1], (len - cand -
> 1) * sizeof(int));
>
> Should be
>
> int32 *dr;
> ...
> memmove((void *) &dr[cand - 1], (void *) &dr[cand + 1], (len - cand -
> 1)
""Brock Peabody"" <[EMAIL PROTECTED]> wrote
>
> FATAL: semctl(167894456, 4, SETVAL, 0) failed: A non-blocking socket
> operation could not be completed immediately.
>
Can you reliablly reproduce the problem? If so, we may come up with a
testing patch to it. We encounter similar problems before b
In "g_int_compress" :
int*dr;
...
memmove((void *) &dr[cand - 1], (void *) &dr[cand + 1], (len - cand -
1) * sizeof(int));
Should be
int32 *dr;
...
memmove((void *) &dr[cand - 1], (void *) &dr[cand + 1], (len - cand -
1) * sizeof(int32));
--
On 4/3/06, Tom Lane <[EMAIL PROTECTED]> wrote:
(...)You need to read up on SECURITY DEFINER functions.regards, tom lane Ok, I'll do this way, but still don't understand why it doesn't returns. I'm doing things simillar to this to create users automatically, and works fin
18 matches
Mail list logo
