[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

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 >

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

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

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

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

[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

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

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)

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. Okay, i'm going to try this. Currently Tomas' scripts are still running, i'll provide updates as

Re: [HACKERS] Should we cacheline align PGXACT?

Am Montag, den 13.02.2017, 16:55 +0300 schrieb Alexander Korotkov: > > Thank you for testing. > > Yes, influence seems to be low.  But nevertheless it's important to > insure > that there is no regression here. > Despite pg_prewarm'ing and running tests 300s, there is still > significant >

Re: [HACKERS] LWLock optimization for multicore Power machines

Am Samstag, den 11.02.2017, 15:42 +0300 schrieb Alexander Korotkov: > Thus, I see reasons why in your tests absolute results are lower than > in my > previous tests. > 1.  You use 28 physical cores while I was using 32 physical cores. > 2.  You run tests in PowerVM while I was running test on bare

Re: [HACKERS] Should we cacheline align PGXACT?

Am Samstag, den 11.02.2017, 00:28 +0100 schrieb Tomas Vondra: > Comparing averages of tps, measured on 5 runs (each 5 minutes long), > the  > difference between master and patched master is usually within 2%, > which  > is pretty much within noise. > > I'm attaching spreadsheets with summary of

Re: [HACKERS] LWLock optimization for multicore Power machines

Am Dienstag, den 07.02.2017, 16:48 +0300 schrieb Alexander Korotkov: > But win isn't > as high as I observed earlier.  And I wonder why absolute numbers are > lower > than in our earlier experiments.  We used IBM E880 which is actually > two Did you run your tests on bare metal or were they also

Re: [HACKERS] LWLock optimization for multicore Power machines

Am Montag, den 06.02.2017, 22:44 +0300 schrieb Alexander Korotkov: >    2. Also could you run each test longer: 3-5 mins, and run them > with > >    variety of clients count? So here are some other results. I've changed max_connections to 300. The bench was prewarmed and run 300s each. I could

Re: [HACKERS] LWLock optimization for multicore Power machines

On Mon, 2017-02-06 at 22:44 +0300, Alexander Korotkov wrote: > Results looks strange for me.  I wonder why there is difference > between > lwlock-power-1.patch and lwlock-power-3.patch?  From my intuition, it > shouldn't be there because it's not much difference between them.  > Thus, I > have

Re: [HACKERS] LWLock optimization for multicore Power machines

Am Montag, den 06.02.2017, 16:45 +0300 schrieb Alexander Korotkov: > I tried lwlock-power-2.patch on multicore Power machine we have in > PostgresPro. > I realized that using labels in assembly isn't safe.  Thus, I removed > labels and use relative jumps instead (lwlock-power-2.patch). >

Re: [HACKERS] LWLock optimization for multicore Power machines

On Fri, 2017-02-03 at 20:11 +0300, Alexander Korotkov wrote: > On Fri, Feb 3, 2017 at 8:01 PM, Alexander Korotkov < > a.korot...@postgrespro.ru> wrote: > > > Unfortunately, I have no big enough Power machine at hand to > > reproduce > > that results.  Actually, I have no Power machine at hand at

Re: [HACKERS] Deadlock in XLogInsert at AIX

Hi Konstantin, We had observed exactly the same issues on a customer system with the same environment and PostgreSQL 9.5.5. Additionally, we've tested on Linux with XL/C 12 and 13 with exactly the same deadlock behavior. So we assumed that this is somehow a compiler issue. Am Dienstag, den

[HACKERS] recovery_min_apply_delay vs. synchronous_commit

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 make cha

[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

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

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

Re: [HACKERS] PSA: Systemd will kill PostgreSQL

--On 11. Juli 2016 13:25:51 +0800 Craig Ringer wrote: > Perhaps by uid threshold in login.defs? systemd's configure.ac has this: AC_ARG_WITH(system-uid-max, AS_HELP_STRING([--with-system-uid-max=UID] [Maximum UID for system users]),

[HACKERS] pg_dump vs. idle_in_transaction_session_timeout

Currently pg_dump doesn't turn off idle_in_transaction_session_timeout. Okay, the window of failure here is very narrow (on my machine it breaks with an insane setting of 1ms only), but for the sake of reliable backups and protection against over motivated DBA it looks better to me to turn that

Re: [HACKERS] Using FDW AddForeignUpdateTargets for a hidden pseudo-column

--On 14. Juni 2016 10:32:13 + Albe Laurenz wrote: > I first thought of using the internal ROWID column that's probably > similar to your case, but that wouldn't fit into a tid's 6 bytes, and I > found that I could only add resjunk columns for existing columns of

Re: [HACKERS] standalone backend PANICs during recovery

--On 5. April 2016 21:50:17 -0400 Robert Haas wrote: > If nobody's going to commit this right away, this should be added to > the next CommitFest so we don't forget it. Done. -- Thanks Bernd -- Sent via pgsql-hackers mailing list

Re: [HACKERS] Problems with huge_pages and IBM Power8

--On 12. April 2016 13:20:10 -0700 Andres Freund wrote: >> When working with huge_pages, we initially got this error. >> >> munmap(0x3efbe400) failed: Invalid argument > > *munmap*, not mmap failed? that's odd; because there the hugepagesize > shouldn't have much of

[HACKERS] standalone backend PANICs during recovery

While investigating a problem on a streaming hot standby instance at a customer site, i got the following when using a standalone backend: PANIC: btree_xlog_delete_get_latestRemovedXid: cannot operate with inconsistent data CONTEXT: xlog redo delete: index 1663/65588/65625; iblk 11, heap

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

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

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

[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] 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?

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:

[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

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

--On 6. Mai 2015 16:28:43 -0400 Andrew Dunstan and...@dunslane.net 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

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

--On 30. April 2015 08:00:23 -0400 Robert Haas robertmh...@gmail.com 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

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

--On 1. Mai 2015 11:30:51 -0700 Tom Lane t...@sss.pgh.pa.us 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

[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] [COMMITTERS] pgsql: Move pg_upgrade from contrib/ to src/bin/

--On 15. April 2015 15:02:05 -0400 Andrew Dunstan and...@dunslane.net 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

[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

Re: [HACKERS] Re: [COMMITTERS] pgsql: Disable -faggressive-loop-optimizations in gcc 4.8+ for pre-9.2

--On 20. Januar 2015 17:15:01 +0100 Andres Freund and...@2ndquadrant.com wrote: I personally think that being able to at least compile/make check old versions a bit longer is a good idea. +1 from me for this idea. -- Thanks Bernd -- Sent via pgsql-hackers mailing list

Re: [HACKERS] [GENERAL] ON_ERROR_ROLLBACK

--On 29. Dezember 2014 12:55:11 -0500 Tom Lane t...@sss.pgh.pa.us wrote: Given the lack of previous complaints, this probably isn't backpatching material, but it sure seems like a bit of attention to consistency would be warranted here. Now that i read it i remember a client complaining

Re: [HACKERS] Amazon Redshift

--On 5. November 2014 23:36:03 +0100 philip taylor philta...@mail.com 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

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

--On 3. November 2014 18:15:04 +0100 Sven Wegener sven.wege...@stealer.net 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

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

--On 4. November 2014 17:18:14 -0500 Tom Lane t...@sss.pgh.pa.us 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

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

--On 1. September 2014 17:00:32 +0900 Michael Paquier michael.paqu...@gmail.com 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

Re: [HACKERS] Hardening pg_upgrade

--On 21. August 2014 22:08:58 +0200 Magnus Hagander mag...@hagander.net 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

Re: [HACKERS] SSL information view

--On 12. Juli 2014 15:08:01 +0200 Magnus Hagander mag...@hagander.net 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

Re: [HACKERS] Clarification of FDW API Documentation

--On 13. Juni 2014 13:46:38 -0400 Tom Lane t...@sss.pgh.pa.us 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

Re: [HACKERS] tab completion for setting search_path

--On 3. Mai 2014 10:11:33 +0200 Andres Freund and...@2ndquadrant.com wrote: diff --git a/src/bin/psql/tab-complete.c b/src/bin/psql/tab-complete.c new file mode 100644 index 6d26ffc..dec3d4a *** a/src/bin/psql/tab-complete.c --- b/src/bin/psql/tab-complete.c ***

Re: [HACKERS] Sending out a request for more buildfarm animals?

It's a POWER 7 machine. On 3. Mai 2014 10:31:34 MESZ, Dave Page dave.p...@enterprisedb.com wrote: Hamid@EDB; Can you please have someone configure anole to build git head as well as the other branches? Thanks. Andres, Andrew; I think the only other gap EDB could fill at the moment is RHEL6 on

Re: [HACKERS] Should pg_stat_bgwriter.buffers_backend_fsync be removed?

--On 26. April 2014 19:42:47 -0700 Peter Geoghegan p...@heroku.com wrote: I suggest removing it for 9.5, and instead logging individual occurrences of backend fsync requests within ForwardFsyncRequest(). It seems fair to treat that as an anomaly to draw particular attention to. But wouldn't

Re: [HACKERS] Including replication slot data in base backups

--On 1. April 2014 11:26:08 -0400 Robert Haas robertmh...@gmail.com wrote: As a general comment, I think that replication slots, while a great feature, have more than the usual potential for self-inflicted injury. A replication slot prevents the global xmin from advancing (so your tables

Re: [HACKERS] Selecting large tables gets killed

--On 20. Februar 2014 14:49:28 +0530 Ashutosh Bapat ashutosh.ba...@enterprisedb.com 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

Re: [HACKERS] Selecting large tables gets killed

--On 20. Februar 2014 09:51:47 -0500 Tom Lane t...@sss.pgh.pa.us 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

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 hlinn...@iki.fi 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

Re: [HACKERS] Fixing pg_basebackup with tablespaces found in $PGDATA

--On 1. Januar 2014 23:53:46 +0100 Dimitri Fontaine dimi...@2ndquadrant.fr wrote: Hi, As much as I've seen people frown upon $subject, it still happens in the wild, and Magnus seems to agree that the current failure mode of our pg_basebackup tool when confronted to the situation is a bug.

Re: [HACKERS] Wait free LW_SHARED acquisition

--On 27. September 2013 09:57:07 +0200 Andres Freund and...@2ndquadrant.com 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 =

Re: [HACKERS] Wait free LW_SHARED acquisition

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

Re: [HACKERS] ENABLE/DISABLE CONSTRAINT NAME

--On 13. September 2013 20:17:19 -0400 Robert Haas robertmh...@gmail.com 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

Re: [HACKERS] psql should show disabled internal triggers

--On 18. September 2013 13:52:29 +0200 Andres Freund and...@2ndquadrant.com 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

Re: [HACKERS] psql should show disabled internal triggers

--On 18. September 2013 15:19:27 +0200 Andres Freund and...@2ndquadrant.com 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

[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

Re: [HACKERS] GUC for data checksums

--On 15. September 2013 00:25:34 +0200 Andres Freund and...@2ndquadrant.com 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

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

--On 8. Juli 2013 16:04:31 + Dean Rasheed dean.a.rash...@gmail.com 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

[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

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

--On 13. Juni 2013 18:12:05 -0400 Tom Lane t...@sss.pgh.pa.us 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

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

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

--On 13. Juni 2013 11:06:31 -0400 Tom Lane t...@sss.pgh.pa.us 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

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

--On 6. Juni 2013 16:25:29 -0700 Josh Berkus j...@agliodbs.com 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

Re: [HACKERS] background worker and normal exit

--On 26. Mai 2013 11:38:55 +0900 Michael Paquier michael.paqu...@gmail.com 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

Re: [HACKERS] pg_controldata gobbledygook

--On 25. April 2013 23:19:14 -0400 Tom Lane t...@sss.pgh.pa.us 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,

[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

[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] 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

Re: [HACKERS] Hanging backends and possible index corruption

--On 25. Januar 2013 20:37:32 -0500 Tom Lane t...@sss.pgh.pa.us 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

[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,

Re: [HACKERS] Hanging backends and possible index corruption

--On 25. Januar 2013 16:28:16 +0100 Andres Freund and...@2ndquadrant.com 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

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

--On 2. Januar 2013 23:04:43 -0500 Robert Haas robertmh...@gmail.com 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

[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:

Re: [HACKERS] Patch pg_is_in_backup()

--On 3. Februar 2012 13:21:11 +0900 Fujii Masao masao.fu...@gmail.com 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

Re: [HACKERS] pg_stats_recovery view

--On 2. Februar 2012 17:12:11 +0900 Fujii Masao masao.fu...@gmail.com 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

Re: [HACKERS] Patch pg_is_in_backup()

--On 2. Februar 2012 18:47:35 +0100 Gilles Darold gilles.dar...@dalibo.com 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

Re: [HACKERS] pg_stats_recovery view

--On 15. Januar 2012 02:50:00 -0500 Jaime Casanova ja...@2ndquadrant.com 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

Re: [HACKERS] Measuring relation free space

--On 6. November 2011 01:08:11 -0200 Greg Smith g...@2ndquadrant.com wrote: Attached patch adds a new function to the pageinspect extension for measuring total free space, in either tables or indexes. I wonder if that should be done in the pgstattuple module, which output some similar

Re: [HACKERS] Update on documentation builds on OSX w/ macports

--On 20. Oktober 2011 02:02:09 +0200 Florian Pflug f...@phlo.org wrote: In the mean time, the modified ports are all contained in the attached tar.bz2, should any of ye fellow OSX users want to try them out before that. Simply extract that archive, and add file://Absolute path to the

Re: [HACKERS] Patch to improve reliability of postgresql on linux nfs

--On 9. September 2011 10:27:22 -0400 Tom Lane t...@sss.pgh.pa.us wrote: On the whole I think you'd be better off lobbying your NFS implementors to provide something closer to the behavior of every other filesystem on the planet. Or checking to see if you need to adjust your NFS

[HACKERS] Informix FDW - anybody working on this?

Out of curiosity, is anybody working on $subject? I'm currently planning to work on such a driver, but given the current stream of new drivers i want to make sure to not duplicate any efforts... -- Thanks Bernd -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To

Re: [HACKERS] pgstat wait timeout warnings

--On 10. August 2011 21:54:06 +0300 Heikki Linnakangas heikki.linnakan...@enterprisedb.com wrote: So my theory is that if the I/O is really busy, write() on the stats file blocks for more than 5 seconds, and you get the timeout. I've seen it on customer instances with very high INSERT

Re: [HACKERS] Another issue with invalid XML values

--On 20. Juli 2011 13:06:17 -0400 Tom Lane t...@sss.pgh.pa.us wrote: I've committed this patch with the discussed changes and some other editorialization. I have to leave for an appointment and can't write anything now about the changes, but feel free to ask questions if you have any. Hmm,

Re: [HACKERS] Another issue with invalid XML values

--On 25. Juli 2011 19:07:50 +0200 Florian Pflug f...@phlo.org wrote: Hm, I have libxml2 2.7.8, installed via Mac Ports, and I cannot reproduce this. Maybe Mac Ports uses a modified libxml2, though. I'll check that. Where did you obtain libxml2 from? This is MacPorts, too: % port installed

Re: [HACKERS] Another issue with invalid XML values

--On 25. Juli 2011 19:57:40 +0200 Florian Pflug f...@phlo.org wrote: I got a theory. We do distinguish between libxml2 versions for which the structured and the generic error context handler share the error context (older ones), and those with don't (newer ones). Our configure scripts checks

Initial Review: JSON contrib modul was: Re: [HACKERS] Another swing at JSON

--On 18. Juni 2011 12:29:38 +0200 Bernd Helmle maili...@oopsware.de wrote: Similar problems occur with a couple other modules I tried (hstore, intarray). Hmm, works for me. Seems you have messed up your installation in some way (build against current -HEAD but running against a 9.1?). I'm

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

--On 24. Juni 2011 12:06:17 -0400 Robert Haas robertmh...@gmail.com wrote: Uh, really? pg_upgrade uses SQL commands to recreate the contents of the system catalogs, so if these entries aren't getting created automatically, that sounds like a bug in the patch... AFAIR, i've tested it and it

Re: [HACKERS] Another swing at JSON

--On 17. Juni 2011 18:06:58 -0400 Joseph Adams joeyadams3.14...@gmail.com wrote: Done. Note that this module builds, tests, and installs successfully with USE_PGXS=1. However, building without USE_PGXS=1 produces the following: CREATE EXTENSION json; ERROR: incompatible library

Re: [HACKERS] Another swing at JSON

--On 16. Juni 2011 17:38:07 -0400 Tom Lane t...@sss.pgh.pa.us 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

Re: [HACKERS] Patch - Debug builds without optimization

--On 16. Juni 2011 14:30:27 +0200 Radosław Smogura rsmog...@softperience.eu 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

Re: [HACKERS] procpid?

--On 16. Juni 2011 15:33:35 + Greg Sabino Mullane g...@turnstep.com 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,

  1   2   3   4   5   >