[COMMITTERS] pgsql: Fix error message from wal_level value renaming

Fix error message from wal_level value renaming found by Ian Barwick Branch -- master Details --- http://git.postgresql.org/pg/commitdiff/4dcd4da98c786c48b0dbf129c8f7ea592c34a185 Modified Files -- src/backend/replication/slot.c | 2 +- 1 file changed, 1 insertion(+), 1

Re: [COMMITTERS] pgsql: Avoid archiving XLOG_RUNNING_XACTS on idle server

On Mon, Apr 4, 2016 at 4:50 PM, Andres Freund wrote: > On 2016-04-04 08:44:47 +0100, Simon Riggs wrote: >> That patch does exactly the same thing as the patch you prefer, just >> does it differently; > > No, it doesn't; as explained above. FWIW, I vote also for reverting this

[COMMITTERS] pgsql: Disallow newlines in parameter values to be set in ALTER SYSTEM.

Disallow newlines in parameter values to be set in ALTER SYSTEM. As noted by Julian Schauder in bug #14063, the configuration-file parser doesn't support embedded newlines in string literals. While there might someday be a good reason to remove that restriction, there doesn't seem to be one

[COMMITTERS] pgsql: Disallow newlines in parameter values to be set in ALTER SYSTEM.

Disallow newlines in parameter values to be set in ALTER SYSTEM. As noted by Julian Schauder in bug #14063, the configuration-file parser doesn't support embedded newlines in string literals. While there might someday be a good reason to remove that restriction, there doesn't seem to be one

[COMMITTERS] pgsql: Disallow newlines in parameter values to be set in ALTER SYSTEM.

Disallow newlines in parameter values to be set in ALTER SYSTEM. As noted by Julian Schauder in bug #14063, the configuration-file parser doesn't support embedded newlines in string literals. While there might someday be a good reason to remove that restriction, there doesn't seem to be one

[COMMITTERS] pgsql: Display WAL pointer in rm_redo error callback

Display WAL pointer in rm_redo error callback This makes it easier to identify the source of a recovery problem in case of a bug or data corruption. Branch -- master Details --- http://git.postgresql.org/pg/commitdiff/890614d2b35bd20468352043870edc7f24a7b8ec Modified Files

[COMMITTERS] pgsql: Partially revert commit 3d3bf62f30200500637b24fdb7b992a99f9704c3

Partially revert commit 3d3bf62f30200500637b24fdb7b992a99f9704c3. On reflection, the pre-existing logic in ANALYZE is specifically meant to compare the frequency of a candidate MCV against the estimated frequency of a random distinct value across the whole table. The change to compare it against

[COMMITTERS] pgsql: Add a few comments about ANALYZE's strategy for collecting MCVs.

Add a few comments about ANALYZE's strategy for collecting MCVs. Alex Shulgin complained that the underlying strategy wasn't all that apparent, particularly not the fact that we intentionally have two code paths depending on whether we think the column has a limited set of possible values or not.

Re: [COMMITTERS] pgsql: XLogReader general code cleanup

Alvaro Herrera wrote: > Peter Eisentraut wrote: > > On 03/30/2016 05:57 PM, Alvaro Herrera wrote: > > >XLogReader general code cleanup > > > > This is causing compiler warnings on 32-bit environments(?): > > Will fix. Fix pushed. -- Álvaro Herrerahttp://www.2ndQuadrant.com/

[COMMITTERS] pgsql: Silence compiler warning

Silence compiler warning Reported by Peter Eisentraut to occur on 32bit systems Branch -- master Details --- http://git.postgresql.org/pg/commitdiff/c9ff752a854b687fc0a05fd4aba1066028ec5495 Modified Files -- src/backend/access/transam/xlogreader.c | 8 1 file

[COMMITTERS] pgsql: Add a \gexec command to psql for evaluation of computed queries.

Add a \gexec command to psql for evaluation of computed queries. \gexec executes the just-entered query, like \g, but instead of printing the results it takes each field as a SQL command to send to the server. Computing a series of queries to be executed is a fairly common thing, but up to now

