[HACKERS] orafce on 64 bit windows

Hello I released 3.0.3 version of PostgreSQL. Please, can somebody to create package for 64 bit windows and test it? Regards Pavel Stehule -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hacke

[HACKERS] Question regarding psql or libpq

Hi, It seems psql(or libpq) connects to PostgreSQL twice when md5 auth is required. Here is a strace log on my Linux machine. Is there any reason for this? IMO frontend/backend protocol allows to send salt after receiving AuthenticationMD5Password using the same socket. So there's no reason to cl

Re: [HACKERS] Complier warnings on mingw gcc 4.5.0

Andrew Dunstan writes: > On 12/15/2010 08:46 PM, Tom Lane wrote: >> We can't change the meaning of HAVE_INT_OPTRESET because that would >> break the declaration logic in getopt.c. I'm thinking we have to >> complicate the #if logic in postmaster.c and postgres.c. > I agree. >> Will look >> into

Re: [HACKERS] Complier warnings on mingw gcc 4.5.0

On 12/15/2010 08:46 PM, Tom Lane wrote: I believe #2 is in fact necessary. When I tried just #1 before it failed. What's the best way to do #2 cleanly? We can't change the meaning of HAVE_INT_OPTRESET because that would break the declaration logic in getopt.c. I'm thinking we have to compli

Re: [HACKERS] getting composite types info from libpq

On Wed, Dec 15, 2010 at 6:56 PM, Merlin Moncure wrote: > On Wed, Dec 15, 2010 at 1:25 PM, Daniele Varrazzo > wrote: >> Hello, >> >> when a query returns a composite type, the libpq PQftype() function >> reports the oid of the "record" type. In psycopg: >> >>    >>> cur.execute("select (1,2)") >>

Re: [HACKERS] Complier warnings on mingw gcc 4.5.0

Andrew Dunstan writes: > On 12/15/2010 07:24 PM, Tom Lane wrote: >> Should we backpatch either of these things? > Yes. We need it to back at least to 9.0. On reflection I think we probably better fix it back to 8.2, since we're supposedly supporting Windows on all those branches, and somebody mi

Re: [HACKERS] Complier warnings on mingw gcc 4.5.0

On 12/15/2010 07:24 PM, Tom Lane wrote: Huh, I wonder why it doesn't match what's in sourceforge CVS? Sourceforge's CVS is way out of date. CVS tip for the getopt.h is here:

Re: [HACKERS] Complier warnings on mingw gcc 4.5.0

