Re: [HACKERS] Push down more UPDATEs/DELETEs in postgres_fdw

On 2016/11/16 13:10, Ashutosh Bapat wrote: On Wed, Nov 16, 2016 at 8:25 AM, Etsuro Fujita wrote: On 2016/11/15 19:04, Rushabh Lathia wrote: Your latest patch doesn't not get apply cleanly apply on master branch. Did you apply the patch set in [1]

Re: [HACKERS] Document how to set up TAP tests for Perl 5.8.8

On Wed, Nov 16, 2016 at 12:48:03PM +0800, Craig Ringer wrote: > --- a/src/test/perl/README > +++ b/src/test/perl/README > @@ -64,3 +64,20 @@ For available PostgreSQL-specific test methods and some > example tests read the > perldoc for the test modules, e.g.: > > perldoc

Re: [HACKERS] Adding the optional clause 'AS' in CREATE TRIGGER

> But in any case it would be a serious mistake to do this without first > implementing CREATE OR REPLACE TRIGGER. I think that's an entirely separate > proposal and you would be well advised to treat it as such. I see. There are more problems than I expected... Let me start with 'OR REPLACE'

Re: [HACKERS] pgsql: Add putenv support for msvcrt from Visual Studio 2013

On Tue, Apr 26, 2016 at 07:39:29PM +0200, Christian Ullrich wrote: > * Christian Ullrich wrote: > > >wrong even without considering the debug/release split. If we load a > >compiled extension built with a CRT we have not seen yet, _after_ the > >first call to pgwin32_putenv(), that module's CRT's

Re: [HACKERS] Patch: Implement failover on libpq connect level.

> JDBC is sending "show transaction_read_only" to find whether it is master > or not. > Victor's patch also started with it, but later it was transformed into > pg_is_in_recovery > by him as it appeared more appropriate to identify the master / slave. In my understanding pg_is_in_recovery()

[HACKERS] regression tests fails

Hi I have a repeated problem with regress tests master, Fedora 25, running on port 50848 with PID 5548 == creating database "regression" == CREATE DATABASE ALTER DATABASE == running regression test queries== test ddl

Re: [HACKERS] [PATCH] Logical decoding timeline following take II

On 16 November 2016 at 12:44, Craig Ringer wrote: > Despite that, I've attached a revised version of the current approach > incorporating fixes for the issues you mentioned. It's preceded by the > patch to add an --endpos option to pg_recvlogical so that we can > properly

[HACKERS] Document how to set up TAP tests for Perl 5.8.8

I found it a real pain to set up Perl 5.8.8 to re-check recent TAP changes against it. It turns out there's a much easier way than messing with VMs or manually doing a source install, so I documented it to save others the future pain. It'd be nice to commit this at least to 9.6 and v10. Trivial

Re: [HACKERS] [PATCH] Logical decoding timeline following take II

On 12 November 2016 at 23:07, Andres Freund wrote > On 2016-10-24 17:49:13 +0200, Petr Jelinek wrote: >> + * Determine which timeline to read an xlog page from and set the >> + * XLogReaderState's state->currTLI to that timeline ID. > > "XLogReaderState's state->currTLI" - the

Re: [HACKERS] Patch: Implement failover on libpq connect level.

> > > So I am tempted to just > > hold my nose and hard-code the SQL as JDBC is presumably already > doing. JDBC is sending "show transaction_read_only" to find whether it is master or not. Victor's patch also started with it, but later it was transformed into pg_is_in_recovery by him as it

Re: [HACKERS] Push down more UPDATEs/DELETEs in postgres_fdw

On Wed, Nov 16, 2016 at 8:25 AM, Etsuro Fujita wrote: > On 2016/11/15 19:04, Rushabh Lathia wrote: >> >> Thanks Fujita-san for working on this. I've signed up to review this >> patch. > > > Thank you for reviewing the patch! > >> Your latest patch doesn't not get

Re: [HACKERS] Quorum commit for multiple synchronous replication.

