Re: [HACKERS] skipping context for RAISE statements - maybe obsolete?

2012/12/11 Tom Lane : > Pavel Stehule writes: >> Some flag of RAISE statement can be solution, but I don't like it. >> Probably you would to change behave for all RAISE statements in >> function - not individually for one or second. And when you debug some >> application, you probably invite any s

[HACKERS] Fix fmgroids.h not regenerated after "clean" (not "clean dist") on Windows

Hi all There's an issue with MSVC builds on Windows where clean.bat deletes src\include\utils\fmgroids.h (as it should) but build.pl doesn't re-create it reliably. It's created fine on the first build because Gen_fmgrtab.pl is called if src\backend\utils\fmgrtab.c is missing, which it is on first

Re: [HACKERS] Shuffling xlog header files

Heikki Linnakangas wrote: > Andres Freund's xlogreader patch contains a change to move the > declarations of SQL-callable functions in xlogfuncs.c to a new > header file, xlog_fn.h. The purpose is to allow xlog_internal.h to > be included in a frontend program, as the PG_FUNCTION_ARGS and Datum > u

Re: [HACKERS] Multiple --table options for other commands

On Tue, Dec 11, 2012 at 11:46 AM, Karl O. Pinc wrote: > Hi Josh, > > I've signed up to review this patch. Thanks! > I configured with assertions, built, and tested using > the attached script. It seems to do what it's supposed > to and the code looks ok to me. > > The docs build. The text is r

Re: [HACKERS] Logical decoding & exported base snapshot

On 12-12-11 06:52 PM, Andres Freund wrote: Hi, Problem 1: One problem I see is that while exporting a snapshot solves the visibility issues of the table's contents it does not protect against schema changes. I am not sure whether thats a problem. If somebody runs a CLUSTER or something like

Re: [HACKERS] Logical decoding & exported base snapshot

Joachim Wieland writes: > On Tue, Dec 11, 2012 at 6:52 PM, Andres Freund wrote: >> One problem I see is that while exporting a snapshot solves the >> visibility issues of the table's contents it does not protect against >> schema changes. I am not sure whether thats a problem. >> >> If somebody