On 12/15/2010 07:24 PM, Tom Lane wrote: So I concur with the previous suggestions: 1. Make this problem go away by forcing use of our getopt code on mingw. 2. Make sure we reset optreset when using our code. (Probably not really necessary, but let's just be careful.) Should we backpatch ei

Re: [HACKERS] Complier warnings on mingw gcc 4.5.0

Andrew Dunstan writes: > On 12/15/2010 06:42 PM, Tom Lane wrote: >> Hm, where did you get this? > I downloaded > > > which is allegedly the source for the l

Re: [HACKERS] Complier warnings on mingw gcc 4.5.0

On 12/15/2010 06:42 PM, Tom Lane wrote: Andrew Dunstan writes: Mingw code attached. Hm, where did you get this? Because it does have optreset, albeit in a gratuitously ABI-incompatible fashion: #ifdef _BSD_SOURCE /* * BSD adds the non-standard `optreset' feature, for reinitialisation

Re: [HACKERS] Complier warnings on mingw gcc 4.5.0

Andrew Dunstan writes: > Mingw code attached. Hm, where did you get this? Because it does have optreset, albeit in a gratuitously ABI-incompatible fashion: > #ifdef _BSD_SOURCE > /* > * BSD adds the non-standard `optreset' feature, for reinitialisation > * of `getopt' parsing. We support thi

Re: [HACKERS] Fix for seg picksplit function

Yeb Havinga writes: > I think it is time to mark this patch ready for committer: > The unintuitive result thus far is that sorting outperforms the R-tree > bounding boxes style index, as Alexander has demonstrated with several > different distributions on 20-11 (uniform, natural (is that a bell

Re: [HACKERS] BufFreelistLock

On Dec 15, 2010, at 2:40 PM, Jeff Janes wrote: > On Tue, Dec 14, 2010 at 1:42 PM, Jim Nasby wrote: >> >> On Dec 14, 2010, at 11:08 AM, Jeff Janes wrote: >>> I wouldn't expect an increase in shared_buffers to make contention on >>> BufFreelistLock worse. If the increased buffers are used to hold

Re: [HACKERS] range intervals in window function frames

Excerpts from Daniel Popowich's message of mié dic 15 15:02:05 -0300 2010: > 1) Is there active work on window functions with frames over > interval ranges? Yeah, we had a patch for that but it was rejected; only ROWS was implemented. RANGE needed more work; not sure if the patch author i

Re: [HACKERS] Default mode for shutdown

On Wed, Dec 15, 2010 at 16:11, Alvaro Herrera wrote: > Excerpts from Robert Haas's message of mié dic 15 12:03:06 -0300 2010: > >> Certainly, if you have an environment where people are mostly logging >> into the database directly (not through a connection pooler) and they >> do a few important qu

Re: [HACKERS] Default mode for shutdown

On Wed, Dec 15, 2010 at 15:47, Tom Lane wrote: > Robert Haas writes: >> On Wed, Dec 15, 2010 at 9:39 AM, Tom Lane wrote: >>> Really?  Personally I'm quite happy with that default. > >> Why?  It seems to me that just leads to, oh, gee, the database isn't >> shutting down, where's the window where

Re: [HACKERS] hstores in pl/python

On Dec15, 2010, at 16:34 , Jan Urbański wrote: > On 15/12/10 16:25, Dmitriy Igrishin wrote: >> 2010/12/15 Jan Urbański >>> So how about just adding a text column to pg_type and a IDENTIFIER >>> keywork to CREATE TYPE. It's not guaranteed to be unique, but isn't it >>> pushing the argument to the e

Re: [HACKERS] hstores in pl/python

2010/12/15 Dmitriy Igrishin : > > > 2010/12/15 Florian Pflug >> >> On Dec15, 2010, at 18:33 , Dmitriy Igrishin wrote: >> > 2010/12/15 Florian Pflug >> > On Dec15, 2010, at 16:18 , Dmitriy Igrishin wrote: >> > >> 2010/12/15 Florian Pflug >> > >> On Dec15, 2010, at 02:14 , James William Pye wrote:

Re: [HACKERS] hstores in pl/python

2010/12/15 Robert Haas > On Wed, Dec 15, 2010 at 2:14 PM, Robert Haas > wrote: > > On Wed, Dec 15, 2010 at 1:22 PM, Dmitriy Igrishin > wrote: > >> Yes, but range of PostgreSQL's OIDs can be reserved. One or even ten > >> millions, e.g. can be enough. > > > > No, they can't. PostgreSQL is alrea

Re: [HACKERS] pg_execute_from_file, patch v10

On Wed, Dec 15, 2010 at 12:55, Robert Haas wrote: >>> It seems like pg_read_binary_file() is good to have regardless of >>> whatever else we decide to do here.  Should we pull that part out and >>> commit it separately? >> > The whole-file versions seem like a good idea - my only hesitation is, >

Re: [HACKERS] hstores in pl/python

2010/12/16 Florian Pflug > On Dec15, 2010, at 21:28 , Dimitri Fontaine wrote: > > Florian Pflug writes: > >> Not if CREATE EXTENSION allows you install hstore into an arbitrary > schema. > > > > It also allows you to change it after the fact, and to easily track it > > down. Here's an updated ve

Re: [HACKERS] hstores in pl/python

On Dec15, 2010, at 21:28 , Dimitri Fontaine wrote: > Florian Pflug writes: >> Not if CREATE EXTENSION allows you install hstore into an arbitrary schema. > > It also allows you to change it after the fact, and to easily track it > down. Here's an updated version of the query to find the hstore ty

Re: [HACKERS] Complier warnings on mingw gcc 4.5.0

On 12/15/2010 04:26 PM, Tom Lane wrote: Anyway seems like the next step is to compare the Fedora getopt code with mingw's ... Mingw code attached. cheers andrew #ifndef __GETOPT_H__ /* * getopt.h * * $Id: getopt.h,v 1.4 2009/01/04 17:35:36 keithmarshall Exp $

Re: [HACKERS] mvcc & DML on the same row

2010/12/15 matteo durighetto : > But why we need all these versions of the same row on table, if for > rollback we need only the original row X (X0) ? And the "previous" value of row X during the execution of a statement (because statements don't see their own changes, think INSERT INTO a SELECT

Re: [HACKERS] mvcc & DML on the same row

On Wed, Dec 15, 2010 at 2:50 PM, matteo durighetto wrote: > Hi, >    I have an idea about mvcc and different DML of the same row in the > same transaction. > Normally when a backend do an unpdate on a row ( call it X ) , we done > an insert and logical delete on this row  (0,1,2..N are the "versio

Re: [HACKERS] Complier warnings on mingw gcc 4.5.0

Andrew Dunstan writes: > On my Fedora box, man 3 getopt says this: > A program that scans multiple argument vectors, or rescans the same > vector more than once, and wants to make use of GNU extensions such > as '+' and '-' at the start of optstring, or changes the value of > P

Re: [HACKERS] Complier warnings on mingw gcc 4.5.0

On 12/15/2010 03:52 PM, Tom Lane wrote: Andrew Dunstan writes: And here is where it changed: * A replacement implementation for the getopt() family of functions, adding support for the GNU getopt_long_only() function

Re: [HACKERS] Complier warnings on mingw gcc 4.5.0

Andrew Dunstan writes: > And here is where it changed: > > * A replacement implementation for the getopt() family of functions, >adding support for the GNU getopt_long_only() function. Users >should note that th

Re: [HACKERS] BufFreelistLock

On Tue, Dec 14, 2010 at 1:42 PM, Jim Nasby wrote: > > On Dec 14, 2010, at 11:08 AM, Jeff Janes wrote: > >> I wouldn't expect an increase in shared_buffers to make contention on >> BufFreelistLock worse.  If the increased buffers are used to hold >> heavily-accessed data, then you will find the pa

Re: [HACKERS] hstores in pl/python

Florian Pflug writes: > Not if CREATE EXTENSION allows you install hstore into an arbitrary schema. It also allows you to change it after the fact, and to easily track it down. Here's an updated version of the query to find the hstore type OID reliably once we have extensions in: dim=# SELECT t.

Re: [HACKERS] Complier warnings on mingw gcc 4.5.0

On 12/15/2010 02:22 PM, Andrew Dunstan wrote: On 12/15/2010 02:06 PM, Tom Lane wrote: Andrew Dunstan writes: And the attached hack allowed "make check" to succeed. I think the logic in tcop/postgres.c and postmaster/postmaster.c is probably wrong. If we are using our getopt/getopt_long, we

Re: [HACKERS] hstores in pl/python

On tis, 2010-12-14 at 11:52 -0500, Tom Lane wrote: > Peter Eisentraut writes: > > On mån, 2010-12-13 at 08:50 +0100, Jan Urbański wrote: > >> It would be cool to be able to transparently use hstores as Python > >> dictionaries and vice versa. It would be easy enough with hstore as a > >> core type

Re: [HACKERS] Segfault related to pg_authid when running initdb from git master

On 15 December 2010 19:43, Robert Haas wrote: > Gah.  I assumed you had cleaned out your tree.  Oh, well. > > If you don't use --enable-depend, you can get this kind of issue. > Even if you do, it's worth trying a full clean out (I use git clean > -dfx) if you get something weird. Thanks for the

Re: [HACKERS] Hot Standby: too many KnownAssignedXids

On Tue, Dec 7, 2010 at 3:42 AM, Heikki Linnakangas wrote: > Ok, I've committed this patch now. I can confirm that I could continue replaying the logfiles on the standby host with this patch. Thanks a lot, Joachim -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make ch

Re: [HACKERS] Segfault related to pg_authid when running initdb from git master

Excerpts from Peter Geoghegan's message of mié dic 15 16:40:41 -0300 2010: > > Before that, have you tried the old standby of "make distclean" and a > > full rebuild/reinstall?  The lack of buildfarm confirmation makes me > > highly suspicious that there's any real problem. > > That's fixed both p

[HACKERS] mvcc & DML on the same row

Hi, I have an idea about mvcc and different DML of the same row in the same transaction. Normally when a backend do an unpdate on a row ( call it X ) , we done an insert and logical delete on this row (0,1,2..N are the "version of the row) : X0 (delete "old" row) X1 (insert "new" row

Re: [HACKERS] Segfault related to pg_authid when running initdb from git master

On Wed, Dec 15, 2010 at 2:40 PM, Peter Geoghegan wrote: >> Before that, have you tried the old standby of "make distclean" and a >> full rebuild/reinstall?  The lack of buildfarm confirmation makes me >> highly suspicious that there's any real problem. > > That's fixed both problems. I should have

Re: [HACKERS] Segfault related to pg_authid when running initdb from git master

> Before that, have you tried the old standby of "make distclean" and a > full rebuild/reinstall?  The lack of buildfarm confirmation makes me > highly suspicious that there's any real problem. That's fixed both problems. I should have tried it much sooner. I guess that even though the binaries bu

Re: [HACKERS] ALTER TABLE ... REPLACE WITH

Heikki Linnakangas wrote: > On 14.12.2010 20:27, Simon Riggs wrote: >> 1. Prepare new data into "new_table" and build indexes >> 2. Swap old for new >> BEGIN; >> DROP TABLE "old_table"; >> ALTER TABLE "new_table" RENAME to "old_table"; >> COMMIT; >> >> Step (2) works, but any people queuing to a

Re: [HACKERS] hstores in pl/python

2010/12/15 Dmitriy Igrishin > > > 2010/12/15 Pavel Stehule > > 2010/12/15 Dmitriy Igrishin : >> > >> > >> > 2010/12/15 Florian Pflug >> >> >> >> On Dec15, 2010, at 18:33 , Dmitriy Igrishin wrote: >> >> > 2010/12/15 Florian Pflug >> >> > On Dec15, 2010, at 16:18 , Dmitriy Igrishin wrote: >> >>

Re: [HACKERS] CommitFest wrap-up

Robert Haas writes: > On Mon, Dec 13, 2010 at 12:37 PM, Robert Haas wrote: >> - fix for seg picksplit function - I don't have confidence this change >> is for the best and can't take responsibility for it. It needs review >> by a committer who understands this stuff better than me and can >> det

Re: [HACKERS] ALTER TABLE ... REPLACE WITH

On Wed, Dec 15, 2010 at 10:50 AM, Simon Riggs wrote: > On Wed, 2010-12-15 at 12:17 +0100, Csaba Nagy wrote: > >> But one problem would be when the replaced table is the _parent_ for a >> foreign key relationship. I don't think you can have that constraint >> pre-verified on the replacement table a

Re: [HACKERS] Complier warnings on mingw gcc 4.5.0

On 12/15/2010 02:06 PM, Tom Lane wrote: Andrew Dunstan writes: And the attached hack allowed "make check" to succeed. I think the logic in tcop/postgres.c and postmaster/postmaster.c is probably wrong. If we are using our getopt/getopt_long, we want to be setting optreset, whether or not conf

Re: [HACKERS] hstores in pl/python

2010/12/15 Dmitriy Igrishin > > > 2010/12/15 Robert Haas > > On Wed, Dec 15, 2010 at 2:14 PM, Robert Haas >> wrote: >> > On Wed, Dec 15, 2010 at 1:22 PM, Dmitriy Igrishin >> wrote: >> >> Yes, but range of PostgreSQL's OIDs can be reserved. One or even ten >> >> millions, e.g. can be enough. >>

Re: [HACKERS] hstores in pl/python

2010/12/15 Pavel Stehule > 2010/12/15 Dmitriy Igrishin : > > > > > > 2010/12/15 Florian Pflug > >> > >> On Dec15, 2010, at 18:33 , Dmitriy Igrishin wrote: > >> > 2010/12/15 Florian Pflug > >> > On Dec15, 2010, at 16:18 , Dmitriy Igrishin wrote: > >> > >> 2010/12/15 Florian Pflug > >> > >> On D

Re: [HACKERS] hstores in pl/python

On Wed, Dec 15, 2010 at 2:14 PM, Robert Haas wrote: > On Wed, Dec 15, 2010 at 1:22 PM, Dmitriy Igrishin wrote: >> Yes, but range of PostgreSQL's OIDs can be reserved. One or even ten >> millions, e.g. can be enough. > > No, they can't.  PostgreSQL is already deployed without any such > restrictio

Re: [HACKERS] hstores in pl/python

On Wed, Dec 15, 2010 at 1:22 PM, Dmitriy Igrishin wrote: > Yes, but range of PostgreSQL's OIDs can be reserved. One or even ten > millions, e.g. can be enough. No, they can't. PostgreSQL is already deployed without any such restriction. You can "reserve" those OIDs because they may already be i

Re: [HACKERS] [PATCH] V3: Idle in transaction cancellation

On Wed, Dec 15, 2010 at 10:02 AM, Andres Freund wrote: >> Is there a way that errstart() and/or errfinish() can know enough >> about the state of the communication with the frontend to decide >> whether to suppress edata->output_to_client?  In other words, instead >> of explicitly passing in a fla

Re: [HACKERS] Complier warnings on mingw gcc 4.5.0

Andrew Dunstan writes: > And the attached hack allowed "make check" to succeed. > I think the logic in tcop/postgres.c and postmaster/postmaster.c is > probably wrong. If we are using our getopt/getopt_long, we want to be > setting optreset, whether or not configure found one in the system > l

Re: [HACKERS] Complier warnings on mingw gcc 4.5.0

On 12/15/2010 12:28 PM, Andrew Dunstan wrote: I think you're probably right. narwhal reports having optreset, but my Mingw reports not having it, so this looks like a likely culprit. And the attached hack allowed "make check" to succeed. I think the logic in tcop/postgres.c and postmast

Re: [HACKERS] getting composite types info from libpq

On Wed, Dec 15, 2010 at 1:25 PM, Daniele Varrazzo wrote: > Hello, > > when a query returns a composite type, the libpq PQftype() function > reports the oid of the "record" type. In psycopg: > >    >>> cur.execute("select (1,2)") >    >>> cur.description >    (('row', 2249, None, -1, None, None, No

Re: [HACKERS] Segfault related to pg_authid when running initdb from git master

Robert Haas writes: > What distro are you using? This can't be broken across the board, > given the lack of metoos. Can you use git bisect to figure out which > commit broke it? Before that, have you tried the old standby of "make distclean" and a full rebuild/reinstall? The lack of buildfarm

[HACKERS] getting composite types info from libpq

Hello, when a query returns a composite type, the libpq PQftype() function reports the oid of the "record" type. In psycopg: >>> cur.execute("select (1,2)") >>> cur.description (('row', 2249, None, -1, None, None, None),) test=# select typname from pg_type where oid = 2249;

Re: [HACKERS] hstores in pl/python

2010/12/15 Florian Pflug > On Dec15, 2010, at 18:33 , Dmitriy Igrishin wrote: > > 2010/12/15 Florian Pflug > > On Dec15, 2010, at 16:18 , Dmitriy Igrishin wrote: > > >> 2010/12/15 Florian Pflug > > >> On Dec15, 2010, at 02:14 , James William Pye wrote: > > >> > On Dec 13, 2010, at 6:16 PM, Tom

Re: [HACKERS] Default mode for shutdown

Robert Haas writes: > On Wed, Dec 15, 2010 at 9:47 AM, Tom Lane wrote: >> Yeah, and more to the point, do I want to finish whatever I was doing in >> that window?  Fast-by-default is a nice hammer to swing, but one day >> you'll pound your finger. > I guess. I've pounded my finger enough time w

Re: [HACKERS] hstores in pl/python

Robert Haas writes: > Well then we need a reliable way to identify a type. What would satisfy you? An oid ? =# select objid from pg_extension_objects('hstore') where class = 'pg_type'::regclass and objdesc ~ '(^|\.)hstore$'; objid --- 16387 (1 row) You have 4

Re: [HACKERS] Default mode for shutdown

On Wed, Dec 15, 2010 at 9:57 AM, Tom Lane wrote: > Robert Haas writes: >> On Wed, Dec 15, 2010 at 9:47 AM, Tom Lane wrote: >>> Yeah, and more to the point, do I want to finish whatever I was doing in >>> that window?  Fast-by-default is a nice hammer to swing, but one day >>> you'll pound your f

Re: [HACKERS] [PATCH] V3: Idle in transaction cancellation

On Wednesday 15 December 2010 15:40:20 Robert Haas wrote: > On Wed, Dec 15, 2010 at 7:47 AM, Andres Freund wrote: > > I thought about doing that first. Btw, LOG_NO_CLIENT is just a more > > abstracted way of what COMERROR did before... > > Hmm, but it must not be quite the same, because that didn

Re: [HACKERS] Segfault related to pg_authid when running initdb from git master

On Wed, Dec 15, 2010 at 12:39 PM, Peter Geoghegan wrote: > Observe that the initdb and postgres timestamps are the same. Hrm. >>> I cannot find the coredump. Perhaps it's a permissions issue. What do you >>> think? >> >> It would presumably get dumped into the data directory.  So if >> --noclea

[HACKERS] range intervals in window function frames

Hello, all! I first posted this to pgsql-general, but didn't get a definitive answer to my question concerning if a window function feature is scheduled or being worked on for 9.x. -- I need to do moving averages over time series data and was hoping window functions could solve the prob

Re: [HACKERS] hstores in pl/python

On Dec15, 2010, at 18:33 , Dmitriy Igrishin wrote: > 2010/12/15 Florian Pflug > On Dec15, 2010, at 16:18 , Dmitriy Igrishin wrote: > >> 2010/12/15 Florian Pflug > >> On Dec15, 2010, at 02:14 , James William Pye wrote: > >> > On Dec 13, 2010, at 6:16 PM, Tom Lane wrote: > >> >> how do you identify

Re: [HACKERS] Instrument checkpoint sync calls

On Wed, Dec 15, 2010 at 9:22 AM, Greg Smith wrote: > patch I submit.  Doesn't seem worth going through the trouble of committing > that minor rework on its own, I'll slip it into the next useful thing that > touches this area I do.  Thanks for the hint, this would work better than > what I did. W

Re: [HACKERS] Segfault related to pg_authid when running initdb from git master

On 15 December 2010 16:26, Robert Haas wrote: > On Wed, Dec 15, 2010 at 6:07 AM, Peter Geoghegan > wrote: >> On 15 December 2010 01:35, Robert Haas wrote: >>> I am suspicious of the fact that you are invoking initdb as ./initdb. >>> Is it possible you're invoking this from the build tree, and th

Re: [HACKERS] hstores in pl/python

2010/12/15 Florian Pflug > On Dec15, 2010, at 16:18 , Dmitriy Igrishin wrote: > >> 2010/12/15 Florian Pflug > >> On Dec15, 2010, at 02:14 , James William Pye wrote: > >> > On Dec 13, 2010, at 6:16 PM, Tom Lane wrote: > >> >> how do you identify which type OID is really hstore? > >> > > >> > How

Re: [HACKERS] Complier warnings on mingw gcc 4.5.0

On 12/15/2010 11:49 AM, Tom Lane wrote: Magnus Hagander writes: On Wed, Dec 15, 2010 at 17:43, Tom Lane wrote: Do we use configure at all on a mingw build? If we don't, then HAVE_INT_OPTRESET is surely not getting defined. We do use configure on mingw. The output from a regular mingw conf

Re: [HACKERS] Complier warnings on mingw gcc 4.5.0

Magnus Hagander writes: > On Wed, Dec 15, 2010 at 17:43, Tom Lane wrote: >> Do we use configure at all on a mingw build?  If we don't, then >> HAVE_INT_OPTRESET is surely not getting defined. > We do use configure on mingw. The output from a regular mingw > configure run formed the base for the

Re: [HACKERS] Default mode for shutdown

On Dec 15, 2010, at 9:11 AM, Alvaro Herrera wrote: > Excerpts from Robert Haas's message of mié dic 15 12:03:06 -0300 2010: > >> Certainly, if you have an environment where people are mostly logging >> into the database directly (not through a connection pooler) and they >> do a few important quer

Re: [HACKERS] Complier warnings on mingw gcc 4.5.0

On Wed, Dec 15, 2010 at 17:43, Tom Lane wrote: > Andrew Dunstan writes: >> On 12/15/2010 11:12 AM, Tom Lane wrote: >>> 1. Is that build using src/port/getopt.c, or a library-supplied getopt? >>> What about getopt_long.c? >>> >>> 2. Is HAVE_INT_OPTRESET getting defined?  Should it be? > >> I had t

Re: [HACKERS] Complier warnings on mingw gcc 4.5.0

Andrew Dunstan writes: > On 12/15/2010 11:12 AM, Tom Lane wrote: >> 1. Is that build using src/port/getopt.c, or a library-supplied getopt? >> What about getopt_long.c? >> >> 2. Is HAVE_INT_OPTRESET getting defined? Should it be? > I had the same thought. I did try forcing use of our getopt and

Re: [HACKERS] ALTER TABLE ... REPLACE WITH

On Wed, Dec 15, 2010 at 11:30 AM, Kevin Grittner wrote: > Heikki Linnakangas  wrote: >> On 14.12.2010 20:27, Simon Riggs wrote: > >>> 1. Prepare new data into "new_table" and build indexes >>> 2. Swap old for new >>> BEGIN; >>> DROP TABLE "old_table"; >>> ALTER TABLE "new_table" RENAME to "old_tab

Re: [HACKERS] Complier warnings on mingw gcc 4.5.0

On 12/15/2010 11:12 AM, Tom Lane wrote: Alvaro Herrera writes: This bug seems closely related to process_postgres_switches. I guess it'd be useful to add some debugging printouts there to figure out what's being passed the second time around. It strikes me that the most obvious source for a

Re: [HACKERS] Segfault related to pg_authid when running initdb from git master

On Wed, Dec 15, 2010 at 6:07 AM, Peter Geoghegan wrote: > On 15 December 2010 01:35, Robert Haas wrote: >> I am suspicious of the fact that you are invoking initdb as ./initdb. >> Is it possible you're invoking this from the build tree, and there's >> an installed copy out there that doesn't matc

Re: [HACKERS] CommitFest wrap-up

On Dec15, 2010, at 17:17 , Robert Haas wrote: > Nah, don't bother reposting. It'd be helpful if you could add a link > to that message on the CF app though. Already done. Seems we've hit a race condition there - you must have overlooked the signalling the semaphore on my rooftop did to warn you

Re: [HACKERS] Complier warnings on mingw gcc 4.5.0

Alvaro Herrera writes: > This bug seems closely related to process_postgres_switches. I guess > it'd be useful to add some debugging printouts there to figure out > what's being passed the second time around. It strikes me that the most obvious source for a platform dependency there would be get

Re: [HACKERS] Complier warnings on mingw gcc 4.5.0

On 12/15/2010 10:17 AM, Tom Lane wrote: Alvaro Herrera writes: Excerpts from Andrew Dunstan's message of mié dic 15 02:08:24 -0300 2010: That didn't work. But git bisect says it's this commit that's to blame:

Re: [HACKERS] CommitFest wrap-up

On Wed, Dec 15, 2010 at 10:57 AM, Florian Pflug wrote: > On Dec15, 2010, at 16:45 , Robert Haas wrote: >> On Wed, Dec 15, 2010 at 9:20 AM, Florian Pflug wrote: >>> On Dec14, 2010, at 15:01 , Robert Haas wrote: On Tue, Dec 14, 2010 at 7:51 AM, Florian Pflug wrote: >> - serializable lock

Re: [HACKERS] CommitFest wrap-up

On Dec15, 2010, at 16:45 , Robert Haas wrote: > On Wed, Dec 15, 2010 at 9:20 AM, Florian Pflug wrote: >> On Dec14, 2010, at 15:01 , Robert Haas wrote: >>> On Tue, Dec 14, 2010 at 7:51 AM, Florian Pflug wrote: > - serializable lock consistency - I am fairly certain this needs > rebasing.

Re: [HACKERS] hstores in pl/python

On Dec15, 2010, at 16:18 , Dmitriy Igrishin wrote: >> 2010/12/15 Florian Pflug >> On Dec15, 2010, at 02:14 , James William Pye wrote: >> > On Dec 13, 2010, at 6:16 PM, Tom Lane wrote: >> >> how do you identify which type OID is really hstore? >> > >> > How about an identification field on pg_type?

Re: [HACKERS] ALTER TABLE ... REPLACE WITH

On Wed, 2010-12-15 at 12:17 +0100, Csaba Nagy wrote: > But one problem would be when the replaced table is the _parent_ for a > foreign key relationship. I don't think you can have that constraint > pre-verified on the replacement table and simply replacing the content > could leave the child rela

Re: [HACKERS] ALTER TABLE ... REPLACE WITH

On Wed, 2010-12-15 at 07:43 -0600, David Christensen wrote: > Are there any considerations with toast tables and the inline line pointers > for toasted tuples? Toast tables would be swapped as well. Toast pointers are only applicable within a relfilenode, so we could not do otherwise. -- Simo

Re: [HACKERS] CommitFest wrap-up

On Wed, Dec 15, 2010 at 9:20 AM, Florian Pflug wrote: > On Dec14, 2010, at 15:01 , Robert Haas wrote: >> On Tue, Dec 14, 2010 at 7:51 AM, Florian Pflug wrote: - serializable lock consistency - I am fairly certain this needs rebasing.  I don't have time to deal with it right away.  That

Re: [HACKERS] Default mode for shutdown

On Wed, Dec 15, 2010 at 10:11 AM, Alvaro Herrera wrote: > Excerpts from Robert Haas's message of mié dic 15 12:03:06 -0300 2010: > >> Certainly, if you have an environment where people are mostly logging >> into the database directly (not through a connection pooler) and they >> do a few important

Re: [HACKERS] hstores in pl/python

On Wed, Dec 15, 2010 at 10:15 AM, Dimitri Fontaine wrote: > Robert Haas writes: >> Wrong probem.  What we need is a way to identify a type without >> knowing in advance what its OID is.  In other words, we need to >> distinguish between the hstore type that is shipped in contrib, and >> some stup

Re: [HACKERS] unlogged tables

On Wed, Dec 15, 2010 at 4:06 AM, Simon Riggs wrote: > On Sat, 2010-11-13 at 20:55 -0500, Robert Haas wrote: >> I think that would be a recipe for bugs.  Look at the three new macros >> I introduced.  If you keep relistemp around, then any code which >> relies on it is likely testing for one of tho

Re: [HACKERS] hstores in pl/python

On 15/12/10 16:25, Dmitriy Igrishin wrote: > 2010/12/15 Jan Urbański >> So how about just adding a text column to pg_type and a IDENTIFIER >> keywork to CREATE TYPE. It's not guaranteed to be unique, but isn't it >> pushing the argument to the extreme? Someone can change around bool and >> text ty

Re: [HACKERS] hstores in pl/python

2010/12/15 Jan Urbański > On 15/12/10 16:11, Tom Lane wrote: > > Robert Haas writes: > >> I was asking what would satisfy you as regards a reliable way to > >> identify a type, not what you think we should do about this particular > >> proposal. > > > > Okay: a preassigned OID is safe. I haven'

Re: [HACKERS] hstores in pl/python

On 15/12/10 16:11, Tom Lane wrote: > Robert Haas writes: >> I was asking what would satisfy you as regards a reliable way to >> identify a type, not what you think we should do about this particular >> proposal. > > Okay: a preassigned OID is safe. I haven't seen any other safe > proposals. Rel

Re: [HACKERS] hstores in pl/python

2010/12/15 Florian Pflug > On Dec15, 2010, at 02:14 , James William Pye wrote: > > On Dec 13, 2010, at 6:16 PM, Tom Lane wrote: > >> how do you identify which type OID is really hstore? > > > > How about an identification field on pg_type? > > > > CREATE TYPE hstore ..., IDENTIFIER 'org.postgresq

Re: [HACKERS] Complier warnings on mingw gcc 4.5.0

Alvaro Herrera writes: > Excerpts from Andrew Dunstan's message of mié dic 15 02:08:24 -0300 2010: >> That didn't work. But git bisect says it's this commit that's to blame: >> > Hmm I wonder if this is reprod

Re: [HACKERS] hstores in pl/python

Robert Haas writes: > Wrong probem. What we need is a way to identify a type without > knowing in advance what its OID is. In other words, we need to > distinguish between the hstore type that is shipped in contrib, and > some stupid DBA who types "CREATE DOMAIN hstore as text". Yeah, yeah. Now

Re: [HACKERS] Default mode for shutdown

Excerpts from Robert Haas's message of mié dic 15 12:03:06 -0300 2010: > Certainly, if you have an environment where people are mostly logging > into the database directly (not through a connection pooler) and they > do a few important queries and then disconnect, smart is a better > default. But

Re: [HACKERS] hstores in pl/python

Robert Haas writes: > I was asking what would satisfy you as regards a reliable way to > identify a type, not what you think we should do about this particular > proposal. Okay: a preassigned OID is safe. I haven't seen any other safe proposals. Relying on a non-reserved name is transparently u

Re: [HACKERS] unlogged tables

On Wed, Dec 15, 2010 at 4:20 AM, Simon Riggs wrote: > On Sat, 2010-11-13 at 19:16 -0500, Robert Haas wrote: > >> 3. The third patch (relax-sync-commit-v1) allows asynchronous commit >> even when synchronous_commit=on if the transaction has not written >> WAL.  Of course, a read-only transaction wo

Re: [HACKERS] Complier warnings on mingw gcc 4.5.0

Excerpts from Andrew Dunstan's message of mié dic 15 02:08:24 -0300 2010: > > On 12/14/2010 12:42 PM, Tom Lane wrote: > > > Another line of attack is that we know from the response packet that the > > failure is being reported at guc.c:4794. It would be really useful to > > know what the call st

Re: [HACKERS] hstores in pl/python

On Wed, Dec 15, 2010 at 10:00 AM, Dimitri Fontaine wrote: > Robert Haas writes: >> Well then we need a reliable way to identify a type.  What would satisfy you? > > An oid ? Wrong probem. What we need is a way to identify a type without knowing in advance what its OID is. In other words, we ne

Re: [HACKERS] hstores in pl/python

On Dec15, 2010, at 02:14 , James William Pye wrote: > On Dec 13, 2010, at 6:16 PM, Tom Lane wrote: >> how do you identify which type OID is really hstore? > > How about an identification field on pg_type? > > CREATE TYPE hstore ..., IDENTIFIER 'org.postgresql.hstore'; > -- Where the "identifier"

Re: [HACKERS] hstores in pl/python

On Wed, Dec 15, 2010 at 9:53 AM, Tom Lane wrote: > Robert Haas writes: >> Well then we need a reliable way to identify a type.  What would satisfy you? > > Either (1) do nothing (reject this whole proposal) or (2) put hstore > in core where it will have a well-known OID.  While it would be nice t

Re: [HACKERS] Crash safe visibility map vs hint bits

Heikki Linnakangas wrote: > On 04.12.2010 09:14, jes...@krogh.cc wrote: > > There has been a lot discussion about index-only scans and how to make the > > visibillity map crash safe. Then followed by a good discussion about hint > > bits. > > > > What seems to be the main concern is the added wal

Re: [HACKERS] hstores in pl/python

On 15/12/10 15:38, Tom Lane wrote: > Jan =?utf-8?B?VXJiYcWEc2tp?= writes: >> OK, here's another master plan: > >> 1) hstore_plplython, when loaded, looks for a type called "hstore". If > you created a "hstore" type that does not come from hstore.so, and you > still load hstore_plpython, you deser

Re: [HACKERS] hstores in pl/python

Robert Haas writes: > Well then we need a reliable way to identify a type. What would satisfy you? Either (1) do nothing (reject this whole proposal) or (2) put hstore in core where it will have a well-known OID. While it would be nice to have some more-workable way to interconnect independent

  1   2   >