Re: [HACKERS] Proposal for changes to recovery.conf API

On Tue, Sep 6, 2016 at 2:18 PM, Abhijit Menon-Sen wrote: > One open issue is the various assign_recovery_target_xxx functions, > which Michael noted in his earlier review: > [...] > I don't like this code, but I'm not yet sure what to replace it with. I > think we should

Re: [HACKERS] Proposal for changes to recovery.conf API

Hi. Here's an updated version of my patch, which now applies on top of the patch that Simon posted earlier (recovery_startup_r10_api.v1b.patch). A few notes: 1. I merged in recovery_target_lsn as a new GUC setting. 2. I fixed various minor nits in the earlier patch, not worth mentioning

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

On Tue, 6 Sep 2016 07:58:28 +0530 Mithun Cy wrote: > > Now if only one host is in connection string and it ask for read_write > connection(connect to master) I mean read_only is set 0 explicitly. > With above logic we will allow it to connect to standby?. I still >

Re: [HACKERS] patch: function xmltable

On 4 September 2016 at 16:06, Pavel Stehule wrote: > Hi > > minor update - using DefElem instead own private parser type I'm really glad that you're doing this and I'll take a look at it for this CF. It's quite a big patch so I expect this will take a few rounds of

Re: [HACKERS] Refactoring of heapam code.

On Mon, Aug 8, 2016 at 3:13 PM, Anastasia Lubennikova < a.lubennik...@postgrespro.ru> wrote: > >> > Thank you for the review, I'll fix these problems in final version. > > Posting the first message I intended to raise the discussion. Patches > were attached mainly to illustrate the problem and to

Re: [HACKERS] IF (NOT) EXISTS in psql-completion

Hello, At Sun, 4 Sep 2016 12:54:57 +0200, Pavel Stehule wrote in

Re: [HACKERS] Comment Typo

On Tue, Sep 6, 2016 at 10:52:22AM +0900, Amit Langote wrote: > Attached fixes a typo in header comment in libpq-be.h. > > s/libpq_be.h/libpq-be.h/g Applied. -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.com + As

Re: [HACKERS] Supporting SJIS as a database encoding

> From: pgsql-hackers-ow...@postgresql.org > [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Kyotaro > HORIGUCHI Implementing radix tree code, then redefining the format of mapping table > to suppot radix tree, then modifying mapping generator script are needed. > > If no one oppse to

Re: [HACKERS] Supporting SJIS as a database encoding

Hello, At Mon, 5 Sep 2016 19:38:33 +0300, Heikki Linnakangas wrote in <529db688-72fc-1ca2-f898-b0b99e300...@iki.fi> > On 09/05/2016 05:47 PM, Tom Lane wrote: > > "Tsunakawa, Takayuki" writes: > >> Before digging into the problem, could you share

Re: [HACKERS] Supporting SJIS as a database encoding

"Tsunakawa, Takayuki" writes: > Using multibyte-functions like mb... to process characters would solve > the problem? Well, sure. The problem is (1) finding all the places that need that (I'd estimate dozens to hundreds of places in the core code, and then

Re: [HACKERS] Supporting SJIS as a database encoding

From: pgsql-hackers-ow...@postgresql.org > [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Heikki > But one thing that would help a little, would be to optimize the UTF-8 > -> SJIS conversion. It uses a very generic routine, with a binary search > over a large array of mappings. I bet you

Re: [HACKERS] Cache Hash Index meta page.

On Tue, Sep 6, 2016 at 12:20 AM, Mithun Cy wrote: > On Sep 2, 2016 7:38 PM, "Jesper Pedersen" > wrote: >> Could you provide a rebased patch based on Amit's v5 ? > > Please find the the patch, based on Amit's V5. > I think you want to say

Re: [HACKERS] Supporting SJIS as a database encoding

From: Tom Lane [mailto:t...@sss.pgh.pa.us] > "Tsunakawa, Takayuki" writes: > > Before digging into the problem, could you share your impression on > > whether PostgreSQL can support SJIS? Would it be hopeless? > > I think it's pretty much hopeless. Even if we

Re: [HACKERS] Speed up Clog Access by increasing CLOG buffers

On Mon, Sep 5, 2016 at 11:34 PM, Tomas Vondra wrote: > > > On 09/05/2016 06:03 AM, Amit Kapila wrote: >> So, in short we have to compare three >> approaches here. >> >> 1) Group mode to reduce CLOGControlLock contention >> 2) Use granular locking model >> 3) Use

