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

Hi, On 2016/02/16 18:25, Kyotaro HORIGUCHI wrote: > At Tue, 16 Feb 2016 10:39:27 +0900, Amit Langote wrote: >> On 2016/02/15 20:21, Kyotaro HORIGUCHI wrote: >>> CREATE FUNCTION >>> pg_stat_get_command_progress(IN cmdtype integer) >>> RETURNS SETOF integer[] as $$ >>> >>> SELECT * from

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

On Wed, Feb 17, 2016 at 4:29 PM, Masahiko Sawada wrote: > On Wed, Feb 17, 2016 at 4:08 AM, Bruce Momjian wrote: >> 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

Re: [HACKERS] about google summer of code 2016

Hi Shubham, On 2016/02/17 16:27, Shubham Barai wrote: > Hello everyone, > > I am currently pursuing my bachelor of engineering in computer science > at Maharashtra > Institute of Technology, Pune ,India. I am very excited about contributing > to postgres through google summer of code program. >

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

On Wed, Feb 17, 2016 at 4:08 AM, Bruce Momjian wrote: > 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,

[HACKERS] about google summer of code 2016

Hello everyone, I am currently pursuing my bachelor of engineering in computer science at Maharashtra Institute of Technology, Pune ,India. I am very excited about contributing to postgres through google summer of code program. Is postgres applying for gsoc 2016 as mentoring organization ?

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

After I unzip the patch it doesn't apply. patch says: patch: Only garbage was found in the patch input. It's a combined diff, the git-diff manual says this about it: Chunk header format is modified to prevent people from accidentally feeding it to patch -p1. Combined diff format was created

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

Hi, On 2016/02/17 14:34, Regina Obe wrote: > 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: >

Re: [HACKERS] Figures in docs

> Hi. > > In DocBook 4.2 sgml dtd, figure tag is supported already. > that was implemented for multi output format. Ok, there's no technical problems with figures then. MySQL docs has some nice figures. I am jealous. > I remember that very old postgresql document has some picture (eg. >

Re: [HACKERS] Bug in StartupSUBTRANS

On Sun, Feb 14, 2016 at 9:03 AM, Jeff Janes wrote: > I've repeated the crash/recovery/wrap-around testing with the proposed > fix in place, and this pre-existing problem seems to be fixed now, and > I have found no other problems. > > I've attached a new version,

Re: [HACKERS] Figures in docs

Hi. In DocBook 4.2 sgml dtd, figure tag is supported already. that was implemented for multi output format. I remember that very old postgresql document has some picture (eg. system architecture, ERD ...). when release new version, these might be changed, nevertheless these can not been. this

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

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

[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

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

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,

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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've been reviewing this patch, and I had a question: why do we need to bother with a lockGroupLeaderIdentifier field? It seems

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

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

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

[HACKERS] commitfest problem ?

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

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!

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

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

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

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

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

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

  1   2   >