Re: [HACKERS] Review: Non-inheritable check constraints

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 hierarc

Re: [HACKERS] [PATCH] Fix ScalarArrayOpExpr estimation for GIN indexes

Marti Raudsepp 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 ANY () queries segfaults in 9.1 if there's > a

Re: [HACKERS] JSON for PG 9.2

On Mon, Dec 19, 2011 at 6:26 PM, David E. Wheeler 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 number of objectionable

Re: [HACKERS] RangeVarGetRelid()

On Mon, Dec 19, 2011 at 3:12 PM, Noah Misch 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 > entirely reas

Re: [HACKERS] Review: Non-inheritable check constraints

> 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

Re: [HACKERS] ALTER TABLE lock strength reduction patch is unsafe

Noah Misch 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 SnapshotNow, >> but

Re: [HACKERS] ToDo: conditional ALTER TABLE

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.

Re: [HACKERS] ALTER TABLE lock strength reduction patch is unsafe

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

[HACKERS] Re: WIP patch: Improve relation size functions such as pg_relation_size() to avoid producing an error when called against a no longer visible relation

On Mon, Dec 19, 2011 at 1:27 PM, Phil Sorber wrote: > On Sat, Dec 17, 2011 at 3:52 PM, Phil Sorber 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 relat

Re: [HACKERS] Review: Non-inheritable check constraints

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!

Re: [HACKERS] Review: Non-inheritable check constraints

> > 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 > The PostgreSQL Company - Command Prompt, I

[HACKERS] PATCH: tracking temp files in pg_stat_database

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

Re: [HACKERS] JSON for PG 9.2

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 desc

Re: [HACKERS] JSON for PG 9.2

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 say

Re: [HACKERS] Lots of FSM-related fragility in transaction commit

Heikki Linnakangas 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 reached at 0/5D71BA8 >> LOG:

Re: [HACKERS] JSON for PG 9.2

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 m

Re: [HACKERS] Page Checksums

Greg Smith 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 I pay attention

[HACKERS] [PATCH] Fix ScalarArrayOpExpr estimation for GIN indexes

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 ANY () queries segfaults in 9.1 if there's a GIN index on the column.

Re: [HACKERS] Review: Non-inheritable check constraints

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 The PostgreSQL Company

Re: [HACKERS] Review: Non-inheritable check constraints

On Mon, Dec 19, 2011 at 12:07 PM, Nikhil Sontakke 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 from A. W

Re: [HACKERS] Postgres 9.1: Adding rows to table causing too much latency in other queries

Jesper Krogh 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 foreground >

Re: [HACKERS] Postgres 9.1: Adding rows to table causing too much latency in other queries

Marti Raudsepp writes: > On Mon, Dec 19, 2011 at 17:30, Sushant Sinha 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

Re: [HACKERS] Autonomous subtransactions

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/ROLL

Re: [HACKERS] Autonomous subtransactions

On Mon, Dec 19, 2011 at 05:52:40PM +0200, Marti Raudsepp wrote: > On Sun, Dec 18, 2011 at 10:28, Gianni Ciolli > wrote: > >  http://wiki.postgresql.org/wiki/Autonomous_subtransactions > > > > It is meant to be an ongoing project, requesting comments and > > contributions, rather than a conclusive

Re: [HACKERS] Page Checksums

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 ou

Re: [HACKERS] Autonomous subtransactions

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

Re: [HACKERS] Page Checksums

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 t

Re: [HACKERS] RangeVarGetRelid()

On Mon, Dec 19, 2011 at 01:43:18PM -0500, Robert Haas wrote: > On Mon, Dec 19, 2011 at 11:55 AM, Noah Misch 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

Re: [HACKERS] ALTER TABLE lock strength reduction patch is unsafe

On Sat, Dec 17, 2011 at 6:11 AM, Simon Riggs 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 commits. SnapshotNow

Re: [HACKERS] Autonomous subtransactions

On Mon, Dec 19, 2011 at 21:43, Alvaro Herrera 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 disappear and can't

Re: [HACKERS] Page Checksums

Robert Haas wrote: > On Mon, Dec 19, 2011 at 2:16 PM, Kevin Grittner > 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 en

Re: [HACKERS] Autonomous subtransactions

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 disa

