Re: [HACKERS] unlogged tables

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 those three things, or maybe > even something subtly differen

Re: [HACKERS] unlogged tables

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 won't even have an XID and > therefore won't need a commit re

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

On Wed, 2010-12-15 at 10:54 +0100, Csaba Nagy wrote: > On Tue, 2010-12-14 at 14:36 -0500, Robert Haas wrote: > > > Well, you have to do that for DROP TABLE as well, and I don't see any > > > way around doing it for REPLACE WITH. > > > > Sure, but in Simon's proposal you can load the data FIRST and

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

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 match, but is getting used? > Like maybe in /usr/local/pgsql/bin?

Re: [HACKERS] hstores in pl/python

On Wed, Dec 15, 2010 at 12:19:53AM +0100, Jan Urbański wrote: > Problem: what to do it hstore_plpython gets loaded, but hstore is not > yet loaded. hstore_plpython will want to DirectFunctionCall(hstore_in), > so loading hstore_plpython without loading hstore will result in an > ereport(ERROR, "und

[HACKERS] Default mode for shutdown

I'm sure this has been up before, but hey, let's take it another round. Why don't we change the default shutdown mode for pg_ctl from "smart" to "fast"? I've never come across a single usecase where "smart" is what people *want*... Not sure if others have? Yes, I realize it's somewhat of a backwa

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

On Wednesday 15 December 2010 02:20:31 Robert Haas wrote: > On Sat, Oct 30, 2010 at 4:49 AM, Andres Freund wrote: > >> > Here is a proposed patch which enables cancellation of $subject. > > Disclaimer: This isn't my area of expertise, so take the below with a > grain or seven of salt. I don't kno

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

On Wed, Dec 15, 2010 at 7:13 AM, Andres Freund wrote: >> It sort of looks to me like the LOG_NO_CLIENT error flag and the >> silent_error_while_idle flag are trying to cooperate to get the effect >> of throwing an error without actually throwing an error.  I'm >> wondering if it would be at all se

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

On Wed, Dec 15, 2010 at 5:39 AM, Simon Riggs wrote: > Perhaps a more useful definition would be > > EXCHANGE TABLE target WITH source; > > which just swaps the heap and indexes of each table. > You can then use TRUNCATE if you want to actually destroy data. > > I will go with that unless we have o

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

On Wednesday 15 December 2010 13:33:30 Robert Haas wrote: > On Wed, Dec 15, 2010 at 7:13 AM, Andres Freund wrote: > >> It sort of looks to me like the LOG_NO_CLIENT error flag and the > >> silent_error_while_idle flag are trying to cooperate to get the effect > >> of throwing an error without actu

Re: [HACKERS] Re: Proposed Windows-specific change: Enable crash dumps (like core files)

I've updated this entry in the CommitFest app to note that Craig had some implementation questions attached to his patch submission that I haven't seen anyone address yet, and to include a reference to Tom's latest question--which may make those questions moot, not sure. This pretty clearly ne

Re: [HACKERS] SQL/MED - file_fdw

Hi hackers, Attached is the revised WIP version of file_fdw patch. This patch should be applied after both of fdw_syntax and fdw_scan patches, which have been posted to another thread "SQL/MED - core functionality". In this version, file_fdw consists of two parts, file_fdw core part and copy of

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

On Dec 15, 2010, at 4:39 AM, Simon Riggs wrote: > On Wed, 2010-12-15 at 10:54 +0100, Csaba Nagy wrote: >> On Tue, 2010-12-14 at 14:36 -0500, Robert Haas wrote: Well, you have to do that for DROP TABLE as well, and I don't see any way around doing it for REPLACE WITH. >>> >>> Sure, but

Re: [HACKERS] Re: Proposed Windows-specific change: Enable crash dumps (like core files)

On 12/15/2010 01:01 AM, Tom Lane wrote: Craig Ringer writes: I've attached an updated patch that fixes a failure when compiling on gcc/linux. The no-op inline installCrashDumpHandler() for unsupported platforms was not declared static, so it was not being optimized out of objects it wasn't used

Re: [HACKERS] Instrument checkpoint sync calls

Alvaro Herrera wrote: I gave this patch a look and it seems pretty good to me, except that I'm uncomfortable with the idea of mdsync filling in the details for CheckpointStats fields directly. Would it work to pass a struct (say SmgrSyncStats) from CheckPointBuffers to smgrsync and from there to

Re: [HACKERS] hstores in pl/python

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 deserve a segfault. No, you don't. I said upthre

Re: [HACKERS] Default mode for shutdown

Magnus Hagander writes: > I'm sure this has been up before, but hey, let's take it another round. > Why don't we change the default shutdown mode for pg_ctl from "smart" > to "fast"? I've never come across a single usecase where "smart" is > what people *want*... Really? Personally I'm quite hap

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

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't require the silent_error_while_idle flag. >> Yeah.  I'll try to

Re: [HACKERS] Default mode for shutdown

On Wed, Dec 15, 2010 at 9:39 AM, Tom Lane wrote: > Magnus Hagander writes: >> I'm sure this has been up before, but hey, let's take it another round. >> Why don't we change the default shutdown mode for pg_ctl from "smart" >> to "fast"? I've never come across a single usecase where "smart" is >>

Re: [HACKERS] Default mode for shutdown

On Wed, Dec 15, 2010 at 09:39:12AM -0500, Tom Lane wrote: > Magnus Hagander writes: > > I'm sure this has been up before, but hey, let's take it another round. > > Why don't we change the default shutdown mode for pg_ctl from "smart" > > to "fast"? I've never come across a single usecase where "sm

Re: [HACKERS] Default mode for shutdown

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 I failed to exit a session? Yeah, and more to the poi

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

On Wed, 2010-12-15 at 10:39 +, Simon Riggs wrote: > Perhaps a more useful definition would be > > EXCHANGE TABLE target WITH source; > > which just swaps the heap and indexes of each table. > You can then use TRUNCATE if you want to actually destroy data. Yes please, that's exactly what I wo

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

On Tue, 2010-12-14 at 14:36 -0500, Robert Haas wrote: > > Well, you have to do that for DROP TABLE as well, and I don't see any > > way around doing it for REPLACE WITH. > > Sure, but in Simon's proposal you can load the data FIRST and then > take a lock just long enough to do the swap. That's ve

Re: [HACKERS] hstores in pl/python

On Wed, Dec 15, 2010 at 9:38 AM, 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_plpyt

Re: [HACKERS] Default mode for shutdown

On Wed, Dec 15, 2010 at 9:47 AM, 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 whe

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

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] 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 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] 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 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] 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] 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] 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] 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: > 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] 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

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] 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 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: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] 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 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] 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] 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] 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] 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] 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] 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] 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] 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] 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] 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] 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] 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] 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

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] 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] 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

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] 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] 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] 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] 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] 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

[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] 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

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] 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

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

[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] 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

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] 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] 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] [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] 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] 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

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

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] 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] 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] 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] 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] 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] 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] 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

[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

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

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

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] 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] 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

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] 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] 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] 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: > 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

  1   2   >