Re: [HACKERS] pg_sequence catalog

Andres Freund writes: > On September 5, 2016 7:26:42 AM PDT, Tom Lane wrote: >> The main problem I can see with this is that serial columns will have >> default expressions that are written out as >> "nextval('foo_f1_seq'::regclass)". I do not think we

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

On Mon, Sep 5, 2016 at 4:33 PM, Aleksander Alekseev < a.aleks...@postgrespro.ru> wrote: >After a brief examination I've found following ways to improve the patch. Adding to above comments. 1) + /* + * consult connection options and check if RO connection is OK + * RO connection is OK if readonly

Re: Install extensions using update scripts (was Re: [HACKERS] Remove superuser() checks from pgstattuple)

On 2016-09-05 22:24:09 -0400, Tom Lane wrote: > Ordinarily I'd be willing to stick this on the queue for the next > commitfest, but it seems like we ought to try to get it pushed now > so that Stephen can make use of the feature for his superuser changes. > Thoughts? Seems sensible to me. I can

Install extensions using update scripts (was Re: [HACKERS] Remove superuser() checks from pgstattuple)

Andres Freund writes: > On September 4, 2016 6:33:30 PM PDT, Tom Lane wrote: >> I think nearly all of the >> infrastructure for this is already there in extension.c. > Yes, it doesn't sound very hard... I poked at this a bit, and indeed it's not that

[HACKERS] Comment Typo

Attached fixes a typo in header comment in libpq-be.h. s/libpq_be.h/libpq-be.h/g Thanks, Amit diff --git a/src/include/libpq/libpq-be.h b/src/include/libpq/libpq-be.h index ecdfbc6..b91eca5 100644 --- a/src/include/libpq/libpq-be.h +++ b/src/include/libpq/libpq-be.h @@ -1,6 +1,6 @@

Re: [HACKERS] Speedup twophase transactions

On Sat, Sep 3, 2016 at 10:26 PM, Michael Paquier wrote: > On Fri, Sep 2, 2016 at 5:06 AM, Simon Riggs wrote: >> On 13 April 2016 at 15:31, Stas Kelvich wrote: >> >>> Fixed patch attached. There already was

Re: [HACKERS] PassDownLimitBound for ForeignScan/CustomScan

