Re: [HACKERS] [PATCH] Enabling atomics on ARM64

On Fri, Mar 10, 2017 at 11:20 AM, Andres Freund wrote: > Hi, > > On 2017-03-08 19:18:04 -0800, Roman Shaposhnik wrote: >> I'd like to offer a forward port from a change I'm contributing >> the Greenplum code base over here > > I think the change makes sense.

[HACKERS] [PATCH] Enabling atomics on ARM64

x0, [x0] 148: d2800041 mov x1, #0x2 // #2 14c: 97e6 bl e4 150: 5280 mov w0, #0x0 // #0 154: a8c17bfd ldp x29, x30, [sp],#16 158: d65f03c0 ret Thanks, Roman. 0001-Enabling-atomics-on-ARM64.patch Description: Binary data -- Sent via pgsql-hacker

[HACKERS] Students enrollment

..@gmail.com or Skype: rprykhodchenko Sincerely, Roman Prykhodchenko -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

[HACKERS] [pgsql-general 2011-1-21:] Are there any projects interested in object functionality? (+ rule bases)

Dear all, for the sake academic teaching, a colleague asked me in how far PostgreSQL does support object functionality these days. I am afraid my web research was not very fruitful to him; the impression is that hardly anybody is occupied in working on PostgreSQL object functionality -- have

Re: [HACKERS] BUG #5237: strange int->bit and bit->int conversions

The bitfromint8() and bitfromint4() are hosed. They produce wrong results when the BIT size is more than 64 and 32 respectively, and the BIT size is not multiple of 8, and the most significant byte of the integer value is not 0x00 or 0xff. For example: test=# select (11::int4<<23 | 11::int4):

[HACKERS] Can't replace default converter.

Hello! There is a database in KOI8-R encoding. And we have a client who is querying the database: set client_encoding TO 'ALT' and then he write some data into the database. I have a problem with some symbols which exists in ALT encoding and which are absent in KOI8-R encoding. As result, duri

Re: [HACKERS] UUID generation functions

# [EMAIL PROTECTED] / 2007-04-11 14:27:47 +0200: > I have built some UUID generation functions using the library at > . This should cover all the usual ways to > do it, and it also provides some special constants that could be useful. There's already a mapping

Re: [HACKERS] [DOCS] uuid type not documented

# [EMAIL PROTECTED] / 2007-04-10 15:49:08 -0400: > Neil Conway wrote: > >On Tue, 2007-04-10 at 18:28 +0200, Peter Eisentraut wrote: > > > >>The problem is that most of the standard methods are platform dependent, > >>as they require MAC addresses or a "good" random source, for instance. > >>

Re: [HACKERS] [PATCHES] [BUGS] BUG #2846: inconsistent and confusing handling

; numeric conversions should reject INF. A slightly less radical proposal is to reject only the case where isinf(result) and neither input isinf(); and perhaps likewise with respect to NaNs. This might look like another possibility for confusion. For example INF-INF

Re: [HACKERS] [PATCHES] [BUGS] BUG #2846: inconsistent and confusing

On 12/29/2006 11:27 AM, Tom Lane wrote: Doesn't even compile here (no ). Where do you compile? Roman ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org

Re: [HACKERS] [PATCHES] [BUGS] BUG #2846: inconsistent and confusing

ou need to restart the postmaster. It can be fixed by re-enabling FP exceptions in the FP exception handler. Roman - ~/postgresql-8.2.0/src/backend/utils/adt>diff -U3 -p float.orig.c float.c --- float.orig.c2006-12-29 10:49:51.0 -0600 +++ float.c

Re: [HACKERS] [PATCHES] [BUGS] BUG #2846: inconsistent and confusing handling

On 12/27/2006 05:19 PM, Tom Lane wrote: Roman Kononov <[EMAIL PROTECTED]> writes: On 12/27/2006 03:23 PM, Bruce Momjian wrote: Are you sure? As I remember, computation automatically upgrades to 'double'. See this program and output: This is platform- and compiler- depe

Re: [HACKERS] 8.2 features status

# kleptog@svana.org / 2006-08-05 15:49:33 +0200: > On Fri, Aug 04, 2006 at 06:25:35PM -0700, Joshua D. Drake wrote: > > I have heard you make this argument before, and it is just is not true. > > Even Debian is moving toward a more formal structure as has FreeBSD. You > > seem stuck in this world

Re: [HACKERS] FreeBSD ICU was Win32 unicode vs ICU

# kleptog@svana.org / 2006-03-26 15:53:24 +0200: > On Sun, Mar 26, 2006 at 02:13:28PM +0200, Roman Neuhauser wrote: > > > Afaict, from the ICU website, ICU too uses CLDR. > > > Why reinvent the wheel? > > > > Just a thought: PHP is under a BSD-like (Apache-

Re: [HACKERS] FreeBSD ICU was Win32 unicode vs ICU

# [EMAIL PROTECTED] / 2005-08-25 04:53:47 +1000: > Kevin McArthur Wrote: > > > Should the postgresql project also be looking at CLDR for > > cross-platform unicode support? > > Afaict, from the ICU website, ICU too uses CLDR. > Why reinvent the wheel? Just a thought: PHP is under a BSD-like

Re: [HACKERS] ipcclean in 8.1 broken?

# [EMAIL PROTECTED] / 2006-03-01 12:49:13 +0100: > Am Dienstag, 28. Februar 2006 07:42 schrieb Christopher Kings-Lynne: > > I just tried using ipcclean in 8.1.3. It doesn't work when I su to the > > pgsql user. This part of the script: > > > > if [ "$USER" = 'root' -o "$LOGNAME" = 'root' ] > > >

Re: [HACKERS] bug #1702: nested composite types in plpgsql

# [EMAIL PROTECTED] / 2005-09-13 12:17:06 -0400: > Roman Neuhauser <[EMAIL PROTECTED]> writes: > > Looking at src/pl/plpgsql/src/pl_exec.c for the first time, is it a problem > > of make_tuple_from_row() not accounting for nested composite types? > > Looks that way. I

[HACKERS] bug #1702: nested composite types in plpgsql

Hello, I'm getting this error with the code below (on 8.0.3 like the other guy in #1702. Is this a hard problem to fix? Looking at src/pl/plpgsql/src/pl_exec.c for the first time, is it a problem of make_tuple_from_row() not accounting for nested composite types? test=# SELECT takes_ct2parts(1, A

Re: [HACKERS] uuid type for postgres

# [EMAIL PROTECTED] / 2005-09-06 17:54:34 -0400: > There's a fair amount of nearly > unmaintained cruft in the core distro already (eg, the never-finished > "line" datatype ... or the entire rtree index module ...) and a datatype > that might be used by only a few people is a likely candidate to be

[HACKERS] Getting dump from old version

Hi! I use postgres6.1. Before install new version I do not make dump_all, but I move /usr/local/pgsql to /usr/local/pgsql_bk. After that I successfuly install new version to /usr/local/pgsql. But now I need some data from old postgres. I try to do this: % kill postmaster_id % mv /usr/local