Re: [HACKERS] Making tab-complete.c easier to maintain

Thomas Munro wrote: > New version attached, merging recent changes. I wonder about the TailMatches and Matches macros --- wouldn't it be better to have a single one, renaming TailMatches to Matches and replacing the current Matches() with an initial token that corresponds to anchoring to start of

Re: [HACKERS] Support for N synchronous standby servers - take 2

On Fri, Nov 13, 2015 at 12:52 PM, Kyotaro HORIGUCHI wrote: > Hello, > > At Fri, 13 Nov 2015 09:07:01 +0900, Masahiko Sawada > wrote in >> On Thu, Oct 29, 2015 at 11:16

Re: [HACKERS] [DESIGN] ParallelAppend

> On Thu, Nov 12, 2015 at 12:09 AM, Kouhei Kaigai wrote: > > I'm now designing the parallel feature of Append... > > > > Here is one challenge. How do we determine whether each sub-plan > > allows execution in the background worker context? > > I've been thinking about

Re: [HACKERS] check for interrupts in set_rtable_names

I wrote: > I experimented with using a hash table to avoid the O(N^2) behavior. > This seems to work quite well, and I think it doesn't change the results > (leastwise, it does not break the regression tests). Looking at this again in the light of morning, it occurred to me that it's pretty

Re: [HACKERS] Making tab-complete.c easier to maintain

Kyotaro HORIGUCHI wrote: > Auto-generating from grammer should be the ultimate solution but > I don't think it will be available. But still I found that the > word-splitting-then-match-word-by-word-for-each-matching is > terriblly unmaintainable and poorly capable. So, how about > regular

Re: [HACKERS] proposal: multiple psql option -c

On Sun, Nov 15, 2015 at 3:53 PM, Andrew Dunstan wrote: > I suggest you review the original thread on this subject before a line was > ever written. "multiple" (see subject line on this whole thread) is clearly > what is being asked for. Making people turn that into a single

Re: [HACKERS] proposal: multiple psql option -c

On 11/15/2015 08:24 PM, Peter Eisentraut wrote: On 11/15/15 9:53 AM, Andrew Dunstan wrote: I suggest you review the original thread on this subject before a line was ever written. "multiple" (see subject line on this whole thread) is clearly what is being asked for. Making people turn that

Re: [HACKERS] [PATCH] Refactoring of LWLock tranches

On Sun, 15 Nov 2015 16:24:24 -0500 Robert Haas wrote: > > I have some questions about next steps on other tranches. > > First of all, I think we can have two API calls, something like: > > > > 1) LWLockRequestTranche(char *tranche_name, int locks_count) > > 2)

Re: [HACKERS] Conversion error of floating point numbers in pl/pgsql

Kyotaro HORIGUCHI writes: > Hello. I found that 9.5 has an undocumented difference from 9.4 > in type cast in pl/pgsql and I think it might better be mentioned > as a change of behavior in release notes. > Whether do you think it is worth mentioning or not in

Re: [HACKERS] [PROPOSAL] Improvements of Hunspell dictionaries support

On 10.11.2015 13:23, Artur Zakirov wrote: Link to patch in commitfest: https://commitfest.postgresql.org/8/420/ Link to regression tests: https://dl.dropboxusercontent.com/u/15423817/HunspellDictTest.tar.gz Hello! Do you have any remarks or comments about my patch? -- Artur Zakirov

Re: [HACKERS] Parallel Seq Scan

On Mon, Nov 16, 2015 at 4:35 AM, Robert Haas wrote: > > On Fri, Nov 13, 2015 at 10:46 AM, Thom Brown wrote: > >>> And perhaps associated PIDs? > >> > >> Yeah, that can be useful, if others also feel like it is important, I can > >> look into preparing a

Re: [HACKERS] Parallel Seq Scan

2015-11-16 14:17 GMT+01:00 Amit Kapila : > On Mon, Nov 16, 2015 at 4:35 AM, Robert Haas > wrote: > > > > On Fri, Nov 13, 2015 at 10:46 AM, Thom Brown wrote: > > >>> And perhaps associated PIDs? > > >> > > >> Yeah, that can be

Re: [HACKERS] Making tab-complete.c easier to maintain

