Re: [HACKERS] standalone backend PANICs during recovery

--On 20. August 2016 12:41:48 -0400 Tom Lane wrote: > So at this point I'm pretty baffled as to what the actual use-case is > here. I am tempted to say that a standalone backend should refuse to > start at all if a recovery.conf file is present. If we do want to > allow the case, we need some

Re: [HACKERS] standalone backend PANICs during recovery

--On 3. September 2016 um 02:05:00 -0400 Tom Lane wrote: >> Well, the "use case" was a crashed hot standby at a customer site (it >> kept PANICing after restarting), where i decided to have a look through >> the recovery process with gdb. The exact PANIC was > >> 2016-03-29 15:12:40 CEST [1609

[HACKERS] recovery_min_apply-delay and remote_apply

Current PostgreSQL Documentation on recovery.conf has this about recovery_min_apply_delay[1]: ---<--- This parameter is intended for use with streaming replication deployments; however, if the parameter is specified it will be honored in all cases. Synchronous replication is not affected by this

[HACKERS] recovery_min_apply_delay vs. synchronous_commit

9.6 should have a corrected one, too. [1] <https://www.postgresql.org/docs/devel/static/standby-settings.html> -- Mit freundlichen Grüßen Bernd Helmle recovery-config-doc.patch Description: Binary data -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To mak

Re: [HACKERS] parallel worker (PID ) exited with exit code 1

Am Freitag, den 06.10.2017, 17:49 +0530 schrieb tushar: > I got some few queries after running sqlsmith against PG HEAD , where > i > am getting LOG message like - "parallel worker (PID) exited with > exit > code 1" > > set force_parallel_mode =1; > select >pg_catalog.pg_wal_replay

[HACKERS] Minor comment issue in receivelog.c

Please find a minor comment fix for receivelog.c, HandleCopyStream(). The comments talks about a START_STREAMING command, but i think START_REPLICATION is what's meant here. Bernd diff --git a/src/bin/pg_basebackup/receivelog.c b/src/bin/pg_basebackup/receivelog.c index 888458f4a9..befbb

Re: [HACKERS] LWLock optimization for multicore Power machines

Am Dienstag, den 14.02.2017, 15:53 +0300 schrieb Alexander Korotkov: > +1 > And you could try to use pg_wait_sampling > to sampling of wait > events. I've tried this with your example from your blog post[1] and got this: (pgbench scale 1000) pgbe

Re: [HACKERS] [patch] reorder tablespaces in basebackup tar stream for backup_label

Am Dienstag, den 21.02.2017, 11:17 +0100 schrieb Michael Banck: > However, third party tools using the BASE_BACKUP command might want > to > extract the backup_label, e.g. in order to figure out the START WAL > LOCATION. If they make a big tarball for the whole cluster > potentially > including all

[HACKERS] Make subquery alias optional in FROM clause

>From time to time, especially during migration projects from Oracle to PostgreSQL, i'm faced with people questioning why the alias in the FROM clause for subqueries in PostgreSQL is mandatory. The default answer here is, the SQL standard requires it. This also is exactly the comment in our parser

Re: [HACKERS] Make subquery alias optional in FROM clause

On Wed, 2017-02-22 at 10:08 -0500, Tom Lane wrote: > > Indeed.  When I wrote the comment you're referring to, quite a few > years > ago now, I thought that popular demand might force us to allow > omitted > aliases.  But the demand never materialized.  At this point it seems > clear to me that the

Re: [HACKERS] Make subquery alias optional in FROM clause

On Wed, 2017-02-22 at 08:13 -0700, David G. Johnston wrote: > I'll contribute to the popular demand aspect but given that the error > is > good and the fix is very simple its not exactly a strong desire. In one project i've recently seen, for some reasons, they need to maintain an application twic

Re: [HACKERS] Make subquery alias optional in FROM clause

Am Mittwoch, den 22.02.2017, 22:17 -0500 schrieb Tom Lane: > [ shrug... ]  Well, I won't resist this hard as long as it's done > competently, which to me means "the subquery name doesn't conflict > with > anything else".  Not "it doesn't conflict unless you're unlucky > enough > to have used the sa

Re: [HACKERS] [patch] reorder tablespaces in basebackup tar stream for backup_label

Am Freitag, den 03.03.2017, 15:44 +0900 schrieb Michael Paquier: > So, the main directory is located at the end on purpose. When using > --wal-method=fetch the WAL segments are part of the main tarball, so > if you send the main tarball first you would need to generate a > second > tarball with the

Re: [HACKERS] Clarification of FDW API Documentation

--On 13. Juni 2014 13:46:38 -0400 Tom Lane wrote: Imagine if `BeginForeignScan` set up a remote cursor and `IterateForeignScan` just fetched _one tuple at a time_ (unlike the current behavior where they are fetched in batches). The tuple would be passed to `ExecForeignDelete` (as is required)

Re: [HACKERS] SSL information view

--On 12. Juli 2014 15:08:01 +0200 Magnus Hagander wrote: Before doing that, however, I'd like to ask for opinions :) The hack currently exposes a separate view that you can join to pg_stat_activity (or pg_stat_replication) on the pid -- this is sort of the same way that pg_stat_replication

[HACKERS] 9.3.9 and pg_multixact corruption

A customer had a severe issue with a PostgreSQL 9.3.9/sparc64/Solaris 11 instance. The database crashed with the following log messages: 2015-09-08 00:49:16 CEST [2912] PANIC: could not access status of transaction 1068235595 2015-09-08 00:49:16 CEST [2912] DETAIL: Could not open file "pg_multi

Re: [HACKERS] 9.3.9 and pg_multixact corruption

...and here it is ;) --On 10. September 2015 19:45:46 -0300 Alvaro Herrera wrote: > Anyway, can you please request pg_controldata to be run on the failed > cluster and paste it here? pg_control version number:937 Catalog version number: 201306121 Database system identi