Re: [HACKERS] Escaping ":" in .pgpass - code or docs bug?

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 Reedstrom wrote: > >> This should either be fixed by changing the documentation to say to not > >> escape > >> colons or backslashes in the

Re: [HACKERS] Escaping ":" in .pgpass - code or docs bug?

On 19/12/11 16:48, Robert Haas wrote: On Sat, Dec 17, 2011 at 3:27 AM, Ross Reedstrom 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 unescape the passw

Re: [HACKERS] Autonomous subtransactions

On Mon, Dec 19, 2011 at 20:34, Simon Riggs 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 that's just my paran

Re: [HACKERS] Page Checksums

On Mon, Dec 19, 2011 at 2:16 PM, Kevin Grittner 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 time has elapsed for ev

Re: [HACKERS] Page Checksums

On Mon, Dec 19, 2011 at 12:07 PM, David Fetter 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 wrote: >> > * Aidan Van Dyk (ai...@highrise.ca) wrote: >> >> But the scary part is you don't know how long *ago* the crash was. >>

Re: [HACKERS] why do we need two snapshots per query?

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 whe

Re: [HACKERS] Page Checksums

Greg Smith 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 > performance testing to r

Re: [HACKERS] pgsql_fdw, FDW for PostgreSQL server

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 >

[HACKERS] reprise: pretty print viewdefs

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:

Re: [HACKERS] Page Checksums

On 12/19/2011 07:50 AM, Robert Haas wrote: On Mon, Dec 19, 2011 at 6:10 AM, 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 up

Re: [HACKERS] RangeVarGetRelid()

On Mon, Dec 19, 2011 at 11:55 AM, Noah Misch 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?  Relation > owners

Re: [HACKERS] Command Triggers

On Mon, Dec 19, 2011 at 12:52 PM, Tom Lane 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 to do it is

Re: [HACKERS] Autonomous subtransactions

On Mon, Dec 19, 2011 at 3:52 PM, Marti Raudsepp wrote: > On Sun, Dec 18, 2011 at 10:28, Gianni Ciolli > 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. >

Re: [HACKERS] Autonomous subtransactions

On Sun, Dec 18, 2011 at 4:22 PM, Jim Nasby 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 >> >>  http://wiki.postgresql.org/wiki/

[HACKERS] Re: WIP patch: Improve relation size functions such as pg_relation_size() to avoid producing an error when called against a no longer visible relation

On Sat, Dec 17, 2011 at 3:52 PM, Phil Sorber 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." > > http://archives.postgresql.org/pgsql-general/201

Re: [HACKERS] Command Triggers

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

Re: [HACKERS] Review: Non-inheritable check constraints

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 > 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 > >> wrote: > >> > >> > Ye

Re: [HACKERS] archive_keepalive_command

On Mon, Dec 19, 2011 at 1:17 PM, Robert Haas wrote: > On Fri, Dec 16, 2011 at 10:01 AM, Simon Riggs 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

Re: [HACKERS] Postgres 9.1: Adding rows to table causing too much latency in other queries

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 lis

Re: [HACKERS] Command Triggers

Andres Freund 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 time for 9.2.

Re: [HACKERS] Postgres 9.1: Adding rows to table causing too much latency in other queries

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. Typical

Re: [HACKERS] Postgres 9.1: Adding rows to table causing too much latency in other queries

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.

Re: [HACKERS] Page Checksums

* 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

Re: [HACKERS] Page Checksums

* 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 wrote: > > > Fair enough, but, could we distinguish these two cases?  In other words, > > > would it be possible to detect if a page was torn d

Re: [HACKERS] Page Checksums

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 C

Re: [HACKERS] Postgres 9.1: Adding rows to table causing too much latency in other queries

On Mon, Dec 19, 2011 at 17:30, Sushant Sinha 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 ANALYZE for your querie

Re: [HACKERS] Review: Non-inheritable check constraints

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

Re: [HACKERS] Page Checksums

On Mon, Dec 19, 2011 at 09:34:51AM -0500, Robert Haas wrote: > On Mon, Dec 19, 2011 at 9:14 AM, Stephen Frost 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 e

Re: [HACKERS] pgstat wait timeout

On 12/19/2011 11:45 AM, Robert Haas wrote: On Mon, Dec 19, 2011 at 10:02 AM, pratikchirania 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,