On Thu, Nov 12, 2015 at 1:16 PM, Kyotaro HORIGUCHI wrote: > 1. 0001-Allow-regex-module-to-be-used-outside-server.patch > > This small change makes pg_regex possible to be used in > frontend. This is generic enough to live in src/common, then psql would directly reuse it using lpgcommon. > 2.

Re: [HACKERS] [PATCH] SQL function to report log message

On Sunday, November 15, 2015 8:51 PM, Craig Ringer wrote: > I'd prefer to omit fields if explicitly assigned to NULL. You can > always use coalesce if you want the string 'NULL'; I agree with > others here that the vast majority of users will want the field > just

Re: [HACKERS] Default Roles (was: Additional role attributes)

Stephen, On Tue, Jul 14, 2015 at 9:22 PM, Fujii Masao wrote: > > On Tue, Jul 14, 2015 at 3:46 AM, Stephen Frost wrote: > > Fujii, > > > > * Fujii Masao (masao.fu...@gmail.com) wrote: > >> he documents of the functions which the corresponding default

[HACKERS] BRIN cost estimate

Somebody wrote to me a few days ago that the BRIN cost estimation is rather poor. One immediately obvious issue which I think is easily fixed is the correlation estimate, which is currently hardcoded to 1. Since a BRIN scan always entails a scan of the relation in physical order, it's simple

Re: [HACKERS] WIP: SCRAM authentication

On Sat, Sep 5, 2015 at 9:31 AM, Bruce Momjian wrote: > On Fri, Sep 4, 2015 at 04:51:33PM -0400, Stephen Frost wrote: >> > Coming in late, but can you explain how multiple passwords allow for >> > easier automated credential rotation? If you have five applications >> > with stored passwords, I

Re: [HACKERS] proposal: multiple psql option -c

