Re: [HACKERS] Remove or weaken hints about "effective resolution of sleep delays is 10 ms"?

On February 16, 2016 3:09:16 AM GMT+01:00, Merlin Moncure >I guess we should probably explain what is actually happening, namely >that the precise sleep duration is delegated to the operating system >scheduler which may cause the process to sleep longer than requested. In not really seeing why:

Re: [HACKERS] extend pgbench expressions with functions

On Tue, Feb 16, 2016 at 1:55 AM, Michael Paquier wrote: > On Tue, Feb 16, 2016 at 9:18 AM, Robert Haas wrote: >> I experimented with trying to do this and ran into a problem: where >> exactly would you store the evaluated arguments when you don't

Re: [HACKERS] Re: [COMMITTERS] pgsql: Introduce group locking to prevent parallel processes from deadl

On Mon, Feb 15, 2016 at 7:55 PM, Tom Lane wrote: > Robert Haas writes: >> On Sun, Feb 14, 2016 at 5:26 PM, Tom Lane wrote: >>> Also, after fixing that it would be good to add a comment explaining why >>> it's not fundamentally

Re: [HACKERS] Remove or weaken hints about "effective resolution of sleep delays is 10 ms"?

On Wed, Feb 10, 2016 at 5:15 PM, Andres Freund wrote: > Hi, > > Several places in our docs have blurbs like >> Note that on many systems, the effective resolution of sleep delays is >> 10 milliseconds; setting wal_writer_delay to a value that >> is not a multiple of 10 might

Re: [HACKERS] Remove or weaken hints about "effective resolution of sleep delays is 10 ms"?

On February 16, 2016 9:06:57 AM GMT+01:00, Robert Haas wrote: >On Wed, Feb 10, 2016 at 5:15 PM, Andres Freund >wrote: >> Hi, >> >> Several places in our docs have blurbs like >>> Note that on many systems, the effective resolution of sleep delays >is

Re: [HACKERS] [WIP] ALTER ... OWNER TO ... CASCADE

> 15 февр. 2016 г., в 19:25, Tom Lane написал(а): > > Teodor Sigaev writes: >>> So basically, a generic CASCADE facility sounds like a lot of work to >>> produce something that would seldom be anything but a foot-gun. > >> DELETE FROM or TRUNCATE could

Re: [HACKERS] Remove or weaken hints about "effective resolution of sleep delays is 10 ms"?

On 2016-02-16 09:13:09 +0100, Andres Freund wrote: > What we do we think the resolution is on modern > >systems? I would not have guessed that to be inaccurate. > > Depends in a lot of factors. The biggest being how busy you're system > is. On an mostly idle system (i.e. workout so CPUs being >

Re: [HACKERS] extend pgbench expressions with functions

Hello Robert, [...] But we can't have things that are logically part of patch #2 just tossed in with patch #1. So you want integer functions without type in patch #1. I was in the middle of ripping that out of the patch when I realized that evalFunc() is pretty badly designed. Probably,

Re: [HACKERS] [PROPOSAL] VACUUM Progress Checker.

Hello, At Tue, 16 Feb 2016 10:39:27 +0900, Amit Langote wrote in <56c27dcf.7020...@lab.ntt.co.jp> > > Hello, > > On 2016/02/15 20:21, Kyotaro HORIGUCHI wrote: > > At Mon, 8 Feb 2016 11:37:17 +0900, Amit Langote wrote: > >> On 2016/02/05 17:15,

[HACKERS] Identifying a message in emit_log_hook.

Hello. I'm planning to change the error level of a specific error message. We can use emit_log_hook for this purpose but we have no reliable means to identify what a message is. For messages without valid sqlerrcode, filename:lineno could be used to identify but lineno is too unstable. One

Re: [HACKERS] Identifying a message in emit_log_hook.

Hi 2016-02-16 10:47 GMT+01:00 Kyotaro HORIGUCHI < horiguchi.kyot...@lab.ntt.co.jp>: > Hello. > > I'm planning to change the error level of a specific error > message. We can use emit_log_hook for this purpose but we have > no reliable means to identify what a message is. > > For messages

Re: [HACKERS] extend pgbench expressions with functions

Hello Robert, Good point. One simple idea here would be to use a custom pgbench script that has no SQL commands and just calculates the values of some parameters to measure the impact without depending on the backend, with a fixed number of transactions. Sure, we could do that. But whether