> -Original Message- > From: pgsql-hackers-ow...@postgresql.org > [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Kouhei Kaigai > Sent: Monday, September 05, 2016 12:58 PM > To: Jeevan Chalke > Cc: pgsql-hackers@postgresql.org; Etsuro Fujita > Subject: Re: [HACKERS]

Re: [HACKERS] [PATCH] COPY vs \copy HINT

On 5 September 2016 at 16:32, Christoph Berg wrote: > The part about the server permissions might be useful to hint at. > What about > > "COPY TO instructs the PostgreSQL server to write to a file on the > server. " > "You may want a client-side facility such as

Re: [HACKERS] Stopping logical replication protocol

On 25 August 2016 at 13:04, Craig Ringer wrote: > By the way, I now think that the second part of your patch, to allow > interruption during ReorderBufferCommit processing, is also very > desirable. I've updated your patch, rebasing it on top of 10.0 master and splitting

Re: [HACKERS] System load consideration before spawning parallel workers

On Fri, Sep 2, 2016 at 3:01 AM, Peter Eisentraut < peter.eisentr...@2ndquadrant.com> wrote: > On 8/16/16 3:39 AM, Haribabu Kommi wrote: > > Yes, we need to consider many parameters as a system load, not just only > > the CPU. Here I attached a POC patch that implements the CPU load > >

Re: [HACKERS] Suggestions for first contribution?

On Mon, Sep 05, 2016 at 01:25:03PM -0400, Christian Convey wrote: > Hi guys, > > Can anyone suggest a project for my first PG contribution? How about adding PIVOT tables? MS SQL Server and Oracle both have them. If you're interested, I have some ideas about the UI parts and a few about the

Re: [HACKERS] pg_sequence catalog

On September 5, 2016 7:26:42 AM PDT, Tom Lane wrote: >Simon Riggs writes: >> On 4 September 2016 at 23:17, Greg Stark wrote: >>> So? Clients expect changes like this between major releases surely. >>> Subtle changes that cause silent

Re: [HACKERS] Showing parallel status in \df+

I wrote: > Pavel Stehule writes: >> Using footer for this purpose is little bit strange. What about following >> design? >> 1. move out source code of PL functions from \df+ >> 2. allow not unique filter in \sf and allow to display multiple functions > Wasn't that

[HACKERS] Bug in 9.6 tuplesort batch memory growth logic

While working on my parallel CREATE INDEX patch, I came across a problem. I initially assumed that what I saw was just a bug in my development branch. During a final merge in a parallel worker, with very little maintenance_work_mem, workers attempted to allocate an amount of memory slightly less

Re: [HACKERS] Logical Replication WIP

On 09/05/2016 03:58 PM, Steve Singer wrote: On 08/31/2016 04:51 PM, Petr Jelinek wrote: Hi, and one more version with bug fixes, improved code docs and couple more tests, some general cleanup and also rebased on current master for the start of CF. A few more things I noticed when

Re: [HACKERS] Vacuum: allow usage of more than 1GB of work mem

On Mon, Sep 5, 2016 at 5:36 PM, Simon Riggs wrote: > On 5 September 2016 at 15:50, Claudio Freire wrote: >> On Sun, Sep 4, 2016 at 3:46 AM, Simon Riggs wrote: >>> On 3 September 2016 at 04:25, Claudio Freire

Re: [HACKERS] Vacuum: allow usage of more than 1GB of work mem

On 5 September 2016 at 15:50, Claudio Freire wrote: > On Sun, Sep 4, 2016 at 3:46 AM, Simon Riggs wrote: >> On 3 September 2016 at 04:25, Claudio Freire wrote: >>> The patch also makes vacuum free the dead_tuples before

Re: [HACKERS] Logical Replication WIP

On 08/31/2016 04:51 PM, Petr Jelinek wrote: Hi, and one more version with bug fixes, improved code docs and couple more tests, some general cleanup and also rebased on current master for the start of CF. To get the 'subscription' TAP tests to pass I need to set export PGTZ=+02

Re: [HACKERS] Vacuum: allow usage of more than 1GB of work mem

On Mon, Sep 5, 2016 at 11:50 AM, Claudio Freire wrote: > On Sun, Sep 4, 2016 at 3:46 AM, Simon Riggs wrote: >> On 3 September 2016 at 04:25, Claudio Freire wrote: >>> The patch also makes vacuum free the dead_tuples before

Re: [HACKERS] Cache Hash Index meta page.

On Sep 2, 2016 7:38 PM, "Jesper Pedersen" wrote: > Could you provide a rebased patch based on Amit's v5 ? Please find the the patch, based on Amit's V5. I have fixed following things 1. now in "_hash_first" we check if (opaque->hasho_prevblkno == InvalidBlockNumber)

Re: [HACKERS] [PATCH] Alter or rename enum value

Emre Hasegeli writes: >> I started looking at this patch. I'm kind of unhappy with having *both* >> IF EXISTS and IF NOT EXISTS options on the statement, especially since >> the locations of those phrases in the syntax seem to have been chosen >> with a dartboard. This feels

Re: [HACKERS] Speed up Clog Access by increasing CLOG buffers

On 09/05/2016 06:03 AM, Amit Kapila wrote: > On Mon, Sep 5, 2016 at 3:18 AM, Tomas Vondra > wrote: >> Hi, >> >> This thread started a year ago, different people contributed various >> patches, some of which already got committed. Can someone please post a >>

Re: [HACKERS] Suggestions for first contribution?

Hi 2016-09-05 19:25 GMT+02:00 Christian Convey : > Hi guys, > > Can anyone suggest a project for my first PG contribution? > > My first two ideas didn't pan out: Yury doesn't seem to need help > with CMake, and the TODO list's "-Wcast-align" project (now deleted) >

Re: [HACKERS] Better locale-specific-character-class handling for regexps

Heikki Linnakangas writes: > On 09/05/2016 07:10 PM, Tom Lane wrote: >> In any case, this is getting very far afield from the current patch. >> I'm willing to add a regexp.linux.ut8.sql test file if you think it's >> important to have some canned tests that exercise this new

[HACKERS] Suggestions for first contribution?

Hi guys, Can anyone suggest a project for my first PG contribution? My first two ideas didn't pan out: Yury doesn't seem to need help with CMake, and the TODO list's "-Wcast-align" project (now deleted) appeared impractical. I can continue trying things from the TODO list, but if someone knows

Re: [HACKERS] Better locale-specific-character-class handling for regexps

On 09/05/2016 07:10 PM, Tom Lane wrote: Heikki Linnakangas writes: On 09/04/2016 08:44 PM, Tom Lane wrote: I guess I could follow the lead of collate.linux.utf8.sql and produce a test that's only promised to pass on one platform with one encoding, but I'm not terribly excited

Re: [HACKERS] Fun fact about autovacuum and orphan temp tables

On Mon, Sep 5, 2016 at 12:48:32PM -0300, Alvaro Herrera wrote: > > The least invasive solution would be to have a guc, something like > > 'keep_orphan_temp_tables' with boolean value. > > Which would determine a autovacuum worker policy toward encountered orphan > > temp tables. > > The stated

Re: [HACKERS] Minor fix to comments

On Sun, Sep 4, 2016 at 05:30:57PM -0500, Jim Nasby wrote: > I noticed some imbalanced '-'s in execnodes.h. Though, ISTM newer code > doesn't use -'s in comments anymore, so maybe it'd be better to just ditch > them? Patch applied. -- Bruce Momjian http://momjian.us

Re: [HACKERS] Obsolete TODO item "-Wcast-align" ?

On Sun, Sep 4, 2016 at 06:10:23PM -0400, Christian Convey wrote: > On Sun, Sep 4, 2016 at 5:56 PM, Tom Lane wrote: > > Christian Convey writes: > >> I chose this item from the TODO page: "[E] Remove warnings created by > >> -Wcast-align". It

Re: [HACKERS] Supporting SJIS as a database encoding

On 09/05/2016 05:47 PM, Tom Lane wrote: "Tsunakawa, Takayuki" writes: Before digging into the problem, could you share your impression on whether PostgreSQL can support SJIS? Would it be hopeless? I think it's pretty much hopeless. Agreed. But one thing

Re: [HACKERS] less expensive pg_buffercache on big shmem

On 09/03/2016 05:04 AM, Tomas Vondra wrote: > This patch needs a rebase, as 06d7fd6e bumped the version to 1.2. Thank you for a valuable hint. > > If we will replace consistent method, then we should replace it with the > > partially consistent method (called "nonconsistent") because: > > 1)