On Mon, Nov 14, 2016 at 5:39 PM, Masahiko Sawada wrote: > On Tue, Nov 8, 2016 at 10:12 PM, Michael Paquier > wrote: >> On Tue, Nov 8, 2016 at 12:25 AM, Masahiko Sawada >> wrote: >>> On Tue, Oct 25, 2016 at 10:35 PM,

Re: [HACKERS] WIP: About CMake v2

Yeah, there seems to be a lot of these. Looking through them almost all concern the addition of piece of code to wrap putenv. e.g: --- a/src/bin/psql/command.c +++ b/src/bin/psql/command.c @@ -1350,7 +1350,7 @@ exec_command(const char *cmd, char *newval;

Re: [HACKERS] Push down more UPDATEs/DELETEs in postgres_fdw

On 2016/11/15 19:04, Rushabh Lathia wrote: Thanks Fujita-san for working on this. I've signed up to review this patch. Thank you for reviewing the patch! Your latest patch doesn't not get apply cleanly apply on master branch. Did you apply the patch set in [1]

Re: [HACKERS] WIP: About CMake v2

I had a bit a play around to see if I could get this building properly again with v10 (i.e master). I've attached a minimal *incremental* patch that needs to be applied after v1. This gets everything under the src tree building (added the new file_utils.c and reordered some link libs and

[HACKERS] Use of pg_proc.probin is legal?

Hello, I have a question as subject line. https://www.postgresql.org/docs/devel/static/catalog-pg-proc.html According to the documentation, the purpose of pg_proc.probin is introduced as follows: | Additional information about how to invoke the function. Again, the interpretation is

Re: [HACKERS] Dynamic shared memory areas

On Thu, Nov 10, 2016 at 12:37 AM, Thomas Munro wrote: > On Tue, Nov 1, 2016 at 5:06 PM, Thomas Munro > wrote: >> On Wed, Oct 5, 2016 at 11:28 PM, Thomas Munro >> wrote: >>> [dsa-v3.patch] >> >> Here is

Re: [HACKERS] Re: Do we need use more meaningful variables to replace 0 in catalog head files?

Greg Stark writes: > Just throwing this out there > It would be neat if the file format was precisely a tab or comma > separated file suitable for loading into the appropriate table with > COPY or loading into a spreadsheet. Actually, I'd say that's a very accurate

[HACKERS] Re: Do we need use more meaningful variables to replace 0 in catalog head files?

On Tue, Nov 15, 2016 at 4:50 PM, Robert Haas wrote: > On Sun, Nov 13, 2016 at 9:48 AM, Andrew Dunstan wrote: >> I'm not convinced the line prefix part is necessary, though. What I'm >> thinking of is something like this: >> >> PROCDATA( oid=1242

Re: [HACKERS] Password identifiers, protocol aging and SCRAM protocol

On Tue, Nov 15, 2016 at 12:40 PM, Robert Haas wrote: > On Tue, Nov 15, 2016 at 2:24 PM, Michael Paquier > wrote: >> How do you plug in that with OpenSSL? Are you suggesting to use a set >> of undef definitions in the new header in the same way as

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

On Mon, 7 Nov 2016 23:29:28 +0100 Gilles Darold wrote: > Here is the v13 of the patch, Just to keep things up to date... Attached are 3 re-worked patches that I see submitting along with the pg_current_logfile patch. They apply on top of v13. (I still have one more

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

On Sat, 12 Nov 2016 12:59:46 -0600 "Karl O. Pinc" wrote: > On Mon, 7 Nov 2016 23:29:28 +0100 > Gilles Darold wrote: > > Here is the v13 of the patch, > > - Do not write current_logfiles when log_collector is activated > > but log_destination doesn't

Re: [HACKERS] Something is broken about connection startup

Robert Haas writes: > On Mon, Nov 14, 2016 at 4:42 PM, Tom Lane wrote: >> ... I'm inclined to hold my nose and stick a call into step (1) of the >> main loop instead. > Seems like a good idea. >> Also, wherever we end up putting those calls, is it

Re: [HACKERS] Parallel execution and prepared statements

As the patch in [1] targeting the execution of the plan in ExecutePlan depending on the destination was declined, I hacked around a bit to find another way to use parallel mode with SQL prepared statements while disabling the parallel execution in case of an non read-only execution. For this I

Re: [HACKERS] Password identifiers, protocol aging and SCRAM protocol

On Tue, Nov 15, 2016 at 2:24 PM, Michael Paquier wrote: > How do you plug in that with OpenSSL? Are you suggesting to use a set > of undef definitions in the new header in the same way as pgcrypto is > doing, which is rather ugly? Because that's what the deal is about

Re: [HACKERS] SERIALIZABLE on standby servers

On Tue, Nov 8, 2016 at 5:56 PM, Thomas Munro wrote: > Here is an experimental WIP patch to allow SERIALIZABLE READ ONLY > DEFERRABLE transactions on standby servers without serialisation > anomalies, based loosely on an old email from Kevin Grittner[1]. I'm > not

Re: [HACKERS] Snapshot too old logging

Magnus wrote: > Just to be clear, you're suggesting 'One or more rows may have already been > removed from "%s"? Perhaps just 'This query attempted to access a page in "%s" that was modified after the snapshot was acquired.'

Re: [HACKERS] Snapshot too old logging

Magnus Hagander wrote: > On Tue, Nov 15, 2016 at 8:22 PM, Robert Haas wrote: > > > On Tue, Nov 15, 2016 at 2:21 PM, Kevin Grittner wrote: > > > That particular language would be misleading. All we know about > > > the page is that it was modified

Re: [HACKERS] Performance degradation in Bitmapscan (commit 75ae538bc3168bf44475240d4e0487ee2f3bb376)

Hi Dilip, thanks for noticing that one. On 2016-11-09 21:17:22 +0530, Dilip Kumar wrote: > While testing bitmap performance, I have observed that some of the > TPCH queries taking huge time in BitmapIndexScan node, when there are > lossy pages. It's not really related to lossy pages, it's just

Re: [HACKERS] Snapshot too old logging

On Tue, Nov 15, 2016 at 8:22 PM, Robert Haas wrote: > On Tue, Nov 15, 2016 at 2:21 PM, Kevin Grittner wrote: > > On Tue, Nov 15, 2016 at 12:43 PM, Robert Haas > wrote: > > > >> I think it would be better not to include either the

Re: [HACKERS] Password identifiers, protocol aging and SCRAM protocol

On Tue, Nov 15, 2016 at 10:40 AM, Robert Haas wrote: > On Fri, Nov 4, 2016 at 11:58 AM, Peter Eisentraut > wrote: >> The organization of these patches makes sense to me. >> >> On 10/20/16 1:14 AM, Michael Paquier wrote: >>> - 0001, moving

Re: [HACKERS] Snapshot too old logging

On Tue, Nov 15, 2016 at 2:21 PM, Kevin Grittner wrote: > On Tue, Nov 15, 2016 at 12:43 PM, Robert Haas wrote: > >> I think it would be better not to include either the snapshot or the >> block number, and just find some way to reword the error message so

Re: [HACKERS] Declarative partitioning - another take

On Tue, Nov 15, 2016 at 5:30 AM, Amit Langote wrote: > On 2016/11/11 19:30, Amit Langote wrote: >> >> Attached updated patches. > > Here is the latest version of the patches with some fixes along with those > mentioned below (mostly in 0003): > > - Fixed the logic

Re: [HACKERS] Snapshot too old logging

On Tue, Nov 15, 2016 at 12:43 PM, Robert Haas wrote: > I think it would be better not to include either the snapshot or the > block number, and just find some way to reword the error message so > that it mentions which relation was involved without implying that all >

Re: [HACKERS] Snapshot too old logging

On Tue, Nov 15, 2016 at 7:43 PM, Robert Haas wrote: > On Tue, Nov 15, 2016 at 1:30 PM, Magnus Hagander > wrote: > > On Tue, Nov 15, 2016 at 7:27 PM, Robert Haas > wrote: > >> > >> On Tue, Nov 15, 2016 at 1:18 PM, Magnus

Re: [HACKERS] Snapshot too old logging

On Tue, Nov 15, 2016 at 12:45 PM, Tom Lane wrote: > Magnus Hagander writes: >> Is there value in showing which snapshot as well? Something like: >> DETAIL: snapshot is too old to access relation > > Snapshots don't have names, and I can't think of a

Re: [HACKERS] Snapshot too old logging

Magnus Hagander writes: > Is there value in showing which snapshot as well? Something like: > DETAIL: snapshot is too old to access relation Snapshots don't have names, and I can't think of a useful way of identifying them to users. regards, tom

Re: [HACKERS] Snapshot too old logging

On Tue, Nov 15, 2016 at 1:30 PM, Magnus Hagander wrote: > On Tue, Nov 15, 2016 at 7:27 PM, Robert Haas wrote: >> >> On Tue, Nov 15, 2016 at 1:18 PM, Magnus Hagander >> wrote: >> > Is there value in showing which snapshot as well?

Re: [HACKERS] Password identifiers, protocol aging and SCRAM protocol

On Fri, Nov 4, 2016 at 11:58 AM, Peter Eisentraut wrote: > The organization of these patches makes sense to me. > > On 10/20/16 1:14 AM, Michael Paquier wrote: >> - 0001, moving all the SHA2 functions to src/common/ and introducing a >> PG-like interface. No

Re: [HACKERS] Snapshot too old logging

On Tue, Nov 15, 2016 at 12:20 PM Magnus Hagander wrote: > Is there value in showing the snapshot as well? I don't think so. Knowing the relname let's you look at your report/job and figure out if the access to that relation can be moved. Having the exact snapshot version isn't going to change

Re: [HACKERS] Snapshot too old logging

On Tue, Nov 15, 2016 at 7:27 PM, Robert Haas wrote: > On Tue, Nov 15, 2016 at 1:18 PM, Magnus Hagander > wrote: > > Is there value in showing which snapshot as well? Something like: > > DETAIL: snapshot is too old to access relation > > IIUC, the

Re: [HACKERS] Patch: Implement failover on libpq connect level.

On Tue, Nov 15, 2016 at 12:53 PM, Catalin Iacob wrote: > On Tue, Nov 15, 2016 at 5:58 PM, Robert Haas wrote: >> On Tue, Nov 15, 2016 at 9:42 AM, Alvaro Herrera >> wrote: >>> I would rather come up with something that works

Re: [HACKERS] Snapshot too old logging

On Tue, Nov 15, 2016 at 1:18 PM, Magnus Hagander wrote: > Is there value in showing which snapshot as well? Something like: > DETAIL: snapshot is too old to access relation IIUC, the granularity is per-block, not per-relation, so that might be misleading. -- Robert Haas

Re: [HACKERS] Snapshot too old logging

On Tue, Nov 15, 2016 at 10:30 AM, Tom Lane wrote: > > Kevin Grittner writes: > > On Tue, Nov 15, 2016 at 3:38 AM, Magnus Hagander > wrote: > >> Is there a reason why we don't log which relation triggered the > >> snapshot too old error when it happens? >

Re: [HACKERS] Snapshot too old logging

On Tue, Nov 15, 2016 at 5:29 PM, Tom Lane wrote: > Kevin Grittner writes: > > On Tue, Nov 15, 2016 at 3:38 AM, Magnus Hagander > wrote: > >> Is there a reason why we don't log which relation triggered the > snapshot too > >> old error

Re: [HACKERS] Patch: Implement failover on libpq connect level.

Catalin Iacob wrote: > On Tue, Nov 15, 2016 at 3:42 PM, Alvaro Herrera > wrote: > > FWIW I'm not sure "primary" is the right term here either. I think what > > we really want to know is whether the node can accept writes; maybe > > "pg_is_writable_node". > > This made

Re: [HACKERS] postgres_fdw and defaults

On 11/15/2016 10:49 AM, Tom Lane wrote: Andrew Dunstan writes: I know we've discussed this before, but I have just had the unpleasant experience of trying to get around the difficulty of inserting into a foreign table with a serial field, surely a common enough scenario

Re: [HACKERS] Patch: Implement failover on libpq connect level.

On Tue, Nov 15, 2016 at 3:42 PM, Alvaro Herrera wrote: > FWIW I'm not sure "primary" is the right term here either. I think what > we really want to know is whether the node can accept writes; maybe > "pg_is_writable_node". This made me think of another complication:

Re: [HACKERS] Patch: Implement failover on libpq connect level.

On Tue, Nov 15, 2016 at 5:58 PM, Robert Haas wrote: > On Tue, Nov 15, 2016 at 9:42 AM, Alvaro Herrera > wrote: >> I would rather come up with something that works in both cases that we >> can extend internally later, say pg_is_primary_node() or

Re: [HACKERS] Parallel execution and prepared statements

Thanks Laurenz, for your help with debugging on this topic. I was preparing a message to the list myself and found an earlier discussion [1] on the topic. If I understand it correctly, the issue is with CREATE TABLE ... AS EXECUTE So it seems parallel execution of prepared statements was

Re: [HACKERS] WAL consistency check facility

On Tue, Nov 15, 2016 at 7:50 AM, Kuntal Ghosh wrote: > I've modified the guc parameter name as wal_consistency_check (little > hesitant for a participle in suffix :) ). Also, updated the sgml and > variable name accordingly. The changes look good to me. -- Michael

Re: [HACKERS] Patch: Implement failover on libpq connect level.

On Tue, Nov 15, 2016 at 9:42 AM, Alvaro Herrera wrote: > Robert Haas wrote: >> On Mon, Nov 14, 2016 at 2:38 AM, Mithun Cy >> wrote: >> > I have not tested with logical replication. Currently we identify the >> > primary to connect based on

Re: [HACKERS] Do we need use more meaningful variables to replace 0 in catalog head files?

On Sun, Nov 13, 2016 at 9:48 AM, Andrew Dunstan wrote: > I'm not convinced the line prefix part is necessary, though. What I'm > thinking of is something like this: > > PROCDATA( oid=1242 name=boolin isstrict=t volatile=i parallel=s nargs=1 > rettype=bool

Re: [HACKERS] proposal: psql \setfileref

2016-11-15 17:39 GMT+01:00 Daniel Verite : > Corey Huinker wrote: > > > I am not asking for this feature now, but do you see any barriers to > later > > adding x/xq/xb/xbq equivalents for executing a shell command? > > For text contents, we already have this

Re: [HACKERS] Logical Replication WIP

On Sun, Nov 13, 2016 at 4:21 AM, Andres Freund wrote: > It can be extended from what core provides, for extended versions of > replication solutions, for one. I presume publications/subscriptions > aren't only going to be used by built-in code. Hmm, I would not have presumed

Re: [HACKERS] proposal: psql \setfileref

Corey Huinker wrote: > I am not asking for this feature now, but do you see any barriers to later > adding x/xq/xb/xbq equivalents for executing a shell command? For text contents, we already have this (pasted right from the doc): testdb=> \set content `cat my_file.txt` testdb=> INSERT

Re: [HACKERS] Snapshot too old logging

Kevin Grittner writes: > On Tue, Nov 15, 2016 at 3:38 AM, Magnus Hagander wrote: >> Is there a reason why we don't log which relation triggered the snapshot too >> old error when it happens? > I would probably not want to mess with the text of the error >

Re: [HACKERS] Something is broken about connection startup

On Mon, Nov 14, 2016 at 4:42 PM, Tom Lane wrote: >> No, I'm not at all proposing to assume that. But I may be willing to >> assume that "we don't hold a CatalogSnapshot between Bind and Execute >> unless we're also holding a transaction snapshot". I need to do a bit >> more

Re: [HACKERS] pg_dump, pg_dumpall and data durability

On Sun, Nov 13, 2016 at 4:18 AM, Andres Freund wrote: > On 2016-11-08 18:18:01 -0500, Tom Lane wrote: >> I think this might be better addressed by adding something to backup.sgml >> pointing out that you'd better fsync or sync your backups before assuming >> that they can't be

Re: [HACKERS] proposal: psql \setfileref

Hi 2016-11-13 19:46 GMT+01:00 Pavel Stehule : > Hi > > I am sending a initial implementation of psql content commands. This > design is reaction to Tom's objections against psql file ref variables. > This design is more cleaner, more explicit and more practical - import

Re: [HACKERS] Snapshot too old logging

On Tue, Nov 15, 2016 at 3:38 AM, Magnus Hagander wrote: > Is there a reason why we don't log which relation triggered the snapshot too > old error when it happens? > > Since we do have Relation available in TestForOldSnapshot_impl(), shouldn't > we be able to include it? > >

[HACKERS] jsonb_delete with arrays

Attached is an implantation of jsonb_delete that instead of taking a single key to remove accepts an array of keys (it still does just keys, so it's using the - operator, it's not like the path delete function that also takes an array, but uses a different operator). In some simple testing of

Re: [HACKERS] WAL consistency check facility

On Tue, Nov 15, 2016 at 7:23 PM, Robert Haas wrote: > On Sat, Nov 12, 2016 at 10:06 PM, Peter Eisentraut > wrote: >> On 11/9/16 11:55 PM, Michael Paquier wrote: >>> + >>> + wal_consistency (string) >>> + >>> +

Re: [HACKERS] postgres_fdw and defaults

Andrew Dunstan writes: > I know we've discussed this before, but I have just had the unpleasant > experience of trying to get around the difficulty of inserting into a > foreign table with a serial field, surely a common enough scenario that > we should try to deal with it

Re: [HACKERS] proposal: psql \setfileref

2016-11-15 16:41 GMT+01:00 Corey Huinker : > > On Sun, Nov 13, 2016 at 1:46 PM, Pavel Stehule > wrote: > >> r - read file without any modification >> rq - read file, escape as literal and use outer quotes >> rb - read binary file - transform to

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

On Wed, Nov 9, 2016 at 10:18 PM, Peter Geoghegan wrote: >> Maybe another way of putting this is that, while there's clearly a >> benefit to having some kind of a cap, it's appropriate to pick a large >> value, such as 500. Having no cap at all risks creating many extra >> tapes

Re: [HACKERS] proposal: psql \setfileref

On Sun, Nov 13, 2016 at 1:46 PM, Pavel Stehule wrote: > r - read file without any modification > rq - read file, escape as literal and use outer quotes > rb - read binary file - transform to hex code string > rbq - read binary file, transform to hex code string and use

[HACKERS] Parallel execution and prepared statements

Tobias Bussmann has discovered an oddity with prepared statements. Parallel scan is used with prepared statements, but only if they have been created with protocol V3 "Parse". If a prepared statement has been prepared with the SQL statement PREPARE, it will never use a parallel scan. I guess

Re: [HACKERS] Danger of automatic connection reset in psql

On 11/14/16 5:41 AM, Oleksandr Shulgin wrote: Automatic connection reset is a nice feature for server development, IMO. Is it really useful for anything else is a good question. I use it all the time for application development; my rebuild script will forcibly kick everyone out to re-create

Re: [HACKERS] Physical append-only tables

On Mon, Nov 14, 2016 at 9:43 PM, Greg Stark wrote: > On Sun, Nov 13, 2016 at 3:45 PM, Magnus Hagander > wrote: > > For a scenario like this, would it make sense to have an option that > could > > be set on an individual table making it physical append only?

Re: [HACKERS] A bug in UCS_to_most.pl

On Tue, Nov 8, 2016 at 3:56 AM, Kyotaro HORIGUCHI wrote: > I was surprised to find that > src/backend/utils/mb/Unicode/Makefile got changed (3a47c70) to > have download feature of character conversion authority files. It > seems fine according to the previous

Re: [HACKERS] Patch: Implement failover on libpq connect level.

Robert Haas wrote: > On Mon, Nov 14, 2016 at 2:38 AM, Mithun Cy wrote: > > I have not tested with logical replication. Currently we identify the > > primary to connect based on result of "SELECT pg_is_in_recovery()". So I > > think it works. Do you want me test a

Re: [HACKERS] Patch: Implement failover on libpq connect level.

On Mon, Nov 14, 2016 at 8:09 PM, Tsunakawa, Takayuki wrote: > From: pgsql-hackers-ow...@postgresql.org >> [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Mithun Cy >> Thanks, my concern is suppose you have 3 server in cluster A(new version), >> B(new

Re: [HACKERS] Patch: Implement failover on libpq connect level.

On Mon, Nov 14, 2016 at 2:38 AM, Mithun Cy wrote: > On Fri, Nov 11, 2016 at 7:33 PM, Peter Eisentraut > wrote: >> We tend to use the term "primary" instead of "master". > > Thanks, I will use primary instead of master in my next

Re: [HACKERS] [bug fix] Cascading standby cannot catch up and get stuck emitting the same message repeatedly

On Tue, Nov 15, 2016 at 7:51 AM, Tsunakawa, Takayuki wrote: > From: pgsql-hackers-ow...@postgresql.org >> [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Amit Kapila >> It looks like the code in 9.3 or later version uses the recptr as the target >> segment

Re: [HACKERS] WAL consistency check facility

On Sat, Nov 12, 2016 at 10:06 PM, Peter Eisentraut wrote: > On 11/9/16 11:55 PM, Michael Paquier wrote: >> + >> + wal_consistency (string) >> + >> + wal_consistency configuration >> parameter >> + >> + >> + >> + >>

[HACKERS] postgres_fdw and defaults

I know we've discussed this before, but I have just had the unpleasant experience of trying to get around the difficulty of inserting into a foreign table with a serial field, surely a common enough scenario that we should try to deal with it better. The solution of using a local sequence

Re: [HACKERS] Fix checkpoint skip logic on idle systems by tracking LSN progress

On Tue, Nov 15, 2016 at 9:27 AM, Kyotaro HORIGUCHI wrote: > Hello, > > At Mon, 14 Nov 2016 16:53:35 +0530, Amit Kapila > wrote in >> > >> >> The progress parameter is used not only for checkpoint activity but by >> bgwriter as well for

Re: [HACKERS] Push down more full joins in postgres_fdw

On 2016/11/11 20:50, Etsuro Fujita wrote: On 2016/11/11 19:22, Ashutosh Bapat wrote: The patch looks in good shape now. Here are some comments. I have also made several changes to comments correcting grammar, typos, style and at few places logic. Let me know if the patch looks good. OK, will

Re: [HACKERS] Improvements in psql hooks for variables

Hi, I'm attaching v3 of the patch with error reporting for FETCH_COUNT as mentioned upthread, and rebased on the most recent master. > I was suggesting change on the lines of extending generic_boolean_hook to > include enum(part in enum_hooks which calls ParseVariableBool) and > integer

Re: [HACKERS] Remove the comment on the countereffectiveness of large shared_buffers on Windows

On Tue, Nov 15, 2016 at 7:14 AM, Tsunakawa, Takayuki wrote: > From: pgsql-hackers-ow...@postgresql.org >> [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Amit Kapila >> Okay, not a problem. However, I am not sure the results in this thread >> are

Re: [HACKERS] Push down more UPDATEs/DELETEs in postgres_fdw

Thanks Fujita-san for working on this. I've signed up to review this patch. Your latest patch doesn't not get apply cleanly apply on master branch. patching file contrib/postgres_fdw/deparse.c 6 out of 17 hunks FAILED -- saving rejects to file contrib/postgres_fdw/deparse.c.rej patching file

Re: [HACKERS] Declarative partitioning - another take

On 2016/11/11 20:49, Ashutosh Bapat wrote: > I have not looked at the latest set of patches, but in the version > that I have we create one composite type for every partition. This > means that if there are thousand partitions, there will be thousand > identical entries in pg_type. Since all the

[HACKERS] Snapshot too old logging

Is there a reason why we don't log which relation triggered the snapshot too old error when it happens? Since we do have Relation available in TestForOldSnapshot_impl(), shouldn't we be able to include it? Having that in the log message would be very helpful, but is there a reason why it

Re: [HACKERS] [PATCH] Generic type subscription

Hello. I took a look on the latest -v4 patch. I would like to note that this patch breaks a backward compatibility. For instance sr_plan extension[1] stop to compile with errors like: ``` serialize.c:38:2: error: unknown type name ‘ArrayRef’ JsonbValue *ArrayRef_ser(const ArrayRef *node,