Re: [HACKERS] Identifying a message in emit_log_hook.

On 16 February 2016 at 09:47, Kyotaro HORIGUCHI < horiguchi.kyot...@lab.ntt.co.jp> wrote: > I'm planning to change the error level of a specific error > message. We can use emit_log_hook for this purpose but we have > no reliable means to identify what a message is. > > For messages without

Re: [HACKERS] custom function for converting human readable sizes to bytes

On 16 February 2016 at 05:01, Pavel Stehule wrote: > 2016-02-15 10:16 GMT+01:00 Dean Rasheed : >> Is there any reason not to make >> pg_size_bytes() return numeric? >> > This is a question. I have not a strong opinion about it. There are no any >

Re: [HACKERS] custom function for converting human readable sizes to bytes

2016-02-16 11:25 GMT+01:00 Dean Rasheed : > On 16 February 2016 at 05:01, Pavel Stehule > wrote: > > 2016-02-15 10:16 GMT+01:00 Dean Rasheed : > >> Is there any reason not to make > >> pg_size_bytes() return numeric? >

Re: [HACKERS] custom function for converting human readable sizes to bytes

On 2/16/16, Dean Rasheed wrote: > On 16 February 2016 at 05:01, Pavel Stehule > wrote: >> 2016-02-15 10:16 GMT+01:00 Dean Rasheed : >>> Is there any reason not to make >>> pg_size_bytes() return numeric? >>> >> This is

Re: [HACKERS] custom function for converting human readable sizes to bytes

On 2/16/16, Vitaly Burovoy wrote: > On 2/16/16, Dean Rasheed wrote: >> On 16 February 2016 at 05:01, Pavel Stehule >> wrote: >>> 2016-02-15 10:16 GMT+01:00 Dean Rasheed : >> Fixing that in

Re: [HACKERS] [WIP] ALTER ... OWNER TO ... CASCADE

On Mon, Feb 15, 2016 at 7:25 PM, Tom Lane wrote: > Teodor Sigaev writes: > >> So basically, a generic CASCADE facility sounds like a lot of work to > >> produce something that would seldom be anything but a foot-gun. > > > DELETE FROM or TRUNCATE could be

[HACKERS] Packaging of postgresql-jdbc

Hello pg-hackers, I need advice about postgresql-jdbc driver. Current version in Fedora is behind latest version of postgresql-jdbc (1200 vs 1207). We are trying to package latest version into Fedora, but there are dependencies, which are not useless in Fedora (waffle-jna) and ones which we

Re: [HACKERS] postgres_fdw vs. force_parallel_mode on ppc

On 02/15/2016 07:57 PM, Tom Lane wrote: Noah Misch writes: On Mon, Feb 15, 2016 at 07:31:40PM -0500, Robert Haas wrote: Oh, crap. I didn't realize that TEMP_CONFIG didn't affect the contrib test suites. Is there any reason for that, or is it just kinda where we ended

Re: [HACKERS] Remove or weaken hints about "effective resolution of sleep delays is 10 ms"?

On Tue, Feb 16, 2016 at 3:50 AM, Andres Freund wrote: > On 2016-02-16 09:13:09 +0100, Andres Freund wrote: >> What we do we think the resolution is on modern >> >systems? I would not have guessed that to be inaccurate. >> >> Depends in a lot of factors. The biggest being how

Re: [HACKERS] extend pgbench expressions with functions

On Tue, Feb 16, 2016 at 3:53 AM, Fabien COELHO wrote: > My opinion is that the submitted version is simple and fine for the purpose, > and the plan you suggest replaces 5*2 repetitions by a lot of code and > complexity, which is not desirable and should be avoided. > >

Re: [HACKERS] extend pgbench expressions with functions

On Tue, Feb 16, 2016 at 5:18 AM, Fabien COELHO wrote: >>> Good point. One simple idea here would be to use a custom pgbench >>> script that has no SQL commands and just calculates the values of some >>> parameters to measure the impact without depending on the backend, >>>

Re: [HACKERS] Packaging of postgresql-jdbc

On 16 February 2016 at 20:15, Pavel Kajaba wrote: > Hello pg-hackers, > > I need advice about postgresql-jdbc driver. > > Current version in Fedora is behind latest version of postgresql-jdbc > (1200 vs 1207). > > We are trying to package latest version into Fedora, but there

Re: [HACKERS] GetExistingLocalJoinPath() vs. the docs