Re: [HACKERS] Better locale-specific-character-class handling for regexps

Heikki Linnakangas writes: > On 09/04/2016 08:44 PM, Tom Lane wrote: >> I guess I could follow the lead of collate.linux.utf8.sql and produce >> a test that's only promised to pass on one platform with one encoding, >> but I'm not terribly excited by that. AFAIK that test file

Re: [HACKERS] Fun fact about autovacuum and orphan temp tables

Grigory Smolkin wrote: > > On 09/05/2016 04:34 PM, Alvaro Herrera wrote: > >Grigory Smolkin wrote: > > > >>Funny part is that it never drops them. So when backend is finally > >>terminated, it tries to drop them and fails with error: > >> > >>FATAL: out of shared memory > >>HINT: You might need

Re: [HACKERS] Optimization for lazy_scan_heap

On Mon, Sep 5, 2016 at 6:27 PM, Simon Riggs wrote: > On 4 August 2016 at 05:57, Masahiko Sawada wrote: > >> While reviewing freeze map code, Andres pointed out[1] that >> lazy_scan_heap could accesses visibility map twice and its logic is >> seems a

Re: [HACKERS] Vacuum: allow usage of more than 1GB of work mem

On Sun, Sep 4, 2016 at 3:46 AM, Simon Riggs wrote: > On 3 September 2016 at 04:25, Claudio Freire wrote: >> The patch also makes vacuum free the dead_tuples before starting >> truncation. It didn't seem necessary to hold onto it beyond that >>

Re: [HACKERS] Supporting SJIS as a database encoding

"Tsunakawa, Takayuki" writes: > Before digging into the problem, could you share your impression on > whether PostgreSQL can support SJIS? Would it be hopeless? I think it's pretty much hopeless. Even if we were willing to make every bit of code that looks for

Re: [HACKERS] new autovacuum criterion for visible pages

On 12 August 2016 at 01:01, Tom Lane wrote: > Michael Paquier writes: >> In short, autovacuum will need to scan by itself the VM of each >> relation and decide based on that. > > That seems like a worthwhile approach to pursue. The VM is supposed

Re: [HACKERS] pg_sequence catalog

