Re: [HACKERS] [patch] Proposal for \rotate in psql

Hi, This is the 2nd iteration of this patch, for comments and review. Changes: - the arguments can be column names (rather than only numbers). - the horizontal headers are sorted server-side according to their original type. DESC order is possible by prefixing the column arg with a minus

Re: [HACKERS] Partitioned checkpointing

Hello Takashi-san, I've noticed that the behavior in 'checkpoint_partitions = 1' is not the same as that of original 9.5alpha2. Attached 'partitioned-checkpointing-v3.patch' fixed the bug, thus please use it. I've done two sets of run on an old box (16 GB, 8 cores, RAID1 HDD) with "pgbench

Re: [HACKERS] T_PrivGrantee is left in NodeTag

Hi, thank you for pointing it out. At Wed, 16 Sep 2015 14:02:30 +0900, Yugo Nagata wrote in <20150916140230.a232426c.nag...@sraoss.co.jp> > I found that codes about T_PrivGrantee was removed > by the following commit; >

[HACKERS] Reliance on undefined behaviour in << operator

Hi all Our implementation of << is a direct wrapper around the C operator. It does not check the right-hand side's value. Datum int8shl(PG_FUNCTION_ARGS) { int64 arg1 = PG_GETARG_INT64(0); int32 arg2 = PG_GETARG_INT32(1);

[HACKERS] Obsolete cross-references to set_append_rel_pathlist in comments

My previous report and subsequently commit 70d44dd apparently missed to notice a few more cross-references to set_append_rel_pathlist where set_append_rel_size is now meant. Attached fixes it. Thanks, Amit diff --git a/src/backend/optimizer/path/costsize.c b/src/backend/optimizer/path/costsize.c

Re: [HACKERS] Reliance on undefined behaviour in << operator

Hello, I don't think so many people have used shift operators with too-large or negative shift amount relying on the undetermined behavior. But if explicit definition is required, I prefer the result of a shift operation with too-large shift mount is simplly zero. And shift left with negative

[HACKERS] PostgreSQL streaming replication doubt

Hi Team, I am working towards using PostgreSQL 9.3 streaming replication feature for Two servers say primary and secondary. Looking at the documentation I have doubt, please help me to understand. Documentation says, Hardware need not be exactly the same, but experience shows that maintaining

Re: [HACKERS] Sequence Access Method WIP

On 28 July 2015 at 19:51, Petr Jelinek wrote: > On 2015-07-28 20:11, Heikki Linnakangas wrote: > >> >> Petr, is this enough feedback on this patch for this commitfest, or are >> there some other issues you want to discuss before I mark this as >> returned? >> >> > You can

Re: [HACKERS] synchronous_commit = apply

On Tue, Sep 8, 2015 at 1:11 AM, Thomas Munro wrote: > On Thu, Sep 3, 2015 at 12:02 AM, Fujii Masao > wrote: >> >> One idea is to change the standby so that it manages the locations >> that the backends in "apply" mode are waiting for in the

Re: [HACKERS] [PATCH] Microvacuum for gist.

16.09.2015 07:30, Jeff Janes: The commit of this patch seems to have created a bug in which updated tuples can disappear from the index, while remaining in the table. It looks like the bug depends on going through a crash-recovery cycle, but I am not sure of that yet. I've looked

Re: [HACKERS] synchronous_commit = apply

On 1 September 2015 at 20:25, Thomas Munro wrote: > Do you think it's reasonable to want to COMMIT a particular transaction on > a master node, and then immediately run a read-only query on a hot standby > node that is guaranteed to see that transaction? > Yes,

[HACKERS] pltcl: sentence improvement

Hi, This simple patch improves a sentence. Spotted while working on translation. -- Euler Taveira Timbira - http://www.timbira.com.br/ PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento >From 7cae997155e222e0a8280018cccf717ab2ee1c38 Mon Sep 17 00:00:00

Re: [HACKERS] Additional LWLOCK_STATS statistics

On 09/15/2015 03:51 PM, Jesper Pedersen wrote: It would be nice to get a better sense of how *long* we block on various locks. It's hard to tell whether some other lock might be have fewer blocking events but for a much longer average duration. I did a run with the attached patch,

