Please keep in mind, that the Call for Speakers is open until December 20th.
Only a few days left.
Now it's a good time to submit your proposal ;-)
Did someone applied?
--
--
Emanuel Calvo
Helpame.com
--
Sent via pgsql-hackers mailing list
Hello
I am working on quiet dumps now. i found a small issue.
pg_dump produces a statements
ALTER TABLE ONLY public.b DROP CONSTRAINT b_fk_fkey;
ALTER TABLE ONLY public.a DROP CONSTRAINT a_pkey;
DROP TABLE IF EXISTS public.b;
DROP TABLE IF EXISTS public.a;
Actually there is no a conditional
Hi list,
As discussed on the pgsql-general list, the bool_and() and bool_or()
aggregate functions behave exactly like min() and max() would over
booleans. While it's not likely that people would have an appropriate
index on a boolean column, it seems it wouldn't cost us anything to
take advantage
Merlin Moncure mmonc...@gmail.com writes:
Getting back on point, I'm curious about your statement: without
writing a single line of C. I took a look at the pl/scheme docs and
was pretty impressed -- what exactly would be involved to get a
guile-based ECMAscript working over the pl/scheme
On Mon, Dec 19, 2011 at 4:21 AM, Josh Berkus j...@agliodbs.com wrote:
On 12/18/11 5:55 PM, Greg Stark wrote:
There is another way to look at this problem. Perhaps it's worth
having a checksum *even if* there are ways for the checksum to be
spuriously wrong. Obviously having an invalid checksum
On Monday, December 19, 2011 12:10:11 PM Simon Riggs wrote:
The only sensible way to handle this is to change the page format as
discussed. IMHO the only sensible way that can happen is if we also
support an online upgrade feature. I will take on the online upgrade
feature if others work on
On Mon, Dec 19, 2011 at 6:10 AM, Simon Riggs si...@2ndquadrant.com wrote:
Throwing WARNINGs for normal events would not help anybody; thousands
of false positives would just make Postgres appear to be less robust
than it really is. That would be a credibility disaster. VMWare
already have
On Thu, Dec 15, 2011 at 8:30 AM, 高增琦 pgf...@gmail.com wrote:
I found this several days ago when I try to debug a fetch of cursor.
And I have sent a mail to this list, but no one reply...
Maybe this is a very simple problem, please help me, thanks a lot...
Here is the example:
create
On Fri, Dec 16, 2011 at 2:06 PM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
Yeah. Nikhil, Alex, this is the merged patch. Have a look that it
still works for you (particularly the pg_dump bits) and I'll commit it.
I adjusted the regression test a bit too.
It seems hard to believe that
On Fri, Dec 16, 2011 at 10:01 AM, Simon Riggs si...@2ndquadrant.com wrote:
To provide some form of keepalive on quiet systems the
archive_keepalive_command provides a generic hook to implement
keepalives. This is implemented as a separate command to avoid storing
keepalive messages in the
On 12/19/2011 08:17 AM, Robert Haas wrote:
If you want keepalives, why use log shipping rather than SR? Implementing a
really-high-latency method of passing protocol messages through the
archive seems like a complex solution to a non-problem
The problem being addressed is how can people using
* Aidan Van Dyk (ai...@highrise.ca) wrote:
But the scary part is you don't know how long *ago* the crash was.
Because a hint-bit-only change w/ a torn-page is a non event in
PostgreSQL *DESIGN*, on crash recovery, it doesn't do anything to try
and scrub every page in the database.
Fair
* Aidan Van Dyk (ai...@highrise.ca) wrote:
#) Anybody investigated putting the CRC in a relation fork, but not
right in the data block? If the CRC contains a timestamp, and is WAL
logged before the write, at least on reading a block with a wrong
checksum, if a warning is emitted, the
On 12/18/2011 09:02 PM, Robert Haas wrote:
If we're actually going to expose the parse tree, I think JSON
(or even XML) would be a far better way to expose that than the
existing nodeToString() output. Sure, you could make due with the
nodeToString() output for some things, especially in
Excerpts from Stephen Frost's message of lun dic 19 11:18:21 -0300 2011:
* Aidan Van Dyk (ai...@highrise.ca) wrote:
#) Anybody investigated putting the CRC in a relation fork, but not
right in the data block? If the CRC contains a timestamp, and is WAL
logged before the write, at least on
On Mon, Dec 19, 2011 at 9:14 AM, Stephen Frost sfr...@snowman.net wrote:
* Aidan Van Dyk (ai...@highrise.ca) wrote:
But the scary part is you don't know how long *ago* the crash was.
Because a hint-bit-only change w/ a torn-page is a non event in
PostgreSQL *DESIGN*, on crash recovery, it
Excerpts from Dimitri Fontaine's message of dom dic 18 16:54:11 -0300 2011:
Tom Lane t...@sss.pgh.pa.us writes:
Hmm ... I don't think that I *am* ok with that. ISTM that we'd then
find ourselves with any changes in utility statement parse trees
amounting to a user-visible API break, and
On 12/18/2011 07:31 AM, Magnus Hagander wrote:
* I restructured the if statements, because I had a hard time
following the comments around that ;) I find this one easier - but I'm
happy to change back if you think your version was more readable.
That looks fine. I highlighted this because I
On 12/17/2011 04:00 PM, Pavel Stehule wrote:
I use it for checking of my most large plpgsql project - it is about
300KB plpgsql procedures - but this code is not free - and this module
helps to find lot of bugs.
Great. If you continue to check against that regularly, that makes me
feel
OS: I am using Windows server 2003
Version upgrade: hmm.. Is there any fix/change related to this issue in
9.0.6?
If yes, I will upgrade in next scheduled downtime (I am using this as
production server)...
postgres queries are very occasionly used (a set of calls once in 30
minutes).. so I guess
On Fri, Dec 16, 2011 at 10:32 AM, Noah Misch n...@leadboat.com wrote:
I agree, but my point is that so far we have no callbacks that differ
only in that detail. I accept that we'd probably want to avoid that.
To illustrate what I had in mind, here's a version of your patch that has five
Upgrading an instance containing plpython from =8.4 to =9.0 is broken
because the module plpython.so was renamed to plpython2.so, and so the
pg_upgrade check for loadable libraries fails thus:
Your installation references loadable libraries that are missing from the
new installation.
I recently upgraded my postgres server from 9.0 to 9.1.2 and I am
finding a peculiar problem.I have a program that periodically adds rows
to this table using INSERT. Typically the number of rows is just 1-2
thousand when the table already has 500K rows. Whenever the program is
adding rows, the
On 19-12-2011 12:30, Sushant Sinha wrote:
I recently upgraded my postgres server from 9.0 to 9.1.2 and I am
finding a peculiar problem.I have a program that periodically adds rows
to this table using INSERT. Typically the number of rows is just 1-2
thousand when the table already has 500K
2011/12/19 Greg Smith g...@2ndquadrant.com:
On 12/17/2011 04:00 PM, Pavel Stehule wrote:
I use it for checking of my most large plpgsql project - it is about
300KB plpgsql procedures - but this code is not free - and this module
helps to find lot of bugs.
Great. If you continue to check
On Sun, Dec 18, 2011 at 10:28, Gianni Ciolli
gianni.cio...@2ndquadrant.it wrote:
http://wiki.postgresql.org/wiki/Autonomous_subtransactions
It is meant to be an ongoing project, requesting comments and
contributions, rather than a conclusive document.
In addition to what Jim Nasby said, this
On Mon, Dec 19, 2011 at 9:31 AM, Greg Smith g...@2ndquadrant.com wrote:
That seems pretty sensible; I wouldn't want to make it a hard requirement
though. There are three major ways this could go for 9.2:
1) Nothing is changed in core, the best that can be done is whatever you can
cram into
Hi,
On Monday, December 19, 2011 05:12:13 PM Robert Haas wrote:
On Mon, Dec 19, 2011 at 9:31 AM, Greg Smith g...@2ndquadrant.com wrote:
That seems pretty sensible; I wouldn't want to make it a hard requirement
though. There are three major ways this could go for 9.2:
1) Nothing is
2011/12/19 Robert Haas robertmh...@gmail.com:
On Mon, Dec 19, 2011 at 9:31 AM, Greg Smith g...@2ndquadrant.com wrote:
That seems pretty sensible; I wouldn't want to make it a hard requirement
though. There are three major ways this could go for 9.2:
1) Nothing is changed in core, the best
On Mon, Dec 19, 2011 at 11:20 AM, Andres Freund and...@anarazel.de wrote:
I do. Anyone coding in PL/pgsql is going to find the nodeToString()
output unusable, and we can easily provide a built-in JSON datatype
with enough richness to make that problem go away in time for 9.2.
People in
On Mon, Dec 19, 2011 at 10:02 AM, pratikchirania pratik.chira...@hp.com wrote:
Version upgrade: hmm.. Is there any fix/change related to this issue in
9.0.6?
You could read the release notes for those minor version upgrades.
Based on a quick look through the commit logs, and a quick grep of
On Sat, Dec 17, 2011 at 3:27 AM, Ross Reedstrom reeds...@rice.edu wrote:
On Fri, Dec 16, 2011 at 02:55:09PM +, Richard Huxton wrote:
According to the docs [1], you should escape embedded colons in
.pgpass (fair enough). Below is PG 9.1.1
user = te:st, db = te:st, password = te:st
$
On Mon, Dec 19, 2011 at 10:11:23AM -0500, Robert Haas wrote:
On Fri, Dec 16, 2011 at 10:32 AM, Noah Misch n...@leadboat.com wrote:
I agree, but my point is that so far we have no callbacks that differ
only in that detail. ?I accept that we'd probably want to avoid that.
To illustrate what
On Fri, Dec 16, 2011 at 00:15, amit sehas cu...@yahoo.com wrote:
There is the TOAST mechanism for oversized tuples but that is still
considered to be a single tuple. Is there any circumstance in which an
attribute which is an array will be broken up into individual
tuples which are somehow
On 12/19/2011 11:45 AM, Robert Haas wrote:
On Mon, Dec 19, 2011 at 10:02 AM, pratikchiraniapratik.chira...@hp.com wrote:
Version upgrade: hmm.. Is there any fix/change related to this issue in
9.0.6?
You could read the release notes for those minor version upgrades.
Based on a quick look
On Mon, Dec 19, 2011 at 09:34:51AM -0500, Robert Haas wrote:
On Mon, Dec 19, 2011 at 9:14 AM, Stephen Frost sfr...@snowman.net wrote:
* Aidan Van Dyk (ai...@highrise.ca) wrote:
But the scary part is you don't know how long *ago* the crash was.
Because a hint-bit-only change w/ a torn-page
It seems hard to believe that ATExecDropConstraint() doesn't need any
adjustment.
Yeah, I think we could return early on for only type of constraints.
Also, shouldn't the systable scan break out of the while loop after a
matching constraint name has been found? As of now, it's doing a full
On Mon, Dec 19, 2011 at 17:30, Sushant Sinha sushant...@gmail.com wrote:
This never happened earlier with postgres 9.0 Is there a known issue
with Postgres 9.1? Or how to report this problem?
What *did* change in 9.1 is that there's new GIN cost estimation in
the planner. If you do EXPLAIN
On Monday, December 19, 2011 03:33:22 PM Alvaro Herrera wrote:
Excerpts from Stephen Frost's message of lun dic 19 11:18:21 -0300 2011:
* Aidan Van Dyk (ai...@highrise.ca) wrote:
#) Anybody investigated putting the CRC in a relation fork, but not
right in the data block? If the CRC
* David Fetter (da...@fetter.org) wrote:
On Mon, Dec 19, 2011 at 09:34:51AM -0500, Robert Haas wrote:
On Mon, Dec 19, 2011 at 9:14 AM, Stephen Frost sfr...@snowman.net wrote:
Fair enough, but, could we distinguish these two cases? In other words,
would it be possible to detect if a page
* Andres Freund (and...@anarazel.de) wrote:
On Monday, December 19, 2011 03:33:22 PM Alvaro Herrera wrote:
I do like the idea of putting the CRC info in a relation fork, if it can
be made to work decently, as we might be able to then support it on a
per-relation basis, and maybe even
On Mon, 2011-12-19 at 19:08 +0200, Marti Raudsepp wrote:
Another thought -- have you read about the GIN fast updates feature?
This existed in 9.0 too. Instead of updating the index directly, GIN
appends all changes to a sequential list, which needs to be scanned in
whole for read queries. The
On Mon, 2011-12-19 at 12:41 -0300, Euler Taveira de Oliveira wrote:
On 19-12-2011 12:30, Sushant Sinha wrote:
I recently upgraded my postgres server from 9.0 to 9.1.2 and I am
finding a peculiar problem.I have a program that periodically adds
rows
to this table using INSERT. Typically the
Andres Freund and...@anarazel.de writes:
On Monday, December 19, 2011 05:12:13 PM Robert Haas wrote:
I do. Anyone coding in PL/pgsql is going to find the nodeToString()
output unusable, and we can easily provide a built-in JSON datatype
with enough richness to make that problem go away in
On 2011-12-19 18:08, Marti Raudsepp wrote:
The query uses the gin index and the tsearch ranking function
ts_rank_cd.
Another thought -- have you read about the GIN fast updates feature?
This existed in 9.0 too. Instead of updating the index directly, GIN
appends all changes to a sequential
On Mon, Dec 19, 2011 at 1:17 PM, Robert Haas robertmh...@gmail.com wrote:
On Fri, Dec 16, 2011 at 10:01 AM, Simon Riggs si...@2ndquadrant.com wrote:
To provide some form of keepalive on quiet systems the
archive_keepalive_command provides a generic hook to implement
keepalives. This is
Excerpts from Alex Hunsaker's message of vie dic 16 18:07:05 -0300 2011:
On Fri, Dec 16, 2011 at 14:01, Alvaro Herrera
alvhe...@commandprompt.com wrote:
Excerpts from Alex Hunsaker's message of vie dic 16 17:50:12 -0300 2011:
On Fri, Dec 16, 2011 at 12:06, Alvaro Herrera
On 12/19/2011 11:12 AM, Robert Haas wrote:
But before we get bogged down in the data representation, I think we
need to make a more fundamental decision: to what extent are we OK
with exporting the parse tree at all, in any form? Tom is arguing
that we shouldn't, and I see his point: the recent
On Sat, Dec 17, 2011 at 3:52 PM, Phil Sorber p...@omniti.com wrote:
Attached is a patch that addresses the todo item Improve relation
size functions such as pg_relation_size() to avoid producing an error
when called against a no longer visible relation.
On Sun, Dec 18, 2011 at 4:22 PM, Jim Nasby j...@nasby.net wrote:
On Dec 18, 2011, at 2:28 AM, Gianni Ciolli wrote:
I have written some notes about autonomous subtransactions, which have
already been touched (at least) in two separate threads; please find
them at
On Mon, Dec 19, 2011 at 3:52 PM, Marti Raudsepp ma...@juffo.org wrote:
On Sun, Dec 18, 2011 at 10:28, Gianni Ciolli
gianni.cio...@2ndquadrant.it wrote:
http://wiki.postgresql.org/wiki/Autonomous_subtransactions
It is meant to be an ongoing project, requesting comments and
contributions,
On Mon, Dec 19, 2011 at 12:52 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I personally think youre underestimating the complexity of providing a
sensible json compatibility shim ontop the nodestring representation. But I
would like to be proven wrong ;)
If we were going to do this at all, the way
On Mon, Dec 19, 2011 at 11:55 AM, Noah Misch n...@leadboat.com wrote:
Here's the rule I used: the pre-lock checks must prove that the user could, by
some command working as-designed, have taken a lock at least as strong as the
one we're about to acquire. How does that work out in practice?
On 12/19/2011 07:50 AM, Robert Haas wrote:
On Mon, Dec 19, 2011 at 6:10 AM, Simon Riggssi...@2ndquadrant.com wrote:
The only sensible way to handle this is to change the page format as
discussed. IMHO the only sensible way that can happen is if we also
support an online upgrade feature. I will
A client has again raised with me the ugliness of pretty printed
viewdefs. We looked at this a couple of years ago, but discussion went
off into the weeds slightly, so I dropped it, but as requested I'm
revisiting it.
The problem can be simply seen in the screenshot here:
On 12/14/2011 09:02 AM, Shigeru Hanada wrote:
Here I'd like to propose three incremental patches:
1) fdw_helper_funcs_v3.patch...: This is not specific to pgsql_fdw, but
probably useful for every FDWs which use FDW options...
2) pgsql_fdw_v5.patch: This patch provides simple pgsql_fdw
Greg Smith g...@2ndquadrant.com wrote:
2) Rework hint bits to make the torn page problem go away.
Checksums go elsewhere? More WAL logging to eliminate the bad
situations? Eliminate some types of hint bit writes? It seems
every alternative has trade-offs that will require serious
This feature has now passed through review by Dimitri with him no longer
having anything to say about it. I've marked it ready for committer
now. Seems the main decision left here is whether another committer
wants to take a look at this, or if Robert wants to take a spin on the
buildfarm
On Mon, Dec 19, 2011 at 12:07 PM, David Fetter da...@fetter.org wrote:
On Mon, Dec 19, 2011 at 09:34:51AM -0500, Robert Haas wrote:
On Mon, Dec 19, 2011 at 9:14 AM, Stephen Frost sfr...@snowman.net wrote:
* Aidan Van Dyk (ai...@highrise.ca) wrote:
But the scary part is you don't know how
On Mon, Dec 19, 2011 at 2:16 PM, Kevin Grittner
kevin.gritt...@wicourts.gov wrote:
It seems to me that on a typical production system you would
probably have zero or one such page per OS crash, with zero being
far more likely than one. If we can get that one fixed (if it
exists) before enough
On Mon, Dec 19, 2011 at 20:34, Simon Riggs si...@2ndquadrant.com wrote:
It's not clear to me why you think there would be a limitation to
exactly 2 autonomous transactions.
Sorry my bad, I didn't read the proposal carefully. Nesting does
indeed allow multiple autonomous subtransactions.
Maybe
On 19/12/11 16:48, Robert Haas wrote:
On Sat, Dec 17, 2011 at 3:27 AM, Ross Reedstromreeds...@rice.edu wrote:
This should either be fixed by changing the documentation to say to not escape
colons or backslashes in the password part, only, or modify this function
(PasswordFromFile) to silently
Excerpts from Richard Huxton's message of lun dic 19 16:33:31 -0300 2011:
On 19/12/11 16:48, Robert Haas wrote:
On Sat, Dec 17, 2011 at 3:27 AM, Ross Reedstromreeds...@rice.edu wrote:
This should either be fixed by changing the documentation to say to not
escape
colons or backslashes
Excerpts from Marti Raudsepp's message of lun dic 19 16:32:06 -0300 2011:
(I do realize that allowing subtransactions to commit out of order
also makes it failure prone)
Uhm? You can't commit savepoints out of order. You can release an
older one, but then all the ones following it disappear
Robert Haas robertmh...@gmail.com wrote:
On Mon, Dec 19, 2011 at 2:16 PM, Kevin Grittner
kevin.gritt...@wicourts.gov wrote:
It seems to me that on a typical production system you would
probably have zero or one such page per OS crash, with zero being
far more likely than one. If we can get
On Mon, Dec 19, 2011 at 21:43, Alvaro Herrera
alvhe...@commandprompt.com wrote:
(I do realize that allowing subtransactions to commit out of order
also makes it failure prone)
Uhm? You can't commit savepoints out of order. You can release an
older one, but then all the ones following it
On Sat, Dec 17, 2011 at 6:11 AM, Simon Riggs si...@2ndquadrant.com wrote:
A simpler example shows it better. Tom's idea prevents 2 rows being
returned, but doesn't prevent zero rows.
I don't think it prevents either one. Suppose we read and return a
tuple, and then someone HOT-updates it and
On Mon, Dec 19, 2011 at 01:43:18PM -0500, Robert Haas wrote:
On Mon, Dec 19, 2011 at 11:55 AM, Noah Misch n...@leadboat.com wrote:
Here's the rule I used: the pre-lock checks must prove that the user could,
by
some command working as-designed, have taken a lock at least as strong as
the
On 12/19/2011 02:44 PM, Kevin Grittner wrote:
I was thinking that we would warn when such was found, set hint bits
as needed, and rewrite with the new CRC. In the unlikely event that
it was a torn hint-bit-only page update, it would be a warning about
something which is a benign side-effect of
Excerpts from Marti Raudsepp's message of lun dic 19 16:50:22 -0300 2011:
On Mon, Dec 19, 2011 at 21:43, Alvaro Herrera
alvhe...@commandprompt.com wrote:
(I do realize that allowing subtransactions to commit out of order
also makes it failure prone)
Uhm? You can't commit savepoints
On 19.12.2011 21:27, Robert Haas wrote:
To put this another way, we currently WAL-log just about everything.
We get away with NOT WAL-logging some things when we don't care about
whether they make it to disk. Hint bits, killed index tuple pointers,
etc. cause no harm if they don't get written
On Mon, Dec 19, 2011 at 05:52:40PM +0200, Marti Raudsepp wrote:
On Sun, Dec 18, 2011 at 10:28, Gianni Ciolli
gianni.cio...@2ndquadrant.it wrote:
http://wiki.postgresql.org/wiki/Autonomous_subtransactions
It is meant to be an ongoing project, requesting comments and
contributions, rather
On Mon, Dec 19, 2011 at 09:32:06PM +0200, Marti Raudsepp wrote:
Maybe that's just my paranoia, but the fact that subtransactions
aren't named means it's pretty easy to accidentally get out of step
and commit the wrong subtransaction. I see app developers often
messing up BEGIN/COMMIT/ROLLBACK
Marti Raudsepp ma...@juffo.org writes:
On Mon, Dec 19, 2011 at 17:30, Sushant Sinha sushant...@gmail.com wrote:
This never happened earlier with postgres 9.0 Is there a known issue
with Postgres 9.1? Or how to report this problem?
What *did* change in 9.1 is that there's new GIN cost
Jesper Krogh jes...@krogh.cc writes:
I have to say that I consistently have to turn fastupdate off for
our heavily updated gin-indexes. The overall performance gain
may be measurable, but its not intolerable without. The spikes seen
from the applications, when cleanup happens. Either in the
On Mon, Dec 19, 2011 at 12:07 PM, Nikhil Sontakke nikkh...@gmail.com wrote:
It seems hard to believe that ATExecDropConstraint() doesn't need any
adjustment.
Yeah, I think we could return early on for only type of constraints.
It's not just that. Suppose that C inherits from B which inherits
Excerpts from Nikhil Sontakke's message of lun dic 19 14:07:02 -0300 2011:
PFA, revised version containing the above changes based on Alvaro's v4
patch.
Committed with these fixes, and with my fix for the pg_dump issue noted
by Alex, too. Thanks.
--
Álvaro Herrera
Hi list,
Since PostgreSQL 9.1, GIN has new cost estimation code. This code
assumes that the only expression type it's going to see is OpExpr.
However, ScalarArrayOpExpr has also been possible in earlier versions.
Estimating col op ANY (array) queries segfaults in 9.1 if there's
a GIN index on the
Greg Smith g...@2ndquadrant.com wrote:
But if you need all that infrastructure just to get the feature
launched, that's a bit hard to stomach.
Triggering a vacuum or some hypothetical scrubbing feature?
Also, as someone who follows Murphy's Law as my chosen religion,
If you don't think
On Dec 18, 2011, at 4:41 AM, Magnus Hagander wrote:
We can hopefully get around this for the extensions in contrib (and
reasonably well has already), but few large companies are going to be
happy to go to pgxn and download an extension that has a single
maintainer (not the team, and in most
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
On 08.12.2011 08:20, Tom Lane wrote:
I thought that removing the unreadable file would let me restart,
but after rm 52860_fsm and trying again to start the server,
there's a different problem:
LOG: consistent recovery state
On Dec 19, 2011, at 3:39 PM, David E. Wheeler wrote:
Well, no, JSON is formally “a lightweight data-interchange format.” It’s
derived from JavaScript syntax, but it is not a programming language, so I
wouldn’t say it was accurate to describe it as a subset of JS or ECMAScript.
Bah, it says
On Dec 19, 2011, at 2:49 AM, Dimitri Fontaine wrote:
My understanding is that JSON is a subset of ECMAscript
Well, no, JSON is formally “a lightweight data-interchange format.” It’s
derived from JavaScript syntax, but it is not a programming language, so I
wouldn’t say it was accurate to
Hello everybody,
this patch adds two counters to pg_stat_database to track temporary
files - number of temp files and number of bytes. I see this as a useful
feature, as temporary files often cause a lot of IO (because of low
work_mem etc.). The log_temp_files is useful, but you have to parse the
PFA, revised version containing the above changes based on Alvaro's v4
patch.
Committed with these fixes, and with my fix for the pg_dump issue noted
by Alex, too. Thanks.
Thanks a lot Alvaro!
Regards,
Nikhils
--
Álvaro Herrera alvhe...@commandprompt.com
The PostgreSQL Company -
Excerpts from Nikhil Sontakke's message of lun dic 19 22:32:57 -0300 2011:
PFA, revised version containing the above changes based on Alvaro's v4
patch.
Committed with these fixes, and with my fix for the pg_dump issue noted
by Alex, too. Thanks.
Thanks a lot Alvaro!
You're
On Mon, Dec 19, 2011 at 1:27 PM, Phil Sorber p...@omniti.com wrote:
On Sat, Dec 17, 2011 at 3:52 PM, Phil Sorber p...@omniti.com wrote:
Attached is a patch that addresses the todo item Improve relation
size functions such as pg_relation_size() to avoid producing an error
when called against a
On Mon, Dec 19, 2011 at 12:05:09PM -0500, Robert Haas wrote:
Yet another option, which I wonder whether we're dismissing too
lightly, is to just call GetSnapshotData() and do the scan using a
plain old MVCC snapshot. Sure, it's more expensive than SnapshotNow,
but is it expensive enough to
On Mon, Dec 19, 2011 at 10:25:34AM +0100, Pavel Stehule wrote:
I am working on quiet dumps now. i found a small issue.
pg_dump produces a statements
ALTER TABLE ONLY public.b DROP CONSTRAINT b_fk_fkey;
ALTER TABLE ONLY public.a DROP CONSTRAINT a_pkey;
DROP TABLE IF EXISTS public.b;
Noah Misch n...@leadboat.com writes:
On Mon, Dec 19, 2011 at 12:05:09PM -0500, Robert Haas wrote:
Yet another option, which I wonder whether we're dismissing too
lightly, is to just call GetSnapshotData() and do the scan using a
plain old MVCC snapshot. Sure, it's more expensive than
But did you see Robert Haas' response upthread? It looks like there's
still some work to do -- at least some research to determine that we're
correctly handling all those cases. As the committer I'm responsible
for it, but I don't have resources to get into it any time soon.
Yeah, am
On Mon, Dec 19, 2011 at 3:12 PM, Noah Misch n...@leadboat.com wrote:
I'm satisfied that you and I have a common understanding of the options and
their respective merits. There's plenty of room for judgement in choosing
which merits to seize at the expense of others. Your judgements here seem
On Mon, Dec 19, 2011 at 6:26 PM, David E. Wheeler da...@kineticode.com wrote:
+1, though I think the core type will at least need some basic operators and
indexing support.
And I'm willing to do that, but I thought it best to submit a bare
bones patch first, in the hopes of minimizing the
Marti Raudsepp ma...@juffo.org writes:
Since PostgreSQL 9.1, GIN has new cost estimation code. This code
assumes that the only expression type it's going to see is OpExpr.
However, ScalarArrayOpExpr has also been possible in earlier versions.
Estimating col op ANY (array) queries segfaults in
Hi Robert,
First of all, let me state that this ONLY feature has not messed around
with existing inheritance semantics. It allows attaching a constraint to
any table (which can be part of any hierarchy) without the possibility of
it ever playing any part in future or existing inheritance
95 matches
Mail list logo