[COMMITTERS] pgsql: Introduce a LOG_SERVER_ONLY ereport level, which is never sent t

Introduce a LOG_SERVER_ONLY ereport level, which is never sent to client. This elevel is useful for logging audit messages and similar information that should not be passed to the client. It's equivalent to LOG in terms of decisions about logging priority in the postmaster log, but messages with

[COMMITTERS] pgsql: Fix latent portability issue in pgwin32_dispatch_queued_signals(

Fix latent portability issue in pgwin32_dispatch_queued_signals(). The first iteration of the signal-checking loop would compute sigmask(0) which expands to 1<<(-1) which is undefined behavior according to the C standard. The lack of field reports of trouble suggest that it evaluates to 0 on all

[COMMITTERS] pgsql: Fix latent portability issue in pgwin32_dispatch_queued_signals(

Fix latent portability issue in pgwin32_dispatch_queued_signals(). The first iteration of the signal-checking loop would compute sigmask(0) which expands to 1<<(-1) which is undefined behavior according to the C standard. The lack of field reports of trouble suggest that it evaluates to 0 on all

[COMMITTERS] pgsql: Fix latent portability issue in pgwin32_dispatch_queued_signals(

Fix latent portability issue in pgwin32_dispatch_queued_signals(). The first iteration of the signal-checking loop would compute sigmask(0) which expands to 1<<(-1) which is undefined behavior according to the C standard. The lack of field reports of trouble suggest that it evaluates to 0 on all

[COMMITTERS] pgsql: Fix latent portability issue in pgwin32_dispatch_queued_signals(

Fix latent portability issue in pgwin32_dispatch_queued_signals(). The first iteration of the signal-checking loop would compute sigmask(0) which expands to 1<<(-1) which is undefined behavior according to the C standard. The lack of field reports of trouble suggest that it evaluates to 0 on all

[COMMITTERS] pgsql: Fix latent portability issue in pgwin32_dispatch_queued_signals(

Fix latent portability issue in pgwin32_dispatch_queued_signals(). The first iteration of the signal-checking loop would compute sigmask(0) which expands to 1<<(-1) which is undefined behavior according to the C standard. The lack of field reports of trouble suggest that it evaluates to 0 on all

[COMMITTERS] pgsql: Fix latent portability issue in pgwin32_dispatch_queued_signals(

Fix latent portability issue in pgwin32_dispatch_queued_signals(). The first iteration of the signal-checking loop would compute sigmask(0) which expands to 1<<(-1) which is undefined behavior according to the C standard. The lack of field reports of trouble suggest that it evaluates to 0 on all

[COMMITTERS] pgsql: Fix typo

Fix typo Michael Paquier Branch -- master Details --- http://git.postgresql.org/pg/commitdiff/eb7308d29875df773b5b52b06ed3d8b60f1b8242 Modified Files -- contrib/bloom/blutils.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) -- Sent via pgsql-committers mailing list

[COMMITTERS] pgsql: fix typo

fix typo Andreas Ulbrich Branch -- master Details --- http://git.postgresql.org/pg/commitdiff/9b27aebe7124210c1b0dbacac657edfefa16a006 Modified Files -- doc/src/sgml/generic-wal.sgml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) -- Sent via pgsql-committers

[COMMITTERS] pgsql: Improve estimate of distinct values in estimate_num_groups().

Improve estimate of distinct values in estimate_num_groups(). When adjusting the estimate for the number of distinct values from a rel in a grouped query to take into account the selectivity of the rel's restrictions, use a formula that is less likely to produce under-estimates. The old formula

Re: [COMMITTERS] pgsql: Avoid archiving XLOG_RUNNING_XACTS on idle server

On 2016-04-04 08:44:47 +0100, Simon Riggs wrote: > On 4 April 2016 at 08:22, Andres Freund wrote: > > No, because in the alternative proposal we determine that the system > > indeed has been idle since the last time a WAL record was logged. > Why would that change anything?

Re: [COMMITTERS] pgsql: Avoid archiving XLOG_RUNNING_XACTS on idle server

On 4 April 2016 at 08:22, Andres Freund wrote: > On 2016-04-04 08:08:32 +0100, Simon Riggs wrote: > > For that matter, it's also important for hot standby; to deal with > > > FATALed transactions which didn't write an abort record. It's kinda > > > important to call

Re: [COMMITTERS] pgsql: Avoid archiving XLOG_RUNNING_XACTS on idle server

On 2016-04-04 08:08:32 +0100, Simon Riggs wrote: > For that matter, it's also important for hot standby; to deal with > > FATALed transactions which didn't write an abort record. It's kinda > > important to call StandbyReleaseOldLocks for those. And if a standby is > > in STANDBY_SNAPSHOT_READY

Re: [COMMITTERS] pgsql: Avoid archiving XLOG_RUNNING_XACTS on idle server

On 4 April 2016 at 07:49, Andres Freund wrote: > > It doesn't? > Nope, clearly in the code 2 lines above. For that matter, it's also important for hot standby; to deal with > FATALed transactions which didn't write an abort record. It's kinda > important to call

Re: [COMMITTERS] pgsql: Avoid archiving XLOG_RUNNING_XACTS on idle server

On 2016-04-04 08:42:02 +0200, Andres Freund wrote: > On 2016-04-04 07:31:46 +0100, Simon Riggs wrote: > > On 4 April 2016 at 07:24, Andres Freund wrote: > > > > > On 2016-04-04 06:19:04 +, Simon Riggs wrote: > > > > Avoid archiving XLOG_RUNNING_XACTS on idle server > > >

Re: [COMMITTERS] pgsql: Avoid archiving XLOG_RUNNING_XACTS on idle server

On 2016-04-04 07:31:46 +0100, Simon Riggs wrote: > On 4 April 2016 at 07:24, Andres Freund wrote: > > > On 2016-04-04 06:19:04 +, Simon Riggs wrote: > > > Avoid archiving XLOG_RUNNING_XACTS on idle server > > > > > > If archive_timeout > 0 we should avoid logging

Re: [COMMITTERS] pgsql: Avoid archiving XLOG_RUNNING_XACTS on idle server

On 4 April 2016 at 07:24, Andres Freund wrote: > On 2016-04-04 06:19:04 +, Simon Riggs wrote: > > Avoid archiving XLOG_RUNNING_XACTS on idle server > > > > If archive_timeout > 0 we should avoid logging XLOG_RUNNING_XACTS if > idle. > > > > Bug 13685 reported by Laurence

Re: [COMMITTERS] pgsql: Avoid archiving XLOG_RUNNING_XACTS on idle server

On Mon, Apr 4, 2016 at 3:24 PM, Andres Freund wrote: > On 2016-04-04 06:19:04 +, Simon Riggs wrote: >> Avoid archiving XLOG_RUNNING_XACTS on idle server >> >> If archive_timeout > 0 we should avoid logging XLOG_RUNNING_XACTS if idle. >> >> Bug 13685 reported by Laurence

Re: [COMMITTERS] pgsql: Avoid archiving XLOG_RUNNING_XACTS on idle server

On 2016-04-04 06:19:04 +, Simon Riggs wrote: > Avoid archiving XLOG_RUNNING_XACTS on idle server > > If archive_timeout > 0 we should avoid logging XLOG_RUNNING_XACTS if idle. > > Bug 13685 reported by Laurence Rowe, investigated in detail by Michael > Paquier, > though this is not his

[COMMITTERS] pgsql: Avoid archiving XLOG_RUNNING_XACTS on idle server

Avoid archiving XLOG_RUNNING_XACTS on idle server If archive_timeout > 0 we should avoid logging XLOG_RUNNING_XACTS if idle. Bug 13685 reported by Laurence Rowe, investigated in detail by Michael Paquier, though this is not his proposed fix. 20151016203031.3019.72...@wrigleys.postgresql.org