Re: [HACKERS] [PROPOSAL] VACUUM Progress Checker.

On Tue, Sep 15, 2015 at 11:35 PM, Syed, Rahila wrote: > > Hello Thom, > >>Okay, I've just tested this with a newly-loaded table (1,252,973 of jsonb >>data), > Thanks a lot! > >>but after it's finished, I end up with this: >>json=# select * from pg_stat_vacuum_progress;

Re: [HACKERS] Inaccurate results from numeric ln(), log(), exp() and pow()

On Wed, Sep 16, 2015 at 2:31 AM, Dean Rasheed wrote: > Hi, > > I recently noticed that numeric log() produces inaccurate results for > certain ranges of inputs. This isn't just small errors in the last 1 > or 2 digits, but sometimes quite large errors, with over half the

Re: [HACKERS][PROPOSAL] Covering + unique indexes.

On 09/15/2015 06:57 PM, Anastasia Lubennikova wrote: Proposal Clarification. I see that discussion become too complicated. So, I'd like to clarify what we are talking about. [snip] What are we doing now: CREATE UNIQUE INDEX on tbl(f1,f2); CREATE INDEX on tbl(f1, f2, f3, f4); [snip]

Re: [HACKERS] pltcl: sentence improvement

Euler Taveira writes: > This simple patch improves a sentence. Spotted while working on translation. I concur that spelling out "#" as "number" is an improvement, but I'm curious which backend error you think this matches? Also, if we're going to change this message at

Re: [HACKERS][PROPOSAL] Covering + unique indexes.

On 16 September 2015 at 14:03, José Luis Tallón wrote: > On 09/15/2015 06:57 PM, Anastasia Lubennikova wrote: > > Proposal Clarification. > I see that discussion become too complicated. So, I'd like to clarify > what we are talking about. > > [snip] > What are we

Re: [HACKERS] CREATE POLICY and RETURNING

Stephen, > I agree that if we force a single visibility policy for all commands > then we wouldn't need the USING clauses for UPDATE and DELETE, but we > would certainly need *some* policy for DELETE to prevent users from > being able to delete records that they aren't supposed to be allowed to.

Re: [HACKERS] On-demand running query plans using auto_explain and signals

On Tue, Sep 15, 2015 at 11:00 AM, Shulgin, Oleksandr < oleksandr.shul...@zalando.de> wrote: > On Mon, Sep 14, 2015 at 7:27 PM, Pavel Stehule > wrote: > >> >> 2015-09-14 18:46 GMT+02:00 Shulgin, Oleksandr < >> oleksandr.shul...@zalando.de>: >> >>> >>> ... This way the

Re: [HACKERS] Inaccurate results from numeric ln(), log(), exp() and pow()

On 16 September 2015 at 09:32, Tom Lane wrote: > Dean Rasheed writes: > > ... For example, exp() works for inputs up to 6000. However, if you > > compute exp(5999.999) the answer is truly huge -- probably only of > > academic interest to anyone.

Re: [HACKERS] Additional LWLOCK_STATS statistics

On 09/16/2015 10:13 AM, Jesper Pedersen wrote: On 09/15/2015 03:51 PM, Jesper Pedersen wrote: It would be nice to get a better sense of how *long* we block on various locks. It's hard to tell whether some other lock might be have fewer blocking events but for a much longer average duration.

Re: [HACKERS] pgbench progress with timestamp

Thank you, committed Fabien COELHO wrote: --progress-timestamp use Unix epoch timestamps in ms for progress A quibble, but it isn't in ms, it is in seconds. The digits after the decimal point give a precision to the ms level, but they don't change the base unit. Yes. The issue is

Re: [HACKERS] Additional LWLOCK_STATS statistics

On 09/16/2015 10:25 AM, Jesper Pedersen wrote: Likely from LWLOCK_STATS' own lwlock.c::print_lwlock_stats, which would make sense. Version 3 attached, which ignores entries from MainLWLockArray[0]. Best regards, Jesper *** /tmp/NTwtmh_lwlock.c 2015-09-16 10:34:02.955957192 -0400 ---