On Mon, Feb 15, 2016 at 9:11 PM, Stephen Frost wrote: > Greetings, > > While getting back into the thread Re: Optimization for updating foreign > tables in Postgres FDW, I noticed some issues with the docs and > GetExistingLocalJoinPath(): > > GetExistingLocalJoinPath()

Re: [HACKERS] Declarative partitioning

On Fri, Jan 15, 2016 at 5:48 AM, Amit Langote wrote: > If we have a CREATE statement for each partition, how do we generalize > that to partitions at different levels? For example, if we use something > like the following to create a partition of parent_name: > >

Re: [HACKERS] Sequence Access Method WIP

On Sat, Jan 30, 2016 at 3:37 PM, Petr Jelinek wrote: > On 29 January 2016 at 23:59, Robert Haas wrote: > > On Fri, Jan 29, 2016 at 5:24 PM, Tom Lane wrote: > >> Alexander Korotkov writes: > >>> On Fri,

Re: [HACKERS] Packaging of postgresql-jdbc

Oh, Pavel probably forgot to CC pgjdbc, fixing. Forwarded message from Craig Ringer: On 16 February 2016 at 20:15, Pavel Kajaba wrote: > Hello pg-hackers, > > I need advice about postgresql-jdbc driver. > > Current version in Fedora is

Re: [HACKERS] Declarative partitioning

On Fri, Jan 22, 2016 at 8:54 AM, Tomas Vondra wrote: > I'd like to comment on the one thing and that's the syntax. It seems to me > we're really trying to reinvent the wheel and come up with our own version > of the syntax. Is there a particular reason why not to

Re: [HACKERS] Packaging of postgresql-jdbc

On 16 February 2016 at 07:50, Craig Ringer wrote: > On 16 February 2016 at 20:15, Pavel Kajaba wrote: > >> Hello pg-hackers, >> >> I need advice about postgresql-jdbc driver. >> >> Current version in Fedora is behind latest version of postgresql-jdbc

Re: [HACKERS] pgbench - allow backslash-continuations in custom scripts

On Mon, Feb 15, 2016 at 1:04 AM, Kyotaro HORIGUCHI wrote: > I'm sorry, but I didn't understood the 'submission notes' exactly > means. Is it precise descriptions in source comments? or commit > message of git-commit? Write a detailed email explaining each change

Re: [HACKERS] Small PATCH: check of 2 Perl modules

On Mon, 15 Feb 2016 08:34:11 -0500 Peter Eisentraut wrote: > On 2/12/16 8:20 AM, Eugene Kazakov wrote: > > TAP-tests need two Perl modules: Test::More and IPC::Run. > > > > The patch adds checking of modules in configure.in and configure. > > I think those modules are part

Re: [HACKERS] extend pgbench expressions with functions

Hello Robert, However, for obvious reasons the committer opinion prevails:-) You're welcome to solicit other opinions. I'm not unwilling to give way if there's a chorus of support for the way you've done it. Hmmm. I do not expect much chorus on such a minor subject:-) But to me it sounds

Re: [HACKERS] exposing pg_controldata and pg_config as functions

On 02/15/2016 11:20 PM, Michael Paquier wrote: > Here are just a couple of cosmetic comments. > Missing markup around PostgreSQL. Added, but I'll note that there are tons of locations in the docs where we do not do that. Maybe they should all be made consistent. > + Application. There is a

Re: [HACKERS] pglogical - logical replication contrib module

On Tue, Jan 26, 2016 at 08:14:26PM -0800, Joshua Drake wrote: > On 12/31/2015 03:34 PM, Petr Jelinek wrote: > >Hi, > > > >I'd like to submit the replication solution which is based on the > >pglogical_output [1] module (which is obviously needed for this to > >compile). > > This is fantastic!

[HACKERS] commitfest problem ?

This entry https://commitfest.postgresql.org/8/419/ contains very unrelated patches from another commitfest. I think Oleg

Re: [HACKERS] Freeze avoidance of very large table.

On Tue, Feb 16, 2016 at 6:13 AM, Bruce Momjian wrote: > On Wed, Feb 10, 2016 at 04:39:15PM +0900, Kyotaro HORIGUCHI wrote: >> > I still agree with this plugin approach, but I felt it's still >> > complicated a bit, and I'm concerned that patch size has been >> > increased. >> >

Re: [JDBC] [HACKERS] Packaging of postgresql-jdbc

