Re: [HACKERS] path toward faster partition pruning

On 10 January 2018 at 17:18, David Rowley wrote: > Basically, the changes to add_paths_to_append_rel() are causing > duplication in partition_rels. > > A test case is: > > create table part (a int, b int) partition by list(a); > create table part1 partition of part

Re: [Sender Address Forgery]Re: [HACKERS] path toward faster partition pruning

On 12 January 2018 at 22:51, Amit Langote wrote: > On 2018/01/12 18:09, David Rowley wrote: >> On 10 January 2018 at 17:18, David Rowley >> wrote: >>> Basically, the changes to add_paths_to_append_rel() are causing >>> duplication in

Re: Enhance pg_stat_wal_receiver view to display connected host

On Fri, Jan 12, 2018 at 04:32:54PM +1100, Haribabu Kommi wrote: > On Fri, Jan 12, 2018 at 4:06 PM, Michael Paquier > wrote: > > On Fri, Jan 12, 2018 at 03:55:04PM +1100, Haribabu Kommi wrote: > > > Before posting the patch, first I did the same, upon further study > > >

Re: CREATE ROUTINE MAPPING

2018-01-12 10:02 GMT+01:00 Ashutosh Bapat : > On Fri, Jan 12, 2018 at 8:07 AM, Corey Huinker > wrote: > > A few months ago, I was researching ways for formalizing calling > functions > > on one postgres instance from another. RPC,

Re: [Sender Address Forgery]Re: [HACKERS] path toward faster partition pruning

Hi. On 2018/01/12 18:09, David Rowley wrote: > On 10 January 2018 at 17:18, David Rowley > wrote: >> Basically, the changes to add_paths_to_append_rel() are causing >> duplication in partition_rels. [ ... ] > I also noticed earlier that this is still broken in

Re: master make check fails on Solaris 10

On 11-01-2018 20:39, Andres Freund wrote: Hi, On 2018-01-11 20:21:11 +0300, Marina Polyakova wrote: Hello, hackers! I got a permanent failure of master (commit ca454b9bd34c75995eda4d07c9858f7c22890c2b) make check on Solaris 10. Did this use to work? It always fails if you have asked about

Re: Changing WAL Header to reduce contention during ReserveXLogInsertLocation()

Hi Simon, Pavan, I tried benchmarking your patch. I ran pgbench on a 72-core machine with a simple append-only script: BEGIN; INSERT INTO pgbench_history (tid, bid, aid, delta, mtime) VALUES (:tid, :bid, :aid, :delta, CURRENT_TIMESTAMP); the insert repeated 20 times total --- END;

Re: WIP Patch: Pgbench Serialization and deadlock errors

Hello Marina, A partial answer, to focus on how the feature may be simplified. I apologise as it seems that I overlooked one of your mail. Changing the thread has not helped. I'm wondering whether the whole feature could be simplified by considering that one script is one "transaction" (it

Re: General purpose hashing func in pgbench

Hello Fabien, 11/01/2018 19:21, Ildar Musin пишет: > > 10/01/2018 21:42, Fabien COELHO пишет: >> Hmm. I do not think that we should want a shared seed value. The seed >> should be different for each call so as to avoid undesired >> correlations. If wanted, correlation could be obtained by using

Re: [HACKERS] Re: proposal - psql: possibility to specify sort for describe commands, when size is printed

Hi 2018-01-12 2:35 GMT+01:00 Thomas Munro : > On Thu, Nov 2, 2017 at 12:44 AM, Pavel Stehule > wrote: > > I am sending updated patch with some basic doc > > Hi Pavel, > > I am not sure what the status of this patch is, but FYI: > >

Re: Changing WAL Header to reduce contention during ReserveXLogInsertLocation()

Robert Haas writes: > On Sat, Dec 30, 2017 at 5:32 AM, Simon Riggs wrote: >> So we can't completely remove xl_prev field, without giving up some >> functionality. But we don't really need to store the 8-byte previous >> WAL pointer in order to detect

Re: [HACKERS] PoC: custom signal handler for extensions