[HACKERS] hot_standby_feedback default and docs

Related to the ongoing discussion about replication default settings, is there a current reason why hot_standby_feedback is not the default? Also, the documentation claims that this parameter requires a postmaster restart, but the code thinks it's SIGHUP. Which one is wrong? -- Sent via

Re: [HACKERS] Inaccurate results from numeric ln(), log(), exp() and pow()

Dean Rasheed writes: > ... For example, exp() works for inputs up to 6000. However, if you > compute exp(5999.999) the answer is truly huge -- probably only of > academic interest to anyone. With HEAD, exp(5999.999) produces a > number with 2609 significant digits in

Re: [HACKERS] T_PrivGrantee is left in NodeTag

Kyotaro HORIGUCHI writes: > At Wed, 16 Sep 2015 14:02:30 +0900, Yugo Nagata wrote > in <20150916140230.a232426c.nag...@sraoss.co.jp> >> but T_PrivGrantee is left in NodeTag in src/include/nodes/nodes.h. >> Is it intended? > Thoughts? The

Re: [HACKERS] pltcl: sentence improvement

On 16-09-2015 10:57, Tom Lane wrote: Euler Taveira writes: This simple patch improves a sentence. Spotted while working on translation. I concur that spelling out "#" as "number" is an improvement, but I'm curious which backend error you think this matches? It is sort

[HACKERS] BUFFER_LOCK_* synonyms

All of the index methods have their own synonyms of the BUFFER_LOCK_* constants, for example: #define GIN_SHARE BUFFER_LOCK_SHARE #define GIST_SHARE BUFFER_LOCK_SHARE #define HASH_READ BUFFER_LOCK_SHARE #define BT_READ BUFFER_LOCK_SHARE But most of them pass their

Re: [HACKERS] [PATCH] Microvacuum for gist.

But It seems to me that it would be better to rewrite all mentions of TupleDelete to MultiDelete in gist code. Sure. Patch is attached, and it changes WAL format, so be carefull with testing. Please, have a look. Also in attach scripts reproduce bug from Jeff's report: g.pl - creates and fills

Re: [HACKERS] Inaccurate results from numeric ln(), log(), exp() and pow()

On Wed, Sep 16, 2015 at 10:14 AM, Dean Rasheed wrote: > On 16 September 2015 at 14:49, Merlin Moncure wrote: >>> AFAICT, this kind of slowdown only happens in cases like this where a >>> very large number of digits are being returned. >> >> Can you

Re: [HACKERS] Inaccurate results from numeric ln(), log(), exp() and pow()

On 16 September 2015 at 14:49, Merlin Moncure wrote: >> AFAICT, this kind of slowdown only happens in cases like this where a >> very large number of digits are being returned. > > Can you clarify "very large"? > I haven't done much performance testing because I've been

Re: [HACKERS] Additional LWLOCK_STATS statistics

Hi, On 09/16/2015 12:26 PM, Andres Freund wrote: On 2015-09-16 10:37:43 -0400, Jesper Pedersen wrote: #ifdef LWLOCK_STATS lwstats->spin_delay_count += SpinLockAcquire(>mutex); + + /* +* We scan the list of waiters from the back in order to find +* out how many

Re: [HACKERS] BUFFER_LOCK_* synonyms

On Wed, Sep 16, 2015 at 9:30 AM, Andres Freund wrote: > I was annoyed by this more than once too. It also bugs me that unlocking > a buffer is spelled LockBuffer(..., BUFFER_LOCK_UNLOCK) - that just > reads wrong. Pretty sure that this was discussed a couple of times before.

Re: [HACKERS] Use pg_rewind when target timeline was switched

On Thu, Sep 10, 2015 at 8:33 AM, Michael Paquier wrote: > On Wed, Sep 9, 2015 at 7:13 PM, Alexander Korotkov wrote: > > On Wed, Sep 9, 2015 at 9:01 AM, Michael Paquier wrote: > >> The code building the target history file is a duplicate of what is done > >> with the

Re: [HACKERS] statistics for array types