Pavel Raiskup writes: > Oh, Pavel probably forgot to CC pgjdbc, fixing. In fact, this is completely off-topic for pgsql-hackers, please confine the discussion to pgsql-jdbc. regards, tom lane -- Sent via pgsql-hackers mailing list

Re: [HACKERS] commitfest problem ?

On 16.02.2016 17:50, Oleg Bartunov wrote: This entry https://commitfest.postgresql.org/8/419/ contains very unrelated patches from another commitfest. I think Oleg No, this is not commitfest problem. The part of the thread "[PROPOSAL] Improvements of Hunspell dictionaries support"

Re: [HACKERS] Freeze avoidance of very large table.

On Tue, Feb 16, 2016 at 11:56:25PM +0900, Masahiko Sawada wrote: > > I agreed on ripping out the converter plugin ability of pg_upgrade. > > Remember pg_upgrade was originally written by EnterpriseDB staff, and I > > think they expected their closed-source fork of Postgres might need a > > custom

Re: [HACKERS] Remove or weaken hints about "effective resolution of sleep delays is 10 ms"?

Robert Haas writes: > On Tue, Feb 16, 2016 at 3:50 AM, Andres Freund wrote: >> To back up my claim on this, read man 7 time >> (e.g. http://linux.die.net/man/7/time), especially "The software clock, >> HZ, and jiffies" and "High-resolution timers". To

Re: [HACKERS] [PROPOSAL] Improvements of Hunspell dictionaries support

I attached a new version of the patch. On 10.02.2016 19:46, Teodor Sigaev wrote: I duplicate the patch here. it's very good thing to update disctionaries to support modern versions. And thank you for improving documentation. Also I've impressed by long description in spell.c header. Som

Re: [HACKERS] [WIP] ALTER ... OWNER TO ... CASCADE

> Sometimes I hit the following. You have created a database and schema inside > it from the superuser (i.e. postgres). Than you want to change ownership of > whole database to another user (i.e. alice), but only this database, not > all other objects in all other databases. Actually, it skips

Re: [HACKERS] [WIP] ALTER ... OWNER TO ... CASCADE

Vladimir Borodin wrote: > > Moreover, the use case you've sketched (ie, change ownership of all > > objects inside a database) doesn't actually have anything to do with > > following dependencies. It's a lot closer to REASSIGN OWNED ... in > > fact, it's not clear to me why REASSIGN OWNED

Re: [HACKERS] Small PATCH: check of 2 Perl modules

Victor Wagner wrote: > Not everyone have "standard perl installation" nowadays. Most Linux > users, for example, use Perl package from the distrubution, and > distributions love to strip down standard perl installation putting its > parts into separate packages, some of which might be optional. >

Re: [HACKERS] Freeze avoidance of very large table.

On Wed, Feb 17, 2016 at 12:02 AM, Bruce Momjian wrote: > On Tue, Feb 16, 2016 at 11:56:25PM +0900, Masahiko Sawada wrote: >> > I agreed on ripping out the converter plugin ability of pg_upgrade. >> > Remember pg_upgrade was originally written by EnterpriseDB staff, and I >> >

Re: [HACKERS] proposal: PL/Pythonu - function ereport

On Sat, Feb 13, 2016 at 4:26 PM, Pavel Stehule wrote: > I am sending new version. Current version does: Hello, I had a look and I like the big picture. Tests fail when built against Python 3.5 with stuff like this in regression.diffs: -ERROR: plpy.Error: stop on error

Re: [HACKERS] [WIP] ALTER ... OWNER TO ... CASCADE

> 16 февр. 2016 г., в 18:20, Alvaro Herrera > написал(а): > > Vladimir Borodin wrote: > >>> Moreover, the use case you've sketched (ie, change ownership of all >>> objects inside a database) doesn't actually have anything to do with >>> following dependencies. It's

Re: [HACKERS] Small PATCH: check of 2 Perl modules

On Tue, 16 Feb 2016 12:23:56 -0300 Alvaro Herrera wrote: > ... but I agree with the point upthread that this should wait to see > what happens with the CMake stuff, since this is not a newly > introduced problem. I doubt, that CMake stuff would be ready for 9.6. There

Re: [HACKERS] pglogical - logical replication contrib module

On Tue, Feb 16, 2016 at 5:38 PM, Bruce Momjian wrote: > On Tue, Jan 26, 2016 at 08:14:26PM -0800, Joshua Drake wrote: > > On 12/31/2015 03:34 PM, Petr Jelinek wrote: > > >Hi, > > > > > >I'd like to submit the replication solution which is based on the > > >pglogical_output [1]

[HACKERS] Question about Restart point and checkpoint_segments

Hello, I am using a hot_standby setup on PostgreSQL 9.1 While I was testing, I found out that only checkpoint_timeout (+ a checkpoint since the last restart point) could trigger a restart point. The code (bgwriter.c) seems to confirm this: /* * Check progress against WAL segments

Re: [HACKERS] Doubt in 9.5 release note

On Wed, Jan 27, 2016 at 01:31:45PM +0900, Tatsuo Ishii wrote: > > Tatsuo Ishii writes: > >> I saw following item in release-9.5.sgml: > >> > >> > >> Support comments on domain > >> constraints (lvaro Herrera) > >> > >> > > > >> It

Re: [HACKERS] Freeze avoidance of very large table.

Masahiko Sawada wrote: > On Wed, Feb 17, 2016 at 12:02 AM, Bruce Momjian wrote: > > On Tue, Feb 16, 2016 at 11:56:25PM +0900, Masahiko Sawada wrote: > >> > I agreed on ripping out the converter plugin ability of pg_upgrade. > >> > Remember pg_upgrade was originally written by

Re: [HACKERS] Freeze avoidance of very large table.

On Tue, Feb 16, 2016 at 03:57:01PM -0300, Alvaro Herrera wrote: > Masahiko Sawada wrote: > > On Wed, Feb 17, 2016 at 12:02 AM, Bruce Momjian wrote: > > > On Tue, Feb 16, 2016 at 11:56:25PM +0900, Masahiko Sawada wrote: > > >> > I agreed on ripping out the converter plugin

Re: [HACKERS] Re: [COMMITTERS] pgsql: Introduce group locking to prevent parallel processes from deadl

Robert Haas writes: > Yeah, you're right. Attached is a draft patch that tries to clean up > that and a bunch of other things that you raised. I've been reviewing this patch, and I had a question: why do we need to bother with a lockGroupLeaderIdentifier field? It seems

Re: [HACKERS] proposal: PL/Pythonu - function ereport

On Tue, Feb 16, 2016 at 5:18 PM, Catalin Iacob wrote: > We have > elog_test_legacy to test elog_test_legacy=true, the rest of the tests > should use legacy_custom_exception=false. This should have been: We have elog_test_legacy to test legacy_custom_exception=true, the

Re: [HACKERS] Re: [COMMITTERS] pgsql: Introduce group locking to prevent parallel processes from deadl

Robert Haas writes: > Yeah, you're right. Attached is a draft patch that tries to clean up > that and a bunch of other things that you raised. I reviewed this patch. I don't have any particular comment on the changes in deadlock.c; I haven't studied the code closely

Re: [HACKERS] proposal: PL/Pythonu - function ereport

2016-02-16 21:06 GMT+01:00 Catalin Iacob : > On Tue, Feb 16, 2016 at 5:18 PM, Catalin Iacob > wrote: > > We have > > elog_test_legacy to test elog_test_legacy=true, the rest of the tests > > should use legacy_custom_exception=false. > > This should

Re: [HACKERS] Remove or weaken hints about "effective resolution of sleep delays is 10 ms"?

On Tue, Feb 16, 2016 at 12:06 AM, Robert Haas wrote: > On Wed, Feb 10, 2016 at 5:15 PM, Andres Freund wrote: >> Hi, >> >> Several places in our docs have blurbs like >>> Note that on many systems, the effective resolution of sleep delays is >>> 10

Re: [HACKERS] Re: [COMMITTERS] pgsql: Introduce group locking to prevent parallel processes from deadl

Robert Haas writes: > 1. It removes the groupLeader flag from PGPROC. You're right: we don't need > it. It occurs to me that this claim is bogus: > We institute a further coding rule that a process cannot join or leave a lock > group while owning any PROCLOCK.

Re: [HACKERS] auto_explain sample rate

On 25/08/2015 14:45, Michael Paquier wrote: > On Fri, Jul 17, 2015 at 2:53 PM, Craig Ringer wrote: >> On 7 July 2015 at 21:37, Julien Rouhaud wrote: >> >>> Well, I obviously missed that pg_srand48() is only used if the system >>> lacks

Re: [HACKERS] auto_explain sample rate

Julien Rouhaud wrote: Hijacking this macro is just too obscure: > #define auto_explain_enabled() \ > (auto_explain_log_min_duration >= 0 && \ > - (nesting_level == 0 || auto_explain_log_nested_statements)) > + (nesting_level == 0 || auto_explain_log_nested_statements) && \ > +

Re: [HACKERS] proposal: PL/Pythonu - function ereport

Hi 2016-02-16 17:18 GMT+01:00 Catalin Iacob : > On Sat, Feb 13, 2016 at 4:26 PM, Pavel Stehule > wrote: > > I am sending new version. Current version does: > > Hello, > > I had a look and I like the big picture. > > Tests fail when built against

[HACKERS] Tab Completion for CREATE DATABASE ... TEMPLATE ...

We use "CREATE DATABASE foo TEMPLATE foo_bk" to restore development databases to a known snapshot (ex: prior to testing DB migrations). Currently psql only autocompletes "foo_bk" if it's marked as a template database. It's mildly inconvenient to have to type out the entire database name (as

Re: [HACKERS] PostgreSQL Audit Extension

On Fri, Feb 5, 2016 at 01:16:25PM -0500, Stephen Frost wrote: > Looking at pgaudit and the other approaches to auditing which have been > developed (eg: applications which sit in front of PG and essentially > have to reimplement large bits of PG to then audit the commands sent > before passing

Re: [HACKERS] auto_explain sample rate

On 16/02/2016 22:51, Alvaro Herrera wrote: > Julien Rouhaud wrote: > > Hijacking this macro is just too obscure: > >> #define auto_explain_enabled() \ >> (auto_explain_log_min_duration >= 0 && \ >> - (nesting_level == 0 || auto_explain_log_nested_statements)) >> + (nesting_level ==

Re: [HACKERS] proposal: function parse_ident

On 2/11/16 1:27 AM, Pavel Stehule wrote: I editorialized the docs and some of the comments. In particular, I documented behavior of not truncating, and recommended casting to name[] if user cares about that. Added a unit test to verify that works. BTW, I saw mention in the thread

Re: [HACKERS] custom function for converting human readable sizes to bytes

On 2/16/16, Vitaly Burovoy wrote: > On 2/16/16, Dean Rasheed wrote: >> Fixing that in parse_memory_unit() would be messy because it assumes a >> base unit of kB, so it would require a negative multiplier, and >> pg_size_bytes() would have to be

Re: [HACKERS] exposing pg_controldata and pg_config as functions

On Tue, Feb 16, 2016 at 11:36 PM, Joe Conway wrote: > Thanks! OK. I think I'm good now. Thanks for the quick update. -- Michael -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription:

[HACKERS] Figures in docs

It seems there's no figures/diagrams in our docs. I vaguely recall that we used to have a few diagrams in our docs. If so, was there any technical reason to remove them? Best regards, -- Tatsuo Ishii SRA OSS, Inc. Japan English: http://www.sraoss.co.jp/index_en.php

Re: [HACKERS] pglogical - logical replication contrib module

On 17 February 2016 at 00:54, Oleg Bartunov wrote: > > DDL support is what it's missed for now. > > TBH, based on experience with DDL replication and deparse in BDR, it's going to be missing for a while yet too, or at least not comprehensively present without caveats or

Re: [HACKERS] Re: [COMMITTERS] pgsql: Introduce group locking to prevent parallel processes from deadl

On 14 February 2016 at 08:05, Robert Haas wrote: > > The concept of a > lock group is formally separate from the concept of a parallel group > created by a ParallelContext, but it is not clear that there will ever > be any other context in which a lock group will be a

Commitfest Bug (was: [HACKERS] Re: Reusing abbreviated keys during second pass of ordered [set] aggregates)

On 2/16/16 12:38 AM, Michael Paquier wrote: When a patch with status "Ready for committer" on CF N is moved to CF (N+1), its status is automatically changed to "Needs Review". That's something to be aware of when cleaning up the CF app entries. I agree with Alvarro; this seems like a bug to

Re: [HACKERS] [patch] Proposal for \crosstabview in psql

On 2/11/16 4:21 AM, Dean Rasheed wrote: Thinking about this some more though, perhaps*sorting* the columns is the wrong way to be thinking about it. Perhaps a better approach would be to allow the columns to be*listed* (optionally, using a separate query). Something like the following (don't

Re: [HACKERS] proposal: enhancing slow query log, and autoexplain log about waiting on lock before query exec time

On 2/14/16 11:24 AM, Pavel Stehule wrote: > We have a patch, that inject logs about the time waiting on locks before > query execution. This feature helps us lot of, and I hope, it can be > generally useful. Doesn't log_lock_waits cover that territory already? It does. But It

Re: [HACKERS] Declarative partitioning

On 2016/02/15 10:55, Amit Langote wrote: > required. There is also basic planner support but no support yet to enable > constraint exclusion on partitions (which will be fulfilled shortly by > installing equivalent check constraints on partitions). Just to follow up on this - attached now adds

[HACKERS] How are CREATE EXTENSION ... VERSION or ALTER EXTENSION ... UPDATE TO ... intended to work?

I've been looking a little more deeply at the extension mechanism, trying to answer my own question about what happens once there have been several releases of an extension, and the extensions directory is now populated with a bunch of files quux--1.0.sql, quux--1.1.sql, quux--1.0--1.1.sql,

[HACKERS] Bug with int2

I run into the following. Seems this is a bug for -32768, which should be a valid smallint value. Test was run on 9.4.5. Thanks, Feng ftian=# select 32767::int2; int2 --- 32767 (1 row) ftian=# select -32767::int2; ?column? -- -32767 (1 row) ftian=# select 32768::int2;

Re: [HACKERS] How are CREATE EXTENSION ... VERSION or ALTER EXTENSION ... UPDATE TO ... intended to work?

Chapman Flack writes: > I've been looking a little more deeply at the extension mechanism, > trying to answer my own question about what happens once there have > been several releases of an extension, and the extensions directory > is now populated with a bunch of files

Re: [HACKERS] Bug with int2

Feng Tian writes: > I run into the following. Seems this is a bug for -32768, which should be > a valid smallint value. > ftian=# select -32768::int2; > ERROR: smallint out of range You have the wrong idea about the precedence of those operators. "select

Re: [HACKERS] Bug with int2

On Wed, Feb 17, 2016 at 12:27 PM, Feng Tian wrote: > ftian=# select -32768::int2; > ERROR: smallint out of range But 32768 is not. You should just use parenthesis, a cast does not take into account the minus sign here: =# select (-32768)::int2; int2 -32768 (1

Re: [HACKERS] Bug with int2

On Tue, Feb 16, 2016 at 7:27 PM, Feng Tian wrote: > I run into the following. Seems this is a bug for -32768, which should be > a valid smallint value. This isn't a bug. You see the error only due to operator precedence: postgres=# select (-32768)::int2; int2

Re: [HACKERS] tsearch_extras extension

Just following up here since I haven't gotten a reply -- I'd love to work with someone from the Postgres community on a plan to make the tsearch_extras functionality available as part of mainline postgres. -Tim Abbott On Wed, Feb 3, 2016 at 9:41 PM, Tim Abbott wrote:

Re: [HACKERS] proposal: enhancing slow query log, and autoexplain log about waiting on lock before query exec time

2016-02-17 3:43 GMT+01:00 Jim Nasby : > On 2/14/16 11:24 AM, Pavel Stehule wrote: > >> > We have a patch, that inject logs about the time waiting on locks >> before >> > query execution. This feature helps us lot of, and I hope, it can be >> > generally

Re: [HACKERS] Re: [COMMITTERS] pgsql: Introduce group locking to prevent parallel processes from deadl

On Tue, Feb 16, 2016 at 8:37 PM, Craig Ringer wrote: > On 14 February 2016 at 08:05, Robert Haas wrote: >> The concept of a >> lock group is formally separate from the concept of a parallel group >> created by a ParallelContext, but it is not clear

Re: Commitfest Bug (was: [HACKERS] Re: Reusing abbreviated keys during second pass of ordered [set] aggregates)

2016-02-17 3:19 GMT+01:00 Jim Nasby : > On 2/16/16 12:38 AM, Michael Paquier wrote: > >> When a patch with status "Ready for committer" on CF N is moved to CF >> (N+1), its status is automatically changed to "Needs Review". That's >> something to be aware of when

Re: [HACKERS] Re: [COMMITTERS] pgsql: Introduce group locking to prevent parallel processes from deadl

On Tue, Feb 16, 2016 at 3:54 PM, Tom Lane wrote: > Robert Haas writes: >> 1. It removes the groupLeader flag from PGPROC. You're right: we don't need >> it. > > It occurs to me that this claim is bogus: > >> We institute a further coding rule that a

Re: [HACKERS] Re: [COMMITTERS] pgsql: Introduce group locking to prevent parallel processes from deadl

Robert Haas writes: > Hmm, that's true. I don't think it actually matters all that much, > because proclock->tag.myProc->lockGroupLeader == NULL has pretty much > the same effect as if proclock->tag.myProc->lockGroupLeader == > proclock->tag.myProc. But not completely.

Re: [HACKERS] Parallel Aggregate

On Sat, Feb 13, 2016 at 3:51 PM, Robert Haas wrote: > On Sun, Feb 7, 2016 at 8:21 PM, Haribabu Kommi > wrote:future. >> Here I attached updated patch with the corrections. > > So, what about the main patch, for parallel aggregation itself? I'm >

Re: [HACKERS] proposal: function parse_ident

2016-02-17 1:38 GMT+01:00 Jim Nasby : > On 2/11/16 1:27 AM, Pavel Stehule wrote: > >> I editorialized the docs and some of the comments. In particular, I >> documented behavior of not truncating, and recommended casting to >> name[] if user cares about that.

[HACKERS] commitfest application doesn't see new patch

Hi In a entry https://commitfest.postgresql.org/9/525/ the commitfest application show last patch Latest attachment (incompat.py) at 2016-02-04 09:13:55 from Catalin Iacob although last patch is from yesterday Attachment: plpython-enhanced-error-02.patch.gz Regards Pavel

Re: [HACKERS] proposal: PL/Pythonu - function ereport

I noticed the patch isn't registered in the March CF, please do that. > It would be a pity to miss 9.6 because of not registering it in time. > https://commitfest.postgresql.org/9/525/ Regards Pavel

Re: [HACKERS] Bug with int2

Ah, thanks! On Tue, Feb 16, 2016 at 7:54 PM, Peter Geoghegan wrote: > On Tue, Feb 16, 2016 at 7:27 PM, Feng Tian wrote: > > I run into the following. Seems this is a bug for -32768, which should > be > > a valid smallint value. > > This isn't a bug.

Re: [HACKERS] tsearch_extras extension

On Wed, Feb 17, 2016 at 6:57 AM, Tim Abbott wrote: > Just following up here since I haven't gotten a reply -- I'd love to work > with someone from the Postgres community on a plan to make the > tsearch_extras functionality available as part of mainline postgres. > > >

Re: [HACKERS] Figures in docs

On Wed, Feb 17, 2016 at 4:17 AM, Tatsuo Ishii wrote: > It seems there's no figures/diagrams in our docs. I vaguely recall that > we used to have a few diagrams in our docs. If so, was there any > technical reason to remove them? > I don't know the reason, but it's shame,

[HACKERS] Fix handling of invalid sockets returned by PQsocket()

Hi all, After looking at Alvaro's message mentioning the handling of PQsocket() for invalid sockets, I just had a look by curiosity at other calls of this routine, and found a couple of issues: 1) In vacuumdb.c, init_slot() does not check for the return value of PQsocket(): slot->sock =

[HACKERS] On Conflict Do nothing errors IF conflict and there is a data type length or check failure

I'm guessing this is by design but just wanted to confirm that since it makes this feature not as useful for us. It also wasn't absolutely clear to me from the documentation. We are running PostgreSQL 9.5.1 and if we do something like: CREATE TABLE test(field1 varchar(5) primary key, field2

Re: [HACKERS] Figures in docs

> On Wed, Feb 17, 2016 at 4:17 AM, Tatsuo Ishii wrote: > >> It seems there's no figures/diagrams in our docs. I vaguely recall that >> we used to have a few diagrams in our docs. If so, was there any >> technical reason to remove them? >> > > I don't know the reason, but

Re: [HACKERS] extend pgbench expressions with functions

On Tue, Feb 16, 2016 at 11:12 PM, Fabien COELHO wrote: > > Hello Robert, > >>> However, for obvious reasons the committer opinion prevails:-) >> >> >> You're welcome to solicit other opinions. I'm not unwilling to give >> way if there's a chorus of support for the way you've

Re: [HACKERS] planstats.sgml

On 16/02/16 20:01, Tatsuo Ishii wrote: Tatsuo Ishii writes: While reading planstats.sgml, I encounted a sentence which I don't understand. These numbers are current as of the last VACUUM or ANALYZE on the table. The planner then fetches the actual

  1   2   >