Re: [HACKERS] Too many autovacuum workers spawned during forced auto-vacuum

On Fri, Jan 20, 2017 at 4:11 AM, Alvaro Herrera wrote: > Robert Haas wrote: > >> After sleeping on this, I'm inclined to go with Amit's fix for now. >> It seems less likely to break anything in the back-branches than any >> other option I can think up. > > Yeah, no objections here. +1. -- Michae

Re: [HACKERS] increasing the default WAL segment size

On Fri, Jan 20, 2017 at 12:49 AM, Robert Haas wrote: > On Wed, Jan 18, 2017 at 12:42 PM, Robert Haas wrote: >> Problems 2-4 actually have to do with a DestReceiver of type >> DestRemote really, really wanting to have an associated Portal and >> database connection, so one approach is to create a

Re: [HACKERS] pg_hba_file_settings view patch

On Fri, Jan 20, 2017 at 12:46 PM, Michael Paquier wrote: > On Fri, Jan 20, 2017 at 10:56 AM, Haribabu Kommi > wrote: >> The Assert case can be hit only, when the user added to new options to >> display >> to the user through view but not updating the macro to the max number of >> options then, it

Re: [HACKERS] Declarative partitioning - another take

Hi Andres, On 2017/01/20 15:15, Andres Freund wrote: > On 2017-01-19 14:18:23 -0500, Robert Haas wrote: >> Committed. > > One of the patches around this topic committed recently seems to cause > valgrind failures like > https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=skink&dt=2017-01-19%2

Re: [HACKERS] pg_hba_file_settings view patch

On Fri, Jan 20, 2017 at 10:56 AM, Haribabu Kommi wrote: > The Assert case can be hit only, when the user added to new options to > display > to the user through view but not updating the macro to the max number of > options then, it can lead to that assert. > > Updated patch attached including rev

Re: [HACKERS] Patch to implement pg_current_logfile() function

On Fri, Jan 20, 2017 at 3:29 AM, Karl O. Pinc wrote: > On Thu, 19 Jan 2017 12:12:18 -0300 > Alvaro Herrera wrote: > >> Karl O. Pinc wrote: >> > On Wed, 18 Jan 2017 19:27:40 -0300 >> > Alvaro Herrera wrote: >> >> > > I thought this part was odd -- I mean, why is SysLogger_Start() >> > > being cal

Re: [HACKERS] Too many autovacuum workers spawned during forced auto-vacuum

On 18 January 2017 at 02:32, Robert Haas wrote: > On Fri, Jan 13, 2017 at 8:45 AM, Alvaro Herrera > wrote: >> I think this is the same problem as reported in >> https://www.postgresql.org/message-id/CAMkU=1yE4YyCC00W_GcNoOZ4X2qxF7x5DUAR_kMt-Ta=ypy...@mail.gmail.com > > If I understand correctly,

Re: [HACKERS] Declarative partitioning - another take

On 2017-01-19 14:18:23 -0500, Robert Haas wrote: > Committed. One of the patches around this topic committed recently seems to cause valgrind failures like https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=skink&dt=2017-01-19%2008%3A40%3A02 : ==24969== Conditional jump or move depends on uni

Re: [HACKERS] postgres_fdw bug in 9.6

On Thu, Jan 19, 2017 at 10:38 PM, Robert Haas wrote: > On Wed, Jan 18, 2017 at 10:26 PM, Ashutosh Bapat > wrote: >>> Yes, I think that's broadly the approach Tom was recommending. >> >> I don't have problem with that approach, but the latest patch has >> following problems. >> 1. We are copying c

Re: [HACKERS] New SQL counter statistics view (pg_stat_sql)