On Mon, Aug 24, 2015 at 8:26 PM, Jeff Janes wrote: > On Thu, Aug 20, 2015 at 6:00 PM, Tomas Vondra < > tomas.von...@2ndquadrant.com> wrote: > >> Hi, >> >> On 08/11/2015 04:38 PM, Jeff Janes wrote: >> >>> When reviewing some recent patches, I decided the statistics gathered

Re: [HACKERS] BUFFER_LOCK_* synonyms

On 2015-09-16 08:31:48 -0700, Jeff Janes wrote: > All of the index methods have their own synonyms of the BUFFER_LOCK_* > constants, for example: > > #define GIN_SHARE BUFFER_LOCK_SHARE > #define GIST_SHARE BUFFER_LOCK_SHARE > #define HASH_READ BUFFER_LOCK_SHARE > #define BT_READ

Re: [HACKERS][PROPOSAL] Covering + unique indexes.

2015-09-16 Rod Taylor : > 2015-09-15 Anastasia Lubennikova : > >> - We have a table tbl(f1, f2, f3, f4). >> - We want to have an unique index on (f1,f2). >> - We want to have an index on (f1, f2, f3) which allow us to use index for >> complex

Re: [HACKERS] Inaccurate results from numeric ln(), log(), exp() and pow()

On 16 September 2015 at 16:14, Dean Rasheed wrote: > On 16 September 2015 at 14:49, Merlin Moncure wrote: >>> AFAICT, this kind of slowdown only happens in cases like this where a >>> very large number of digits are being returned. >> >> Can you

Re: [HACKERS] pltcl: sentence improvement

Euler Taveira writes: > On 16-09-2015 10:57, Tom Lane wrote: >> Also, if we're going to change this message at all, I'm inclined to >> rewrite it completely, because it doesn't really follow the style >> guidelines. How about "trigger's return list must have even number of

Re: [HACKERS] Additional LWLOCK_STATS statistics

Hi, On 2015-09-16 10:37:43 -0400, Jesper Pedersen wrote: > #ifdef LWLOCK_STATS > lwstats->spin_delay_count += SpinLockAcquire(>mutex); > + > + /* > + * We scan the list of waiters from the back in order to find > + * out how many of the same lock type are waiting for a

Re: [HACKERS] RFC: replace pg_stat_activity.waiting with something more descriptive

On Mon, Sep 14, 2015 at 3:03 PM, Robert Haas wrote: > On Mon, Sep 14, 2015 at 5:32 AM, Alexander Korotkov > wrote: > > In order to build the consensus we need the roadmap for waits monitoring. > > Would single byte in PgBackendStatus be the only way

Re: [HACKERS] pltcl: sentence improvement

Tom Lane wrote: > Also, if we're going to change this message at all, I'm inclined to > rewrite it completely, because it doesn't really follow the style > guidelines. How about "trigger's return list must have even number of > elements"? I agree a full rewrite is sensible, but that particular

Re: [HACKERS] Reliance on undefined behaviour in << operator

On Wed, Sep 16, 2015 at 3:57 PM, Tom Lane wrote: > Robert Haas writes: >> On Wed, Sep 16, 2015 at 3:16 AM, Craig Ringer wrote: >>> Our implementation of << is a direct wrapper around the C operator. It >>> does not check the

Re: [HACKERS] Reliance on undefined behaviour in << operator

On 2015-09-16 15:57:04 -0400, Tom Lane wrote: > Robert Haas writes: > > On Wed, Sep 16, 2015 at 3:16 AM, Craig Ringer wrote: > >> Our implementation of << is a direct wrapper around the C operator. It > >> does not check the right-hand side's value.

Re: [HACKERS] WIP: Rework access method interface

validate_opclass was renamed to amvalidate. It seems to me, that amvalidate method of AM should get as argument only Oid of operator family. Layout and meaning of amproc/amop fields are differ for different AM and there isn't an AM which implements all possible features. Actually, I'm a bit

Re: [HACKERS] RFC: replace pg_stat_activity.waiting with something more descriptive

On Wed, Sep 16, 2015 at 12:29 PM, Alexander Korotkov wrote: > Yes, the major question is cost. But I think we should validate our thoughts > by experiments assuming there are more possible synchronization protocols. > Ildus posted implemention of double buffering approach