Hi 2015-11-16 17:16 GMT+01:00 Catalin Iacob : > On Sun, Nov 15, 2015 at 3:53 PM, Andrew Dunstan > wrote: > > I suggest you review the original thread on this subject before a line > was > > ever written. "multiple" (see subject line on this whole

Re: [HACKERS] Proposal: "Causal reads" mode for load balancing reads without stale data

On Tue, Nov 17, 2015 at 12:44 AM, Simon Riggs wrote: > On 15 November 2015 at 10:41, Simon Riggs wrote: > > >> So anyway, consider me nudged to finish my patch to provide capability >> for that by 1 Jan. >> > > My earlier patch aimed to allow

Re: [HACKERS] Parallel Seq Scan

On Sat, Nov 14, 2015 at 10:12 PM, Amit Kapila wrote: > On Fri, Nov 13, 2015 at 11:05 PM, Jeff Janes wrote: >> >> On Wed, Nov 11, 2015 at 6:53 AM, Robert Haas >> wrote: >> > >> > I've committed most of this, except for some

Re: [HACKERS] pg_receivexlog: spurious error message connecting to 9.3

On 10/11/15 07:35, Craig Ringer wrote: > On 10 November 2015 at 01:47, Marco Nenciarini > wrote: > >> I've attached a little patch that removes the errors when connected to 9.3. > > Looks good to me. No point confusing users. > > The other callers of

Re: [HACKERS] [PATCH] SQL function to report log message

Peter Eisentraut writes: > On 11/15/15 9:50 PM, Craig Ringer wrote: >> I'd prefer to omit fields if explicitly assigned to NULL. You can always >> use coalesce if you want the string 'NULL'; I agree with others here >> that the vast majority of users will want the field just

Re: [HACKERS] pg_hba_lookup function to get all matching pg_hba.conf entries

On 11/16/15 2:37 AM, Haribabu Kommi wrote: > On Mon, Nov 16, 2015 at 2:30 PM, Peter Eisentraut wrote: >> On 7/21/15 5:15 AM, Haribabu Kommi wrote: >>> With the output of this view, administrator can identify the lines >>> that are matching for the given >>> criteria easily

Re: [HACKERS] proposal: PL/Pythonu - function ereport

On 11/15/15 11:29 PM, Pavel Stehule wrote: > > > 2015-11-16 5:20 GMT+01:00 Peter Eisentraut >: > > I don't think it's right to reuse SPIError for this. SPIError is > clearly meant to signal an error in the SPI calls. Of course, we can't >

Re: [HACKERS] [PATCH] SQL function to report log message

On 11/16/15 5:10 PM, Tom Lane wrote: > Peter Eisentraut writes: >> On 11/15/15 9:50 PM, Craig Ringer wrote: >>> I'd prefer to omit fields if explicitly assigned to NULL. You can always >>> use coalesce if you want the string 'NULL'; I agree with others here >>> that the vast

Re: [HACKERS] [DOCS] max_worker_processes on the standby

I paraphrase Fujii Masao, who wrote: > 1. Start the master and standby servers with track_commit_timestamp enabled. > 2. Disable track_commit_timestamp in the master and restart the master server. > 3. Run checkpoint in the master. > 4. Run restartpoint in the standby after the checkpoint WAL

Re: CustomScan in a larger structure (RE: [HACKERS] CustomScan support on readfuncs.c)

On Wed, Nov 11, 2015 at 11:13 PM, Kouhei Kaigai wrote: > I agree with we have no reason why only custom-scan is allowed to have > serialize/deserialize capability. I can implement an equivalent stuff > for foreign-scan also, and it is helpful for extension authors,

Re: [HACKERS] Proposal: "Causal reads" mode for load balancing reads without stale data

On Mon, Nov 16, 2015 at 5:44 AM, Simon Riggs wrote: > On 15 November 2015 at 14:50, Robert Haas wrote: >> On Sun, Nov 15, 2015 at 5:41 AM, Simon Riggs >> wrote: >> > Hmm, if that's where we're at, I'll summarize my thoughts.

[HACKERS] Re: Generalizing SortSupport for text to work with char(n), bytea, and alternative opclasses

On Thu, Nov 12, 2015 at 4:38 PM, Peter Geoghegan wrote: > * bytea default opclass. This is a type that, like the others, shares > its representation with text (a varlena header and some data bytes -- > a string, essentially). Its comparator already behaves identically to > that

Re: [HACKERS] Question concerning XTM (eXtensible Transaction Manager API)

Konstantin Knizhnik wrote: > But you may notice that original TransactionIdSetTreeStatus function is void > - it is not intended to return anything. > It is called in RecordTransactionCommit in critical section where it is not > expected that commit may fail. > But in case of DTM transaction may

Re: [HACKERS] Question concerning XTM (eXtensible Transaction Manager API)

On 11/16/2015 10:54 PM, Alvaro Herrera wrote: Konstantin Knizhnik wrote: But you may notice that original TransactionIdSetTreeStatus function is void - it is not intended to return anything. It is called in RecordTransactionCommit in critical section where it is not expected that commit may

Re: [HACKERS] Question concerning XTM (eXtensible Transaction Manager API)

On Monday, November 16, 2015 2:47 AM, Konstantin Knizhnik wrote: > Some time ago at PgConn.Vienna we have proposed eXtensible >Transaction Manager API (XTM). > The idea is to be able to provide custom implementation of >transaction managers as standard

Re: [HACKERS] Parallel Seq Scan

Hey, I've just pulled and compiled the new code. I'm running a TPC-DS like test on different PostgreSQL installations, but running (max) 12queries in parallel on a server with 12cores. I've configured max_parallel_degree to 2, and I get messages that backend processes crash. I am running the same

Re: [HACKERS] Parallel Seq Scan

On Mon, Nov 16, 2015 at 2:51 PM, Bert wrote: > I've just pulled and compiled the new code. > I'm running a TPC-DS like test on different PostgreSQL installations, but > running (max) 12queries in parallel on a server with 12cores. > I've configured max_parallel_degree to 2, and

Re: [HACKERS] [PATCH] SQL function to report log message

On 11/15/15 9:50 PM, Craig Ringer wrote: > On 16 November 2015 at 09:50, Peter Eisentraut > wrote: > > > I haven't seen this discussed before, but I don't find the name > pg_report_log particularly good. Why not jut pg_log? > > > Sounds like

Re: [HACKERS] [PATCH] SQL function to report log message

On Mon, Nov 16, 2015 at 3:58 PM, Kevin Grittner wrote: > On Sunday, November 15, 2015 8:51 PM, Craig Ringer > wrote: > > > I'd prefer to omit fields if explicitly assigned to NULL. You can > > always use coalesce if you want the string 'NULL'; I agree

Re: [HACKERS] Proposing COPY .. WITH PERMISSIVE

On Mon, Nov 16, 2015 at 11:27 AM, Michael Paquier wrote: > In short, it seems that this patch is better rejected. And I am > planning to do so if there are no complaints. OK, done so in the CF app. Dinesh, please do not be discouraged by that. Everybody has patches rejected, and I know a bit of

Re: [HACKERS] proposal: function parse_ident

On 9/11/15 12:25 PM, Pavel Stehule wrote: new update of parse_ident function patch Nice! I've certainly wanted something like this a number of times. Some comments about the v2 of the patch: - The patch doesn't apply anymore, so it should be rebased. - The docs don't even try and

Re: [HACKERS] proposal: multiple psql option -c

On 11/16/2015 11:16 AM, Catalin Iacob wrote: On Sun, Nov 15, 2015 at 3:53 PM, Andrew Dunstan wrote: I suggest you review the original thread on this subject before a line was ever written. "multiple" (see subject line on this whole thread) is clearly what is being asked

Re: [HACKERS] Erroneous cost estimation for nested loop join

On Mon, Nov 9, 2015 at 6:37 AM, Tom Lane wrote: > kawami...@tkl.iis.u-tokyo.ac.jp writes: >> - cost parameter calibration: random_page_cost = 92.89 > > TBH, you lost me there already. I know of no hardware on which that would > be a sane depiction of reality, so I think

Re: [HACKERS] [PATCH] Refactoring of LWLock tranches

On Mon, Nov 16, 2015 at 7:32 AM, Ildus Kurbangaliev wrote: > What if just create a control struct in shared memory like in other places? > BufferDescriptors > and BufferBlocks can be kept there along with tranches definitions > and lwlocks. Buffer locks that are

Re: [HACKERS] Conversion error of floating point numbers in pl/pgsql

Hello, At Mon, 16 Nov 2015 09:49:54 -0500, Tom Lane wrote in <32508.1447685...@sss.pgh.pa.us> > Kyotaro HORIGUCHI writes: > > Hello. I found that 9.5 has an undocumented difference from 9.4 > > in type cast in pl/pgsql and I think it might

Re: [HACKERS] Should TIDs be typbyval = FLOAT8PASSBYVAL to speed up CREATE INDEX CONCURRENTLY?

On Mon, Sep 7, 2015 at 9:20 PM, Peter Geoghegan wrote: >>> This matters because a major cost during CREATE INDEX CONCURRENTLY is >>> a TID-based datum sort (this is probably most of the cost over and >>> above a conventional CREATE INDEX). >> >> Might be better to hack a special

Re: [HACKERS] Proposal: "Causal reads" mode for load balancing reads without stale data

On 15 November 2015 at 10:41, Simon Riggs wrote: > So anyway, consider me nudged to finish my patch to provide capability > for that by 1 Jan. > My earlier patch aimed to allow WALReceiver to wait on both a latch and a socket as well as allow WALWriter to be active, so

Re: [HACKERS] [DESIGN] ParallelAppend

On Mon, Nov 16, 2015 at 10:10 AM, Kouhei Kaigai wrote: > This idea will solve my concern gracefully. > The new partial_pathlist keeps candidate of path-nodes to be gathered > in this level or upper. Unlike path-nodes in the pathlist already, we > don't need to rip off

Re: [HACKERS] check for interrupts in set_rtable_names

On Mon, Nov 16, 2015 at 8:35 AM, Tom Lane wrote: > I wrote: >> I experimented with using a hash table to avoid the O(N^2) behavior. >> This seems to work quite well, and I think it doesn't change the results >> (leastwise, it does not break the regression tests). > > Looking

Re: [HACKERS] [PATCH] Refactoring of LWLock tranches

On Sun, Nov 15, 2015 at 7:20 PM, and...@anarazel.de wrote: >> /* >> + * We reserve a few predefined tranche IDs. These values will never be >> + * returned by LWLockNewTrancheId. >> + */ >> +#define LWTRANCHE_MAIN 0 >> +#define

Re: [HACKERS] Support for N synchronous standby servers - take 2

Hello, At Tue, 17 Nov 2015 01:09:57 +0900, Masahiko Sawada wrote in

Re: [HACKERS] Parallel Seq Scan

On Mon, Nov 16, 2015 at 7:39 AM, Robert Haas wrote: > On Sun, Nov 15, 2015 at 1:12 AM, Amit Kapila wrote: > > Thanks for the report. > > > > I think main reason of the leak in workers seems to be due the reason > > that one of the buffer used while

Re: [HACKERS] Parallel Seq Scan

On Mon, Nov 16, 2015 at 10:36 PM, Jeff Janes wrote: > > On Sat, Nov 14, 2015 at 10:12 PM, Amit Kapila wrote: > > On Fri, Nov 13, 2015 at 11:05 PM, Jeff Janes wrote: > > > > I think main reason of the leak in workers seems to

Re: [HACKERS] vacuumdb sentence

On 9/17/15 11:00 PM, Euler Taveira wrote: > Hi, > > Is there a reason to quote "jobs" at this sentence? > > 190 fprintf(stderr, _("%s: number of parallel \"jobs\" must be at least > 1\n"), > progname); > > AFAICS "jobs" is neither an identifier nor an option to justify the > quotation. Also,

Re: [HACKERS] Freeze avoidance of very large table.

On Sun, Nov 15, 2015 at 1:47 AM, Amit Kapila wrote: > On Sat, Nov 14, 2015 at 1:19 AM, Andres Freund wrote: >> On 2015-10-31 11:02:12 +0530, Amit Kapila wrote: >> > On Thu, Oct 8, 2015 at 11:05 PM, Simon Riggs >> > wrote: >> >

Re: CustomScan in a larger structure (RE: [HACKERS] CustomScan support on readfuncs.c)

> On Wed, Nov 11, 2015 at 11:13 PM, Kouhei Kaigai wrote: > > I agree with we have no reason why only custom-scan is allowed to have > > serialize/deserialize capability. I can implement an equivalent stuff > > for foreign-scan also, and it is helpful for extension authors,

Re: [HACKERS] Making tab-complete.c easier to maintain

Hello, thank you for many valuable opinions. I am convinced that bare regular expressions cannot be applied here:) At Mon, 16 Nov 2015 18:59:06 +1300, Thomas Munro wrote in