In perspective, this mechanism provides the low-level instrument to define remote procedure call on extension side. The simple RPC that defines effective userid on remote backend (remote_effective_user function) is attached for example. Suppose, it's useful patch. Some notes: 1)

Re: WIP: a way forward on bootstrap data

Pushed 0001 with some changes of my own. I'm afraid I created a few conflicts for the later patches in your series; please rebase. I don't think we introduced anything that would fail on old Perls, but let's see what buildfarm has to say. Others: Now is the time to raise concerns related to the

Re: Changing WAL Header to reduce contention during ReserveXLogInsertLocation()

On Sat, Dec 30, 2017 at 5:32 AM, Simon Riggs wrote: > So we can't completely remove xl_prev field, without giving up some > functionality. But we don't really need to store the 8-byte previous > WAL pointer in order to detect torn pages. Something else which can > tell us

Re: Changing WAL Header to reduce contention during ReserveXLogInsertLocation()

I wrote: > Robert Haas writes: >> On Sat, Dec 30, 2017 at 5:32 AM, Simon Riggs wrote: >>> For this to work, we must ensure that WAL files are either recycled in >>> such a way that the "xl_walid" of the previous (to be recycled) WAL >>> differs from

Re: CREATE ROUTINE MAPPING

> > PostgreSQL allows function overloading, which means that there can be > multiple functions with same name differing in argument types. So, the > syntax has to include the input parameters or their types at least. > "local_routine_name" and "remote_routine_spec" were my own paraphrasings of

Re: WIP: a way forward on bootstrap data

Alvaro Herrera writes: > Others: Now is the time to raise concerns related to the proposed file > formats and tooling, so please do have a look when you have a moment. > At this stage, the proposed data format seems a good choice to me. It's not very clear to me what the

Re: WIP: a way forward on bootstrap data

On Fri, Jan 12, 2018 at 11:38:54AM -0500, Tom Lane wrote: > Alvaro Herrera writes: > > Others: Now is the time to raise concerns related to the proposed > > file formats and tooling, so please do have a look when you have a > > moment. At this stage, the proposed data

Re: [HACKERS] Proposal: Local indexes for partitioned table

On 1/11/18 13:52, Alvaro Herrera wrote: > The delta patch turned out to have at least one stupid bug, and a few > non-stupid bugs. Here's an updated version that should behave > correctly, and addresses all reported problems. It seems that CompareIndexInfo() still doesn't compare indexes'

Re: [HACKERS] UPDATE of partition key

On Fri, Jan 12, 2018 at 5:12 AM, Amit Khandekar wrote: > The reason why I am having map_required field inside a structure along > with the map, as against a separate array, is so that we can do the > on-demand allocation for both per-leaf array and per-subplan array.

[PATCH] Find additional connection service files in pg_service.conf.d directory

I love centralizing connection service definitions in /pg_service.conf, but for a large enterprise, sometimes we have multiple sets of connection service definitions independently managed. The convention widely adopted for this type of thing is to allow multiple config files to be in a directory,

Re: pgbench - add \if support

Hi! Hm, isn't already commited when/case/then/else syntax do the same? If not, could it be added to existing synax? Fabien COELHO wrote: Here is a rebase. I made some tests use actual expressions instead of just 0 and 1. No other changes. Sigh. Better with the attachment. Sorry for the

Re: PATCH: logical_work_mem and logical streaming of large in-progress transactions

On 1/11/18 18:23, Greg Stark wrote: > AIUI spilling to disk doesn't affect absorbing future updates, we > would just keep accumulating them in memory right? We won't need to > unspill until it comes time to commit. Once a transaction has been serialized, future updates keep accumulating in

Re: Doc tweak for huge_pages?

On 12/1/17 10:08, Peter Eisentraut wrote: > Part of the confusion is that the huge_pages setting is only for shared > memory, whereas the kernel settings affect all memory. Is the same true > for the proposed Windows patch? Btw., I'm kind of hoping that the Windows patch would be committed

Re: WIP Patch: Pgbench Serialization and deadlock errors

