On Dec 13, 2011, at 8:21 PM, Tom Lane wrote:
I'm not sure whether we'd want something like this in core, so for a
first go-around, you might want to consider building it as an
extension. ... I'm not sure you
need NOTIFY for anything anywhere in here.
Actually, what I'd suggest is just
On Tue, Dec 13, 2011 at 07:54:14PM -0500, Greg Smith wrote:
After this bit of tinkering with the code, it feels to me like this
really wants a split() function to break out the two sides of a
string across a delimiter, eating it in the process. Adding the
level of paranoia I'd like around
On Mon, Dec 12, 2011 at 21:04, Peter Eisentraut pete...@gmx.net wrote:
On mån, 2011-12-12 at 14:47 +0100, Magnus Hagander wrote:
We're either pretty inconsistent with our output in psql, or I'm not
completely understanding it.. I was trying to implement a switch that
would let me put all the
Robert Haas robertmh...@gmail.com writes:
it. Dimitri says that he wants it so that we can add support for
CREATE TABLE, ALTER TABLE, and DROP TABLE to Slony, Bucardo, and
Londiste. My fear is that it won't turn out to be adequate to that
task, because there won't actually be enough
On Tue, Dec 13, 2011 at 11:59, Greg Smith g...@2ndquadrant.com wrote:
The submission from Edward Muller I'm replying to is quite similar to what
the other raging discussion here decided was the right level to target.
There was one last year from Josh Kupershmidt with similar goals:
On 2011-12-13 18:34, Tom Lane wrote:
Heikki Linnakangasheikki.linnakan...@enterprisedb.com writes:
Attached is a patch with those changes. I also I removed a few of the
syntax error regression tests, that seemed excessive, plus some general
naming and comment fiddling. I'll apply this
Christopher Browne cbbro...@gmail.com writes:
- What I'd much rather have is a form of the query that is replete
with Full Qualification, so that create table foo (id serial primary
key, data text not null unique default 'better replace this', dns_data
dnsrr not null); may be transformed into
Jan Wieck janwi...@yahoo.com writes:
I agree. While it is one of the most asked for features among the trigger
based replication systems, I fear that an incomplete solution will cause
more problems than it solves. It is far easier to tell people DDL doesn't
propagate automatically, do this
Not sure that I have a lot to add here, but I am officially listed as
a reviewer, which is a responsibility that I don't want to shirk.
In my opinion, this patch is obviously useful. I don't find the
asymmetry that it will create with pg_restore to be troubling, so I'd
favour committing it as-is.
On Mon, Nov 21, 2011 at 6:43 PM, Robert Haas robertmh...@gmail.com wrote:
In buffer fill mode, we scan the index and add matching tuples and
their CTIDs to the buffer. When the buffer is full or the index AM
reports that there are no more tuples in the scan, we switch to buffer
drain mode.
On Wed, Dec 14, 2011 at 4:15 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Without the added assert, you'd only notice this if you were running a
standby slave --- the zero xid results in an assert failure in WAL
replay on the slave end, which is how I found out about this to start
with. But since
On Wed, Dec 14, 2011 at 12:20 PM, Pavan Deolasee
pavan.deola...@gmail.com wrote:
On Wed, Dec 14, 2011 at 4:15 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Without the added assert, you'd only notice this if you were running a
standby slave --- the zero xid results in an assert failure in WAL
On 14.12.2011 12:31, Yeb Havinga wrote:
On 2011-12-13 18:34, Tom Lane wrote:
Heikki Linnakangasheikki.linnakan...@enterprisedb.com writes:
Attached is a patch with those changes. I also I removed a few of the
syntax error regression tests, that seemed excessive, plus some general
naming and
On 12/14/2011 04:43 AM, Mark Cave-Ayland wrote:
On 12/12/11 15:00, Andrew Dunstan wrote:
Yeah, fair enough. I'll work on that.
If we're talking about adding support for a previously-unsupported
Definitely do this (and then file a bug report with the project). I've
worked with both Kai and
On 12/14/2011 05:24 AM, Magnus Hagander wrote:
How about passing a parameter to pg_signal_backend? Making
pg_signal_backend(int pid, int sig, bool allow_samerole)?
That sounds like it will result in less code, and make the API I was
documenting be obvious from the parameters instead.
On Wed, Dec 14, 2011 at 6:58 AM, Greg Stark st...@mit.edu wrote:
On Mon, Nov 21, 2011 at 6:43 PM, Robert Haas robertmh...@gmail.com wrote:
In buffer fill mode, we scan the index and add matching tuples and
their CTIDs to the buffer. When the buffer is full or the index AM
reports that there
Excerpts from Dimitri Fontaine's message of mié dic 14 07:22:21 -0300 2011:
Again, that's a caveat of the first implementation, you can't have sub
commands support without forcing them through ProcessUtility and that's
a much more invasive patch. Maybe we will need that later.
I can get
On 12/14/2011 06:28 AM, Peter Geoghegan wrote:
Not sure that I have a lot to add here, but I am officially listed as
a reviewer, which is a responsibility that I don't want to shirk.
In my opinion, this patch is obviously useful. I don't find the
asymmetry that it will create with pg_restore
On 14/12/11 13:59, Andrew Dunstan wrote:
Hmm. Yeah, if I remove -O0 and instead set CFLAGS to -ffloat-store the
error goes away.
So, would we want to use that just for this file, or for the whole build?
Well the latest documentation for gcc gives 2 options: -ffloat-store and
On 14 December 2011 14:31, Andrew Dunstan and...@dunslane.net wrote:
Thanks. Committed with that changed, although we seem to be getting
altogether too obsessive about white space, IMNSHO.
I agree, but I think it's important that we judge patches by a
consistent standard. Right now, for better
Excerpts from Greg Smith's message of Wed Dec 14 02:54:14 +0200 2011:
Initial quick review of your patch: you suggested this as the general form:
psql -d postgresql://user@pw:host:port/dbname?param1=value1param2=value2...
That's presumably supposed to be:
psql -d
Pavel Golub pa...@microolap.com writes:
You wrote:
TL about OSX though. (You're aware that Apple ships a perfectly fine
TL libpq.so in Lion, no?)
Is it true? Really? Where can we read about it?
/Library/WebServer/Documents/postgresql/html ...
I don't know where else Apple documents this,
On Tue, Dec 13, 2011 at 11:27 PM, Thomas Munro mu...@ip9.org wrote:
Actually, what I'd suggest is just some code to serialize and
deserialize tuples and transmit 'em via the existing NOTIFY payload
facility. I agree that presenting it as some functions would be a lot
less work than inventing
Magnus Hagander mag...@hagander.net writes:
On Tue, Dec 13, 2011 at 11:59, Greg Smith g...@2ndquadrant.com wrote:
HINT: you can use pg_cancel_backend() on your own processes
That HINT sounds a bit weird to me. you can cancel your own queries
using pg_cancel_backend() instead or something
Pavan Deolasee pavan.deola...@gmail.com writes:
BTW, on an unrelated note, I was looking at the way ShmemInitStruct()
is used. It internally uses ShmemAlloc to allocate from shared memory.
ShmemAlloc always MAXALIGN the requested size. But while calculating
the total shared memory requirement,
Pavan Deolasee pavan.deola...@gmail.com writes:
Looking at CommitTransaction(), it seems quite clear to me that we
call ProcArrayEndTransaction() before releasing the locks held by the
transaction. So its quite possible that when
GetRunningTransactionLocks goes through the list of currently
On Tue, Dec 13, 2011 at 06:36:21PM -0300, Alvaro Herrera wrote:
Excerpts from Noah Misch's message of dom dic 04 09:20:27 -0300 2011:
@@ -2725,11 +2884,20 @@ l2:
oldtup.t_data-t_infomask = ~(HEAP_XMAX_COMMITTED |
HEAP_XMAX_INVALID |
Pavel Stehule wrote:
changes:
* fixed warnings
* support for options - actually only two options are supported -
quite and fatal_errors
these options are +/- useful - main reason for their existence is
testing of support of options - processing on CHECK ... stmt side and
processing on
Noah Misch n...@leadboat.com writes:
On Tue, Dec 13, 2011 at 06:36:21PM -0300, Alvaro Herrera wrote:
Yeah, I've been wondering about this: do we have a problem already with
exclusion constraints? I mean, if a concurrent inserter doesn't see the
tuple that we've marked here as deleted while we
On Wed, Dec 14, 2011 at 4:45 AM, Magnus Hagander mag...@hagander.net wrote:
* There are a number of things that are always written to stdout, that
there is no way to redirect. In some cases it's interactive prompts -
makes sense - but also for example the output of \timing goes to
stdout
On Mon, Dec 12, 2011 at 12:17 PM, Simon Riggs si...@2ndquadrant.com wrote:
On Sat, Dec 10, 2011 at 12:29 PM, Greg Smith g...@2ndquadrant.com wrote:
We can send regular special messages from WALSender to WALReceiver that do
not form part of the WAL stream, so we don't bulk
up WAL archives.
On 14 December 2011 15:10, Merlin Moncure mmonc...@gmail.com wrote:
As to the wider point I'm wondering why you can't layer your API on
top of existing facilities (tables, notifications, etc). PGQ (have you
seen that?) does this and it's an absolute marvel. Meaning, I bet you
could do this
Andrew Dunstan and...@dunslane.net writes:
Done and done (see
https://sourceforge.net/tracker/?func=detailaid=3458244group_id=202880atid=983354).
Did you see Kai's update on the ticket? If this is the case, I know
that we have seen similar bugs with PostGIS and the work-around has
been
On Dec 14, 2011, at 6:31 AM, Andrew Dunstan wrote:
Thanks. Committed with that changed, although we seem to be getting
altogether too obsessive about white space, IMNSHO.
If that’s all there is to complain about, I think it’s a pretty good sign. ;-P
David
--
Sent via pgsql-hackers mailing
On Wed, Dec 14, 2011 at 11:14 AM, Tom Lane t...@sss.pgh.pa.us wrote:
-ffloat-store is a brute force solution, I think, and would affect old
versions of gcc that don't exhibit any problems. I would suggest
altering configure to see whether the compiler recognizes
-fexcess-precision=standard
I started reading the spgist vacuum code last night, and didn't like it
at all. I found a number of smaller issues, but it seems to me that
the design is just fundamentally wrong. Unless I'm misunderstanding it,
the approach is to recursively traverse the tree in sort of the same way
that a
Robert Haas robertmh...@gmail.com writes:
On Wed, Dec 14, 2011 at 11:14 AM, Tom Lane t...@sss.pgh.pa.us wrote:
-ffloat-store is a brute force solution, I think, and would affect old
versions of gcc that don't exhibit any problems. I would suggest
altering configure to see whether the compiler
On Wed, Dec 14, 2011 at 12:36 PM, Tom Lane t...@sss.pgh.pa.us wrote:
AFAICS it's really impractical to do that. The code Andrew is having
problems with is essentially
double a,b,c;
...
a = b * c;
if (isinf(a)) throw error;
and the problem is that the
It would not take very much at all to make the SP-GiST stuff support
index-only scans, except for one thing: it's conceivable that an opclass
might choose to store only a lossy version of the original indexed
datum, in which case it'd not be able to reconstruct the datum on
demand.
I'm not sure
Robert Haas robertmh...@gmail.com writes:
Uh, wow. That really is pretty insane. How is anyone supposed to
write sensible code around that non-API?
Usability seems to be very low on the gcc project's list of goals
these days.
Personally I think this sort of thing might be fine if it were
On 2011-12-14 19:00, Tom Lane wrote:
So the problem is that we have to either disallow such opclass designs,
or support per-opclass rather than per-index-AM decisions about whether
index-only scans are possible.
Just a quick comment, for some queries like the famous
select count(*) from table
Jesper Krogh jes...@krogh.cc writes:
On 2011-12-14 19:00, Tom Lane wrote:
So the problem is that we have to either disallow such opclass designs,
or support per-opclass rather than per-index-AM decisions about whether
index-only scans are possible.
Just a quick comment, for some queries like
On Wed, Dec 14, 2011 at 3:20 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Pavan Deolasee pavan.deola...@gmail.com writes:
Looking at CommitTransaction(), it seems quite clear to me that we
call ProcArrayEndTransaction() before releasing the locks held by the
transaction. So its quite possible that
On 12/14/2011 11:14 AM, Tom Lane wrote:
-ffloat-store is a brute force solution, I think, and would affect old
versions of gcc that don't exhibit any problems. I would suggest
altering configure to see whether the compiler recognizes
-fexcess-precision=standard and adding that to CFLAGS if
On 2011-12-14 19:48, Tom Lane wrote:
Jesper Kroghjes...@krogh.cc writes:
On 2011-12-14 19:00, Tom Lane wrote:
So the problem is that we have to either disallow such opclass designs,
or support per-opclass rather than per-index-AM decisions about whether
index-only scans are possible.
Just a
Andrew Dunstan and...@dunslane.net writes:
+ # Disable FP optimizations that cause isinf errors on gcc 4.5+
+ PGAC_PROG_CC_CFLAGS_OPT([-fexcess-precision=standard])
Looks sane to me, except isinf errors is an awfully narrow reading of
the problem. Maybe just say assorted errors?
Jesper Krogh jes...@krogh.cc writes:
On 2011-12-14 19:48, Tom Lane wrote:
I think this is somewhat wishful thinking unfortunately. The difficulty
is that if the index isn't capable of reconstructing the original value,
then it's probably giving only an approximate (lossy) answer, which
means
On 12/14/2011 03:09 PM, Tom Lane wrote:
Andrew Dunstanand...@dunslane.net writes:
+ # Disable FP optimizations that cause isinf errors on gcc 4.5+
+ PGAC_PROG_CC_CFLAGS_OPT([-fexcess-precision=standard])
Looks sane to me, except isinf errors is an awfully narrow reading of
the
Hello
so removed quite option
and removed multiple check regression tests also - there is missing
explicit order of function checking, so regress tests can fail :(
Regards
Pavel
2011/12/14 Albe Laurenz laurenz.a...@wien.gv.at:
Pavel Stehule wrote:
changes:
* fixed warnings
* support for
I've submitted two patches for adding new include features to the
postgresql.conf file. While not quite commit quality yet, I hope
everyone will agree their reviews this week suggest both are close
enough that any number of people could finish them off. Before
re-opening this can of worms, I
On Wed, Dec 14, 2011 at 9:05 AM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
Excerpts from Dimitri Fontaine's message of mié dic 14 07:22:21 -0300 2011:
Again, that's a caveat of the first implementation, you can't have sub
commands support without forcing them through ProcessUtility and
On Wed, Dec 14, 2011 at 4:16 PM, Greg Smith g...@2ndquadrant.com wrote:
[ plan for deprecating recovery.conf ]
+1. I'd be very happy with this plan.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list
On Wed, Dec 14, 2011 at 22:16, Greg Smith g...@2ndquadrant.com wrote:
I've submitted two patches for adding new include features to the
postgresql.conf file. While not quite commit quality yet, I hope everyone
will agree their reviews this week suggest both are close enough that any
number of
On 12/14/11 1:16 PM, Greg Smith wrote:
-Creating a standby.enabled file in the directory that houses the
postgresql.conf (same logic as include uses to locate things) puts the
system into recovery mode. That feature needs to save some state, and
making those decisions based on existence of
Robert Haas robertmh...@gmail.com writes:
I can get behind this argument: force all stuff through ProcessUtility
for regularity, and not necessarily in the first patch for this feature.
That seems like a pretty heavy dependency on an implementation detail
that we might want to change at some
On 12/14/2011 04:47 PM, Magnus Hagander wrote:
You say the server can just delete it. But how will this work if the
file is *not* in the data directory? If you are on a Debian style
system for example, where all these files go in /etc/postgresql -
wouldn't that suddenly require the postgres user
On 12/14/2011 04:57 PM, Josh Berkus wrote:
How will things work for PITR?
Left that out mainly because I was already running too long there, but I
do think there's a reasonable path. There is one additional wrinkle in
there to consider that I've thought of so far, falling into the what is
Greg,
Put the stuff you used to insert into recovery.conf into postgresql.conf
instead. If you don't like that, use another file and include it with
one of the multiple options for that--same migration option I already
suggested. Run pg_ctl recovery; under the hood that's actually
creating
(2011/12/14 15:34), Shigeru Hanada wrote:
(2011/12/13 22:00), Etsuro Fujita wrote:
Thank you for your effectiveness experiments and proposals for
improvements. I updated the patch according to your proposals.
Attached is the updated version of the patch.
I think this patch could be marked
On 12/14/2011 08:56 PM, Josh Berkus wrote:
So for streaming replication, will I need to have a standby.enabled
file, or will there be a parameter in postgresql.conf (or included
files) which controls whether or not that server is a standby, available?
In the best of all possible worlds, I'd
60 matches
Mail list logo