Simon Riggs writes: > On 4 September 2016 at 23:17, Greg Stark wrote: >> So? Clients expect changes like this between major releases surely. >> Subtle changes that cause silent breakage for end-users seems scarier >> than unsubtle breakage that tool authors

Re: [HACKERS] Index Onlys Scan for expressions

Hi Tomas, On 03.09.2016 14:37, Tomas Vondra wrote: Hi Ildar, I've looked at this patch again today to do a bit more thorough review, and I think it's fine. There are a few comments (particularly in the new code in check_index_only) that need improving, and also a few small tweaks in the

Re: [HACKERS] pg_sequence catalog

On 4 September 2016 at 23:17, Greg Stark wrote: > On Wed, Aug 31, 2016 at 3:01 PM, Tom Lane wrote: >> >> Uh, not as subtly as all that, because "select * from sequence" will >> now return a different set of columns, which will flat out break a >> lot of clients

Re: [HACKERS] INSERT .. SET syntax

On 09/05/2016 03:58 PM, Simon Riggs wrote: > On 3 July 2016 at 20:36, Marko Tiikkaja wrote: > >> Here's a patch for $SUBJECT. I'll probably work on the docs a bit more >> before the next CF, but I thought I'd post it anyway. > > I think this should be Returned With Feedback.

Re: [HACKERS] Fun fact about autovacuum and orphan temp tables

On 09/05/2016 04:34 PM, Alvaro Herrera wrote: Grigory Smolkin wrote: Funny part is that it never drops them. So when backend is finally terminated, it tries to drop them and fails with error: FATAL: out of shared memory HINT: You might need to increase max_locks_per_transaction If I

Re: [HACKERS] INSERT .. SET syntax

On 3 July 2016 at 20:36, Marko Tiikkaja wrote: > Here's a patch for $SUBJECT. I'll probably work on the docs a bit more > before the next CF, but I thought I'd post it anyway. I think this should be Returned With Feedback. -- Simon Riggs

Re: [HACKERS] Index Onlys Scan for expressions

Hi Vladimir, On 03.09.2016 19:31, Vladimir Sitnikov wrote: Ildar>The reason why this doesn't work is that '~~' operator (which is a Ildar>synonym for 'like') isn't supported by operator class for btree. Since Ildar>the only operators supported by btree are <, <=, =, >=, >, you can use Ildar>it

Re: [HACKERS] Fun fact about autovacuum and orphan temp tables

Grigory Smolkin wrote: > Funny part is that it never drops them. So when backend is finally > terminated, it tries to drop them and fails with error: > > FATAL: out of shared memory > HINT: You might need to increase max_locks_per_transaction > > If I understand that rigth, we are trying to

Re: [HACKERS] Fun fact about autovacuum and orphan temp tables

On 09/05/2016 01:54 PM, Grigory Smolkin wrote: > What is the purpose of keeping orphan tables around and not dropping > them on the spot? You can read the discussion about it here: https://www.postgresql.org/message-id/flat/3507.1214581513%40sss.pgh.pa.us -- Vik Fearing

[HACKERS] Fun fact about autovacuum and orphan temp tables

Hello, hackers! We were testing how well some application works with PostgreSQL and stumbled upon an autovacuum behavior which I fail to understand. Application in question have a habit to heavily use temporary tables in funny ways. For example it creates A LOT of them. Which is ok. Funny

Re: [HACKERS] OpenSSL 1.1 breaks configure and more

On 09/05/2016 03:12 AM, Andreas Karlsson wrote: On 08/30/2016 08:42 AM, Heikki Linnakangas wrote: There's the ResourceOwner mechanism, see src/backend/utils/resowner/. That would be the proper way to do this. Call RegisterResourceReleaseCallback() when the context is allocated, and have the

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

Hello, Victor. > As community shows an interest with this patch, and it has been > included in the current commitfest, I've to submit it. Naturally we show interest in this patch. It's a great feature that would be very nice to have! > This version of patch includes > > 1. Most important - a

[HACKERS] CF app and patch series

Hi all Now that it's becoming more common to post patch series, not just standalone patches, it might be worth looking at how the CF app can help manage them. Any ideas? Especially since the patch series may not get committed all in one go, but progressively rebased on top of the bits that did

Re: [HACKERS] Assert(LWLockHeldByMeInMode(lock, LW_EXCLUSIVE))