Re: [HACKERS] Reliance on undefined behaviour in << operator

Robert Haas writes: > On Wed, Sep 16, 2015 at 3:16 AM, Craig Ringer wrote: >> Our implementation of << is a direct wrapper around the C operator. It >> does not check the right-hand side's value. >> ... On x64 intel gcc linux it does a rotation but

Re: [HACKERS] Additional LWLOCK_STATS statistics

On Wed, Sep 16, 2015 at 10:13 AM, Jesper Pedersen wrote: > Doing block_time / block_count basically only shows "main 0" -- its called > "unassigned:0"; it also shows up in the max exclusive report. Where it is > coming from is another question, since it shouldn't be in

Re: [HACKERS] pg_resetxlog sentences

On Tue, Sep 15, 2015 at 9:52 PM, Euler Taveira wrote: > While updating translations, I came across those almost similar sentences. > > pg_controldata.c > > 273 printf(_("Latest checkpoint's oldestCommitTs: %u\n"), > 274

Re: [HACKERS] pg_resetxlog sentences

Robert Haas wrote: > On Tue, Sep 15, 2015 at 9:52 PM, Euler Taveira wrote: > > While updating translations, I came across those almost similar sentences. > > > > pg_controldata.c > > > > 273 printf(_("Latest checkpoint's oldestCommitTs: %u\n"), > > 274

Re: [HACKERS] On-demand running query plans using auto_explain and signals

2015-09-16 16:31 GMT+02:00 Shulgin, Oleksandr : > On Tue, Sep 15, 2015 at 11:00 AM, Shulgin, Oleksandr < > oleksandr.shul...@zalando.de> wrote: > >> On Mon, Sep 14, 2015 at 7:27 PM, Pavel Stehule >> wrote: >> >>> >>> 2015-09-14 18:46

[HACKERS] Building storage/lwlocknames.h?

Hi, the Debian package build compiles plpython twice, once for python 2 in the main build, and then for python 3 in an extra run. In order not to waste too much time, we have this recipe in there: stamp/build-py3: stamp/configure-build-py3 $(MAKE) -C build-py3/src/backend/

Re: [HACKERS] Parallel Seq Scan

On Thu, Sep 10, 2015 at 12:12 AM, Amit Kapila wrote: >> 2. I think it's probably a good idea - at least for now, and maybe >> forever - to avoid nesting parallel plans inside of other parallel >> plans. It's hard to imagine that being a win in a case like this, and >> it

Re: [HACKERS] hot_standby_feedback default and docs

On 9/16/15 1:12 PM, Michael Paquier wrote: > On Wed, Sep 16, 2015 at 7:51 AM, Peter Eisentraut wrote: >> Also, the documentation claims that this parameter requires a postmaster >> restart, but the code thinks it's SIGHUP. Which one is wrong? > > To which part of the

Re: [HACKERS] Spurious standby query cancellations

On 14 September 2015 at 12:00, Jeff Janes wrote: > It's now possible to fix this by putting a lock wait on the actual lock >> request, which wasn't available when I first wrote that, hence the crappy >> wait loop. Using the timeout handler would now be the preferred way to

Re: [HACKERS] Reliance on undefined behaviour in << operator

On Wed, Sep 16, 2015 at 03:57:04PM -0400, Tom Lane wrote: > Robert Haas writes: > > On Wed, Sep 16, 2015 at 3:16 AM, Craig Ringer wrote: > >> Our implementation of << is a direct wrapper around the C operator. It > >> does not check the right-hand

Re: [HACKERS] Parallel Seq Scan

On Thu, Sep 3, 2015 at 6:21 AM, Amit Kapila wrote: > Attached, find the rebased version of patch. It fixes the comments raised > by Jeff Davis and Antonin Houska. The main changes in this version are > now it supports sync scan along with parallel sequential scan

Re: [HACKERS] Building storage/lwlocknames.h?

Re: Andres Freund 2015-09-16 <20150916201955.gj2...@alap3.anarazel.de> > On 2015-09-16 22:10:00 +0200, Christoph Berg wrote: > > Can we have a "submake-lwlocknames" build target like there already is > > for submake-errcodes? Reading the Makefile I could not see how to > > manually trigger this

Re: [HACKERS] creating extension including dependencies

On 2015-09-16 05:44:22 +0200, Petr Jelinek wrote: > On 2015-09-08 04:06, Michael Paquier wrote: > >On Tue, Sep 8, 2015 at 10:44 AM, Michael Paquier > > wrote: > >> > >>Attached are as well changes for the documentation that I spotted in > >>earlier reviews but were not

Re: [HACKERS] Building storage/lwlocknames.h?

On 2015-09-16 22:10:00 +0200, Christoph Berg wrote: > Can we have a "submake-lwlocknames" build target like there already is > for submake-errcodes? Reading the Makefile I could not see how to > manually trigger this individually. > stamp/build-py3: stamp/configure-build-py3 > $(MAKE) -C

Re: [HACKERS] What is the extent of FDW join pushdown support in 9.5?

On 9/15/15 10:02 PM, Kouhei Kaigai wrote: >> The 9.5 release notes contain this promising but cryptic item: >> >> - Allow foreign data wrappers and custom scans to implement join >> pushdown (KaiGai Kohei) >> >> As phrased, this seems to mean, "it can be done, but we haven't done >> it". But

Re: [HACKERS] hot_standby_feedback default and docs

On 16 September 2015 at 15:37, Peter Eisentraut wrote: > On 9/16/15 1:12 PM, Michael Paquier wrote: > > On Wed, Sep 16, 2015 at 7:51 AM, Peter Eisentraut > wrote: > >> Also, the documentation claims that this parameter requires a postmaster > >> restart, but

Re: [HACKERS] exposing pg_controldata and pg_config as functions

On 2015-08-20 09:59:25 -0400, Andrew Dunstan wrote: > Is there any significant interest in either of these? > > Josh Berkus tells me that he would like pg_controldata information, and I > was a bit interested in pg_config information, for this reason: I had a > report of someone who had

Re: [HACKERS] Unicode mapping scripts cleanup

> What if we discovered that one of our mappings was wrong? Suppose > that there is some encoding where the Unicode mapping for "a" is > inadvertently mapped to the letter "b" in some other character set, > and "b" is mapped to "a". I imagine that anyone using that encoding > would want this

Re: [HACKERS] Parallel Seq Scan

On Wed, Jul 22, 2015 at 10:44 AM, Robert Haas wrote: > One thing I noticed that is a bit dismaying is that we don't get a lot > of benefit from having more workers. Look at the 0.1 data. At 2 > workers, if we scaled perfectly, we would be 3x faster (since the > master can

Re: [HACKERS] creating extension including dependencies

Andres Freund wrote: > > @@ -91,8 +92,38 @@ CREATE EXTENSION [ IF NOT EXISTS ] > class="parameter">extension_name > > The name of the schema in which to install the extension's > > objects, given that the extension allows its contents to be > > relocated. The named

Re: [HACKERS] synchronous_commit = apply

On Thu, Sep 17, 2015 at 12:50 AM, Simon Riggs wrote: > On 1 September 2015 at 20:25, Thomas Munro > wrote: >> The next problem is that the master can be waiting quite a long time for a >> reply from the remote walreceiver containing the

Re: [HACKERS] Parallel Seq Scan

On Mon, Sep 14, 2015 at 11:04 PM, Haribabu Kommi wrote: > Using this function, the backend detaches from the message queue, so > that the workers > which are trying to put results into the queues gets an error message > as SHM_MQ_DETACHED. > Then worker finshes the

Re: [HACKERS] creating extension including dependencies

On 2015-09-16 19:46:10 -0300, Alvaro Herrera wrote: > Andres Freund wrote: > > > > @@ -91,8 +92,38 @@ CREATE EXTENSION [ IF NOT EXISTS ] > > class="parameter">extension_name > > > The name of the schema in which to install the extension's > > > objects, given that the extension

Re: [HACKERS] Parallel Seq Scan

On Thu, Sep 3, 2015 at 6:21 AM, Amit Kapila wrote: > [ new patches ] + pscan = shm_toc_lookup(node->ss.ps.toc, PARALLEL_KEY_SCAN); This is total nonsense. You can't hard-code the key that's used for the scan, because we need to be able to support more

Re: [HACKERS] Improving test coverage of extensions with pg_dump

On 2015-09-09 10:48:24 +0900, Michael Paquier wrote: > On Wed, Sep 9, 2015 at 3:33 AM, Andres Freund wrote: > > On 2015-09-07 22:55:50 +0900, Michael Paquier wrote: > >> So, to summarize the state of this patch whose status is now "Waiting > >> on Author", we have the

Re: [HACKERS] Parallel Seq Scan

On Thu, Sep 17, 2015 at 6:10 AM, Robert Haas wrote: > On Thu, Sep 10, 2015 at 12:12 AM, Amit Kapila wrote: >>> 2. I think it's probably a good idea - at least for now, and maybe >>> forever - to avoid nesting parallel plans inside of other parallel

Re: [HACKERS] Parallel Seq Scan

On Thu, Sep 17, 2015 at 12:03 PM, Amit Kapila wrote: > As mentioned previously [1], we have to do two different things to make > this work, Robert seems to have taken care of one of those (basically > second point in mail[1]) and still another one needs to be taken care >

Re: [HACKERS] some pg_rewind usability issues

On Wed, Sep 16, 2015 at 10:28 PM, Peter Eisentraut wrote: > pg_rewind --source-server uses the libpq default mechanisms for the > database, but that's useless for pg_rewind, which can just always use > dbname=postgres, like other database-agnostic utilities. Keep in mind that

Re: [HACKERS] tsvector work with citext

"David E. Wheeler" writes: > Is there a way to get tsvector_update_trigger() to work with citext > columns? Hmm ... tsvector_op.c has /* Check if datatype is TEXT or binary-equivalent to it */ static bool is_text_type(Oid typid) { /* varchar(n) and char(n) are

Re: [HACKERS] Improving test coverage of extensions with pg_dump

On Wed, Sep 16, 2015 at 8:00 PM, Michael Paquier wrote: > Hm. OK. I didn't get your message correctly, sorry for that. Would you > be fine then to have a pg_regress command using parallel_schedule + an > extra schedule launching tests related to the extensions in > src/test/modules/pg_dumprestore

Re: [HACKERS] Sequence Access Method WIP

On 2015-09-16 13:21, Thom Brown wrote: On 28 July 2015 at 19:51, Petr Jelinek > wrote: On 2015-07-28 20:11, Heikki Linnakangas wrote: Petr, is this enough feedback on this patch for this commitfest, or are there

Re: [HACKERS] Improving test coverage of extensions with pg_dump

On Wed, Sep 16, 2015 at 3:42 PM, Andres Freund wrote: > On 2015-09-09 10:48:24 +0900, Michael Paquier wrote: >> On Wed, Sep 9, 2015 at 3:33 AM, Andres Freund wrote: >> > On 2015-09-07 22:55:50 +0900, Michael Paquier wrote: >> >> So, to summarize the state

Re: [HACKERS] some pg_rewind usability issues

On Wed, Sep 16, 2015 at 7:28 PM, Peter Eisentraut wrote: > pg_rewind requires that the target server be shut down cleanly, but does > not accept shutdown in recovery. Is that necessary? > [blah] > If I patch pg_rewind to allow shutdown in recovery, it goes slightly > easier, but

Re: [HACKERS] a funnel by any other name

On 2015-09-17 04:39, Robert Haas wrote: 1. Exchange Bushy 2. Exchange Inter-Operator (this is what's currently implemented) 3. Exchange Replicate 4. Exchange Merge 5. Interchange Or taking inspiration from Greenplum, we could go with: 1. ? 2. Gather 3. Broadcast (sorta) 4. Gather Merge 5.

Re: [HACKERS] pg_resetxlog sentences

On Thu, Sep 17, 2015 at 5:00 AM, Alvaro Herrera wrote: > Robert Haas wrote: >> On Tue, Sep 15, 2015 at 9:52 PM, Euler Taveira wrote: >> > While updating translations, I came across those almost similar sentences. >> > >> > pg_controldata.c >> > >>

[HACKERS] Obsolete use of volatile in walsender.c, walreceiver.c, walreceiverfuncs.c?

Hi In walsender.c, walreceiver.c, walreceiverfuncs.c there are several places where volatile qualifiers are used apparently only to prevent reordering around spinlock operations. My understanding is that if potential load/store reordering around spinlock operations is the only reason for using

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

On Tue, Sep 15, 2015 at 3:19 PM, Thomas Munro wrote: > I got the following error from clang-602.0.53 on my Mac: > > walsender.c:1955:11: error: passing 'char volatile[8192]' to parameter of > type 'void *' discards qualifiers >

[HACKERS] some pg_rewind usability issues

pg_rewind --source-server uses the libpq default mechanisms for the database, but that's useless for pg_rewind, which can just always use dbname=postgres, like other database-agnostic utilities. pg_rewind requires that the target server be shut down cleanly, but does not accept shutdown in

[HACKERS] tsvector work with citext

Hey Hackers, Is there a way to get tsvector_update_trigger() to work with citext columns? The attached case throws an error: ERROR: column "title" is not of a character type Is the fact that citext is a (non-preferred) member of the string category not sufficient for this to work? If

[HACKERS] a funnel by any other name

I have discovered that I have reinvented the wheel. In http://www.postgresql.org/message-id/CA+TgmobM7X6jgre442638b+33h1EWa=vczqnsvzedx057zh...@mail.gmail.com I invented an operator called Funnel, whose job it is to fire up a bunch of workers and run a plan in all of them, so that we can

Re: [HACKERS] pltcl: sentence improvement

Alvaro Herrera writes: > I agree a full rewrite is sensible, but that particular wording looks > slightly odd to me. I would either have added an "an", or pluralized > the subject, so either > "trigger's return list must have an even number of elements" > or >

Re: [HACKERS] [PATCH v2] GSSAPI encryption support

Michael Paquier writes: > On Thu, Sep 10, 2015 at 4:27 PM, Michael Paquier > wrote: >> On Thu, Sep 10, 2015 at 1:44 AM, Robbie Harwood wrote: >>> Michael Paquier writes: On Wed, Sep 9,

Re: [HACKERS] assessing parallel-safety

On Thu, Sep 3, 2015 at 6:05 AM, Amit Kapila wrote: > On Wed, Jul 15, 2015 at 11:20 AM, Amit Kapila > wrote: >> I went ahead and completed this patch with respect to adding new clause >> in CREATE/ALTER FUNCTION which can allow users to define the

Re: [HACKERS] Can extension build own SGML document?

On Wed, Sep 16, 2015 at 12:16 AM, Peter Eisentraut wrote: > On 9/15/15 11:45 AM, Robert Haas wrote: >> On Tue, Sep 15, 2015 at 9:43 AM, Tom Lane wrote: >>> AFAICT from a quick look at its documentation, asciidoc can produce >>> either html or docbook output;

Re: [HACKERS] Reliance on undefined behaviour in << operator

On Wed, Sep 16, 2015 at 3:16 AM, Craig Ringer wrote: > Our implementation of << is a direct wrapper around the C operator. It > does not check the right-hand side's value. > > Datum > int8shl(PG_FUNCTION_ARGS) > { > int64 arg1 = PG_GETARG_INT64(0);

Re: [HACKERS] hot_standby_feedback default and docs

On Wed, Sep 16, 2015 at 7:51 AM, Peter Eisentraut wrote: > Also, the documentation claims that this parameter requires a postmaster > restart, but the code thinks it's SIGHUP. Which one is wrong? To which part of the documentation are you referring to? The parameter is SIGHUP

Re: [HACKERS] Unicode mapping scripts cleanup

On Tue, Sep 15, 2015 at 9:00 PM, Tatsuo Ishii wrote: >> Then again, I don't have >> any knowledge about how to handle such changes. But the fact that the >> standards bodies are still making changes indicates that such changes >> are to be expected and should be handled.