Re: [HACKERS] Rework the way multixact truncations work

On Sun, Nov 08, 2015 at 11:59:33AM -0800, Andres Freund wrote: > On November 8, 2015 11:52:05 AM PST, Noah Misch wrote: > >On Sun, Nov 08, 2015 at 11:11:42AM -0800, Andres Freund wrote: > >> On November 8, 2015 12:54:07 AM PST, Noah Misch wrote: > >> > >>

[HACKERS] Question concerning XTM (eXtensible Transaction Manager API)

Hello, Some time ago at PgConn.Vienna we have proposed eXtensible Transaction Manager API (XTM). The idea is to be able to provide custom implementation of transaction managers as standard Postgres extensions, primary goal is implementation of distritibuted transaction manager. It should not

[HACKERS] Conversion error of floating point numbers in pl/pgsql

Hello. I found that 9.5 has an undocumented difference from 9.4 in type cast in pl/pgsql and I think it might better be mentioned as a change of behavior in release notes. Whether do you think it is worth mentioning or not in release notes? = 9.4 and 9.5 has difference in casting between

Re: [HACKERS] checkpointer continuous flushing

Hmmm... Maybe I'm a little bit too optimistic here, because it seems that I'm suggesting to create a dead lock if the checkpointer has both buffers to flush in waiting and wishes to close the very same file that holds them. So on wanting to close the file the checkpointer should rather