On 2017/01/18 14:15, Haribabu Kommi wrote: On Sat, Jan 14, 2017 at 2:58 AM, Dilip Kumar > wrote: On Wed, Jan 11, 2017 at 7:47 PM, Dilip Kumar mailto:dilipbal...@gmail.com>> wrote: > +void > +pgstat_count_sqlstmt(const char *commandTag) > +{

Re: [HACKERS] postgres_fdw bug in 9.6

On 2017/01/19 12:26, Ashutosh Bapat wrote: On Thu, Jan 19, 2017 at 2:14 AM, Robert Haas wrote: On Fri, Jan 13, 2017 at 6:22 AM, Etsuro Fujita wrote: My biggest concern about GetExistingLocalJoinPath is that might not be extendable to the case of foreign-join paths with parameterization; in wh

Re: [HACKERS] Declarative partitioning - another take

So testing things out in pg_partman for native sub-partitioning and ran into what is a bug for me that I know I have to fix, but I'm curious if this can be prevented in the first place within the native partitioning code itself. The below shows a sub-partitioning set where the sub-partition has a c

Re: [HACKERS] SearchSysCache, SysCacheGetAttr, and heap_getattr()

Stephen Frost writes: > There's some inconsistency when it comes to if we actually use > SysCacheGetAttr() when pulling an attribute for a tuple we got via > SearchSysCache(), or if we use heap_getattr(). > Maybe I'm missing something, but that seems less than ideal. Well, SysCacheGetAttr just i

Re: [HACKERS] postgres_fdw bug in 9.6

On 2017/01/18 20:34, Ashutosh Bapat wrote: On Wed, Jan 18, 2017 at 8:18 AM, Etsuro Fujita wrote: Done. Attached is the new version. I also adjusted the code a bit further. With this patch there are multiple cases, where CreateLocalJoinPath() would return NULL and hence postgres_fdw would n

[HACKERS] SearchSysCache, SysCacheGetAttr, and heap_getattr()

Greetings, There's some inconsistency when it comes to if we actually use SysCacheGetAttr() when pulling an attribute for a tuple we got via SearchSysCache(), or if we use heap_getattr(). Maybe I'm missing something, but that seems less than ideal. I've generally been under the belief that using

Re: [HACKERS] Declarative partitioning - another take

On 2017/01/20 4:18, Robert Haas wrote: > On Thu, Jan 19, 2017 at 12:15 AM, Amit Langote wrote: >> 0002-Set-ecxt_scantuple-correctly-for-tuple-routing.patch >> >> In 2ac3ef7a01df859c62d0a02333b646d65eaec5ff, we changed things so that >> it's possible for a different TupleTableSlot to be used for par

Re: [HACKERS] Possible issue with expanded object infrastructure on Postgres 9.6.1

Peter Geoghegan writes: > A customer is on 9.6.1, and complains of a segfault observed at least > 3 times. In all cases, the logs look like this: > ... > I can use GDB to get details of the instruction pointer that appeared > in the kernel trap error, which shows a function from the expanded > val

Re: [HACKERS] [WIP]Vertical Clustered Index (columnar store extension)

On Wed, Jan 18, 2017 at 2:25 PM, Peter Eisentraut < peter.eisentr...@2ndquadrant.com> wrote: > On 12/29/16 10:55 PM, Haribabu Kommi wrote: > > Fujitsu was interested in developing a columnar storage extension with > > minimal > > changes the server backend. > > > > The columnar store is implemente

Re: [HACKERS] [BUGS] Bug in Physical Replication Slots (at least 9.5)?

Hello, At Thu, 19 Jan 2017 18:37:31 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI wrote in <20170119.183731.223893446.horiguchi.kyot...@lab.ntt.co.jp> > > > - Delaying recycling a segment until the last partial record on it > > > completes. This seems doable in page-wise (coarse resolution)

[HACKERS] Failure on sittella

Hi Andrew, All, There's a buildfarm failure (just on sittella so far) that I can't quite interpret from here. Timing wise it looks like it might be correlated with ea15e18677fc2eff3135023e27f69ed8821554ed - "Remove obsoleted code relating to targetlist SRF evaluation." but I'm not quite seeing the

Re: [HACKERS] Re: Clarifying "server starting" messaging in pg_ctl start without --wait

* Andres Freund (and...@anarazel.de) wrote: > On 2017-01-19 20:45:57 -0500, Stephen Frost wrote: > > * Andres Freund (and...@anarazel.de) wrote: > > > On 2017-01-19 10:06:09 -0500, Stephen Frost wrote: > > > > WAL replay does do more work, generally speaking (the WAL has to be > > > > read, the che

Re: [HACKERS] Parallel Index Scans

On Thu, Jan 19, 2017 at 1:18 AM, Amit Kapila wrote: > On Wed, Jan 18, 2017 at 6:25 AM, Haribabu Kommi > wrote: > > > > > > On Mon, Jan 16, 2017 at 11:11 PM, Amit Kapila > > wrote: > >> > > > > + * index_beginscan_parallel - join parallel index scan > > > > The name and the description doesn't s

Re: [HACKERS] pg_hba_file_settings view patch

On Thu, Jan 19, 2017 at 11:28 PM, Ashutosh Bapat < ashutosh.ba...@enterprisedb.com> wrote: > On Thu, Jan 19, 2017 at 1:26 PM, Michael Paquier > wrote: > > On Thu, Jan 19, 2017 at 4:25 PM, Haribabu Kommi > > wrote: > >> Added the cleanup mechanism. But the tokenize_file() function call > >> prese

Re: [HACKERS] Re: Clarifying "server starting" messaging in pg_ctl start without --wait

On 2017-01-19 20:45:57 -0500, Stephen Frost wrote: > * Andres Freund (and...@anarazel.de) wrote: > > On 2017-01-19 10:06:09 -0500, Stephen Frost wrote: > > > WAL replay does do more work, generally speaking (the WAL has to be > > > read, the checksum validated on it, and then the write has to go ou

Re: [HACKERS] Re: Clarifying "server starting" messaging in pg_ctl start without --wait

* Andres Freund (and...@anarazel.de) wrote: > On 2017-01-19 10:06:09 -0500, Stephen Frost wrote: > > WAL replay does do more work, generally speaking (the WAL has to be > > read, the checksum validated on it, and then the write has to go out, > > while the checkpointer just writes the page out from

[HACKERS] Possible issue with expanded object infrastructure on Postgres 9.6.1

A customer is on 9.6.1, and complains of a segfault observed at least 3 times. In all cases, the logs look like this: Jan 11 16:11:07 ip-10-0-118-82 kernel: [41913.530453] traps: postgres[6561] general protection ip:55fcf08b0491 sp:7ffc17dfa650 error:0 in postgres[55fcf0557000+638000] Jan 11 16:11

Re: [HACKERS] Re: Clarifying "server starting" messaging in pg_ctl start without --wait

* Michael Paquier (michael.paqu...@gmail.com) wrote: > On Fri, Jan 20, 2017 at 12:06 AM, Stephen Frost wrote: > > We did make the WAL checksum routines a lot > > faster with 9.6, as I recall, so perhaps there's been some change there > > too. > > 9.5, commit 5028f22f with Abhijit's and Heikki's w

Re: [HACKERS] Re: Clarifying "server starting" messaging in pg_ctl start without --wait

On 2017-01-19 10:06:09 -0500, Stephen Frost wrote: > WAL replay does do more work, generally speaking (the WAL has to be > read, the checksum validated on it, and then the write has to go out, > while the checkpointer just writes the page out from memory), but it's > also dealing with less contenti

Re: [HACKERS] Re: Clarifying "server starting" messaging in pg_ctl start without --wait

On Fri, Jan 20, 2017 at 12:06 AM, Stephen Frost wrote: > We did make the WAL checksum routines a lot > faster with 9.6, as I recall, so perhaps there's been some change there > too. 9.5, commit 5028f22f with Abhijit's and Heikki's work on CRC-32 computations. -- Michael -- Sent via pgsql-hack

Re: [HACKERS] Patch to implement pg_current_logfile() function

On Fri, Jan 20, 2017 at 12:08 AM, Karl O. Pinc wrote: > Is this an argument for having the current_logfiles always exist > and be empty when there is no in-filesystem logfile? It always felt > to me that the code would be simpler that way. Well, you'll need to do something in any case if the log

Re: [HACKERS] [JDBC] SEGFAULT in HEAD with replication

I wrote: > Hmm ... that line was last touched by ab1f0c822, so I'm betting that > I broke it somehow, but I'm not sure how. > It looks like S_3 might have been parsed from a totally empty source > string? But if that's the trigger, I'd think it'd be entirely trivial > to reproduce. Oh, duh: the r

Re: [HACKERS] [JDBC] SEGFAULT in HEAD with replication

Yes, in fact it's a totally empty string: https://github.com/pgjdbc/pgjdbc/blob/master/pgjdbc/src/main/java/org/postgresql/jdbc/PgConnection.java#L1317 Jorge Solórzano me.jorsol.com On Thu, Jan 19, 2017 at 3:57 PM, Tom Lane wrote: > =?UTF-8?Q?Jorge_Sol=C3=B3rzano?= writes: > > After many tries

Re: [HACKERS] Implement targetlist SRFs using ROWS FROM() (was Changed SRF in targetlist handling)

Andres Freund writes: > Maybe we ought to remove the paranoia bit about retset > though - it's not paranoia if it has an effect. Exactly, and I already did that in my version. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To ma

Re: [HACKERS] delta relations in AFTER triggers

On Sat, Dec 17, 2016 at 08:15:49PM -0600, Kevin Grittner wrote: > On Sun, Dec 4, 2016 at 11:35 PM, Haribabu Kommi > wrote: > > Moved to next CF with "waiting on author" status. > > [...] I hope what I've done about delta relations will be mostly irrelevant given your patch (which I've not looked

Re: [HACKERS] Causal reads take II

On Fri, Jan 20, 2017 at 3:01 AM, Ants Aasma wrote: > Yes there is a race even with all transactions having the same > synchronization level. But nobody will mind if we some day fix that > race. :) We really should fix that! > With different synchronization levels it is much trickier to > fix as

Re: [HACKERS] Parallel Index Scans

On Wed, Jan 18, 2017 at 8:03 AM, Amit Kapila wrote: >> Why do we need separate AM support for index_parallelrescan()? Why >> can't index_rescan() cover that case? > > The reason is that sometime index_rescan is called when we have to > just update runtime scankeys in index and we don't want to re

Re: [HACKERS] Implement targetlist SRFs using ROWS FROM() (was Changed SRF in targetlist handling)

On 2017-01-19 13:06:20 -0500, Tom Lane wrote: > Andres Freund writes: > > On 2017-01-18 16:56:46 -0500, Tom Lane wrote: > >> Andres Freund writes: > >> I have not actually looked at 0003 at all yet. So yeah, please post > >> for review after you're done rebasing. > > > Here's a rebased and light

Re: [HACKERS] [JDBC] SEGFAULT in HEAD with replication

=?UTF-8?Q?Jorge_Sol=C3=B3rzano?= writes: > After many tries I get this: > #0 0x00836950 in exec_bind_message (input_message=0x7ffce81048a0) > at postgres.c:1562 Hmm ... that line was last touched by ab1f0c822, so I'm betting that I broke it somehow, but I'm not sure how. It looks like S

Re: [HACKERS] Improving RLS planning

Andreas Seltenreich writes: > sqlsmith doesn't seem to like 215b43cdc: > select 1 from information_schema.usage_privileges > where information_schema._pg_keysequal( >(select null::smallint[]), >'{16,25,23}'); > -- TRAP: FailedAssertion("!(!and_clause((Node *) clause))", File: > "restric

Re: [HACKERS] [PATCH] Fix minor race in commit_ts SLRU truncation vs lookups

On 1/19/17 10:06 AM, Alvaro Herrera wrote: >> Also, I wonder whether we should not in vacuum.c change the order of the >> calls of SetTransactionIdLimit() and SetMultiXactIdLimit() as well, just >> to keep everything consistent. > > I am wary of doing that. The current coding is well battle-teste

Re: [HACKERS] [JDBC] SEGFAULT in HEAD with replication

After many tries I get this: #0 0x00836950 in exec_bind_message (input_message=0x7ffce81048a0) at postgres.c:1562 #1 0x0083a23d in PostgresMain (argc=1, argv=0x2bd93d8, dbname=0x2bd9130 "test", username=0x2bd9110 "test") at postgres.c:4113 #2 0x007aacd4 in BackendRun (po

Re: [HACKERS] [PATCH] Fix minor race in commit_ts SLRU truncation vs lookups

Peter Eisentraut wrote: > On 12/29/16 4:28 AM, Craig Ringer wrote: > > On 29 December 2016 at 16:51, Craig Ringer wrote: > >> On 28 December 2016 at 22:16, Petr Jelinek > >> wrote: > >> > >>> About the patch, it looks good to me for master with the minor exception > >>> that: > +

Re: [HACKERS] Improving RLS planning

Tom Lane writes: > Thanks for reviewing --- I'll do something with that test case and > push it. sqlsmith doesn't seem to like 215b43cdc: select 1 from information_schema.usage_privileges where information_schema._pg_keysequal( (select null::smallint[]), '{16,25,23}'); -- TRAP: FailedAsse

Re: [HACKERS] delta relations in AFTER triggers

Attached is v9 which fixes bitrot from v8. No other changes. Still needs review. -- Kevin Grittner EDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company transition-v9.diff.gz Description: GNU Zip compressed data -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.o

Re: [HACKERS] SERIALIZABLE on standby servers

On Wed, Nov 16, 2016 at 9:26 AM, Thomas Munro wrote: > On Tue, Nov 8, 2016 at 5:56 PM, Thomas Munro > wrote: > [..] Another solution > could be to have recovery on the standby detect tokens (CSNs > incremented by PreCommit_CheckForSerializationFailure) arriving out of > order, but I don't know w

Re: [HACKERS] pgbench - allow backslash continuations in \set expressions

Rafia Sabih writes: > Okay, I am marking it as 'Ready for committer' with the following note > to committer, > I am getting whitespace errors in v3 of patch, which I corrected in > v4, however, Fabien is of the opinion that v3 is clean and is showing > whitespace errors because of downloader, etc.

Re: [HACKERS] [JDBC] SEGFAULT in HEAD with replication

Not sure you can get the exec. We are working on producing the BT from Travis-CI or I will build and run the test locally and get the trace Dave Cramer On 19 January 2017 at 15:31, Craig Ringer wrote: > > > On 20 Jan. 2017 04:13, "Robert Haas" wrote: > > On Thu, Jan 19, 2017 at 12:09 PM, Dave

Re: [HACKERS] [JDBC] SEGFAULT in HEAD with replication

On 20 Jan. 2017 04:13, "Robert Haas" wrote: On Thu, Jan 19, 2017 at 12:09 PM, Dave Cramer wrote: > I would have expected more, but this is what I have > > bt full > #0 InitPredicateLocks () at predicate.c:1250 > i = > info = {num_partitions = 1, ssize = 140731424825288, dsize

[HACKERS] [PATCH] Change missleading comment for tm_mon field of pg_tm structure

According to usages, tm_mon (month) field has origin 1, not 0. This is difference from C-library version of struct tm, which has origin 0 for real. For example: ```C if (DateOrder == DATEORDER_DMY) sprintf(str, "%02d/%02d", tm->tm_mday, tm->tm_mon); else sprintf(str, "%02d/%02d", tm->tm_mo

Re: [HACKERS] Parallel Index Scans

On Thu, Jan 19, 2017 at 4:26 AM, Amit Kapila wrote: > Fixed. I think that the whole idea of GatherSupportsBackwardScan is wrong. Gather doesn't support a backwards scan under any circumstances, whether the underlying node does or not. You can read the tuples once, in order, and you can't back up

Re: [HACKERS] Declarative partitioning - another take

On Thu, Jan 19, 2017 at 12:15 AM, Amit Langote wrote: > 0001-Fix-a-bug-of-insertion-into-an-internal-partition.patch > > Since implicit partition constraints are not inherited, an internal > partition's constraint was not being enforced when targeted directly. > So, include such constraint when se

Re: [HACKERS] Too many autovacuum workers spawned during forced auto-vacuum

Robert Haas wrote: > After sleeping on this, I'm inclined to go with Amit's fix for now. > It seems less likely to break anything in the back-branches than any > other option I can think up. Yeah, no objections here. Note typo "imporatant" in the comment. -- Álvaro Herrerahttps

Re: [HACKERS] [PATCH] Fix minor race in commit_ts SLRU truncation vs lookups

Robert Haas wrote: > On Thu, Jan 19, 2017 at 10:06 AM, Alvaro Herrera > wrote: > > Peter Eisentraut wrote: > > > >> Also, I wonder whether we should not in vacuum.c change the order of the > >> calls of SetTransactionIdLimit() and SetMultiXactIdLimit() as well, just > >> to keep everything consist

Re: [HACKERS] Patch to implement pg_current_logfile() function

On Thu, 19 Jan 2017 12:12:18 -0300 Alvaro Herrera wrote: > Karl O. Pinc wrote: > > On Wed, 18 Jan 2017 19:27:40 -0300 > > Alvaro Herrera wrote: > > > > I thought this part was odd -- I mean, why is SysLogger_Start() > > > being called if the collector is not enabled? Turns out we do it > > >

Re: [HACKERS] Logical Replication WIP - FailedAssertion, File: "array_typanalyze.c", Line: 340

On 2017-01-19 19:12, Petr Jelinek wrote: On 19/01/17 18:44, Erik Rijkers wrote: Could probably be whittled down to something shorter but I hope it's still easily reproduced. Just analyze on the pg_subscription is enough. heh. Ah well, I did find it :) Can you give the current patch set?

Re: [HACKERS] Logical Replication WIP - FailedAssertion, File: "array_typanalyze.c", Line: 340

On 19/01/17 18:44, Erik Rijkers wrote: > > Could probably be whittled down to something shorter but I hope it's > still easily reproduced. > Just analyze on the pg_subscription is enough. Looks like it's the name[] type, when I change it to text[] like in the attached patch it works fine for me.

Re: [HACKERS] Implement targetlist SRFs using ROWS FROM() (was Changed SRF in targetlist handling)

Andres Freund writes: > On 2017-01-18 16:56:46 -0500, Tom Lane wrote: >> Andres Freund writes: >> I have not actually looked at 0003 at all yet. So yeah, please post >> for review after you're done rebasing. > Here's a rebased and lightly massaged version. I've read through this and made some

Re: [HACKERS] pg_background contrib module proposal

The following review has been posted through the commitfest application: make installcheck-world: tested, passed Implements feature: tested, passed Spec compliant: tested, passed Documentation:tested, failed I’ll summarize here my thoughts as a reviewer on the current

Re: [HACKERS] Logical Replication WIP - FailedAssertion, File: "array_typanalyze.c", Line: 340

On 2017-01-19 01:02, Petr Jelinek wrote: This causes the replica to crash: #-- #!/bin/bash # 2 instances on 6972 (master) and 6973 (replica) # initially without publication or subscription # clean logs #echo > /var/data1/pg_stuff/pg_installations/pgsql.logical_replication/logfile.

Re: [HACKERS] [JDBC] SEGFAULT in HEAD with replication

On Thu, Jan 19, 2017 at 12:09 PM, Dave Cramer wrote: > I would have expected more, but this is what I have > > bt full > #0 InitPredicateLocks () at predicate.c:1250 > i = > info = {num_partitions = 1, ssize = 140731424825288, dsize = 1, > max_dsize = 0, ffactor = 1407

Re: [HACKERS] [JDBC] SEGFAULT in HEAD with replication

I would have expected more, but this is what I have bt full #0 InitPredicateLocks () at predicate.c:1250 i = info = {num_partitions = 1, ssize = 140731424825288, dsize = 1, max_dsize = 0, ffactor = 140731424836952, keysize = 140356326474085, entrysize = 14072

Re: [HACKERS] [JDBC] SEGFAULT in HEAD with replication

On Thu, Jan 19, 2017 at 12:01 PM, Jorge Solórzano wrote: > Robert, the logs I get from postgres (at least the section that matters) is > here: > If you need something else just ask... That shows that there is a crash, but there's no stack trace in there. Someone needs to get a core dump and use "

Re: [HACKERS] postgres_fdw bug in 9.6

On Wed, Jan 18, 2017 at 10:26 PM, Ashutosh Bapat wrote: >> Yes, I think that's broadly the approach Tom was recommending. > > I don't have problem with that approach, but the latest patch has > following problems. > 1. We are copying chunks of path creation logic, instead of reusing > correspondin

Re: [HACKERS] [JDBC] SEGFAULT in HEAD with replication

I'll try to get the stack trace from the core dump, have to build master first Dave Cramer On 19 January 2017 at 12:01, Jorge Solórzano wrote: > Robert, the logs I get from postgres (at least the section that matters) > is here: > If you need something else just ask... > > 2017-01-19 08:54:57.3

Re: [HACKERS] [JDBC] SEGFAULT in HEAD with replication

Robert, the logs I get from postgres (at least the section that matters) is here: If you need something else just ask... 2017-01-19 08:54:57.319 CST [31734] DEBUG: CommitTransaction(1) name: > unnamed; blockState: STARTED; state: INPROGR, xid/subid/cid: 0/1/0 > 2017-01-19 08:54:57.321 CST [31734]

Re: [HACKERS] [COMMITTERS] pgsql: Generate fmgr prototypes automatically

Peter Eisentraut writes: > Here is a patch that moves two blocks from builtins.h into separate > header files. That avoids having to include nodes/pg_list.h and > utils/sortsupport.h. Seems like a reasonable solution. > The remaining inclusion of nodes/nodes.h is for the oidparse() function. >

Re: [HACKERS] [JDBC] SEGFAULT in HEAD with replication

On Thu, Jan 19, 2017 at 10:59 AM, Jorge Solórzano wrote: > I have isolated the tests run by the pgjdbc project, I have disabled the > replication (wal_level = minimal) and the error is still present so it seems > that this error is not related to the replication, the test that cause the > error is

Re: [HACKERS] [PATCH] Fix minor race in commit_ts SLRU truncation vs lookups

On Thu, Jan 19, 2017 at 10:06 AM, Alvaro Herrera wrote: > Peter Eisentraut wrote: > >> Also, I wonder whether we should not in vacuum.c change the order of the >> calls of SetTransactionIdLimit() and SetMultiXactIdLimit() as well, just >> to keep everything consistent. > > I am wary of doing that.

Re: [HACKERS] Too many autovacuum workers spawned during forced auto-vacuum

On Tue, Jan 17, 2017 at 4:02 PM, Robert Haas wrote: > Amit's chosen yet another possible place to insert the guard: teach > autovacuum that if a worker skips at least one table due to concurrent > autovacuum activity AND ends up vacuuming no tables, don't call > vac_update_datfrozenxid(). Since t

Re: [HACKERS] [COMMITTERS] pgsql: Add pg_sequence system catalog

Peter, * Peter Eisentraut (pete...@gmx.net) wrote: > Add pg_sequence system catalog The query this added to dumpSequence() seems to think that sequence names are unique across databases: appendPQExpBuffer(query, "SELECT seqstart, seqincrement, " "CASE WHEN seq

Re: [HACKERS] [JDBC] SEGFAULT in HEAD with replication

I have isolated the tests run by the pgjdbc project, I have disabled the replication (wal_level = minimal) and the error is still present so it seems that this error is not related to the replication, the test that cause the error is AutoRollbackTestSuite, I have enable DEBUG mesages in postgresql

Re: [HACKERS] increasing the default WAL segment size

On Wed, Jan 18, 2017 at 12:42 PM, Robert Haas wrote: > Problems 2-4 actually have to do with a DestReceiver of type > DestRemote really, really wanting to have an associated Portal and > database connection, so one approach is to create a stripped-down > DestReceiver that doesn't care about those

Re: [HACKERS] ISO/IEC 9075-2:2016 for postgres community

Wolfgang Wilhelm wrote: > are you looking for something like this: > jtc1sc32.org/doc/N2301-2350/32N2311T-text_for_ballot-CD_9075-2.pdf ? That looks like it is from 2013... Yours, Laurenz Albe -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscrip

Re: [HACKERS] ISO/IEC 9075-2:2016 for postgres community

On 1/19/17 10:03 AM, Wolfgang Wilhelm wrote: > are you looking for something like this: > jtc1sc32.org/doc/N2301-2350/32N2311T-text_for_ballot-CD_9075-2.pdf ? That's not very recent. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, T

Re: [HACKERS] Patch to implement pg_current_logfile() function

Karl O. Pinc wrote: > On Wed, 18 Jan 2017 19:27:40 -0300 > Alvaro Herrera wrote: > > I thought this part was odd -- I mean, why is SysLogger_Start() being > > called if the collector is not enabled? Turns out we do it and return > > early if not enabled. But not in all cases -- there is one cal

Re: [HACKERS] Patch to implement pg_current_logfile() function

On Wed, 18 Jan 2017 19:27:40 -0300 Alvaro Herrera wrote: > Karl O. Pinc wrote: > > > @@ -511,10 +519,16 @@ int > > SysLogger_Start(void) > > { > > pid_t sysloggerPid; > > - char *filename; > > > > + /* > > +* Logging collector is not enabled. We don't know where >

Re: [HACKERS] Re: Clarifying "server starting" messaging in pg_ctl start without --wait

* Peter Eisentraut (peter.eisentr...@2ndquadrant.com) wrote: > On 1/19/17 9:53 AM, Stephen Frost wrote: > > Sure, but we're talking about replaying WAL vs. doing a checkpoint, not > > about writing WAL vs. replaying WAL. Replaying WAL and doing a > > checkpoint both require writing to lots of diff

Re: [HACKERS] [PATCH] Fix minor race in commit_ts SLRU truncation vs lookups

Peter Eisentraut wrote: > Also, I wonder whether we should not in vacuum.c change the order of the > calls of SetTransactionIdLimit() and SetMultiXactIdLimit() as well, just > to keep everything consistent. I am wary of doing that. The current coding is well battle-tested by now, but doing thing

Re: [HACKERS] ISO/IEC 9075-2:2016 for postgres community

Hi, are you looking for something like this: jtc1sc32.org/doc/N2301-2350/32N2311T-text_for_ballot-CD_9075-2.pdf ? Kind Regards, Wolfgang Oleg Bartunov schrieb am 16:39 Dienstag, 17.Januar 2017: On Tue, Jan 17, 2017 at 6:26 PM, Alvaro Herrera wrote: Oleg Bartunov wrote: > Hi there,

Re: [HACKERS] Re: Clarifying "server starting" messaging in pg_ctl start without --wait

On 1/18/17 3:47 PM, Robert Haas wrote: > Anybody who has got a script that runs pg_ctl unattended mode likely > now has to go update that script to add --no-wait. The state of init scripts and other start scripts out there is such a mess, it's hard to make general statements like this. Many start

Re: [HACKERS] Re: Clarifying "server starting" messaging in pg_ctl start without --wait

Peter, * Peter Eisentraut (peter.eisentr...@2ndquadrant.com) wrote: > On 1/18/17 3:12 PM, Stephen Frost wrote: > > I don't understand what I'm missing when it comes to checkpoint_timeout > > and the time required to recover from a crash. You aren't the first > > person to question that associatio

Re: [HACKERS] Re: Clarifying "server starting" messaging in pg_ctl start without --wait

On 1/19/17 9:53 AM, Stephen Frost wrote: > Sure, but we're talking about replaying WAL vs. doing a checkpoint, not > about writing WAL vs. replaying WAL. Replaying WAL and doing a > checkpoint both require writing to lots of different places across the > filesystem, of course. Yeah, but they are

Re: [HACKERS] Re: Clarifying "server starting" messaging in pg_ctl start without --wait

* Peter Eisentraut (peter.eisentr...@2ndquadrant.com) wrote: > On 1/18/17 3:47 PM, Robert Haas wrote: > > Anybody who has got a script that runs pg_ctl unattended mode likely > > now has to go update that script to add --no-wait. > > The state of init scripts and other start scripts out there is s

Re: [HACKERS] [JDBC] SEGFAULT in HEAD with replication

Core dump was extracted from this build https://travis-ci.org/Gordiychuk/pgjdbc/builds/193318018 2017-01-19 17:38 GMT+03:00 Vladimir Gordiychuk : > Last success build from postgresql HEAD was 20 days ago > https://travis-ci.org/pgjdbc/pgjdbc/builds/187764274 > We detect this problem 3 days ago.

Re: [HACKERS] [JDBC] SEGFAULT in HEAD with replication

Last success build from postgresql HEAD was 20 days ago https://travis-ci.org/pgjdbc/pgjdbc/builds/187764274 We detect this problem 3 days ago. 2017-01-19 17:22 GMT+03:00 Dave Cramer : > The travis job https://travis-ci.org/pgjdbc/pgjdbc/jobs/192517342 is > seeing a segfault when we are testing a

Re: [HACKERS] Re: Clarifying "server starting" messaging in pg_ctl start without --wait

On 1/18/17 3:12 PM, Stephen Frost wrote: > I don't understand what I'm missing when it comes to checkpoint_timeout > and the time required to recover from a crash. You aren't the first > person to question that association, but it seems pretty clear to me. > > When doing recovery, we have to repl

Re: [HACKERS] [COMMITTERS] pgsql: Generate fmgr prototypes automatically

On 1/17/17 3:07 PM, Tom Lane wrote: > Alternatively ... is there a specific reason why you chose to make > builtins.h the key inclusion file for this change, rather than having > callers include fmgrprotos.h directly? It seems like the stuff remaining > in builtins.h is just a laundry list of rand

[HACKERS] SEGFAULT in HEAD with replication

The travis job https://travis-ci.org/pgjdbc/pgjdbc/jobs/192517342 is seeing a segfault when we are testing against HEAD with REPLICATION turned on. Logs can be found here https://drive.google.com/drive/folders/0B-Heg5ZYCWbreEE4Uk5LdnJ5eWM?usp=sharing Regards, Dave Cramer

[HACKERS] comment ends in the middle of a

ProcessStartupPacket() in src/backend/postmaster/postmaster.c contains the following comment: /* * Due to backward compatibility concerns the replication * parameter is a hybrid beast which allows the

Re: [HACKERS] How to extract bytes from a bit/bit(n) Datum pointer?

Thank you Ashutosh! I've been looking everywhere for this info -- View this message in context: http://postgresql.nabble.com/How-to-extract-bytes-from-a-bit-bit-n-Datum-pointer-tp5939776p5939811.html Sent from the PostgreSQL - hackers mailing list archive at Nabble.com. -- Sent via pgsql-ha

Re: [HACKERS] PoC: Grouped base relation

> >> Yes, it's hard, but I think without having a separate RelOptInfo the >> design won't be complete. Is there a subset of problem that can be >> solved by using a separate RelOptInfo e.g. pushing aggregates down >> child relations or anything else. > > I'm still not convinced that all the fields

Re: [HACKERS] Causal reads take II

On Thu, Jan 19, 2017 at 2:22 PM, Thomas Munro wrote: > On Thu, Jan 19, 2017 at 8:11 PM, Ants Aasma wrote: >> On Tue, Jan 3, 2017 at 3:43 AM, Thomas Munro >> wrote: >>> Long term, I think it would be pretty cool if we could develop a set >>> of features that give you distributed sequential consis

Re: [HACKERS] Microvacuum support for Hash Index

Hi Ashutosh, On 01/10/2017 08:40 AM, Jesper Pedersen wrote: On 01/10/2017 05:24 AM, Ashutosh Sharma wrote: Thanks for reporting this problem. It is basically coming because i forgot to unpin the bucketbuf in hash_xlog_vacuum_one_page(). Please find the attached v5 patch that fixes the issue.

[HACKERS] Fix documentation typo

Hi, Here is a patch that adds temporary column's description to pg_replication_slots document. Regards, -- Ayumi Ishii fix_document_typo.patch Description: Binary data -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgr

Re: [HACKERS] Patch to implement pg_current_logfile() function

On Thu, 19 Jan 2017 16:59:10 +0900 Michael Paquier wrote: > On Thu, Jan 19, 2017 at 7:27 AM, Alvaro Herrera > wrote: > > I don't think the "abstract names" stuff is an improvement (just > > look at the quoting mess in ConfigureNamesString). I think we > > should do without that; at least as pa

Re: [HACKERS] Patch: Write Amplification Reduction Method (WARM)

Hi Alvaro, On Tue, Jan 17, 2017 at 8:41 PM, Alvaro Herrera wrote: > Reading through the track_root_lp patch now. > > Thanks for the review. > > + /* > > + * For HOT (or WARM) updated tuples, we store the offset > of the root > > + * line pointer of this ch

Re: [HACKERS] PoC: Grouped base relation

Ashutosh Bapat wrote: > >> 1. Pushing down aggregates/groups down join tree, so that the number of > >> rows > >> to be joined decreases. This might be a good optimization to have. However > >> there are problems in the current patch. Every path built for a relation > >> (join or base) returns

Re: [HACKERS] Review: GIN non-intrusive vacuum of posting tree

Hi, Jeff! Thanks for review! Here's a patch corrected according to your suggestions. 2017-01-19 11:48 GMT+05:00 Jeff Davis : > https://www.postgresql.org/message-id/CAJEAwVE4UAmm8fr%2BNW8XTnKV6M--ACoNhL3ES8yoKL2sKhbaiw%40mail.gmail.com > > Let me re-summarize what's been done here to make sure I

Re: [HACKERS] How to extract bytes from a bit/bit(n) Datum pointer?

On Thu, Jan 19, 2017 at 5:53 PM, valeriof wrote: > Hi, > > This may come from my lack of experience with Postgres, but I'm trying to > extract the byte portion of a Datum that is of type VarBit - bit/bit(n). I > see that the Datum pointer contains the value content of the bytes (after a > few byte

Re: [HACKERS] patch: function xmltable

2017-01-19 13:35 GMT+01:00 Alvaro Herrera : > Pavel Stehule wrote: > > Hi > > > > New update - rebase after yesterday changes. > > > > What you want to change? > > I think the problem might come from the still pending patch on that > series, which Andres posted in > https://www.postgresql.org/mess

  1   2   >