Re: [HACKERS] array behavior

On Fri, Dec 16, 2011 at 00:15, amit sehas 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 associated with

Re: [HACKERS] RangeVarGetRelid()

On Mon, Dec 19, 2011 at 10:11:23AM -0500, Robert Haas wrote: > On Fri, Dec 16, 2011 at 10:32 AM, Noah Misch 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

Re: [HACKERS] Escaping ":" in .pgpass - code or docs bug?

On Sat, Dec 17, 2011 at 3:27 AM, Ross Reedstrom 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" >> >>     $

Re: [HACKERS] pgstat wait timeout

On Mon, Dec 19, 2011 at 10:02 AM, pratikchirania 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 release-9-0.sgml, I don

Re: [HACKERS] Command Triggers

On Mon, Dec 19, 2011 at 11:20 AM, Andres Freund 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 PL/python and PL/

Re: [HACKERS] Command Triggers

2011/12/19 Robert Haas : > On Mon, Dec 19, 2011 at 9:31 AM, Greg Smith 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 ca

Re: [HACKERS] Command Triggers

Hi, On Monday, December 19, 2011 05:12:13 PM Robert Haas wrote: > On Mon, Dec 19, 2011 at 9:31 AM, Greg Smith 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,

Re: [HACKERS] Command Triggers

On Mon, Dec 19, 2011 at 9:31 AM, Greg Smith 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 an extension. > >

Re: [HACKERS] Autonomous subtransactions

On Sun, Dec 18, 2011 at 10:28, Gianni Ciolli 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 proposal seems a bit inf

Re: [HACKERS] review: CHECK FUNCTION statement

2011/12/19 Greg Smith : > 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 th

Re: [HACKERS] Postgres 9.1: Adding rows to table causing too much latency in other queries

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 r

[HACKERS] Postgres 9.1: Adding rows to table causing too much latency in other queries

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 perf

[HACKERS] pg_upgrade with plpython is broken

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. et

Re: [HACKERS] RangeVarGetRelid()

On Fri, Dec 16, 2011 at 10:32 AM, Noah Misch 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 > callers sharing

Re: [HACKERS] pgstat wait timeout

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

Re: [HACKERS] review: CHECK FUNCTION statement

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 better

Re: [HACKERS] Patch to allow users to kill their own queries

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 ha

Re: [HACKERS] Command Triggers

Excerpts from Dimitri Fontaine's message of dom dic 18 16:54:11 -0300 2011: > > Tom Lane 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 that's not

Re: [HACKERS] Page Checksums

On Mon, Dec 19, 2011 at 9:14 AM, Stephen Frost 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 doesn't do any

Re: [HACKERS] Page Checksums

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 le

Re: [HACKERS] Command Triggers

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 PL/perl

Re: [HACKERS] Page Checksums

* 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 times

Re: [HACKERS] Page Checksums

* 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

Re: [HACKERS] archive_keepalive_command

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

Re: [HACKERS] archive_keepalive_command

On Fri, Dec 16, 2011 at 10:01 AM, Simon Riggs 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 archive, or at least a

Re: [HACKERS] Review: Non-inheritable check constraints

On Fri, Dec 16, 2011 at 2:06 PM, Alvaro Herrera 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 ATExecDropConstraint() d

Re: [HACKERS] why do we need create tuplestore for each fetch?

On Thu, Dec 15, 2011 at 8:30 AM, 高增琦 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 table t (a in

Re: [HACKERS] Page Checksums

On Mon, Dec 19, 2011 at 6:10 AM, Simon Riggs 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 their own distro, so i

Re: [HACKERS] Page Checksums

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

Re: [HACKERS] Page Checksums

On Mon, Dec 19, 2011 at 4:21 AM, Josh Berkus 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 can't be a

Re: [HACKERS] JSON for PG 9.2

Merlin Moncure 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 implementation?

[HACKERS] [PATCH] Enable min/max optimization for bool_and/bool_or/every

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

[HACKERS] ToDo: conditional ALTER TABLE

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 AL

[HACKERS] Re: [pgeu-general] REMINDER: FOSDEM 2012 - PostgreSQL Devroom: Call for Speakers

> > 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 (pgsql-hackers