On 05/09/2016 11:55, Julien Rouhaud wrote: > On 20/06/2016 06:28, Thomas Munro wrote: >> On Mon, Jun 20, 2016 at 3:43 PM, Craig Ringer wrote: >>> On 18 June 2016 at 11:28, Thomas Munro >>> wrote: Several times now when reading, debugging

Re: [HACKERS] Assert(LWLockHeldByMeInMode(lock, LW_EXCLUSIVE))

On 20/06/2016 06:28, Thomas Munro wrote: > On Mon, Jun 20, 2016 at 3:43 PM, Craig Ringer wrote: >> On 18 June 2016 at 11:28, Thomas Munro >> wrote: >>> Several times now when reading, debugging and writing code I've wished >>> that

Re: [HACKERS] condition variables

On Mon, Aug 15, 2016 at 10:35 PM, Robert Haas wrote: >>> Don't you need to set proc->cvSleeping = false in ConditionVariableSignal? >> >> I poked at this a bit... OK, a lot... and have some feedback: >> >> 1. As above, we need to clear cvSleeping before setting the latch.

Re: [HACKERS] Assert(LWLockHeldByMeInMode(lock, LW_EXCLUSIVE))

On 18 June 2016 at 04:28, Thomas Munro wrote: > Hi hackers, > > Several times now when reading, debugging and writing code I've wished > that LWLockHeldByMe assertions specified the expected mode, especially > where exclusive locking is required. > > What do you

Re: [HACKERS] Logical decoding slots can go backwards when used from SQL, docs are wrong

On 5 September 2016 at 16:33, Petr Jelinek wrote: >> The better alternative is to add a variant on >> pg_logical_slot_get_changes(...) etc that accepts a start LSN. But >> it's not convenient or easy for SQL callers to extract the last commit >> LSN received from the last

Re: [HACKERS] [PATCH] Send catalog_xmin separately in hot standby feedback

On 5 September 2016 at 14:44, Craig Ringer wrote: > On 5 September 2016 at 12:40, Craig Ringer wrote: >> Hi all >> >> Currently hot standby feedback sends GetOldestXmin()'s result to the >> upstream as the required xmin. GetOldestXmin() returns a

Re: [HACKERS] Optimization for lazy_scan_heap

On 4 August 2016 at 05:57, Masahiko Sawada wrote: > While reviewing freeze map code, Andres pointed out[1] that > lazy_scan_heap could accesses visibility map twice and its logic is > seems a bit tricky. > As discussed before, it's not nice especially when large relation

Re: [HACKERS] Speed up Clog Access by increasing CLOG buffers

On Mon, Sep 5, 2016 at 2:00 PM, Pavan Deolasee wrote: > > > On Mon, Sep 5, 2016 at 3:18 AM, Tomas Vondra > wrote: >> >> Hi, >> >> This thread started a year ago, different people contributed various >> patches, some of which already got

[HACKERS] Unused function arguments

While reading the logical replication (and related) code, I found a few unused function arguments: * XactLogCommitRecord() - unused argument forceSync * SnapBuildBuildSnapshot() - xid * TeardownHistoricSnapshot() - is_error No idea which ones are intended for future

Re: [HACKERS] Yet another small patch - reorderbuffer.c:1099

> I looked at this and can see some of the argument on both sides, but > if it's setting off static-analyzer warnings for some people, that > seems like a sufficient reason to change it. We certainly make more > significant changes than this in order to silence warnings. > > I rewrote the

Re: [HACKERS] Logical decoding slots can go backwards when used from SQL, docs are wrong

On 5 September 2016 at 03:41, Craig Ringer wrote: > On 2 September 2016 at 17:49, Craig Ringer wrote: > >> So the main change becomes the one-liner in my prior mail. > > Per feedback from Simon, updated with a new test in src/test/recovery . > > If

Re: [HACKERS] Logical decoding slots can go backwards when used from SQL, docs are wrong

On 05/09/16 04:41, Craig Ringer wrote: On 2 September 2016 at 17:49, Craig Ringer wrote: So the main change becomes the one-liner in my prior mail. Per feedback from Simon, updated with a new test in src/test/recovery . If you revert the change to

Re: [HACKERS] [PATCH] COPY vs \copy HINT

Re: Craig Ringer 2016-09-05 > To cover the same-host case we could try something like: > >COPY runs on the PostgreSQL server, using the PostgreSQL server's > directories and permissions, it doesn't run on the client. > >