Re: [HACKERS] Re: [COMMITTERS] pgsql: Add a GUC to report whether data page checksums are enabled.

--On 18. Februar 2014 22:23:59 +0200 Heikki Linnakangas wrote: I considered it a new feature, so not back-patching was the default. If you want to back-patch it, I won't object. That was my original feeling, too, but +1 for backpatching. -- Thanks Bernd -- Sent via pgsql-hacke

Re: [HACKERS] Selecting large tables gets killed

--On 20. Februar 2014 14:49:28 +0530 Ashutosh Bapat wrote: If I set some positive value for this variable, psql runs smoothly with any size of data. But unset that variable, and it gets killed. But it's nowhere written explicitly that psql can run out of memory while collecting the result s

Re: [HACKERS] Selecting large tables gets killed

--On 20. Februar 2014 09:51:47 -0500 Tom Lane wrote: Yeah. The other reason that you can't just transparently change the behavior is error handling: people are used to seeing either all or none of the output of a query. In single-row mode that guarantee fails, since some rows might get outp

[HACKERS] GUC for data checksums

Attached is a small patch to add a new GUC to report wether data checksums for a particular cluster are enabled. The only way to get this info afaik is to look into pg_control and the version number used, but i'd welcome a way to access this remotely, too. If there aren't any objections i'll add

Re: [HACKERS] GUC for data checksums

--On 15. September 2013 00:25:34 +0200 Andres Freund wrote: Looks like a good idea to me. The implementation looks sane as well, except that I am not sure if we really need to introduce that faux variable. If the variable cannot be set and we have a SHOW hook, do we need it? It's along th

Re: [HACKERS] psql should show disabled internal triggers

--On 18. September 2013 13:52:29 +0200 Andres Freund wrote: If you do ALTER TABLE ... DISABLE TRIGGER ALL; and then individually re-enable the disabled triggers it's easy to miss internal triggers. A \d+ tablename will not show anything out of the ordinary for that situation since we don't

Re: [HACKERS] psql should show disabled internal triggers

--On 18. September 2013 15:19:27 +0200 Andres Freund wrote: Well, that will lead the user in the wrong direction, won't it? They haven't disabled the constraint but the trigger. Especially as we already have NOT VALID and might grow DISABLED for constraint themselves... Valid point. But

Re: [HACKERS] ENABLE/DISABLE CONSTRAINT NAME

--On 13. September 2013 20:17:19 -0400 Robert Haas wrote: You're missing the point. Peter wasn't worried that your patch throws an error; he's concerned about the fact that it doesn't. In PostgreSQL, you can only create the following view because test1 has a primary key over column a: =>

Re: [HACKERS] Wait free LW_SHARED acquisition

