Re: [HACKERS] kqueue

On Tue, Oct 11, 2016 at 8:08 PM, Torsten Zuehlsdorff wrote: > On 28.09.2016 23:39, Thomas Munro wrote: >> It's difficult to draw any conclusions at this point. > > I'm currently setting up a new FreeBSD machine. Its a FreeBSD 11 with ZFS, > 64 GB RAM and Quad Core. If you're interested in i can gi

Re: [HACKERS] Get stuck when dropping a subscription during synchronizing table

On Wed, Jun 21, 2017 at 8:10 AM, Peter Eisentraut wrote: > On 6/19/17 22:54, Masahiko Sawada wrote: >>> It seems to me we could just take a stronger lock around >>> RemoveSubscriptionRel(), so that workers can't write in there concurrently. >> >> Since we reduced the lock level of updating pg_subs

Re: [HACKERS] Setting pd_lower in GIN metapage

On Wed, Jun 21, 2017 at 9:42 AM, Amit Langote wrote: > On 2017/06/20 20:37, Amit Kapila wrote: >> On Tue, Jun 20, 2017 at 1:50 PM, Amit Langote >> wrote: >>> On 2017/06/19 23:31, Tom Lane wrote: I'd suggest a rule like "if pd_lower is smaller than SizeOfPageHeaderData then don't trust i

[HACKERS] SQL MERGE patches for PostgreSQL Versions

Dear PG hackers, First my apology if I appear to be a jerk or not following the policy. I emailed Boxuan Zhai who was in charge of the SQL Merge keyword in 2010 of GSoC but without reply. I want to apply merge_v201.patch to specific PG version. It failed saying 1 or 2 of 5 hunk failed. My que

[HACKERS] pg_stop_backup(wait_for_archive := true) on standby server

Hi, Since an optional second argument wait_for_archive of pg_stop_backup has been introduced in PostgreSQL 10 we can choose whether wait for archiving. But my colleagues found that we can do pg_stop_backup with wait_for_archive = true on the standby server but it actually doesn't wait for WAL arc

Re: [HACKERS] SQL MERGE patches for PostgreSQL Versions

On Thu, Jun 22, 2017 at 5:05 PM, Kang Yuzhe wrote: > First my apology if I appear to be a jerk or not following the policy. No problem. > I emailed Boxuan Zhai who was in charge of the SQL Merge keyword in > 2010 of GSoC but without reply. > > I want to apply merge_v201.patch to specific PG ver

Re: [HACKERS] Autovacuum launcher occurs error when cancelled by SIGINT

On Thu, Jun 22, 2017 at 6:10 PM, Michael Paquier wrote: > On Thu, Jun 22, 2017 at 2:44 PM, Kuntal Ghosh > wrote: >> On Thu, Jun 22, 2017 at 9:48 AM, Michael Paquier >> wrote: >>> On Thu, Jun 22, 2017 at 1:29 AM, Kuntal Ghosh >>> wrote: But, I've some more doubts. 1. When should we use

Re: [HACKERS] SQL MERGE patches for PostgreSQL Versions

On 22 June 2017 at 16:05, Kang Yuzhe wrote: > Dear PG hackers, > > First my apology if I appear to be a jerk or not following the policy. > > I emailed Boxuan Zhai who was in charge of the SQL Merge keyword in > 2010 of GSoC but without reply. > > I want to apply merge_v201.patch to specific PG v

Re: [HACKERS] Optional message to user when terminating/cancelling backend

On Thu, 22 Jun 2017 09:24:54 +0900 Michael Paquier wrote: > On Wed, Jun 21, 2017 at 11:42 PM, Daniel Gustafsson wrote: > > The message is truncated in SetBackendCancelMessage() for safety, but > > pg_{cancel|terminate}_backend() could throw an error on too long message, or > > warning truncation

Re: [HACKERS] SQL MERGE patches for PostgreSQL Versions

On Thu, Jun 22, 2017 at 11:16 AM, Michael Paquier wrote: > On Thu, Jun 22, 2017 at 5:05 PM, Kang Yuzhe wrote: >> First my apology if I appear to be a jerk or not following the policy. > > No problem. > >> I emailed Boxuan Zhai who was in charge of the SQL Merge keyword in >> 2010 of GSoC but wit

Re: [HACKERS] An attempt to reduce WALWriteLock contention

On 2017-06-22 04:16, Michael Paquier wrote: On Wed, Jun 21, 2017 at 4:57 PM, jasrajd wrote: We are also seeing contention on the walwritelock and repeated writes to the same offset if we move the flush outside the lock in the Azure environment. pgbench doesn't scale beyond ~8 cores without sa

Re: [HACKERS] Incorrect documentation about pg_stat_activity

On Wed, Jun 21, 2017 at 7:48 PM, Simon Riggs wrote: > On 21 June 2017 at 16:15, Yugo Nagata wrote: >> On Wed, 21 Jun 2017 19:08:35 +0530 >> Kuntal Ghosh wrote: >> >>> On Wed, Jun 21, 2017 at 6:05 PM, Yugo Nagata wrote: >>> > >>> > Attached is a patch for the documentation fix. >>> > >>> Please