Re: [HACKERS] [PATCH] Skip ALTER x SET SCHEMA if the schema didn't change

Hi Haribabu Kommi Thank you so much for the review and patch update. I should have done that myself, but I've been really busy for the last few weeks. :( Regards, Marti On Mon, Nov 16, 2015 at 4:46 AM, Haribabu Kommi wrote: > On Thu, Nov 5, 2015 at 10:20 PM, Haribabu

Re: [HACKERS] Getting sorted data from foreign server for merge join

On Mon, Nov 9, 2015 at 9:39 PM, Robert Haas wrote: > On Fri, Nov 6, 2015 at 2:03 PM, Kevin Grittner wrote: > > Has anyone taken a close look at what happens if the two sides of > > the merge join have different implementations of the same collation > >

Re: [HACKERS] Proposal: "Causal reads" mode for load balancing reads without stale data

On 15 November 2015 at 14:50, Robert Haas wrote: > On Sun, Nov 15, 2015 at 5:41 AM, Simon Riggs > wrote: > > Hmm, if that's where we're at, I'll summarize my thoughts. > > > > All of this discussion presupposes we are distributing/load balancing > >

Re: [HACKERS] Proposal: "Causal reads" mode for load balancing reads without stale data

On 16 November 2015 at 11:01, Craig Ringer wrote: > On 16 November 2015 at 18:44, Simon Riggs wrote: > >> >> The pooler knows which statements are reads and writes >> > > I think that's an iffy assumption. > It's not an assumption, its a