Hello Marina, If you want 2 transactions, then you have to put them in two scripts, which looks fine with me. Different transactions are expected to be independent, otherwise they should be merged into one transaction. Therefore if the script consists of several single statements (= several

Re: Possible performance regression with pg_dump of a large number of relations

> On Jan 12, 2018, at 8:01 AM, Jeff Janes wrote: > > On Thu, Jan 11, 2018 at 5:26 PM, Luke Cowell > wrote: > I've been troubleshooting an issue with slow pg_dump times on postgres 9.6.6. > I believe something changed between

Re: Possible performance regression with pg_dump of a large number of relations

On Thu, Jan 11, 2018 at 5:26 PM, Luke Cowell wrote: > I've been troubleshooting an issue with slow pg_dump times on postgres > 9.6.6. I believe something changed between 9.5.10 and 9.6.6 that has made > dumps significantly slower for databases with a large number of relations.

Re: improve type conversion of SPI_processed in Python

Peter Eisentraut writes: > On 1/9/18 15:54, Tom Lane wrote: >> I'd be inclined to code PLyObject_FromUint64() as an exact >> analog of PLyLong_FromInt64(), ie >> >> /* on 32 bit platforms "unsigned long" may be too small */ >> if (sizeof(uint64) >

Re: General purpose hashing func in pgbench

Hello Ildar, Hmm. I do not think that we should want a shared seed value. The seed should be different for each call so as to avoid undesired correlations. If wanted, correlation could be obtained by using an explicit identical seed. Probably I'm missing something but I cannot see the point.

Re: master make check fails on Solaris 10

On 12-01-2018 18:12, Alvaro Herrera wrote: Marina Polyakova wrote: - on the previous commit (272c2ab9fd0a604e3200030b1ea26fd464c44935) the same failures occur (see the attached regression diffs and output); - on commit bf54c0f05c0a58db17627724a83e1b6d4ec2712c make check-world passes. I'll try

Re: master make check fails on Solaris 10

Marina Polyakova wrote: > - on the previous commit (272c2ab9fd0a604e3200030b1ea26fd464c44935) the same > failures occur (see the attached regression diffs and output); > - on commit bf54c0f05c0a58db17627724a83e1b6d4ec2712c make check-world > passes. > I'll try to find out from what commit it

Re: Jsonb transform for pl/python

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, passed LGTM. The new status of this patch is: Ready for Committer

Re: [HACKERS] Parallel tuplesort (for parallel B-Tree index creation)

On Thu, Jan 11, 2018 at 8:58 PM, Peter Geoghegan wrote: > I've caught up with you again. I just need to take a look at what I > came up with with fresh eyes, and maybe do some more testing. More comments: BufFileView() looks fairly pointless. It basically creates a copy of the

Re: CREATE ROUTINE MAPPING

On Fri, Jan 12, 2018 at 11:11:26AM -0500, Corey Huinker wrote: > > > > PostgreSQL allows function overloading, which means that there can > > be multiple functions with same name differing in argument types. > > So, the syntax has to include the input parameters or their types > > at least. > >

Re: [HACKERS] GSoC 2017: Foreign Key Arrays

Mark Rofail wrote: > > 1) MATCH FULL does not seem to care about NULLS in arrays. In the example > > below I expected both inserts into the referring table to fail. > > > > CREATE TABLE t (x int, y int, PRIMARY KEY (x, y)); > > CREATE TABLE fk (x int, ys int[], FOREIGN KEY (x, EACH ELEMENT OF ys)

Re: master make check fails on Solaris 10

Marina Polyakova writes: > On 12-01-2018 14:05, Marina Polyakova wrote: >> - on the previous commit (272c2ab9fd0a604e3200030b1ea26fd464c44935) >> the same failures occur (see the attached regression diffs and >> output); >> - on commit

Re: pgbench - add \if support

Hm, isn't already commited when/case/then/else syntax do the same? No, not strictly. The "CASE WHEN" is an if *within* an expression: \set i CASE WHEN condition THEN val1 ELSE val2 END The \if is at the script level, like psql already available version, which can change what SQL is sent.

Re: [HACKERS] GSoC 2017: Foreign Key Arrays

Here's a rebased version of this patch. I have done nothing other than fix the conflicts and verify that it passes existing regression tests. I intend to go over the reviews sometime later and hopefully get it all fixed for inclusion in pg11. -- Álvaro Herrera

Re: WIP: a way forward on bootstrap data

Tom Lane wrote: > Alvaro Herrera writes: > > Others: Now is the time to raise concerns related to the proposed file > > formats and tooling, so please do have a look when you have a moment. > > At this stage, the proposed data format seems a good choice to me. > > It's

Re: [HACKERS] UPDATE of partition key

On 12 January 2018 at 20:24, Robert Haas wrote: > On Fri, Jan 12, 2018 at 5:12 AM, Amit Khandekar > wrote: >> The reason why I am having map_required field inside a structure along >> with the map, as against a separate array, is so that we can do

Re: Rangejoin rebased

Hi Jeff, Just a quick comment -- I ran a slightly modified version of a query from the regression tests, and got an assertion failure: select i1, ir1, i2, ir2   from (select * from rangejoin_left order by ir1 desc) as a1 inner join (select * from rangejoin_right order by ir2 desc) as a2    

Re: [HACKERS] GSoC 2017: Foreign Key Arrays

According to the last review, there are still two main issues with the patch. On Mon, Oct 30, 2017 at 3:24 AM, Andreas Karlsson wrote: > 1) MATCH FULL does not seem to care about NULLS in arrays. In the example > below I expected both inserts into the referring table to fail.