Re: [HACKERS] Incorrect documentation about pg_stat_activity

On Thu, 22 Jun 2017 14:14:53 +0530 Ashutosh Bapat wrote: > On Wed, Jun 21, 2017 at 7:48 PM, Simon Riggs wrote: > > On 21 June 2017 at 16:15, Yugo Nagata wrote: > >> On Wed, 21 Jun 2017 19:08:35 +0530 > >> Kuntal Ghosh wrote: > >> > >>> On Wed, Jun 21, 2017 at 6:05 PM, Yugo Nagata wrote: > >>>

Re: [HACKERS] SQL MERGE patches for PostgreSQL Versions

On Thu, Jun 22, 2017 at 11:23 AM, Craig Ringer wrote: > On 22 June 2017 at 16:05, Kang Yuzhe wrote: >> Dear PG hackers, >> >> First my apology if I appear to be a jerk or not following the policy. >> >> I emailed Boxuan Zhai who was in charge of the SQL Merge keyword in >> 2010 of GSoC but witho

Re: [HACKERS] SQL MERGE patches for PostgreSQL Versions

On Thu, Jun 22, 2017 at 9:00 PM, Kang Yuzhe wrote: > I just downloaded the patch from GSoC site. I just looked at https://wiki.postgresql.org/wiki/Add_MERGE_command_GSoC_2010 and saw that the file https://wiki.postgresql.org/wiki/File:Merge_v201.tar was uploaded on 24 Aug 2010. So I picked a ran

Re: [HACKERS] SQL MERGE patches for PostgreSQL Versions

On 22 June 2017 at 17:00, Kang Yuzhe wrote: > diff --git a/src/backend/executor/nodeModifyTable.c > b/src/backend/executor/nodeModifyTable.c > index 8619ce3..e3ac758 100644 > --- a/src/backend/executor/nodeModifyTable.c > +++ b/src/backend/executor/nodeModifyTable.c The first entry in the 'index

Re: [HACKERS] Setting pd_lower in GIN metapage

On 2017/06/22 16:56, Michael Paquier wrote: > On Wed, Jun 21, 2017 at 9:42 AM, Amit Langote > wrote: >> On 2017/06/20 20:37, Amit Kapila wrote: >>> On Tue, Jun 20, 2017 at 1:50 PM, Amit Langote >>> wrote: On 2017/06/19 23:31, Tom Lane wrote: > I'd suggest a rule like "if pd_lower is smal

Re: [HACKERS] A bug in mapping attributes in ATExecAttachPartition()

On Thu, Jun 15, 2017 at 4:06 PM, Amit Langote wrote: > > Anyway, I tried to implement the refactoring in patch 0002, which is not > all of the patch 0001 that Jeevan posted. Please take a look. I wondered > if we should emit a NOTICE when an individual leaf partition validation > can be skipped?

Re: [HACKERS] Regarding Postgres Dynamic Shared Memory (DSA)

Hi Thomas, I'm implementing the In-Memory index as per your suggestion. So far it's good. As of now, only one thing is unclear for me. How could i detach the dsa(dsa_detach() call) in backend (typically during backend quit). Of-course when process quits, all it's associated memory will be

[HACKERS] TRUE and true

Hello, I have a maybe-silly question. What makes us have both TRUE/true or FALSE/false as constants of bool? The following definitions in c.h didn't mess anything up. #define TRUEtrue #define FALSE false # NIL seems causing similar mess. regards, -- Kyotaro Horiguchi NTT Open Source S

Re: [HACKERS] PATCH: Batch/pipelining support for libpq

Craig Ringer wrote: > The kernel will usually do some packet aggregation unless we use > TCP_NODELAY (which we don't and shouldn't) Not sure. As a point of comparison, Oracle has it as a tunable parameter (TCP.NODELAY), and they changed its default from No to Yes starting from their 10g R

Re: [HACKERS] Regarding Postgres Dynamic Shared Memory (DSA)

On Thu, Jun 22, 2017 at 10:59 PM, Mahendranath Gurram wrote: > I'm implementing the In-Memory index as per your suggestion. So far it's > good. Great news. > As of now, only one thing is unclear for me. How could i detach the > dsa(dsa_detach() call) in backend (typically during backend quit). >

Re: [HACKERS] PATCH: Batch/pipelining support for libpq