Re: [HACKERS] Getting sorted data from foreign server for merge join

On 16 November 2015 at 17:47, Ashutosh Bapat < ashutosh.ba...@enterprisedb.com> wrote: > > > collations arising from a foreign table's var are considered to be safer > (FDW_COLLATE_SAFE) to push down to the foreign server , since they are > either local default collation or are assumed to be same

Re: [HACKERS] Proposal: "Causal reads" mode for load balancing reads without stale data

On 16 November 2015 at 18:44, Simon Riggs wrote: > > The pooler knows which statements are reads and writes > I think that's an iffy assumption. It's one we tend to make because otherwise read/write pooling won't work, but in PostgreSQL there's really no way to know when

Re: [HACKERS] Question concerning XTM (eXtensible Transaction Manager API)

> I think the general idea is that if Commit is WAL logged, then the > operation is considered to committed on local node and commit should > happen on any node, only once prepare from all nodes is successful. > And after that transaction is not supposed to abort. But I think you are > trying to

Re: [HACKERS] [PATCH] SQL function to report log message

On 11/15/15 10:56 PM, dinesh kumar wrote: So, shall we make this pg_report_log TO pg_write_log OR pg_ereport OR from you. Why not pg_raise to mirror plpgsql? (The function does have the same semantics, right? It's not doing something like only sending to the log and not the client?) -- Jim

Re: [HACKERS] Making tab-complete.c easier to maintain

Hello, At Mon, 16 Nov 2015 12:19:23 -0300, Alvaro Herrera wrote in <20151116151923.GX614468@alvherre.pgsql> > Thomas Munro wrote: > > New version attached, merging recent changes. > > I wonder about the TailMatches and Matches macros --- wouldn't it be > better to

Re: [HACKERS] Proposing COPY .. WITH PERMISSIVE

On Tue, Nov 17, 2015 at 1:02 AM, Michael Paquier wrote: > On Mon, Nov 16, 2015 at 11:27 AM, Michael Paquier wrote: > > In short, it seems that this patch is better rejected. And I am > > planning to do so if there are no complaints. > > OK, done so in the CF app. >

Re: [HACKERS] Question concerning XTM (eXtensible Transaction Manager API)

On Tue, Nov 17, 2015 at 12:12 PM, konstantin knizhnik < k.knizh...@postgrespro.ru> wrote: > Thank you for your response. > > > On Nov 16, 2015, at 11:21 PM, Kevin Grittner wrote: > > I'm not entirely clear on what you're saying here. I admit I've > not kept in close touch with the distributed

Re: [HACKERS] Question concerning XTM (eXtensible Transaction Manager API)

Thank you for your response. On Nov 16, 2015, at 11:21 PM, Kevin Grittner wrote: > I'm not entirely clear on what you're saying here. I admit I've > not kept in close touch with the distributed processing discussions > lately -- is there a write-up and/or diagram to give an overview of > where

Re: [HACKERS] Proposal: "Causal reads" mode for load balancing reads without stale data

On 11/12/15 1:11 PM, Thomas Munro wrote: It's true that a pooling system/middleware could spy on your sessions and insert causality token handling imposing a global ordering of visibility for you, so that naive users don't have to deal with them. Whenever it sees a COMMIT result (assuming they