Re: [HACKERS] Speed up Clog Access by increasing CLOG buffers

On Mon, Sep 5, 2016 at 3:18 AM, Tomas Vondra wrote: > Hi, > > This thread started a year ago, different people contributed various > patches, some of which already got committed. Can someone please post a > summary of this thread, so that it's a bit more clear what

Re: [HACKERS] Supporting SJIS as a database encoding

> Before digging into the problem, could you share your impression on whether > PostgreSQL can support SJIS? Would it be hopeless? Can't we find any > direction to go? Can I find relevant source code by searching specific words > like "ASCII", "HIGH_BIT", "\\" etc? For starters, you could

Re: [HACKERS] pgbench - allow to store select results into variables

Hi Fabien, On 2016/09/03 2:47, Fabien COELHO wrote: >> This patch needs to be rebased because of commit 64710452 (on 2016-08-19). > > Here it is! Thanks for sending the updated patch. Here are some (mostly cosmetic) comments. Before the comments, let me confirm whether the following result is

Re: [HACKERS] pg_basebackup stream xlog to tar

On Sat, Sep 3, 2016 at 10:35 PM, Magnus Hagander wrote: > Ugh. That would be nice to have, but I think that's outside the scope of > this patch. A test for this patch that could have value would be to use pg_basebackup -X stream -Ft, then untar pg_xlog.tar and look at the

Re: [HACKERS] Supporting SJIS as a database encoding

> From: pgsql-hackers-ow...@postgresql.org > [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Tatsuo Ishii > > But what I'm wondering is why PostgreSQL doesn't support SJIS. Was there > any technical difficulty? Is there anything you are worried about if adding > SJIS? > > Yes, there's

Re: [HACKERS] Supporting SJIS as a database encoding

> But what I'm wondering is why PostgreSQL doesn't support SJIS. Was there any > technical difficulty? Is there anything you are worried about if adding SJIS? Yes, there's a technical difficulty with backend code. In many places it is assumed that any string is "ASCII compatible", which means

[HACKERS] Supporting SJIS as a database encoding

Hello, I'd like to propose adding SJIS as a database encoding. You may wonder why SJIS is still necessary in the world of Unicode. The purpose is to achieve comparable performance when migrating legacy database systems from other DBMSs without little modification of applications. Recently,

Re: [HACKERS] Parallel build with MSVC

* Michael Paquier wrote: On Mon, Sep 5, 2016 at 9:18 AM, Noah Misch wrote: Every vcbuild and msbuild invocation ought to recognize this variable, so please update the two places involving ecpg_regression.proj. Apart from that, the patch looks good. Good catch. I did

Re: [HACKERS] pg_hba_file_settings view patch

On Sun, Sep 4, 2016 at 1:44 AM, Simon Riggs wrote: > On 15 August 2016 at 12:17, Haribabu Kommi > wrote: > > > comments? > > This looks like a good feature contribution, thanks. > > At present the patch doesn't apply cleanly, please rebase. >

Re: [HACKERS] LSN as a recovery target

On Mon, Sep 5, 2016 at 4:02 PM, Simon Riggs wrote: > On 5 September 2016 at 06:55, Michael Paquier > wrote: >> On Sun, Sep 4, 2016 at 11:30 PM, Simon Riggs wrote: > >>> I noticed we don't mention what LSN is anywhere, so

Re: [HACKERS] Better locale-specific-character-class handling for regexps

On 09/04/2016 08:44 PM, Tom Lane wrote: Heikki Linnakangas writes: On 08/23/2016 03:54 AM, Tom Lane wrote: +1 for this patch in general. Some regression test cases would be nice. I'm not sure how to write such tests without introducing insurmountable platform dependencies

Re: [HACKERS] LSN as a recovery target

On 5 September 2016 at 06:55, Michael Paquier wrote: > On Sun, Sep 4, 2016 at 11:30 PM, Simon Riggs wrote: >> I noticed we don't mention what LSN is anywhere, so I'd like to apply >> the following doc patch also. > > +1 for the idea. What do you

Re: [HACKERS] [PATCH] Send catalog_xmin separately in hot standby feedback

On 5 September 2016 at 12:40, Craig Ringer wrote: > Hi all > > Currently hot standby feedback sends GetOldestXmin()'s result to the > upstream as the required xmin. GetOldestXmin() returns a slot's > catalog_xmin if that's the lowest xmin on the system. Note that this