Andres Freund wrote: - if (pqFlush(conn) < 0) - goto sendFailed; + if (conn->batch_status == PQBATCH_MODE_OFF) + { + /* +* Give the data a push. In nonblock mode, don't complain if we're unable +* to send it all

[HACKERS] Multi column range partition table

Hi, While working on the another patch, I came across the case where I need an auto generated partition for a mutil-column range partitioned table having following range bound: PARTITION p1 FROM (UNBOUNDED, UNBOUNDED) TO (10, 10) PARTITION p2 FROM (10, 10) TO (10, UNBOUNDED) PARTITION p3 FROM

Re: [HACKERS] SQL MERGE patches for PostgreSQL Versions

On Thu, Jun 22, 2017 at 5:30 PM, Kang Yuzhe wrote: > I wish I could but it's because I don't believe that I have the right > capability to fix code conflicts. My ultimate goal is to be PG hacker > like YOU. Anyway, I will consider your perspective. Nice to see such a goal, though as a first patc

Re: [HACKERS] Pluggable storage

On Tue, Jun 13, 2017 at 4:50 AM, Haribabu Kommi wrote: > On Fri, Oct 14, 2016 at 7:26 AM, Alvaro Herrera > wrote: > >> I have sent the partial patch I have to Hari Babu Kommi. We expect that >> he will be able to further this goal some more. > > > Thanks Alvaro for sharing your development patc

Re: [HACKERS] Pluggable storage

On Thu, Jun 22, 2017 at 4:01 AM, Michael Paquier wrote: > Putting that in a couple of words. > 1. Table AM with a 6-byte TID. > 2. Table AM with a custom locator format, which could be TID-like. > 3. Table AM with no locators. > > Getting into having #1 first to work out would already be really >

Re: [HACKERS] TRUE and true

On Thu, Jun 22, 2017 at 2:09 PM, Kyotaro HORIGUCHI < horiguchi.kyot...@lab.ntt.co.jp> wrote: > Hello, I have a maybe-silly question. > > What makes us have both TRUE/true or FALSE/false as constants of > bool? > > The following definitions in c.h didn't mess anything up. > > #define TRUEtrue >

[HACKERS] [patch] pg_dump/pg_restore zerror() and strerror() mishap

Hello, our testing team has noticed apparently wrong backup/restore error messages like this: pg_restore: [compress_io] could not read from input file: success pg_dump: [directory archiver] could not write to output file: success Such "success" messages are caused by calling strerror() a

Re: [HACKERS] SQL MERGE patches for PostgreSQL Versions

On 6/22/17 05:13, Craig Ringer wrote: > On 22 June 2017 at 17:00, Kang Yuzhe wrote: > >> diff --git a/src/backend/executor/nodeModifyTable.c >> b/src/backend/executor/nodeModifyTable.c >> index 8619ce3..e3ac758 100644 >> --- a/src/backend/executor/nodeModifyTable.c >> +++ b/src/backend/executor/n

Re: [HACKERS] TRUE and true

On 6/22/17 07:09, Kyotaro HORIGUCHI wrote: > What makes us have both TRUE/true or FALSE/false as constants of > bool? Historical reasons, probably. I plan to submit a patch to phase out or remove TRUE/FALSE as part of a migration toward stdbool.h. So I suggest you use lower case and don't worry

Re: [HACKERS] pg_stop_backup(wait_for_archive := true) on standby server

On Thu, Jun 22, 2017 at 10:12 AM, Masahiko Sawada wrote: > Hi, > > Since an optional second argument wait_for_archive of pg_stop_backup > has been introduced in PostgreSQL 10 we can choose whether wait for > archiving. But my colleagues found that we can do pg_stop_backup with > wait_for_archive

Re: [HACKERS] Fix a typo in partition.c

On Thu, Jun 22, 2017 at 4:16 AM, Masahiko Sawada wrote: > On Wed, Jun 21, 2017 at 3:32 AM, Peter Eisentraut > wrote: > > On 6/19/17 23:02, Masahiko Sawada wrote: > >> Hi, > >> > >> Attached patch for $subject. > >> > >> s/opreator/operator/ > > > > fixed > > > > Thank you! > I found another one.

Re: [HACKERS] Optional message to user when terminating/cancelling backend

> On 22 Jun 2017, at 10:24, Yugo Nagata wrote: > > On Thu, 22 Jun 2017 09:24:54 +0900 > Michael Paquier wrote: > >> On Wed, Jun 21, 2017 at 11:42 PM, Daniel Gustafsson wrote: >>> The message is truncated in SetBackendCancelMessage() for safety, but >>> pg_{cancel|terminate}_backend() could thr

Re: [HACKERS] intermittent failures in Cygwin from select_parallel tests

On 06/21/2017 06:44 PM, Tom Lane wrote: > Today, lorikeet failed with a new variant on the bgworker start crash: > > https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=lorikeet&dt=2017-06-21%2020%3A29%3A10 > > This one is even more exciting than the last one, because it sure looks > like the

Re: [HACKERS] intermittent failures in Cygwin from select_parallel tests

Andrew Dunstan writes: > Please let me know if there are tests I can run. I missed your earlier > request in this thread, sorry about that. That earlier request is still valid. Also, if you can reproduce the symptom that lorikeet just showed and get a stack trace from the (hypothetical) postmas

Re: [HACKERS] Pluggable storage

On Thu, Jun 22, 2017 at 8:32 AM, Alexander Korotkov wrote: > On Thu, Jun 22, 2017 at 4:01 AM, Michael Paquier > wrote: >> Putting that in a couple of words. >> 1. Table AM with a 6-byte TID. >> 2. Table AM with a custom locator format, which could be TID-like. >> 3. Table AM with no locators. >>

Re: [HACKERS] Pluggable storage

On Wed, Jun 21, 2017 at 10:47 PM, Robert Haas wrote: > On Mon, Jun 12, 2017 at 9:50 PM, Haribabu Kommi > wrote: > > Open Items: > > > > 1. The BitmapHeapScan and TableSampleScan are tightly coupled with > > HeapTuple and HeapScanDesc, So these scans are directly operating > > on those structures

Re: [HACKERS] Pluggable storage

On Thu, Jun 22, 2017 at 5:27 PM, Robert Haas wrote: > On Thu, Jun 22, 2017 at 8:32 AM, Alexander Korotkov > wrote: > > On Thu, Jun 22, 2017 at 4:01 AM, Michael Paquier < > michael.paqu...@gmail.com> > > wrote: > >> Putting that in a couple of words. > >> 1. Table AM with a 6-byte TID. > >> 2. Ta

Re: [HACKERS] Re-indent HEAD tomorrow?

On Wed, Jun 21, 2017 at 5:28 PM, Tom Lane wrote: > Right now we're really just speculating about how much pain there will > be, on either end of this. So it'd be interesting for somebody who's > carrying large out-of-tree patches (EDB? Citus?) to try the new > pgindent version on a back branch an

Re: [HACKERS] Multiple TO version in ALTER EXTENSION UPDATE

On Wed, Mar 29, 2017 at 11:13 AM, Daniel Gustafsson wrote: > While reading I noticed that we allow multiple TO in ALTER EXTENSION > UPDATE, and defer throwing a syntax error until command processing. Is there > a > reason for deferring and not handling it in gram.y directly as in the attached >

Re: [HACKERS] Prologue of set_append_rel_size() and partitioned tables

On Wed, Mar 29, 2017 at 3:18 AM, Ashutosh Bapat wrote: >> Update patch attached. > > Looks good to me. Committed. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes t

Re: [HACKERS] Redundant check of em_is_child

On Fri, May 19, 2017 at 3:46 AM, Amit Langote wrote: > In match_eclasses_to_foreign_key_col(), there is this: > > if (em->em_is_child) > continue; /* ignore children here */ > > ISTM, it might as well be: > > Assert(!em->em_is_child);/* no children

Re: [HACKERS] Multiple TO version in ALTER EXTENSION UPDATE

Robert Haas writes: > On Wed, Mar 29, 2017 at 11:13 AM, Daniel Gustafsson wrote: >> While reading I noticed that we allow multiple TO in ALTER >> EXTENSION >> UPDATE, and defer throwing a syntax error until command processing. Is >> there a >> reason for deferring and not handling it in gram.

Re: [HACKERS] [psql] patch to fix ordering in words_after_create array

On Fri, Mar 24, 2017 at 7:10 AM, Rushabh Lathia wrote: > While looking at the code around tab-complete.c, I > found the ordering in words_after_create array is not > correct for DEFAULT PRIVILEGES, which been added > under below commit: > > commit d7d77f3825122bde55be9e06f6c4851028b99795 > Author:

Re: [HACKERS] Multiple TO version in ALTER EXTENSION UPDATE

> On 22 Jun 2017, at 17:02, Tom Lane wrote: > > Robert Haas writes: >> On Wed, Mar 29, 2017 at 11:13 AM, Daniel Gustafsson wrote: >>> While reading I noticed that we allow multiple TO in ALTER >>> EXTENSION >>> UPDATE, and defer throwing a syntax error until command processing. Is >>> there

Re: [HACKERS] [patch] pg_dump/pg_restore zerror() and strerror() mishap

Kunshchikov Vladimir wrote: Hi, > our testing team has noticed apparently wrong backup/restore error > messages like this: > > > pg_restore: [compress_io] could not read from input file: success > pg_dump: [directory archiver] could not write to output file: success > > > > Such "succes

Re: [HACKERS] GSoC 2017 Proposal for predicate locking in hash index

Shubham Barai wrote: > Hi, > > Now that hash index support write-ahead logging, it will be great if we add > support for predicate locking to it. > Implementation of predicate locking in hash index seems very simple. > I have already made changes in the code. I am currently working on testing. So

Re: [HACKERS] PATCH: Batch/pipelining support for libpq

Hi, On 2017-06-22 13:43:35 +0200, Daniel Verite wrote: > But OTOH there are certainly batch workloads where it will be preferrable > for the first query to reach the server ASAP, rather than waiting to be > coalesced with the next ones. Is that really something people expect from a batch API? I

Re: [HACKERS] Optional message to user when terminating/cancelling backend

On Thu, Jun 22, 2017 at 7:18 PM, Daniel Gustafsson wrote: > Good point. I’ve attached a new version which issues a NOTICE on truncation > and also addresses all other comments so far in this thread. Thanks a lot for > the early patch reviews! > > cheers ./daniel I have done an initial review of

Re: [HACKERS] pg_stop_backup(wait_for_archive := true) on standby server

On Thu, Jun 22, 2017 at 10:36 PM, Magnus Hagander wrote: > > > On Thu, Jun 22, 2017 at 10:12 AM, Masahiko Sawada > wrote: >> >> Hi, >> >> Since an optional second argument wait_for_archive of pg_stop_backup >> has been introduced in PostgreSQL 10 we can choose whether wait for >> archiving. But

Re: [HACKERS] SQL MERGE patches for PostgreSQL Versions

On Thu, Jun 22, 2017 at 12:10 PM, Thomas Munro wrote: > On Thu, Jun 22, 2017 at 9:00 PM, Kang Yuzhe wrote: >> I just downloaded the patch from GSoC site. > > I just looked at > https://wiki.postgresql.org/wiki/Add_MERGE_command_GSoC_2010 and saw > that the file https://wiki.postgresql.org/wiki/Fi

Re: [HACKERS] lseek/read/write overhead becomes visible at scale ..

On Wed, Jan 25, 2017 at 2:52 PM, Andres Freund wrote: > You'll, depending on your workload, still have a lot of lseeks even if > we were to use pread/pwrite because we do lseek(SEEK_END) to get file > sizes. I'm pretty convinced that the lseek overhead that we're incurring right now is excessive.

Re: [HACKERS] SQL MERGE patches for PostgreSQL Versions

On Thu, Jun 22, 2017 at 3:51 PM, Peter Eisentraut wrote: > On 6/22/17 05:13, Craig Ringer wrote: >> On 22 June 2017 at 17:00, Kang Yuzhe wrote: >> >>> diff --git a/src/backend/executor/nodeModifyTable.c >>> b/src/backend/executor/nodeModifyTable.c >>> index 8619ce3..e3ac758 100644 >>> --- a/src/b

Re: [HACKERS] Misplacement of function declaration in contrib/postgres_fdw/postgres_fdw.h

On Wed, Jan 11, 2017 at 10:19 PM, Etsuro Fujita wrote: > While working on pushing down more joins/updates to the remote, I noticed > that in contrib/postgres_fdw/postgres_fdw.h the declaration of > get_jointype_name is misplaced in the section of shippable.c. Since that > function is defined in c

Re: [HACKERS] lseek/read/write overhead becomes visible at scale ..

On 2017-06-22 12:43:16 -0400, Robert Haas wrote: > On Wed, Jan 25, 2017 at 2:52 PM, Andres Freund wrote: > > You'll, depending on your workload, still have a lot of lseeks even if > > we were to use pread/pwrite because we do lseek(SEEK_END) to get file > > sizes. > > I'm pretty convinced that th

Re: [HACKERS] SQL MERGE patches for PostgreSQL Versions

On Thursday, June 22, 2017 12:32:14 PM EDT Kang Yuzhe wrote: > Here is a sample what I did after applying the patch. > > testdb=# BEGIN; > BEGIN > testdb=# > testdb=# MERGE INTO Stock USING Buy ON Stock.item_id = Buy.item_id > testdb-# WHEN MATCHED THEN UPDATE SET balance = balance + Buy.volume >

Re: [HACKERS] SQL MERGE patches for PostgreSQL Versions

On Thu, Jun 22, 2017 at 7:52 PM, Jan de Visser wrote: > On Thursday, June 22, 2017 12:32:14 PM EDT Kang Yuzhe wrote: >> Here is a sample what I did after applying the patch. >> >> testdb=# BEGIN; >> BEGIN >> testdb=# >> testdb=# MERGE INTO Stock USING Buy ON Stock.item_id = Buy.item_id >> testdb-#

Re: [HACKERS] SQL MERGE patches for PostgreSQL Versions

On Thu, Jun 22, 2017 at 3:13 PM, Michael Paquier wrote: > On Thu, Jun 22, 2017 at 5:30 PM, Kang Yuzhe wrote: >> I wish I could but it's because I don't believe that I have the right >> capability to fix code conflicts. My ultimate goal is to be PG hacker >> like YOU. Anyway, I will consider your

Re: [HACKERS] SQL MERGE patches for PostgreSQL Versions

On Thu, Jun 22, 2017 at 9:52 AM, Jan de Visser wrote: > I am not quite sure what you're trying to achieve, but are you aware that > pgsql 9.6 introduced the ON CONFLICT clause, which allows you to do the same > with a different syntax? > > https://www.postgresql.org/docs/9.6/static/sql-insert.html

Re: [HACKERS] GSoC 2017 Proposal for predicate locking in hash index

Hi, On 22 June 2017 at 21:12, Alvaro Herrera wrote: > Shubham Barai wrote: > > Hi, > > > > Now that hash index support write-ahead logging, it will be great if we > add > > support for predicate locking to it. > > Implementation of predicate locking in hash index seems very simple. > > I have al

Re: [HACKERS] possible self-deadlock window after bad ProcessStartupPacket

On Thu, Feb 2, 2017 at 3:18 PM, Jimmy Yih wrote: > In that pull request, we fix the issue by checking for proc_exit_inprogress. > Is there a reason why startup_die should not check for proc_exit_inprogress? startup_die() is just calling proc_exit(), so it seems like it might be better to fix it b

Re: [HACKERS] Fast promotion not used when doing a recovery_target PITR restore?

On 2017-06-22 14:04:42 +0900, Michael Paquier wrote: > On Thu, Jun 22, 2017 at 3:04 AM, Andres Freund wrote: > > When doing a PITR style recovery, with recovery target set, we're > > currently not doing a fast promotion, in contrast to the handling when > > doing a pg_ctl or trigger file based pro

Re: [HACKERS] Stale comments in vacuumlazy.c

On Sun, Mar 26, 2017 at 3:22 PM, Pavan Deolasee wrote: > I happened to notice a stale comment at the very beginning of vacuumlazy.c. > ISTM we forgot to fix that when we introduced FSM. With FSM, vacuum no > longer needed to track per-page free space info. I propose attached fix. Committed. --

Re: [HACKERS] possible self-deadlock window after bad ProcessStartupPacket

On 2017-02-02 12:18:22 -0800, Jimmy Yih wrote: > In the above pull request, Heikki also mentions that a similar scenario can > happen during palloc() as well... which is similar to what we saw in > Greenplum a couple years back for a deadlock in a malloc() call where we > responded by changing exit

Re: [HACKERS] PATCH: Batch/pipelining support for libpq

Andres Freund wrote: > > One option may be to leave that decision to the user by providing a > > PQBatchAutoFlush(true|false) property, along with a PQBatchFlush() > > function. > > What'd be the difference between PQflush() and PQbatchFlush()? I guess no difference, I was just not seein

Re: [HACKERS] shift_sjis_2004 related autority files are remaining

On Fri, Apr 7, 2017 at 1:59 AM, Kyotaro HORIGUCHI wrote: > Hi, I happned to notice that backend/utils/mb/Unicode directory > contains two encoding authority files, which I believe are not to > be there. > > euc-jis-2004-std.txt > sjis-0213-2004-std.txt > > And what is more astonishing, make distcl

Re: [HACKERS] possible self-deadlock window after bad ProcessStartupPacket

On 2017-06-22 10:41:41 -0700, Andres Freund wrote: > On 2017-02-02 12:18:22 -0800, Jimmy Yih wrote: > > In the above pull request, Heikki also mentions that a similar scenario can > > happen during palloc() as well... which is similar to what we saw in > > Greenplum a couple years back for a deadlo

Re: [HACKERS] Autovacuum launcher occurs error when cancelled by SIGINT

Thomas Munro wrote: > Hmm. So the problem here is that AutoVacLauncherMain assumes that > there are only two possibilities: (1) there is no handle published in > shmem yet, so we should create a DSA area and publish the handle, and > (2) there is a handle published in shmem so we should attach to

Re: [HACKERS] Missing comment for create_modifytable_path

On Thu, Jun 15, 2017 at 4:40 AM, Etsuro Fujita wrote: > While working on adding support for tuple routing for foreign partitions, I > noticed that in create_modifytable_path, we forgot to add a comment on its > new argument 'partitioned_rels'. Attached a patch for including that in the > comments

Re: [HACKERS] Re-indent HEAD tomorrow?

On Thu, Jun 22, 2017 at 10:38:41AM -0400, Robert Haas wrote: > On Wed, Jun 21, 2017 at 5:28 PM, Tom Lane wrote: > > Right now we're really just speculating about how much pain there will > > be, on either end of this. So it'd be interesting for somebody who's > > carrying large out-of-tree patche

Re: [HACKERS] Autovacuum launcher occurs error when cancelled by SIGINT

Yugo Nagata wrote: > Hi, > > As I report in another thread[1], I found the autovacuum launcher occurs > the following error in PG 10 when this received SIGINT. I can repuroduce > this by pg_cancel_backend or `kill -2 `. Thanks for the report, BTW! -- Álvaro Herrerahttps://www.2n

[HACKERS] Guarding against bugs-of-omission in initdb's setup_depend

While thinking about something else, it started to bother me that initdb's setup_depend() function knows exactly which catalogs might contain pinnable objects. It is not very hard to imagine that somebody might add a DATA() line to, say, pg_transform.h and expect that the represented object could

Re: [HACKERS] possible self-deadlock window after bad ProcessStartupPacket

Andres Freund writes: > Or, probably more robust: Simply _exit(2) without further ado, and rely > on postmaster to output an appropriate error message. Arguably it's not > actually useful to see hundreds of "WARNING: terminating connection because of > crash of another server process" messages in

Re: [HACKERS] Adding support for Default partition in partitioning

On Wed, Jun 21, 2017 at 8:47 PM, Amit Langote wrote: > It's the comma inside the error message that suggests to me that it's a > style that I haven't seen elsewhere in the backend code. Exactly. Avoid that. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Comp

Re: [HACKERS] Guarding against bugs-of-omission in initdb's setup_depend

On Thu, Jun 22, 2017 at 2:11 PM, Tom Lane wrote: > While thinking about something else, it started to bother me that > initdb's setup_depend() function knows exactly which catalogs might > contain pinnable objects. It is not very hard to imagine that somebody > might add a DATA() line to, say, pg

Re: [HACKERS] Fix comment in xlog.c

Amit Langote wrote: > Attached a patch for $SUBJECT. > > - * If RecPtr is not NULL, try to read a record at that position. Otherwise > + * If RecPtr is valid, try to read a record at that position. Otherwise > > Commit 4d6d425ab8d addressed the comment above XLogReadRecord() in > xlogreader.c,

[HACKERS] Dynamic instrumentation of lwlock wait times (lwlock flamegraphs)

Hi, At pgcon some people were talking about the difficulty of instrumenting the time actually spent waiting for lwlocks and related measurements. I'd mentioned that linux these days provides infrastructure to measure such things in unmodified binaries. Attached is a prototype of a script that mea

Re: [HACKERS] Pluggable storage

Hi, On 6/21/17 9:47 PM, Robert Haas wrote: ... > like int8 or numeric, it won't work at all. Even for other things, it's going to cause problems because the bit patterns won't be what the code is expecting; e.g. bitmap scans care about the structure of the TID, not just how many bits it is. (D

Re: [HACKERS] Fix a typo in README.dependencies

Ashutosh Bapat wrote: > On Mon, Jun 5, 2017 at 8:22 AM, atorikoshi > wrote: > > Hi, > > > > I found below formula to compute selectivities, but > > I think the last Probability 'P(b=?)' should be 'P(c=?)'. > > > >> P(a=?,b=?,c=?) = P(a=?,b=?) * (d + (1-d)*P(b=?)) > > > > > > Attached patch fixes

Re: [HACKERS] Autovacuum launcher occurs error when cancelled by SIGINT

On Thu, Jun 22, 2017 at 4:29 AM, Kuntal Ghosh wrote: > On Wed, Jun 21, 2017 at 7:52 PM, Dilip Kumar wrote: >> On Wed, Jun 21, 2017 at 7:47 PM, Kuntal Ghosh >> wrote: IMHO, It's not a good idea to use DSM call to verify the DSA handle. >>> Okay. Is there any particular scenario you've i

Re: [HACKERS] Pluggable storage

Hi, On 6/22/17 4:36 PM, Alexander Korotkov wrote: On Thu, Jun 22, 2017 at 5:27 PM, Robert Haas > wrote: On Thu, Jun 22, 2017 at 8:32 AM, Alexander Korotkov mailto:a.korot...@postgrespro.ru>> wrote: > On Thu, Jun 22, 2017 at 4:01 AM, Michael Paquier mail

Re: [HACKERS] Proposal : For Auto-Prewarm.

On Thu, Jun 15, 2017 at 12:35 AM, Mithun Cy wrote: > [ new patch ] I think this is looking better. I have some suggestions: * I suggest renaming launch_autoprewarm_dump() to autoprewarm_start_worker(). I think that will be clearer. Remember that user-visible names, internal names, and the doc

Re: [HACKERS] Autovacuum launcher occurs error when cancelled by SIGINT

Thomas Munro wrote: > I thought about this when designing the DSA API. I couldn't think of > any good reason to provide an 'am-I-already-attached?' function > equivalent to dsm_find_mapping. It seemed to me that the client code > shouldn't ever be in any doubt about whether it's attached, and th

Re: [HACKERS] initdb initalization failure for collation "ja_JP"

I wrote: > Now the hard part of that is that because pg_import_system_collations > isn't using a temporary staging table, but is just inserting directly > into pg_collation, there isn't any way for it to eliminate duplicates > unless it uses if_not_exists behavior all the time. So there seem to >

Re: [HACKERS] shift_sjis_2004 related autority files are remaining

> Hi, I happned to notice that backend/utils/mb/Unicode directory > contains two encoding authority files, which I believe are not to > be there. > > euc-jis-2004-std.txt > sjis-0213-2004-std.txt Why do you believe so? -- Tatsuo Ishii SRA OSS, Inc. Japan English: http://www.sraoss.co.jp/index_en.

Re: [HACKERS] Autovacuum launcher occurs error when cancelled by SIGINT

On Fri, Jun 23, 2017 at 7:02 AM, Alvaro Herrera wrote: > Thomas Munro wrote: >> I thought about this when designing the DSA API. I couldn't think of >> any good reason to provide an 'am-I-already-attached?' function >> equivalent to dsm_find_mapping. It seemed to me that the client code >> shoul

Re: [HACKERS] Pluggable storage

On Thu, Jun 22, 2017 at 11:27 PM, Robert Haas wrote: > On Thu, Jun 22, 2017 at 8:32 AM, Alexander Korotkov > wrote: >> On Thu, Jun 22, 2017 at 4:01 AM, Michael Paquier >> wrote: >>> Putting that in a couple of words. >>> 1. Table AM with a 6-byte TID. >>> 2. Table AM with a custom locator format

Re: [HACKERS] shift_sjis_2004 related autority files are remaining

On Fri, Jun 23, 2017 at 8:12 AM, Tatsuo Ishii wrote: >> Hi, I happned to notice that backend/utils/mb/Unicode directory >> contains two encoding authority files, which I believe are not to >> be there. (Worked on that with Horiguchi-san a couple of weeks back.) >> euc-jis-2004-std.txt >> sjis-02

Re: [HACKERS] Proposal : For Auto-Prewarm.

On 22 June 2017 at 22:52, Robert Haas wrote: > On Thu, Jun 15, 2017 at 12:35 AM, Mithun Cy > wrote: >> [ new patch ] > > I think this is looking better. I have some suggestions: > > * I suggest renaming launch_autoprewarm_dump() to > autoprewarm_start_worker(). I think that will be clearer. R

Re: [HACKERS] Redundant check of em_is_child

On 2017/06/23 0:00, Robert Haas wrote: > On Fri, May 19, 2017 at 3:46 AM, Amit Langote > wrote: >> In match_eclasses_to_foreign_key_col(), there is this: >> >> if (em->em_is_child) >> continue; /* ignore children here */ >> >> ISTM, it might as well be: >> >>

Re: [HACKERS] Fix comment in xlog.c

On 2017/06/23 5:44, Alvaro Herrera wrote: > Amit Langote wrote: >> Attached a patch for $SUBJECT. >> >> - * If RecPtr is not NULL, try to read a record at that position. Otherwise >> + * If RecPtr is valid, try to read a record at that position. Otherwise >> >> Commit 4d6d425ab8d addressed the co

Re: [HACKERS] shift_sjis_2004 related autority files are remaining

>> Why do you believe so? > > Unicode/Makefile includes that: > euc-jis-2004-std.txt sjis-0213-2004-std.txt: > $(DOWNLOAD) http://x0213.org/codetable/$(@F) > > So those files ought to be downloaded when rebuilding the maps, and > they should not be in the tree. In short, I think that Hori

Re: [HACKERS] shift_sjis_2004 related autority files are remaining

On Fri, Jun 23, 2017 at 9:39 AM, Tatsuo Ishii wrote: > I think we should keep the original .txt files because: Hm. I am wondering about licensing issues here to keep those files in the tree. I am no lawyer. > - It allows to track the changes in the original file if we decide to > change the ma

Re: [HACKERS] shift_sjis_2004 related autority files are remaining

> Hm. I am wondering about licensing issues here to keep those files in > the tree. I am no lawyer. Of course. Regarding euc-jis-2004-std.txt and sjis-0213-2004-std.txt, it seems safe to keep them. > ## Date: 13 May 2006 > ## License: > ##Copyright (C) 2001 earth...@tama.or.jp, All Rights Res

Re: [HACKERS] Setting pd_lower in GIN metapage

On Thu, Jun 22, 2017 at 6:55 PM, Amit Langote wrote: > On 2017/06/22 16:56, Michael Paquier wrote: >> On Wed, Jun 21, 2017 at 9:42 AM, Amit Langote >> wrote: >>> On 2017/06/20 20:37, Amit Kapila wrote: On Tue, Jun 20, 2017 at 1:50 PM, Amit Langote wrote: > On 2017/06/19 23:31, Tom

Re: [HACKERS] Multi column range partition table

On 2017/06/22 20:48, amul sul wrote: > Hi, > > While working on the another patch, I came across the case where > I need an auto generated partition for a mutil-column range partitioned > table having following range bound: > > PARTITION p1 FROM (UNBOUNDED, UNBOUNDED) TO (10, 10) > PARTITION p2

[HACKERS] ICU non-utf8 code path leaks memory like there's no tomorrow

In a database with utf8 encoding, this behaves reasonably: select count(*) from (select * from generate_series(1,1000) x order by x::text collate "en-x-icu") ss; It eats circa 25MB, not a lot worse than the libc-collation equivalent. But try it in say LATIN1, and it eats multiple gigabytes.

Re: [HACKERS] transition table behavior with inheritance appears broken

On Sun, Jun 18, 2017 at 11:59:43PM +0100, Andrew Gierth wrote: > > "Andrew" == Andrew Gierth writes: > > Andrew> Unfortunately I've been delayed over the past couple of days, > Andrew> but I have Thomas' latest patchset in hand and will be working > Andrew> on it over the rest of the week.

Re: [HACKERS] Fast promotion not used when doing a recovery_target PITR restore?

On Fri, Jun 23, 2017 at 2:34 AM, Andres Freund wrote: > I don't think it's really a bug - just a missed optimization. I'd > personally not be in favor of backpatching this - it'll have some chance > of screwing things up, even if I hope that chance is fairly small. It would be better to wait unt

  1   2   >