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 different
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
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 then
On 15 December 2010 01:35, Robert Haas robertmh...@gmail.com 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
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,
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 backwards
On Wednesday 15 December 2010 02:20:31 Robert Haas wrote:
On Sat, Oct 30, 2010 at 4:49 AM, Andres Freund and...@anarazel.de 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.
On Wed, Dec 15, 2010 at 7:13 AM, Andres Freund and...@anarazel.de 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
On Wed, Dec 15, 2010 at 5:39 AM, Simon Riggs si...@2ndquadrant.com 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
On Wednesday 15 December 2010 13:33:30 Robert Haas wrote:
On Wed, Dec 15, 2010 at 7:13 AM, Andres Freund and...@anarazel.de 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
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
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
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 in Simon's
On 12/15/2010 01:01 AM, Tom Lane wrote:
Craig Ringercr...@postnewspapers.com.au 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
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
Jan =?utf-8?B?VXJiYcWEc2tp?= wulc...@wulczer.org 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.
Magnus Hagander mag...@hagander.net 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
On Wed, Dec 15, 2010 at 7:47 AM, Andres Freund and...@anarazel.de 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.
On Wed, Dec 15, 2010 at 9:39 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Magnus Hagander mag...@hagander.net 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
On Wed, Dec 15, 2010 at 09:39:12AM -0500, Tom Lane wrote:
Magnus Hagander mag...@hagander.net 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
Robert Haas robertmh...@gmail.com writes:
On Wed, Dec 15, 2010 at 9:39 AM, Tom Lane t...@sss.pgh.pa.us 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
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 would
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 very
On Wed, Dec 15, 2010 at 9:38 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Jan =?utf-8?B?VXJiYcWEc2tp?= wulc...@wulczer.org 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
On Wed, Dec 15, 2010 at 9:47 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Wed, Dec 15, 2010 at 9:39 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Really? Personally I'm quite happy with that default.
Why? It seems to me that just leads to, oh, gee, the
Robert Haas robertmh...@gmail.com 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
On 15/12/10 15:38, Tom Lane wrote:
Jan =?utf-8?B?VXJiYcWEc2tp?= wulc...@wulczer.org 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,
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 volume
On Wed, Dec 15, 2010 at 9:53 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com 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
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 is an
On Wed, Dec 15, 2010 at 10:00 AM, Dimitri Fontaine
dimi...@2ndquadrant.fr wrote:
Robert Haas robertmh...@gmail.com 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
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 stack is
On Wed, Dec 15, 2010 at 4:20 AM, Simon Riggs si...@2ndquadrant.com 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
Robert Haas robertmh...@gmail.com 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
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 if
Robert Haas robertmh...@gmail.com 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.
Alvaro Herrera alvhe...@commandprompt.com 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:
https://github.com/postgres/postgres/commit/e710b65c1c56ca7b91f662c63d37ff2e72862a94
Hmm I
2010/12/15 Florian Pflug f...@phlo.org
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
On 15/12/10 16:11, Tom Lane wrote:
Robert Haas robertmh...@gmail.com 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
2010/12/15 Jan Urbański wulc...@wulczer.org
On 15/12/10 16:11, Tom Lane wrote:
Robert Haas robertmh...@gmail.com 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
On 15/12/10 16:25, Dmitriy Igrishin wrote:
2010/12/15 Jan Urbański wulc...@wulczer.org
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
On Wed, Dec 15, 2010 at 4:06 AM, Simon Riggs si...@2ndquadrant.com 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
On Wed, Dec 15, 2010 at 10:15 AM, Dimitri Fontaine
dimi...@2ndquadrant.fr wrote:
Robert Haas robertmh...@gmail.com 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
On Wed, Dec 15, 2010 at 10:11 AM, Alvaro Herrera
alvhe...@commandprompt.com 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
On Wed, Dec 15, 2010 at 9:20 AM, Florian Pflug f...@phlo.org wrote:
On Dec14, 2010, at 15:01 , Robert Haas wrote:
On Tue, Dec 14, 2010 at 7:51 AM, Florian Pflug f...@phlo.org wrote:
- serializable lock consistency - I am fairly certain this needs
rebasing. I don't have time to deal with it
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.
--
Simon
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
On Dec15, 2010, at 16:18 , Dmitriy Igrishin wrote:
2010/12/15 Florian Pflug f...@phlo.org
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?
On Dec15, 2010, at 16:45 , Robert Haas wrote:
On Wed, Dec 15, 2010 at 9:20 AM, Florian Pflug f...@phlo.org wrote:
On Dec14, 2010, at 15:01 , Robert Haas wrote:
On Tue, Dec 14, 2010 at 7:51 AM, Florian Pflug f...@phlo.org wrote:
- serializable lock consistency - I am fairly certain this needs
On Wed, Dec 15, 2010 at 10:57 AM, Florian Pflug f...@phlo.org wrote:
On Dec15, 2010, at 16:45 , Robert Haas wrote:
On Wed, Dec 15, 2010 at 9:20 AM, Florian Pflug f...@phlo.org wrote:
On Dec14, 2010, at 15:01 , Robert Haas wrote:
On Tue, Dec 14, 2010 at 7:51 AM, Florian Pflug f...@phlo.org
On 12/15/2010 10:17 AM, Tom Lane wrote:
Alvaro Herreraalvhe...@commandprompt.com 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:
Alvaro Herrera alvhe...@commandprompt.com 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
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
On Wed, Dec 15, 2010 at 6:07 AM, Peter Geoghegan
peter.geoghega...@gmail.com wrote:
On 15 December 2010 01:35, Robert Haas robertmh...@gmail.com 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
On 12/15/2010 11:12 AM, Tom Lane wrote:
Alvaro Herreraalvhe...@commandprompt.com 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
On Wed, Dec 15, 2010 at 11:30 AM, Kevin Grittner
kevin.gritt...@wicourts.gov 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
Andrew Dunstan and...@dunslane.net 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
On Wed, Dec 15, 2010 at 17:43, Tom Lane t...@sss.pgh.pa.us wrote:
Andrew Dunstan and...@dunslane.net 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?
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 queries and
Magnus Hagander mag...@hagander.net writes:
On Wed, Dec 15, 2010 at 17:43, Tom Lane t...@sss.pgh.pa.us 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
On 12/15/2010 11:49 AM, Tom Lane wrote:
Magnus Hagandermag...@hagander.net writes:
On Wed, Dec 15, 2010 at 17:43, Tom Lanet...@sss.pgh.pa.us 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
2010/12/15 Florian Pflug f...@phlo.org
On Dec15, 2010, at 16:18 , Dmitriy Igrishin wrote:
2010/12/15 Florian Pflug f...@phlo.org
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?
On 15 December 2010 16:26, Robert Haas robertmh...@gmail.com wrote:
On Wed, Dec 15, 2010 at 6:07 AM, Peter Geoghegan
peter.geoghega...@gmail.com wrote:
On 15 December 2010 01:35, Robert Haas robertmh...@gmail.com wrote:
I am suspicious of the fact that you are invoking initdb as ./initdb.
Is
On Wed, Dec 15, 2010 at 9:22 AM, Greg Smith g...@2ndquadrant.com 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
On Dec15, 2010, at 18:33 , Dmitriy Igrishin wrote:
2010/12/15 Florian Pflug f...@phlo.org
On Dec15, 2010, at 16:18 , Dmitriy Igrishin wrote:
2010/12/15 Florian Pflug f...@phlo.org
On Dec15, 2010, at 02:14 , James William Pye wrote:
On Dec 13, 2010, at 6:16 PM, Tom Lane wrote:
how do
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
On Wed, Dec 15, 2010 at 12:39 PM, Peter Geoghegan
peter.geoghega...@gmail.com 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.
Robert Haas robertmh...@gmail.com 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
On Wed, Dec 15, 2010 at 9:57 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Wed, Dec 15, 2010 at 9:47 AM, Tom Lane t...@sss.pgh.pa.us 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
On Wednesday 15 December 2010 15:40:20 Robert Haas wrote:
On Wed, Dec 15, 2010 at 7:47 AM, Andres Freund and...@anarazel.de 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,
Robert Haas robertmh...@gmail.com writes:
On Wed, Dec 15, 2010 at 9:47 AM, Tom Lane t...@sss.pgh.pa.us 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
2010/12/15 Florian Pflug f...@phlo.org
On Dec15, 2010, at 18:33 , Dmitriy Igrishin wrote:
2010/12/15 Florian Pflug f...@phlo.org
On Dec15, 2010, at 16:18 , Dmitriy Igrishin wrote:
2010/12/15 Florian Pflug f...@phlo.org
On Dec15, 2010, at 02:14 , James William Pye wrote:
On Dec 13,
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;
typname
Robert Haas robertmh...@gmail.com 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
On Wed, Dec 15, 2010 at 1:25 PM, Daniele Varrazzo
daniele.varra...@gmail.com 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,
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
Andrew Dunstan and...@dunslane.net 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
On Wed, Dec 15, 2010 at 10:02 AM, Andres Freund and...@anarazel.de 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
On Wed, Dec 15, 2010 at 1:22 PM, Dmitriy Igrishin dmit...@gmail.com 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
On Wed, Dec 15, 2010 at 2:14 PM, Robert Haas robertmh...@gmail.com wrote:
On Wed, Dec 15, 2010 at 1:22 PM, Dmitriy Igrishin dmit...@gmail.com 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
2010/12/15 Pavel Stehule pavel.steh...@gmail.com
2010/12/15 Dmitriy Igrishin dmit...@gmail.com:
2010/12/15 Florian Pflug f...@phlo.org
On Dec15, 2010, at 18:33 , Dmitriy Igrishin wrote:
2010/12/15 Florian Pflug f...@phlo.org
On Dec15, 2010, at 16:18 , Dmitriy Igrishin wrote:
2010/12/15 Dmitriy Igrishin dmit...@gmail.com
2010/12/15 Robert Haas robertmh...@gmail.com
On Wed, Dec 15, 2010 at 2:14 PM, Robert Haas robertmh...@gmail.com
wrote:
On Wed, Dec 15, 2010 at 1:22 PM, Dmitriy Igrishin dmit...@gmail.com
wrote:
Yes, but range of PostgreSQL's OIDs can be
On 12/15/2010 02:06 PM, Tom Lane wrote:
Andrew Dunstanand...@dunslane.net 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,
On Wed, Dec 15, 2010 at 10:50 AM, Simon Riggs si...@2ndquadrant.com 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
Robert Haas robertmh...@gmail.com writes:
On Mon, Dec 13, 2010 at 12:37 PM, Robert Haas robertmh...@gmail.com 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
2010/12/15 Dmitriy Igrishin dmit...@gmail.com
2010/12/15 Pavel Stehule pavel.steh...@gmail.com
2010/12/15 Dmitriy Igrishin dmit...@gmail.com:
2010/12/15 Florian Pflug f...@phlo.org
On Dec15, 2010, at 18:33 , Dmitriy Igrishin wrote:
2010/12/15 Florian Pflug f...@phlo.org
On
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 access the table
will
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 built
On Wed, Dec 15, 2010 at 2:40 PM, Peter Geoghegan
peter.geoghega...@gmail.com 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
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)
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 problems.
On Tue, Dec 7, 2010 at 3:42 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com 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
On 15 December 2010 19:43, Robert Haas robertmh...@gmail.com 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.
On tis, 2010-12-14 at 11:52 -0500, Tom Lane wrote:
Peter Eisentraut pete...@gmx.net 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
On 12/15/2010 02:22 PM, Andrew Dunstan wrote:
On 12/15/2010 02:06 PM, Tom Lane wrote:
Andrew Dunstanand...@dunslane.net 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
Florian Pflug f...@phlo.org 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:
On Tue, Dec 14, 2010 at 1:42 PM, Jim Nasby j...@nasby.net 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
Andrew Dunstan and...@dunslane.net writes:
And here is where it changed:
http://sourceforge.net/project/shownotes.php?release_id=24832
* A replacement implementation for the getopt() family of functions,
adding support for the GNU getopt_long_only() function. Users
should
On 12/15/2010 03:52 PM, Tom Lane wrote:
Andrew Dunstanand...@dunslane.net writes:
And here is where it changed:
http://sourceforge.net/project/shownotes.php?release_id=24832
* A replacement implementation for the getopt() family of functions,
adding support for the GNU
Andrew Dunstan and...@dunslane.net 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
1 - 100 of 125 matches
Mail list logo
