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

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

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

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

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

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

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 th

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 v

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 ru

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 foll

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

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 24.0

[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

[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 > >> 2016-03-29 15:12:40 CEST [1609

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] 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]), [SYSTEM_UID_MAX="$withval"],

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

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 the > table. > Making the in

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 (pgsql-hackers@postgresql.org) To make changes to y

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 an influence. If somet

[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 1663/65

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

[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? I see you are int

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

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

[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 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] 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] 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 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 (pgsql-hackers@postgresql.org)

Re: [HACKERS] [GENERAL] ON_ERROR_ROLLBACK

--On 29. Dezember 2014 12:55:11 -0500 Tom Lane 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 about this some time

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

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] tab completion for setting search_path

--On 3. Mai 2014 10:11:33 +0200 Andres Freund 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 *** psql_completion(const char *text, int s

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 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 Power7 (though we do ha

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

--On 26. April 2014 19:42:47 -0700 Peter Geoghegan 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 that make it mo

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

--On 1. April 2014 11:26:08 -0400 Robert Haas 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 will bloat) and WAL from

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

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] 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] Fixing pg_basebackup with tablespaces found in $PGDATA

--On 1. Januar 2014 23:53:46 +0100 Dimitri Fontaine 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. So here's a fix, attac

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

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

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

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

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

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

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

[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] 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] 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] 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] 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] 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] 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] Measuring relation free space

--On 6. November 2011 01:08:11 -0200 Greg Smith 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 numbers. -- Thanks

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

--On 20. Oktober 2011 02:02:09 +0200 Florian Pflug 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:// to /opt/local/etc/macports/sources.conf

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

--On 9. September 2011 10:27:22 -0400 Tom Lane 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 configuration, as the other res

[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 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 peak loads (several dozens backends IN

Re: [HACKERS] Another issue with invalid XML values

--On 25. Juli 2011 19:57:40 +0200 Florian Pflug 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 for the availa

Re: [HACKERS] Another issue with invalid XML values

--On 25. Juli 2011 19:07:50 +0200 Florian Pflug 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 libxml2 The f

Re: [HACKERS] Another issue with invalid XML values

--On 20. Juli 2011 13:06:17 -0400 Tom Lane 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, when building agai

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

--On 18. Juni 2011 12:29:38 +0200 Bernd Helmle 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 going to revi

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 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 worked as expected.

Re: [HACKERS] Another swing at JSON

--On 17. Juni 2011 18:06:58 -0400 Joseph Adams 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 "/usr/lib/postgresql/json.s

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

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

  1   2   3   4   5   >