On Dec 19, 2011, at 10:49 AM, manojk.softengin...@gmail.com wrote:
> The following bug has been logged on the website:
>
> Bug reference: 6345
> Logged by: manoj
> Email address: manojk.softengin...@gmail.com
> PostgreSQL version: 9.1.2
> Operating system: window 7
> Descrip
1. Yes, obviously I launched that command when the program was blocked.
2. The system release is "SUSE SLES 10 SP4 64 BIT" with kernel 2.6.16.60.
Maybe it's not the last release but it can justify the blocks ? In other
systems (VMWARE) the same system work fine.
What you suspect ? libpq ? linux
On Sun, Dec 18, 2011 at 5:42 PM, Martin Pitt wrote:
>> It probably makes sense to use it on any platform where it's
>> defined. Presumably an implementation provided by the compiler is
>> always going to be at least as good as any magic assembler
>> incantations we can come up with.
>
> I agree. H
That's great.
Thanks for doing this and getting back to us.
Andrew Milne
On 18/12/11 17:50, Michael Meskes wrote:
On Fri, Nov 25, 2011 at 12:51:51PM +, Andrew Milne wrote:
The ECPG pre-processor seems to be incorrectly reporting an error when
parsing "EXEC SQL AT :cnx DEALLOCATE..." style
The following bug has been logged on the website:
Bug reference: 6346
Logged by: Marcel Arts
Email address: ma...@jambo-software.com
PostgreSQL version: Unsupported/Unknown
Operating system: unix
Description:
Hi,
I try to unsubscribe but your systen says my email doe
On 19.12.2011 16:31, Robert Haas wrote:
On Sun, Dec 18, 2011 at 5:42 PM, Martin Pitt wrote:
It probably makes sense to use it on any platform where it's
defined. Presumably an implementation provided by the compiler is
always going to be at least as good as any magic assembler
incantations we c
Hi, Craig
Now my process is blocked and I have the case in my hands.
Do you have something to ask me in order to have more details ?
Regards, Andrea
-Messaggio originale-
Da: Craig Ringer [mailto:ring...@ringerc.id.au]
Inviato: sabato 17 dicembre 2011 7.19
A: Andrea Grassi
Cc: pgsql-bugs
The following bug has been logged on the website:
Bug reference: 6347
Logged by: Alexander Fortin
Email address: alexander.for...@gmail.com
PostgreSQL version: 9.1.2
Operating system: Ubuntu 10.04.3
Description:
Hi folks. I'm testing 9.1.2 (source compiled) pg_upgrade
Heikki Linnakangas writes:
> On 19.12.2011 16:31, Robert Haas wrote:
>> On Sun, Dec 18, 2011 at 5:42 PM, Martin Pitt wrote:
>>> I agree. How about a patch like this? It uses builtin atomics if
>>> available, and falls back to the custom implementations if not.
>> -1. Absent some evidence that g
Robert Haas [2011-12-19 9:31 -0500]:
> On Sun, Dec 18, 2011 at 5:42 PM, Martin Pitt wrote:
> >> It probably makes sense to use it on any platform where it's
> >> defined. Presumably an implementation provided by the compiler is
> >> always going to be at least as good as any magic assembler
> >>
Heikki Linnakangas [2011-12-19 17:09 +0200]:
> One thing that caught my eye: if you use __sync_lock_and_test() to
> implement S_LOCK(), you really should be using __sync_lock_release()
> for S_UNLOCK().
Right, the patch I send does that:
#define S_UNLOCK(lock) __sync_lock_release(lock)
Martin
-
Tom Lane [2011-12-19 10:25 -0500]:
> Heikki Linnakangas writes:
> > On 19.12.2011 16:31, Robert Haas wrote:
> >> On Sun, Dec 18, 2011 at 5:42 PM, Martin Pitt wrote:
> >>> I agree. How about a patch like this? It uses builtin atomics if
> >>> available, and falls back to the custom implementations
On 19.12.2011 17:39, Martin Pitt wrote:
Heikki Linnakangas [2011-12-19 17:09 +0200]:
One thing that caught my eye: if you use __sync_lock_and_test() to
implement S_LOCK(), you really should be using __sync_lock_release()
for S_UNLOCK().
Right, the patch I send does that:
#define S_UNLOCK(lo
On 19.12.2011 17:25, Tom Lane wrote:
Heikki Linnakangas writes:
On 19.12.2011 16:31, Robert Haas wrote:
Actually, I believe our Itanium (and possibly ARM, too) implementation
of S_UNLOCK() is wrong as it is.
Hmm. Anybody got a large itanium box we could play with? If it is
wrong, I'd expect
Robert Haas [2011-12-19 9:31 -0500]:
> -1. Absent some evidence that gcc's implementations are superior to
> ours, I think we should not change stuff that works now. That's
> likely to lead to subtle bugs that are hard to find and perhaps
> dependent on the exact compiler version used.
>
> But
Excerpts from marts's message of lun dic 19 10:53:37 -0300 2011:
> Hi,
>
> I try to unsubscribe but your systen says my email does not exist??!!?
>
> your email:
> unsubscribe pgsql-announce
> The unsubscribe command did not succeed.
>
> No e-mail addresses matching
>
On Mon, Dec 19, 2011 at 05:09:11PM +0200, Heikki Linnakangas wrote:
> Actually, I believe our Itanium (and possibly ARM, too) implementation
> of S_UNLOCK() is wrong as it is. There is no platform-specific
> S_UNLOCK() defined for Itanium, so we're using the generic
> implementation:
>
> #if !
Noah Misch writes:
> On Mon, Dec 19, 2011 at 05:09:11PM +0200, Heikki Linnakangas wrote:
>> That is not sufficient on platforms with a weak memory model, like Itanium.
> Other processors may observe the lock as held after its release, but there's
> no
> correctness problem.
How weak is the memo
On 19.12.2011 22:03, Noah Misch wrote:
On Mon, Dec 19, 2011 at 05:09:11PM +0200, Heikki Linnakangas wrote:
Actually, I believe our Itanium (and possibly ARM, too) implementation
of S_UNLOCK() is wrong as it is. There is no platform-specific
S_UNLOCK() defined for Itanium, so we're using the gene
On 19.12.2011 22:12, Tom Lane wrote:
Noah Misch writes:
On Mon, Dec 19, 2011 at 05:09:11PM +0200, Heikki Linnakangas wrote:
That is not sufficient on platforms with a weak memory model, like Itanium.
Other processors may observe the lock as held after its release, but there's no
correctness
On Mon, Dec 19, 2011 at 11:25:06PM +0200, Heikki Linnakangas wrote:
> I compiled the attached test program on an HP Itanium box, using the
> same flags you get from PostgreSQL's configure on that box. The relevant
> assembler output is:
>
> xchg4 r14 = [r15], r14 //
21 matches
Mail list logo