Re: [HACKERS] Strange errors from 9.2.1 and 9.2.2 (I hope I'm missing something obvious)

On Tue, 11 Dec 2012 18:58:58 -0700 Josh Kupershmidt wrote: > On Tue, Dec 11, 2012 at 6:01 PM, David Gould wrote: > > > > I'm sure I've had a stroke or something in the middle of the night and just > > didn't notice, but I'm able to reproduce the following on three different > > hosts on both 9.2

Re: [HACKERS] Logical decoding & exported base snapshot

On Tue, Dec 11, 2012 at 6:52 PM, Andres Freund wrote: > One problem I see is that while exporting a snapshot solves the > visibility issues of the table's contents it does not protect against > schema changes. I am not sure whether thats a problem. > > If somebody runs a CLUSTER or something like

Re: [HACKERS] Strange errors from 9.2.1 and 9.2.2 (I hope I'm missing something obvious)

On Tue, Dec 11, 2012 at 6:01 PM, David Gould wrote: > > I'm sure I've had a stroke or something in the middle of the night and just > didn't notice, but I'm able to reproduce the following on three different > hosts on both 9.2.1 and 9.2.2. As far as I know the only difference between > these quer

Re: [HACKERS] Timing events WIP v1

On 11/20/12 8:02 PM, Craig Ringer wrote: On 11/20/2012 04:48 PM, Pavel Stehule wrote: I don't like to see current hstore in core - It doesn't support nesting, it doesn't support different datatypes, it is not well supported by plpgsql ... or by many client libraries, though converting hstor

Re: [HACKERS] Strange errors from 9.2.1 and 9.2.2 (I hope I'm missing something obvious)

David Gould writes: > I'm sure I've had a stroke or something in the middle of the night and just > didn't notice, but I'm able to reproduce the following on three different > hosts on both 9.2.1 and 9.2.2. As far as I know the only difference between > these queries is whitespace since I just up-

[HACKERS] Strange errors from 9.2.1 and 9.2.2 (I hope I'm missing something obvious)

I'm sure I've had a stroke or something in the middle of the night and just didn't notice, but I'm able to reproduce the following on three different hosts on both 9.2.1 and 9.2.2. As far as I know the only difference between these queries is whitespace since I just up-arrowed them in psql and del

Re: [HACKERS] Use of systable_beginscan_ordered in event trigger patch

Dimitri Fontaine writes: > I don't remember that we fixed that case, I did attach a patch in the > previous email, what do you think? Yeah, I had forgotten about that loose end, but we definitely need something of the sort. Committed with additional documentation. (I put something in the CREATE

Re: [HACKERS] Re: [PATCH 02/14] Add support for a generic wal reading facility dubbed XLogReader

On 2012-12-11 22:52:09 +, Peter Geoghegan wrote: > On 11 December 2012 22:24, Tom Lane wrote: > > TBH, I don't believe that ordinary users will need this tool at all, > > ever, and thus I don't want it in src/bin/. From a packaging standpoint > > it will be a lot easier if it's in contrib ...

Re: [HACKERS] [WIP PATCH] for Performance Improvement in Buffer Management

On 11/23/12 5:57 AM, Amit kapila wrote: Let us try to see by example: Total RAM - 22G Database size - 16G ... Case -2 (Shared Buffers - 10G) a. Load all the files in OS buffers. In best case OS buffers can contain10-12G data as OS has 12G of memory available. b. Try to load all in Shared buffers

[HACKERS] Logical decoding & exported base snapshot

Hi, When initiating a new logical replication "slot" I want to provide a 'SET TRANSACTION SNAPSHOT'able snapshot which can be used to setup a new replica. I have some questions arround this where I could use some input on. First, some basics around how this currently works: Test the other side:

Re: [HACKERS] Re: [PATCH 02/14] Add support for a generic wal reading facility dubbed XLogReader

Peter Geoghegan writes: > Perhaps people who live in countries with less bandwidth care about > these things more. The day they will need it is not the day the bandwidth will magically increase, is all I'm saying. Better have that around just in case you get WAL corruption because of a crappy RAI

Re: [HACKERS] Re: [PATCH 02/14] Add support for a generic wal reading facility dubbed XLogReader

On 11 December 2012 22:24, Tom Lane wrote: > TBH, I don't believe that ordinary users will need this tool at all, > ever, and thus I don't want it in src/bin/. From a packaging standpoint > it will be a lot easier if it's in contrib ... otherwise I'll probably > have to invent some new sub-RPM al

Re: [HACKERS] Re: [PATCH 02/14] Add support for a generic wal reading facility dubbed XLogReader

Tom Lane writes: > User trust, maybe, but the "maintenance" argument seems bogus. > We ship contrib on the same release schedule as core. I meant maintenance as in updating the code when it needs to be, I'm not sure contrib systematically receives the same careness as core. I have no data to back

Re: [HACKERS] pg_dump cosmetic problem while dumping/restoring rules

Andres Freund writes: >> pg_restore: [archiver (db)] Error from TOC entry 3874; 2618 396850 RULE >> geometry_columns_delete postgres >> pg_restore: [archiver (db)] could not execute query: ERROR: rule >> "geometry_columns_delete" for relation "geometry_columns" already exists >> Command was:

Re: [HACKERS] Re: [PATCH 02/14] Add support for a generic wal reading facility dubbed XLogReader

Dimitri Fontaine writes: > Robert Haas writes: >> I think I'm with Heikki on this one. Dumping xlog data is useful, but >> it's really for developers and troubleshooters, not something we >> expect people to do on a regular basis, so contrib seems appropriate. > There are two downsides for cont

Re: [HACKERS] Re: [PATCH 02/14] Add support for a generic wal reading facility dubbed XLogReader

Robert Haas writes: > I think I'm with Heikki on this one. Dumping xlog data is useful, but > it's really for developers and troubleshooters, not something we > expect people to do on a regular basis, so contrib seems appropriate. There are two downsides for contrib rather than src/bin. First, m

Re: [HACKERS] Use of systable_beginscan_ordered in event trigger patch

Hi, I don't remember that we fixed that case, I did attach a patch in the previous email, what do you think? Dimitri Fontaine writes: > Tom Lane writes: >> Or maybe we should disable event triggers altogether in standalone mode? > > Would something as simple as the attached work for doing that?

Re: [HACKERS] skipping context for RAISE statements - maybe obsolete?

Pavel Stehule writes: > Some flag of RAISE statement can be solution, but I don't like it. > Probably you would to change behave for all RAISE statements in > function - not individually for one or second. And when you debug some > application, you probably invite any solution that ensure change >

Re: [HACKERS] [v9.3] OAT_POST_ALTER object access hooks

2012/12/11 Robert Haas : > On Mon, Dec 3, 2012 at 9:59 AM, Kohei KaiGai wrote: >> As we discussed before, it is hard to determine which attributes shall >> be informed to extension via object_access_hook, so the proposed >> post-alter hook (that allows to compare older and newer versions) >> works

Re: [HACKERS] autovacuum truncate exclusive lock round two

Jan Wieck wrote: > Cleaned up all of those. Applied with trivial editing, mostly from a pgindent run against modified files. -Kevin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Support for REINDEX CONCURRENTLY

On 2012-12-11 15:23:52 -0500, Robert Haas wrote: > On Mon, Dec 10, 2012 at 5:18 PM, Peter Eisentraut wrote: > > On 12/8/12 9:40 AM, Tom Lane wrote: > >> I'm tempted to propose that REINDEX CONCURRENTLY simply not try to > >> preserve the index name exactly. Something like adding or removing > >>

Re: [HACKERS] pg_upgrade problem with invalid indexes

On Tue, Dec 11, 2012 at 09:19:34PM +0100, Andres Freund wrote: > > > > Only 9.2 :(. Before that there was no DROP INDEX CONCURRENTLY and in 9.3 > > > > there's an actual indislive field and indisready is always set to false > > > > there if indislive is false. > > > > > > > > But I see no problem u

Re: [HACKERS] Support for REINDEX CONCURRENTLY

On Mon, Dec 10, 2012 at 5:18 PM, Peter Eisentraut wrote: > On 12/8/12 9:40 AM, Tom Lane wrote: >> I'm tempted to propose that REINDEX CONCURRENTLY simply not try to >> preserve the index name exactly. Something like adding or removing >> trailing underscores would probably serve to generate a non

Re: [HACKERS] pg_upgrade problem with invalid indexes

On 2012-12-11 15:12:37 -0500, Bruce Momjian wrote: > On Fri, Dec 7, 2012 at 04:49:19PM -0500, Bruce Momjian wrote: > > On Fri, Dec 7, 2012 at 10:38:39PM +0100, Andres Freund wrote: > > > On 2012-12-07 16:30:36 -0500, Bruce Momjian wrote: > > > > On Fri, Dec 7, 2012 at 04:21:48PM -0500, Tom Lane

Re: [HACKERS] pg_upgrade problem with invalid indexes

On Fri, Dec 7, 2012 at 04:49:19PM -0500, Bruce Momjian wrote: > On Fri, Dec 7, 2012 at 10:38:39PM +0100, Andres Freund wrote: > > On 2012-12-07 16:30:36 -0500, Bruce Momjian wrote: > > > On Fri, Dec 7, 2012 at 04:21:48PM -0500, Tom Lane wrote: > > > > Andres Freund writes: > > > > > On 2012-12-

Re: [HACKERS] Re: [PATCH 02/14] Add support for a generic wal reading facility dubbed XLogReader

On Tue, Dec 11, 2012 at 9:44 AM, Andres Freund wrote: >> * How about we move pg_xlogdump to contrib? It doesn't feel like the kind of >> essential tool that deserves to be in src/bin. > > contrib would be fine, but I think src/bin is better. There have been > quite some bugs by now where it would

Re: [HACKERS] Multiple --table options for other commands

On Tue, Dec 11, 2012 at 1:46 PM, Karl O. Pinc wrote: > Yes, the current pg_restore silently > ignores multiple --table arguments, and seems to use the last > one. You are introducing a backwards incompatible > change here. I don't know what to do about it, other > than perhaps to have the patch

Re: [HACKERS] PageIsAllVisible()'s trustworthiness in Hot Standby

On Tue, Dec 4, 2012 at 12:10 PM, Pavan Deolasee wrote: > Hmm. Yeah, I do not have guts to prove that either. I'll probably write up a > comment for your consideration to explain why we don't trust PD_ALL_VISIBLE > in Hot standby for seq scans, but still trust VM for index-only scans. Sure. > Ano

Re: [HACKERS] skipping context for RAISE statements - maybe obsolete?

2012/12/11 Tom Lane : > Pavel Stehule writes: >> /* if we are doing RAISE, don't report its location */ >> if (estate->err_text == raise_skip_msg) >> return; > >> It is some what we want? > > My recollection is that that special case was added because people > compl

[HACKERS] Re: [PATCH 02/14] Add support for a generic wal reading facility dubbed XLogReader

On 2012-12-11 15:55:35 +0200, Heikki Linnakangas wrote: > I've been molding this patch for a while now, here's what I have this far > (also available in my git repository). > > The biggest change is in the error reporting. A stand-alone program that > wants to use xlogreader.c no longer has to prov

Re: [HACKERS] Multiple --table options for other commands

Hi Josh, I've signed up to review this patch. I configured with assertions, built, and tested using the attached script. It seems to do what it's supposed to and the code looks ok to me. The docs build. The text is reasonable. I also diffed the output of the attached script with the output of

Re: [HACKERS] skipping context for RAISE statements - maybe obsolete?

Pavel Stehule writes: > /* if we are doing RAISE, don't report its location */ > if (estate->err_text == raise_skip_msg) > return; > It is some what we want? My recollection is that that special case was added because people complained about the "noise" from locat

Re: [HACKERS] autovacuum truncate exclusive lock round two

On 12/9/2012 2:37 PM, Kevin Grittner wrote: Jan Wieck wrote: Based on the discussion and what I feel is a consensus I have created an updated patch that has no GUC at all. The hard coded parameters in include/postmaster/autovacuum.h are AUTOVACUUM_TRUNCATE_LOCK_CHECK_INTERVAL 20 /* ms */ AUT

Re: [HACKERS] [BUG?] lag of minRecoveryPont in archive recovery

On 11.12.2012 17:04, Fujii Masao wrote: The patch looks good. I confirmed that the PANIC error didn't happen, with the patch. Ok, committed, and also moved the CheckRecoveryConsistency call. Please take a look to double-check that I didn't miss anything. - Heikki -- Sent via pgsql-hackers

Re: [HACKERS] [BUG?] lag of minRecoveryPont in archive recovery

On 11.12.2012 17:04, Fujii Masao wrote: On Tue, Dec 11, 2012 at 6:14 PM, Heikki Linnakangas wrote: On 11.12.2012 08:07, Kyotaro HORIGUCHI wrote: The cause is that CheckRecoveryConsistency() is called before rm_redo(), as Horiguchi-san suggested upthead. Imagine the case where minRecoveryPoin

Re: [HACKERS] Re: [PATCH 02/14] Add support for a generic wal reading facility dubbed XLogReader

On 2012-12-11 16:43:12 +0100, Andres Freund wrote: > On 2012-12-11 15:44:39 +0100, Andres Freund wrote: > > On 2012-12-11 15:55:35 +0200, Heikki Linnakangas wrote: > > > * It's pretty ugly that to use the rm_desc functions, you have to provide > > > dummy implementations of a bunch of backend funct

Re: [HACKERS] Re: [PATCH 02/14] Add support for a generic wal reading facility dubbed XLogReader

On 2012-12-11 15:44:39 +0100, Andres Freund wrote: > On 2012-12-11 15:55:35 +0200, Heikki Linnakangas wrote: > > * It's pretty ugly that to use the rm_desc functions, you have to provide > > dummy implementations of a bunch of backend functions, including pfree() and > > timestamptz_to_str(). Shoul

Re: [HACKERS] Proposal for Allow postgresql.conf values to be changed via SQL

Amit Kapila writes: > On Tuesday, December 11, 2012 5:25 AM Jaime Casanova wrote: >> can we at least send the source file in the error message when a >> parameter has a wrong value? >> >> suppose you do: SET PERSISTENT shared_preload_libraries TO >> 'some_nonexisting_lib'; >> when you restart pos

Re: [HACKERS] Commits 8de72b and 5457a1 (COPY FREEZE)

On Mon, Dec 10, 2012 at 08:04:55PM -0500, Robert Haas wrote: > You know, I hadn't been taking that option terribly seriously, but > maybe we ought to reconsider it. It would certainly be simpler, and > as you point out, it's not really any worse from an MVCC point of view > than anything else we d

Re: [HACKERS] allowing multiple PQclear() calls

On 11 December 2012 12:18, Boszormenyi Zoltan wrote: >>> Such mechanism already exist - you just need to set >>> your PGresult pointer to NULL after each PQclear(). >> >> So why doesn't PQclear() do that? > > > Because then PQclear() would need a ** not a *. Do you want its > interface changed fo

Re: [HACKERS] Review: create extension default_full_version

Now it works in most of the cases, here is one more point about the patch. * In case we have hstore--1.3.sql file and want to install that file, but failed because of default_full_version. No default_full_version specified --- postgres=# CREATE EXTENSIO

Re: [HACKERS] [WIP] pg_ping utility

On Sat, Dec 8, 2012 at 08:59:00AM -0500, Phil Sorber wrote: > On Sat, Dec 8, 2012 at 7:50 AM, Michael Paquier > wrote: > > On Fri, Dec 7, 2012 at 12:56 PM, Phil Sorber wrote: > >> > >> Something I was just thinking about while testing this again. I > >> mentioned the issue before about someone m

Re: [HACKERS] [BUG?] lag of minRecoveryPont in archive recovery

On Tue, Dec 11, 2012 at 6:14 PM, Heikki Linnakangas wrote: > On 11.12.2012 08:07, Kyotaro HORIGUCHI wrote: >>> >>> The cause is that CheckRecoveryConsistency() is called before rm_redo(), >>> as Horiguchi-san suggested upthead. Imagine the case where >>> minRecoveryPoint is set to the location of

Re: [HACKERS] pg_dump cosmetic problem while dumping/restoring rules

On 2012-12-11 16:34:35 +0200, Gražvydas Valeika wrote: > with 9.2.2 I can see harmless cosmetic defect while dumping/restoring > database with postgis extension. > > Steps to reproduce: > > - create new database; > - CREATE EXTENSION IF NOT EXISTS postgis WITH SCHEMA public; > - backup it; > - crea

[HACKERS] Re: [PATCH 02/14] Add support for a generic wal reading facility dubbed XLogReader

On 2012-12-11 15:55:35 +0200, Heikki Linnakangas wrote: > I've been molding this patch for a while now, here's what I have this far > (also available in my git repository). On a very quick this looks good. I will try to rebase the decoding stuff and read a bit around in the course of that... > Th

[HACKERS] pg_dump cosmetic problem while dumping/restoring rules

Hi, with 9.2.2 I can see harmless cosmetic defect while dumping/restoring database with postgis extension. Steps to reproduce: - create new database; - CREATE EXTENSION IF NOT EXISTS postgis WITH SCHEMA public; - backup it; - create new database and restore it from this new backup. It produces

[HACKERS] Re: [PATCH 02/14] Add support for a generic wal reading facility dubbed XLogReader

I've been molding this patch for a while now, here's what I have this far (also available in my git repository). The biggest change is in the error reporting. A stand-alone program that wants to use xlogreader.c no longer has to provide a full-blown replacement for ereport(). The only thing th

Re: [HACKERS] allowing multiple PQclear() calls

On Tue, Dec 11, 2012 at 12:43 PM, Josh Kupershmidt wrote: > Ah, well. I guess using a macro like: > > #define SafeClear(res) do {PQclear(res); res = NULL;} while (0); > > will suffice for me. Psycopg uses: #define IFCLEARPGRES(pgres) if (pgres) {PQclear(pgres); pgres = NULL;} -- Daniele --

Re: [HACKERS] enhanced error fields

Hello 2012/12/10 Peter Geoghegan : > On 10 December 2012 20:52, David Johnston wrote: >> Just skimming this topic but if these enhanced error fields are going to be >> used by software, and we have 99% adherence to a standard, then my first >> reaction is why not just supply "" (or "" as >> appro

Re: [HACKERS] enhanced error fields

Hello 2012/12/10 Peter Geoghegan : > So, I took a look at this, and made some more changes. > > I have a hard time seeing the utility of some fields that were in this > patch, and so they have been removed from this revision. > > Consider, for example: > > + constraint_table text, > + constrai

Re: [HACKERS] allowing multiple PQclear() calls

On Tue, Dec 11, 2012 at 5:18 AM, Boszormenyi Zoltan wrote: > 2012-12-11 12:45 keltezéssel, Simon Riggs írta: > >> On 11 December 2012 10:39, Marko Kreen wrote: >>> >>> On Tue, Dec 11, 2012 at 6:59 AM, Josh Kupershmidt >>> wrote: Would it be crazy to add an "already_freed" flag to the p

Re: [HACKERS] allowing multiple PQclear() calls

2012-12-11 12:45 keltezéssel, Simon Riggs írta: On 11 December 2012 10:39, Marko Kreen wrote: On Tue, Dec 11, 2012 at 6:59 AM, Josh Kupershmidt wrote: Would it be crazy to add an "already_freed" flag to the pg_result struct which PQclear() would set, or some equivalent safety mechanism, to av

Re: [HACKERS] allowing multiple PQclear() calls

On 11 December 2012 10:39, Marko Kreen wrote: > On Tue, Dec 11, 2012 at 6:59 AM, Josh Kupershmidt wrote: >> Would it be crazy to add an "already_freed" flag to the pg_result >> struct which PQclear() would set, or some equivalent safety mechanism, >> to avoid this hassle for users? > > Such mecha

[HACKERS] skipping context for RAISE statements - maybe obsolete?

Hello Sometimes I had a problems with identification custom exceptions in plpgsql, because we skip collecting context /* * error context callback to let us supply a call-stack traceback */ static void plpgsql_exec_error_callback(void *arg) { PLpgSQL_execstate *estate = (PLpgSQL_execstat

Re: [HACKERS] Proposal for Allow postgresql.conf values to be changed via SQL

On Tuesday, December 11, 2012 5:25 AM Jaime Casanova wrote: > On Fri, Nov 23, 2012 at 4:56 AM, Amit Kapila > wrote: > > On Thursday, November 22, 2012 10:09 PM Fujii Masao wrote: > > > >> Is it helpful to output the notice message like 'Run pg_reload_conf() > or > >> restart the server if you want

Re: [HACKERS] allowing multiple PQclear() calls

On Tue, Dec 11, 2012 at 6:59 AM, Josh Kupershmidt wrote: > Would it be crazy to add an "already_freed" flag to the pg_result > struct which PQclear() would set, or some equivalent safety mechanism, > to avoid this hassle for users? Such mechanism already exist - you just need to set your PGresult

Re: [HACKERS] too much pgbench init output

On Sun, Dec 9, 2012 at 8:11 AM, Tomas Vondra wrote: > On 20.11.2012 08:22, Jeevan Chalke wrote: > > Hi, > > > > > > On Tue, Nov 20, 2012 at 12:08 AM, Tomas Vondra > > wrote: > > > > On 19.11.2012 11:59, Jeevan Chalke wrote: > > > Hi, > > > > > > I gone throu

Re: [HACKERS] [BUG?] lag of minRecoveryPont in archive recovery

On 11.12.2012 08:07, Kyotaro HORIGUCHI wrote: The cause is that CheckRecoveryConsistency() is called before rm_redo(), as Horiguchi-san suggested upthead. Imagine the case where minRecoveryPoint is set to the location of the XLOG_SMGR_TRUNCATE record. When restarting the server with that minRecov