Re: WIP: a way forward on bootstrap data

Alvaro Herrera writes: > Tom Lane wrote: >> So could we have an explanation of what it is we're agreeing to? > Here's a small sample pg_proc entry: > { oid => '2147', descr => 'number of input rows for which the input > expression is not null', > n => 'count',

Re: [Sender Address Forgery]Re: [Sender Address Forgery]Re: [HACKERS] path toward faster partition pruning

On Thu, Jan 11, 2018 at 10:30 PM, David Rowley wrote: > Instead, can you make it: > > if (keys->n_eqkeys > 0 || keys->n_minkeys > 0 || > keys->n_maxkeys > 0 || n_keynullness > 0) > return true; > > return false; Or better yet: return (keys->n_eqkeys > 0 ||

Re: master make check fails on Solaris 10

On 12-01-2018 14:05, Marina Polyakova wrote: - on the previous commit (272c2ab9fd0a604e3200030b1ea26fd464c44935) the same failures occur (see the attached regression diffs and output); - on commit bf54c0f05c0a58db17627724a83e1b6d4ec2712c make check-world passes. I'll try to find out from what

Re: CREATE ROUTINE MAPPING

On Fri, Jan 12, 2018 at 02:29:53PM -0500, Corey Huinker wrote: > > > > > > > > It goes on from there, but I think there's a reasonable interpretation > > of this which allows us to use the same syntax as CREATE > > (FUNCTION|PROCEDURE), apart from the body, e.g.: > > > > CREATE ROUTINE MAPPING

Re: [HACKERS] Parallel tuplesort (for parallel B-Tree index creation)

On Fri, Jan 12, 2018 at 6:14 AM, Robert Haas wrote: > On Fri, Jan 12, 2018 at 8:19 AM, Amit Kapila wrote: >> 1. >> + if (!IsBootstrapProcessingMode() && !indexInfo->ii_Concurrent) >> { >> - snapshot = RegisterSnapshot(GetTransactionSnapshot());

Re: CREATE ROUTINE MAPPING

> > > > It goes on from there, but I think there's a reasonable interpretation > of this which allows us to use the same syntax as CREATE > (FUNCTION|PROCEDURE), apart from the body, e.g.: > > CREATE ROUTINE MAPPING local_routine_name > FOR (FUNCTION | PROCEDURE) remote_routine_name ( [ [ argmode

Re: WIP: a way forward on bootstrap data

On 1/12/18 12:24, Alvaro Herrera wrote: > Here's a small sample pg_proc entry: > > { oid => '2147', descr => 'number of input rows for which the input > expression is not null', > n => 'count', proisagg => 't', v => 'i', p => 's', rt => 'int8', at => > 'any', s => 'aggregate_dummy' }, > >

Re: WIP: a way forward on bootstrap data

On Fri, Jan 12, 2018 at 04:22:26PM -0500, Peter Eisentraut wrote: > On 1/12/18 12:24, Alvaro Herrera wrote: > > Here's a small sample pg_proc entry: > > > > { oid => '2147', descr => 'number of input rows for which the input > > expression is not null', > > n => 'count', proisagg => 't', v =>

Re: WIP: a way forward on bootstrap data

On 2018-01-12 18:36:14 -0300, Alvaro Herrera wrote: > As above -- do we really like our current format so much that we're > satisfied with minor tweaks? A definite no from here. I think especially pg_proc desperately needs something key=value like to be understandable, and that very clearly

Re: [HACKERS] PATCH: multivariate histograms and MCV lists

On 01/12/2018 01:48 AM, Thomas Munro wrote: > On Thu, Jan 4, 2018 at 1:12 PM, Tomas Vondra > wrote: >> Attached is an updated patch series, where the first patch fixes this by >> removing the reset of estimatedclauses (and tweaking the comment). > > Hi Tomas, > >

Re: Changing WAL Header to reduce contention during ReserveXLogInsertLocation()

Claudio Freire writes: > On Sat, Dec 30, 2017 at 7:32 AM, Simon Riggs wrote: >> So we can't completely remove xl_prev field, without giving up some >> functionality. > Or, you can use the lower 16-bits of the previous record's CRC Hmm ... that is

Re: [HACKERS] [BUGS] BUG #14825: enum type: unsafe use?

On Fri, Jan 12, 2018 at 5:06 PM, Andres Freund wrote: > OTOH, it seems quite likely that we'll add more transaction-lifetime > shared data (e.g. combocid), so building per-xact infrastructure > actually seems like a good idea. Sure, but there's no urgency about it.

Re: PATCH: logical_work_mem and logical streaming of large in-progress transactions

On 01/11/2018 08:41 PM, Peter Eisentraut wrote: > On 12/22/17 23:57, Tomas Vondra wrote: >> PART 1: adding logical_work_mem memory limit (0001) >> --- >> >> Currently, limiting the amount of memory consumed by logical decoding is >> tricky (or you

Re: [PROPOSAL] Shared Ispell dictionaries

Hi Arthur, I've done some initial review of the patch today, and here are some thoughts: 0001-Fix-ispell-memory-handling-v2.patch This makes sense. The patch simply replaces two cpstrdup() calls with MemoryContextStrdup, but I see spell.c already has two macros to allocate memory in the

Re: PATCH: logical_work_mem and logical streaming of large in-progress transactions

On 01/12/2018 05:35 PM, Peter Eisentraut wrote: > On 1/11/18 18:23, Greg Stark wrote: >> AIUI spilling to disk doesn't affect absorbing future updates, we >> would just keep accumulating them in memory right? We won't need to >> unspill until it comes time to commit. > > Once a transaction has

Re: Changing WAL Header to reduce contention during ReserveXLogInsertLocation()

On Fri, Jan 12, 2018 at 10:49 PM, Tom Lane wrote: > Claudio Freire writes: > > On Sat, Dec 30, 2017 at 7:32 AM, Simon Riggs > wrote: > >> So we can't completely remove xl_prev field, without giving up some > >> functionality. >

Re: [HACKERS] Planning counters in pg_stat_statements

I wrote: > Haribabu Kommi writes: >> I checked the latest patch and it is working fine and I don't have any >> further comments. Marked the patch as "ready for committer". > I started to look at this patch, ... looking further, I'm really seriously unhappy about this

Re: Possible performance regression with pg_dump of a large number of relations

Greetings Jeff & Luke, * Jeff Janes (jeff.ja...@gmail.com) wrote: > Sorry, that query reflects some munging I did to it. The real part added > to the query is: > > EXISTS (SELECT 1 FROM pg_attribute at LEFT JOIN pg_init_privs pip ON(c.oid > = pip.objoid AND pip.classoid = (SELECT oid FROM

Re: [HACKERS] Refactoring identifier checks to consistently use strcmp

> On 11 Jan 2018, at 09:01, Michael Paquier wrote: > > On Wed, Jan 10, 2018 at 11:49:47PM +0100, Daniel Gustafsson wrote: >>> On 08 Jan 2018, at 17:27, Robert Haas wrote: >>> nor has anyone taken the trouble to list with precision all of the >>>

Re: [HACKERS] postgres_fdw bug in 9.6

On Sun, Dec 3, 2017 at 2:56 PM, Tom Lane wrote: > I thought some more about this. While it seems clear that we don't > actually need to recheck anything within a postgres_fdw foreign join, > there's still a problem: we have to be able to regurgitate the join > row during

Re: Changing WAL Header to reduce contention during ReserveXLogInsertLocation()

On 2018-01-12 10:45:54 -0500, Tom Lane wrote: > Robert Haas writes: > > On Sat, Dec 30, 2017 at 5:32 AM, Simon Riggs wrote: > > I have some reservations about whether this makes the mechanism less > > reliable. > > Yeah, it scares me too. Same

Re: [HACKERS] [BUGS] BUG #14825: enum type: unsafe use?

On 2018-01-12 07:51:34 -0500, Robert Haas wrote: > On Thu, Jan 11, 2018 at 11:01 PM, Thomas Munro > wrote: > > Are you saying we should do the work now to create a per-transaction > > DSM segment + DSA area + thing that every backend attaches to? > > No, I was just

Re: [HACKERS] Race between SELECT and ALTER TABLE NO INHERIT

I wrote: > I think that there might be a much simpler solution to this, which > is to just remove make_inh_translation_list's tests of attinhcount, > as per attached. I went ahead and pushed that, with an isolation test based on the one Horiguchi-san submitted but covering a few related cases.

Re: [HACKERS] Re: [COMMITTERS] pgsql: Remove pgbench "progress" test pending solution of its timing is (fwd)

Fabien COELHO writes: > Attached is an attempt at improving the situation: I took a quick look at this and can't really convince myself that it improves our situation. The fact that it prints nothing if the runtime is outside of a tightly constrained range seems likely to

Re: Changing WAL Header to reduce contention during ReserveXLogInsertLocation()

On Fri, Jan 12, 2018 at 8:43 PM, Claudio Freire wrote: > > > On Sat, Dec 30, 2017 at 7:32 AM, Simon Riggs > wrote: > >> So we can't completely remove xl_prev field, without giving up some >> functionality. But we don't really need to store the

Re: Changing WAL Header to reduce contention during ReserveXLogInsertLocation()

On 2018-01-12 17:43:00 -0500, Tom Lane wrote: > Andres Freund writes: > > On 2018-01-12 17:24:54 -0500, Tom Lane wrote: > >> Andres Freund writes: > >>> Right. I wonder if it be reasonable to move that to a page's header > >>> instead of individual

Re: [HACKERS] Planning counters in pg_stat_statements

Haribabu Kommi writes: > I checked the latest patch and it is working fine and I don't have any > further comments. Marked the patch as "ready for committer". I started to look at this patch, and I'm not entirely convinced whether it is a good thing for the planner_hook

Re: [HACKERS] UPDATE of partition key

On Fri, Jan 12, 2018 at 12:23 PM, Amit Khandekar wrote: >> (1) if they need it by subplan index, first use >> subplan_partition_offsets to convert it to a per-leaf index > > Before that, we need to check if there *is* an offset array. If there > are no partitions, there is

Re: WIP: a way forward on bootstrap data

Peter Eisentraut wrote: > On 1/12/18 12:24, Alvaro Herrera wrote: > > Here's a small sample pg_proc entry: > > > > { oid => '2147', descr => 'number of input rows for which the input > > expression is not null', > > n => 'count', proisagg => 't', v => 'i', p => 's', rt => 'int8', at => > >

Re: WIP: a way forward on bootstrap data

Tom, everyone, It's getting late in my timezone, but I wanted to give a few quick answers. I'll follow up tomorrow. Thanks Alvaro for committing my refactoring of pg_attribute data creation. I think your modifications are sensible and I'll rebase soon. On 1/13/18, Tom Lane

Re: [HACKERS] GSoC 2017: Foreign Key Arrays

On Mon, Nov 13, 2017 at 2:41 AM, Andreas Karlsson wrote: > I think the code would look cleaner if you generate the following query: > > SELECT fk.x, fk.ys FROM ONLY t2 fk CROSS JOIN LATERAL > pg_catalog.unnest(ys) a2 (v) LEFT OUTER JOIN ONLY t1 pk ON pk.x = fk.x AND > pk.y =

Re: Changing WAL Header to reduce contention during ReserveXLogInsertLocation()

Andres Freund writes: > On 2018-01-12 17:24:54 -0500, Tom Lane wrote: >> Andres Freund writes: >>> Right. I wonder if it be reasonable to move that to a page's header >>> instead of individual records? To avoid torn page issues we'd have to >>> reduce the

Re: [HACKERS] [PATCH] Improve geometric types

Hello, sorry for the absense. (Sorry for the long but should be hard-to-read article..) At Thu, 4 Jan 2018 14:53:47 +0100, Emre Hasegeli wrote in > Rebased versions are attached. Thank you for the new

Re: CREATE ROUTINE MAPPING

On Fri, Jan 12, 2018 at 8:07 AM, Corey Huinker wrote: > A few months ago, I was researching ways for formalizing calling functions > on one postgres instance from another. RPC, basically. In doing so, I > stumbled across an obscure part of the the SQL Standard called

Re: master make check fails on Solaris 10

On 11-01-2018 20:34, Tom Lane wrote: Marina Polyakova writes: Hello, hackers! I got a permanent failure of master (commit ca454b9bd34c75995eda4d07c9858f7c22890c2b) make check on Solaris 10. Regression output and diffs are attached. Hm, buildfarm member

Re: Transform for pl/perl

On Fri, 12 Jan 2018 15:19:26 +1300 Thomas Munro wrote: > On Thu, Dec 7, 2017 at 10:56 PM, Anthony Bykov > wrote: > >> Please, find a new version of the patch in attachments to this > >> message. > > Hi again Anthony, > > I wonder why

Re: [HACKERS] [BUGS] BUG #14825: enum type: unsafe use?

On Thu, Jan 11, 2018 at 11:01 PM, Thomas Munro wrote: > Are you saying we should do the work now to create a per-transaction > DSM segment + DSA area + thing that every backend attaches to? No, I was just thinking you could stuff it into the per-parallel-query

Re: [HACKERS] Parallel tuplesort (for parallel B-Tree index creation)

On Sat, Jan 6, 2018 at 3:47 AM, Peter Geoghegan wrote: > On Tue, Jan 2, 2018 at 8:43 PM, Rushabh Lathia > wrote: >> I agree that plan_create_index_workers() needs to count the leader as a >> normal worker for the CREATE INDEX. So what you proposing is -

Re: [HACKERS] Cached plans and statement generalization

On 12.01.2018 03:40, Thomas Munro wrote: On Sun, Jan 7, 2018 at 11:51 AM, Stephen Frost wrote: * Konstantin Knizhnik (k.knizh...@postgrespro.ru) wrote: Updated version of the patch is attached. This patch appears to apply with just a bit of fuzz and make check passes,

Re: [HACKERS] Bug in to_timestamp().

Hello, On Fri, Jan 12, 2018 at 02:48:40PM +1300, Thomas Munro wrote: > > I'm guessing that commit 11b623dd0a2c385719ebbbdd42dd4ec395dcdc9d had > something to do with the following failure, when your patch is > applied: > > horology ... FAILED > Thank you a lot for

Re: WIP Patch: Pgbench Serialization and deadlock errors

On 12-01-2018 15:47, Fabien COELHO wrote: Hello Marina, A partial answer, to focus on how the feature may be simplified. Thank you! I apologise as it seems that I overlooked one of your mail. Changing the thread has not helped. I'm wondering whether the whole feature could be simplified