--On 27. September 2013 09:57:07 +0200 Andres Freund wrote: Ok, was free: padding + 16 partitions: tps = 147884.648416 padding + 32 partitions: tps = 141777.841125 padding + 64 partitions: tps = 141561.539790 padding + 16 partitions + new lwlocks tps = 601895.580903 (yeha, still reprodu

Re: [HACKERS] Wait free LW_SHARED acquisition

--On 30. September 2013 19:00:06 +0200 Andres Freund wrote: HEAD (default): tps = 181738.607247 (including connections establishing) tps = 182665.993063 (excluding connections establishing) HEAD (padding + 16 partitions + your lwlocks patch applied): tps = 269328.259833 (including connec

Re: [HACKERS] btreecheck extension

--On 16. Juni 2014 18:47:30 -0700 Peter Geoghegan wrote: > Attached prototype patch adds contrib extension, btreecheck. This > extension provides SQL-callable functions for checking these > conditions on nbtree indexes on live systems. What's the current state of this module? I see you are int

[HACKERS] Duplicated assignment of slot_name in walsender.c

walsender.c, CreateReplicationSlot() currently has this: slot_name = NameStr(MyReplicationSlot->data.name); if (cmd->kind == REPLICATION_KIND_LOGICAL) { [...] } else if (cmd->kind == REPLICATION_KIND_PHYSICAL && cmd->reserve_wal) { [

Re: [HACKERS] Avoid full page images in streaming replication?

--On 22. Oktober 2015 22:23:58 -0300 Alvaro Herrera wrote: >> You can? The xlog format between 9.4 and 9.5 changed, so I can't see how >> that'd work? > > Oh, crap. Must have been some other cross-version trial run I did, > then. I would hope it's at least not terribly difficult to back-patc

Re: [HACKERS] Avoid full page images in streaming replication?

--On 23. Oktober 2015 00:03:30 +0200 Andres Freund wrote: > > Note that FPIs are often pretty good for replay performance, avoiding > lots of synchronous random reads. That's a very import argument, i think. The difference can be significant, even if you have a decent storage, rendering a rep

Re: [HACKERS] Disabling START TRANSACTION for a SuperUser

--On 27. Oktober 2015 14:07:06 + Kevin Grittner wrote: > It would be a boon to big shops if they could > declare (preferably with the option to set it at a role level) that > specific default_transaction_* settings could not be overridden. A while ago i was faced with exactly the same pro

Re: [HACKERS] pg_stats_recovery view

--On 15. Januar 2012 02:50:00 -0500 Jaime Casanova wrote: Attached is a patch thats implements a pg_stat_recovery view that keeps counters about processed wal records. I just notice that it still lacks documentation but i will add it during the week. Hi Jaime, do you have an updated patc

Re: [HACKERS] pg_stats_recovery view

--On 2. Februar 2012 17:12:11 +0900 Fujii Masao wrote: If only core developer is interested in this view, ISTM that short description for each WAL record is not required because he or she can know the meaning of each WAL record by reading the source code. No? Adding short descriptions for eve

Re: [HACKERS] Patch pg_is_in_backup()

--On 2. Februar 2012 18:47:35 +0100 Gilles Darold wrote: For now the internal function BackupInProgress() only return a boolean. I like the idea that pg_is_in_backup() just works as pg_is_in_recovery() do. I mean it doesn't return the timestamp of the recovery starting time but only true or

Re: [HACKERS] Patch pg_is_in_backup()

--On 3. Februar 2012 13:21:11 +0900 Fujii Masao wrote: It seems to be more user-friendly to introduce a view like pg_stat_backup rather than the function returning an array. I like this idea. A use case i saw for monitoring backup_label's in the past, was mainly to discover a forgotten exc

Re: [HACKERS] background worker and normal exit

--On 26. Mai 2013 11:38:55 +0900 Michael Paquier wrote: This flag makes a worker not to restart only in case of a crash. To solve your problem, you could as well allow your process to restart and put it in indefinite sleep if server is not in recovery such it it will do nothing in your cas

Re: [HACKERS] Hard limit on WAL space used (because PANIC sucks)

--On 6. Juni 2013 16:25:29 -0700 Josh Berkus wrote: Archiving - In some ways, this is the simplest case. Really, we just need a way to know when the available WAL space has become 90% full, and abort archiving at that stage. Once we stop attempting to archive, we can clean up the u

[HACKERS] Passing fdw_private data from PlanForeignScan to PlanForeignModify

I'm currently implementing DML actions in the informix FDW module and trying to understand how UPDATE/DELETE actions interact with the various structures, especially how states between the associated ForeignScan and ForeignModify actions could be transmitted. As far as i understood, with e.g. a

Re: [HACKERS] Passing fdw_private data from PlanForeignScan to PlanForeignModify

--On 13. Juni 2013 11:06:31 -0400 Tom Lane wrote: My recommendation would be to see if you can't save the relevant info in the RelOptInfo node for the relation, probably during GetForeignPlan, and then get it from there in PlanForeignModify instead of digging in the plan tree. (You can use t

Re: [HACKERS] Passing fdw_private data from PlanForeignScan to PlanForeignModify

--On 13. Juni 2013 18:12:05 -0400 Tom Lane wrote: What i tried before was to access (in PlanForeignModify) the RelOptInfo structure through PlannerInfo->simple_rel_array, assuming the the resultRelation index points to the right array member. However, that didn't work, the fdw_private List i

[HACKERS] psql tab completion for updatable foreign tables

Recently i got annoyed that psql doesn't tab complete to updatable foreign tables. Attached is a patch to address this. I'm using the new pg_relation_is_updatable() function to accomplish this. The function could also be used for the trigger based stuff in the query, but i haven't touched thi

Re: [HACKERS] psql tab completion for updatable foreign tables

--On 8. Juli 2013 16:04:31 + Dean Rasheed wrote: * pg_relation_is_updatable is only available in 9.3, whereas psql may connect to older servers, so it needs to guard against that. Oh of course, i forgot about this. Thanks for pointing out. * If we're doing this, I think we should d

[HACKERS] Disabling trust/ident authentication configure option

We have a customer using a patch to harden their PostgreSQL installation (see attached) they would like to contribute. This patch adds the ability to disable "trust" and "ident" authentication at compile time via configure options, thus making it impossible to use these authentication methods for s

Re: [HACKERS] [COMMITTERS] pgsql: Move pg_upgrade from contrib/ to src/bin/

--On 15. April 2015 15:02:05 -0400 Andrew Dunstan wrote: > We've handled the buildfarm being red for a few days before. People are > usually good about applying fixes fairly quickly. Took me some time to get that due to my mail backlog, but i've done the hotfix for dotterel and forced a run fo

[HACKERS] cost_index() and path row estimate.

While looking into a customer performance problem, i saw this in costsize.c, cost_index() (9.3.6, but it looks the same in HEAD): /* Mark the path with the correct row estimate */ if (path->path.param_info) { path->path.rows = path->path.param_info->ppi_rows

Re: [HACKERS] Disabling trust/ident authentication configure option

--On 30. April 2015 08:00:23 -0400 Robert Haas wrote: > But... the user could use password authentication with the password > set to "x" and that would be insecure, too, yet not prevented by any > of this. I think it's pretty hard to prevent someone who has > filesystem-level access to the dat

Re: [HACKERS] cost_index() and path row estimate.

--On 1. Mai 2015 11:30:51 -0700 Tom Lane wrote: > No. The non-parameterized paths for a given relation must all have the > same rowcount estimates; otherwise the path comparison logic fails > fundamentally. Another way to look at it is that every correct path > will yield the same number of r

Re: [HACKERS] Disabling trust/ident authentication configure option

--On 6. Mai 2015 16:28:43 -0400 Andrew Dunstan wrote: >> Single user sessions would work, but the "peer" authentication is also >> still available and should be the preferred method to reset passwords >> when trust is disabled, so this should not be an issue. > > (Personally I think there's

Re: [HACKERS] Hardening pg_upgrade

--On 21. August 2014 22:08:58 +0200 Magnus Hagander wrote: I vote for discarding 8.3 support in pg_upgrade. There are already enough limitations on pg_upgrade from pre-8.4 to make it of questionable value; if it's going to create problems like this, it's time to cut the rope. +1. 8.3 has

Re: [HACKERS] Better support of exported snapshots with pg_dump

--On 1. September 2014 17:00:32 +0900 Michael Paquier wrote: Currently pg_dump does not allow a user to specify an exported snapshot name that he would like to use for a dump using SET TRANSACTION SNAPSHOT (now pg_export_snapshot is only used for parallel pg_dump within it). I imagine that

Re: [HACKERS] COPY TO returning empty result with parallel ALTER TABLE

--On 3. November 2014 18:15:04 +0100 Sven Wegener wrote: I've check git master and 9.x and all show the same behaviour. I came up with the patch below, which is against curent git master. The patch modifies the COPY TO code to create a new snapshot, after acquiring the necessary locks on th

Re: [GENERAL] Re: [BUGS] [HACKERS] COPY TO returning empty result with parallel ALTER TABLE

--On 4. November 2014 17:18:14 -0500 Tom Lane wrote: Yeah, and I think that it's entirely reasonable for rewriting ALTER TABLEs to update the xmin of the rewritten tuples; after all, the output data could be arbitrarily different from what the previous transactions put into the table. But th

Re: [HACKERS] Amazon Redshift

--On 5. November 2014 23:36:03 +0100 philip taylor wrote: Date Functions http://docs.aws.amazon.com/redshift/latest/dg/r_ADD_MONTHS.html http://docs.aws.amazon.com/redshift/latest/dg/r_DATEADD_function.html http://docs.aws.amazon.com/redshift/latest/dg/r_DATEDIFF_function.html http://docs.

Re: [HACKERS] Proposal: Store "timestamptz" of database creation on "pg_database"

--On 2. Januar 2013 23:04:43 -0500 Robert Haas wrote: TBH, I don't think anyone has any business changing the creation timestamp. Ever. For me, the fact that pg_dump wouldn't preserve this information would be a feature, not a bug. I mostly meant to point out that someone could bypass it

[HACKERS] Hanging backends and possible index corruption

We are currently analyzing an issue at one of our customers PostgreSQL database. The current version is 9.1.6 (update to 9.1.7 is scheduled for next monday, no downtime possible before). It runs on POWER7 (pSeries 740) on an RHEL6.3 64-bit LPAR. The packages are built from PGDG SVN sources, no

Re: [HACKERS] Hanging backends and possible index corruption

--On 25. Januar 2013 16:28:16 +0100 Andres Freund wrote: Did you reindex after upgrading to 9.1.6? Did you ever have any crashes or failovers before upgrading to 9.1.6? I have seen pretty similar symptoms caused by "Fix persistence marking of shared buffers during WAL replay" in 9.1.6. Hm

Re: [HACKERS] Hanging backends and possible index corruption

--On 25. Januar 2013 20:37:32 -0500 Tom Lane wrote: Don't know how careful pgbtreecheck is. The pg_filedump output isn't very helpful because you filtered away the flags, so we can't tell if any of these pages are deleted. (If they are, the duplicate-looking links might not be errors, sinc

Re: [HACKERS] walreceiver fallback_application_name

--On 16. Januar 2011 21:53:47 +0100 Dimitri Fontaine wrote: Is "walreceiver" something that "the average DBA" is going to realize what it is? Perhaps go for something like "replication slave"? I think walreceiver is very good here, and the user is already confronted to such phrasing. ht

Re: [HACKERS] bug in SignalSomeChildren

--On 22. Dezember 2010 15:51:09 +0900 Fujii Masao wrote: How about doing target != ALL test at the head for the most common case (target == ALL)? That's an idea, but the test you propose implements it incorrectly. Thanks! I revised the patch. I had a look at this for the current CF an

[HACKERS] PGXS contrib builds broken?

Looks like the recent refactoring of code into common/ stopped PGXS builds within the PostgreSQL source tree from working, i get /Users/bernd/pgsql-dev/install/HEAD/include/server/postgres_fe.h:27:32: fatal error: common/fe_memutils.h: No such file or directory when trying to build pg_upgrade,

[HACKERS] Materialized View patch broke pg_dump

It looks like the recent matview patch broke pg_dump in a way, which make it impossible to dump 9.1 and 9.2 databases. it fails with pg_dump: [Archivierer (DB)] query failed: ERROR: function pg_relation_is_scannable(oid) does not exist Looking into this issue, it seems the version check in

[HACKERS] pg_dump in current master segfaults when dumping 9.2/9.1 databases

My current master segfaults with pg_dump when dumping a 9.1 or 9.2 database: $ LC_ALL=en_US.utf8 pg_dump -s -p 5448 pg_dump: column number -1 is out of range 0..22 zsh: segmentation fault LC_ALL=en_US.utf8 pg_dump -s -p 5448 The reason seems to be that getTables() in pg_dump.c forget to select

Re: [HACKERS] pg_controldata gobbledygook

--On 25. April 2013 23:19:14 -0400 Tom Lane wrote: I think I've heard of scripts grepping the output of pg_controldata for this that or the other. Any rewording of the labels would break that. While I'm not opposed to improving the labels, I would vote against your second, abbreviated scheme

Re: [HACKERS] pg_stop_backup does not complete

--On 24. Februar 2010 16:01:02 -0500 Tom Lane wrote: One objection to this is that it's not very clear to the user when pg_stop_backup has finished with actual work and is just waiting for the archiver, ie when is it safe to hit control-C? Maybe we should emit a "backup done, waiting for arc

Re: [HACKERS] pg_ctl stop -m immediate on the primary server inflates sequences

--On 10. April 2010 09:26:41 +0200 Boszormenyi Zoltan wrote: The above is quite reproducable, "pg_ctl stop -m immediate" "usually" inflated my serial sequence, but I had two occasions when not. The 69 -> 70 was one. The inflated increase is always 33: AFAIKS sequences are pre-logged with

Re: [HACKERS] psql: Add setting to make '+' on \d implicit

--On 23. April 2010 14:34:45 -0700 Steve Atkins wrote: Or more generally an ability to set aliases via .psqlrc similar to \set, maybe? \alias "\d-" = "\d" \alias "\d" = "\d+" You mean something like this? -- Thanks

Re: [HACKERS] no universally correct setting for fsync

--On 7. Mai 2010 09:48:53 -0500 Kevin Grittner wrote: I think it goes beyond "tweaking" -- I think we should have a bald statement like "don't turn this off unless you're OK with losing the entire contents of the database cluster." A brief listing of some cases where that is OK might be il

Re: [HACKERS] no universally correct setting for fsync

--On 7. Mai 2010 19:49:15 -0400 Tom Lane wrote: Bernd Helmle writes: I've recently even started to wonder if the performance gain with fsync=off is still that large on modern hardware. While testing large migration procedures to a new version some time ago (on an admitedly fast st

Re: [HACKERS] BYTEA / DBD::Pg change in 9.0 beta

--On 18. Mai 2010 23:20:26 +0200 Jesper Krogh wrote: That was it. Knowing what the problem was I had no problem finding it in the release notes. May I ask whats the reason is for "breaking" the compatibillity? "Efficency", if i am allowed to call it this way. The new hex representation sh

[HACKERS] Scheduled back-branch releases?

Do we have a schedule for when next back-branch releases are packaged (i hope i didn't miss any announcement...)? -- Thanks Bernd -- 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] WIP: Triggers on VIEWs

--On 5. September 2010 09:09:55 +0100 Dean Rasheed wrote: I had a first look on your patch, great work! Attached is an updated patch with more tests and docs, and a few minor code tidy ups. I think that the INSTEAD OF triggers part of the patch is compliant with Feature T213 of the SQL 200

Re: [HACKERS] WIP: Triggers on VIEWs

--On 23. September 2010 08:59:32 +0100 Dean Rasheed wrote: Yes, I agree. To me this is the least surprising behaviour. I think a more common case would be where the trigger computed a value (such as the 'last updated' example). The executor doesn't have any kind of a handle on the row inser

Re: [HACKERS] Patch: Extend NOT NULL representation to pg_constraint

--On 25. September 2010 19:55:02 -0300 José Arthur Benetasso Villanova wrote: One thing that I take notice is when you create a simple table like this one: select count(*) from pg_constraint ; 12 rows appears in pg_constraint, 10 to the sequence. Is that ok? Not sure i get you here, can y

Re: [HACKERS] Patch: Extend NOT NULL representation to pg_constraint

--On 26. September 2010 15:50:06 -0400 Tom Lane wrote: I think his question was - how do we feel about the massive catalog bloat this patch will create? It's a fair question. I can imagine designing things so that we don't create an explicit pg_constraint row for the simplest case of an un

Re: [HACKERS] TODO: You can alter it, but you can't view it

--On 27. September 2010 16:54:32 +0900 Itagaki Takahiro wrote: I found it in 8.4 and newer versions. It might be an internal API (for pg_dump?), but it'd be better to add documentation for it. Additionally we could extend pg_tables with an additional column? This would make the query mor

[HACKERS] Re: starting to review the Extend NOT NULL representation to pg_constraint patch

--On 29. September 2010 23:05:11 -0400 Andrew Geery wrote: Reference: https://commitfest.postgresql.org/action/patch_view?id=312 The patch from http://archives.postgresql.org/message-id/ca2e4c4762eae28d68404...@amenop his does not apply cleanly to the current git master: Yeah, there wher

[HACKERS] ALTER DATABASE RENAME with HS/SR

Our documentation in currently says the following: Running DROP DATABASE, ALTER DATABASE ... SET TABLESPACE, or ALTER DATABASE ... RENAME on the primary will generate a WAL entry that will cause all users connected to that dat

Re: [HACKERS] ALTER DATABASE RENAME with HS/SR

--On 4. Oktober 2010 13:24:37 -0400 Robert Haas wrote: I understand that we need to disconnect users if the database is dropped (it's kind of hard to access a database that's not there any more...) but I'm fuzzy on why we'd need to do that if it is merely renamed. Yeah, if there's no real

Re: [HACKERS] WIP: Triggers on VIEWs

--On 30. September 2010 07:38:18 +0100 Dean Rasheed wrote: This version doesn't apply clean anymore due to some rejects in plainmain.c. Corrected version attached. Ah yes, those pesky bits have been rotting while I wasn't looking. Thanks for fixing them! Basic summary of this patch: *

Re: [HACKERS] Re: starting to review the Extend NOT NULL representation to pg_constraint patch

--On 14. Oktober 2010 11:42:27 -0400 Robert Haas wrote: I did a sanity make clean && make && make check before applying the patch and all the tests passed.  After applying the patch and doing make clean && make && make check, I got a number of failures of the form “FAILED (test process exit

Re: [HACKERS] Re: starting to review the Extend NOT NULL representation to pg_constraint patch

--On 14. Oktober 2010 10:02:12 -0400 Andrew Geery wrote: The first failure I get is in the inherit tests (tail of /src/test/regress/results/inherit.out): alter table a alter column aa type integer using bit_length(aa); server closed the connection unexpectedly This probably means t

Re: [HACKERS] Re: starting to review the Extend NOT NULL representation to pg_constraint patch

--On 14. Oktober 2010 19:16:56 +0100 Dean Rasheed wrote: Program received signal SIGSEGV, Segmentation fault. ATExecSetNotNullInternal (is_local=1 '\001', is_new_constraint=, atttup=, attr_rel=, rel=) at tablecmds.c:4847 4847Form_pg_constraint constr

Re: [HACKERS] Re: starting to review the Extend NOT NULL representation to pg_constraint patch

--On 14. Oktober 2010 20:47:27 +0100 Dean Rasheed wrote: OK, here it is. I've not cured this compiler warning (in fact I'm not sure what it's complaining about, because the variable *is* used): tablecmds.c: In function 'ATExecSetNotNull': tablecmds.c:4747: warning: unused variable 'is_new

Re: [HACKERS] Re: starting to review the Extend NOT NULL representation to pg_constraint patch

--On 15. Oktober 2010 13:36:38 -0400 Tom Lane wrote: Bernd Helmle writes: Here is an updated version of the patch. It fixes the following issues Andrew discovered during his review cycle: I looked through this a bit. It's not ready to commit unfortunately. Thanks for looking at

Re: Trailing Whitespace Tips (was: [HACKERS] Re: starting to review the Extend NOT NULL representation to pg_constraint patch)

--On 16. Oktober 2010 12:35:06 +0300 Peter Eisentraut wrote: Maybe it should go in src/tools/editors/emacs.samples, too? Yeah, I think we should recommend some way to highlight faulty whitespace. The problem is, after you turn it on, it will make you cry as you realize how sloppy most co

Re: [HACKERS] ALTER OBJECT any_name SET SCHEMA name

--On 30. Oktober 2010 18:59:30 -0400 Tom Lane wrote: I'm not sure whether that really fixes anything, or just provides people with a larger-caliber foot-gun. See for example recent complaints about citext misbehaving if it's not in the public schema (or more generally, any schema not in the

Re: [HACKERS] How can we tell how far behind the standby is?

--On 5. November 2010 11:46:08 -0700 Josh Berkus wrote: I'll work on some tools to make this a bit more palatable, but I disagree with earlier assertions that we have the replication monitoring "done". There's still a *lot* of work to do. While getting familiar with our SR/HS infrastructur

Re: [HACKERS] [COMMITTERS] pgsql: Improved parallel make support

--On 14. November 2010 11:08:13 -0500 Robert Haas wrote: +1. The current master branch fails to build on my (rather new) Mac with make -j2. I could upgrade my toolchain but it seems like more trouble than it's worth, not to mention a possible obstacle to new users and developers. The sa

Re: [HACKERS] JDBC connections to 9.1

--On 18. April 2011 09:44:38 -0400 Tom Lane wrote: I'm getting JDBC exceptions when I try to connect to 9.1 (master) with the postgresql-9.0-801.jdbc3.jar I don't have this issue with 9.0. Hmm, what shows up in the postmaster log? A quick check with an application here gives the followin

Re: [HACKERS] JDBC connections to 9.1

--On 18. April 2011 16:17:57 +0200 Bernd Helmle wrote: 16:09:47.942 (1) <=BE ParameterStatus(client_encoding = UTF8) org.postgresql.util.PSQLException: Protocol error. Session setup failed. at org.postgresql.core.v3.ConnectionFactoryImpl.readStartupMessages(Connectio

Re: [HACKERS] Back branch update releases this week; beta postponed

--On 12. April 2011 10:58:25 -0400 Tom Lane wrote: Hmm, I would like to see the patch for going in for 8.4.8. Simon, was there a reason you only back-patched that to 9.0? So it seems we have shipped 8.4.8 without a fix for t

Re: [HACKERS] Proposed patch: Smooth replication during VACUUM FULL

--On 30. April 2011 20:19:36 +0200 Gabriele Bartolini wrote: I have noticed that during VACUUM FULL on reasonably big tables, replication lag climbs. In order to smooth down the replication lag, I propose the attached patch which enables vacuum delay for VACUUM FULL. Hmm, but this will mo

Re: [HACKERS] tuning autovacuum

--On 9. Juni 2011 11:53:22 -0400 Greg Smith wrote: There are at least four interesting numbers to collect each time autovacuum runs: 1) This one, when was the threshold crossed. I believe one of the AV workers would have to pause periodically to update these if they're all busy doing work.

Re: [HACKERS] procpid?

--On 15. Juni 2011 16:47:55 + Greg Sabino Mullane wrote: Or perhaps pg_connections. Yes, +1 to making things fully backwards compatible by keeping pg_stat_activity around but making a better designed and better named table (view/SRF/whatever). I thought about that too when reading the t

Re: [HACKERS] Patch - Debug builds without optimization

--On 16. Juni 2011 14:30:27 +0200 Radosław Smogura wrote: Hello, I'm sending following patch which disables optimization when --enable-debug is passed. It was nasty (for me, at least) that debug build required passing of CFLAGS with -O0 to get nice traceable code. -O0 hides bugs in

Re: [HACKERS] procpid?

--On 16. Juni 2011 15:33:35 + Greg Sabino Mullane wrote: No, this is clearly connections, not sessions. At least based on the items in the postgresql.conf file, especially max_connections (probably one of the items most closely associated with pg_stat_activity) Well, but it doesn't show

Re: [HACKERS] Re: starting to review the Extend NOT NULL representation to pg_constraint patch

--On 16. Juni 2011 13:25:05 -0400 Tom Lane wrote: Possible solution is to leave bootstrap's behavior alone, and have a step during initdb's post-bootstrap stuff that creates a matching pg_constraint row for every pg_attribute entry that's marked attnotnull. +1 for this idea. I never came to

Re: [HACKERS] Another swing at JSON

--On 29. März 2011 21:15:11 -0400 Joseph Adams wrote: Thanks. I applied a minor variation of this trick to the JSON module, so now it builds/installs/tests cleanly on both REL8_4_0 and HEAD (though it won't work if you copy contrib/json into a pre-9.1 PostgreSQL source directory and type `

Re: [HACKERS] Another swing at JSON

--On 16. Juni 2011 17:38:07 -0400 Tom Lane wrote: After reading Joseph's comment upthread, I don't see any consensus wether the existing pre-9.1 support is required or even desired. Maybe i missed it, but do we really expect an extension (or contrib module) to be backwards compatible to earli

  1   2   3   4   5   >