On Tue, Jan 8, 2019 at 12:14 AM Tom Lane wrote:
> I've been toying with OpenBSD lately, and soon noticed a seriously
> annoying problem for running Postgres on it: by default, its limits
> for SysV semaphores are only SEMMNS=60, SEMMNI=10. Not only does that
> greatly constrain the number of con
On 2019-01-08 07:14, Tom Lane wrote:
I've been toying with OpenBSD lately, and soon noticed a seriously
annoying problem for running Postgres on it: by default, its limits
for SysV semaphores are only SEMMNS=60, SEMMNI=10. Not only does that
greatly constrain the number of connections for a si
Mmm.
At Tue, 08 Jan 2019 16:26:38 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI
wrote in
<20190108.162638.106314087.horiguchi.kyot...@lab.ntt.co.jp>
> FWIW, I got the following result on my environment. It seems
> different enough if this holds on all supported platforms, though
> there still
On Tue, Jan 08, 2019 at 03:05:42PM +0900, Amit Langote wrote:
> I meant to say that the feature to add relations to a subscription is not
> supported for certain relation types, even though it's practically
> *possible* to do so. But maybe, I'm misunderstanding the error code
> selection policy.
Thomas Munro writes:
> On Tue, Jan 8, 2019 at 7:14 PM Tom Lane wrote:
>> So I looked around for an alternative, and found out that modern
>> OpenBSD releases support named POSIX semaphores (though not unnamed
>> ones, at least not shared unnamed ones). What's more, it appears that
>> in this imp
Hello.
At Fri, 21 Dec 2018 11:50:28 -0500, Tom Lane wrote in
<28533.1545411...@sss.pgh.pa.us>
> "Yuzuko Hosoya" writes:
> > From: Kyotaro HORIGUCHI [mailto:horiguchi.kyot...@lab.ntt.co.jp]
> >> At Thu, 20 Dec 2018 17:21:29 +0900, "Yuzuko Hosoya"
> >> wrote in
> >> <008701d4983d$02e731c0$08b59
On Tue, Jan 8, 2019 at 7:14 PM Tom Lane wrote:
> I've been toying with OpenBSD lately, and soon noticed a seriously
> annoying problem for running Postgres on it: by default, its limits
> for SysV semaphores are only SEMMNS=60, SEMMNI=10. Not only does that
> greatly constrain the number of conne
I've been toying with OpenBSD lately, and soon noticed a seriously
annoying problem for running Postgres on it: by default, its limits
for SysV semaphores are only SEMMNS=60, SEMMNI=10. Not only does that
greatly constrain the number of connections for a single installation,
it means that our TAP
On 1/8/19 5:37 AM, Michael Paquier wrote:
-to the latest timeline found in the archive, which is useful in
-a standby server. Other than that you only need to set this parameter
+to the latest timeline found in the archive. That is the default.
+
Isn't it useful t
Hi Hackers,
The Server GUC parameters accepts values in both Octal and hexadecimal
formats also.
postgres=# set max_parallel_workers_per_gather='0x10';
postgres=# show max_parallel_workers_per_gather;
max_parallel_workers_per_gather
-
16
postgres=# set max_paral
On 2019/01/08 13:44, Michael Paquier wrote:
> On Tue, Jan 08, 2019 at 01:13:11PM +0900, Amit Langote wrote:
>> Yeah, I think so too. I also noticed that the patch uses
>> ERRCODE_WRONG_OBJECT_TYPE as the error code, whereas we may want to use
>> ERRCODE_FEATURE_NOT_SUPPORTED. Thoughts on that?
>
On Tue, Jan 08, 2019 at 01:13:11PM +0900, Amit Langote wrote:
> Yeah, I think so too. I also noticed that the patch uses
> ERRCODE_WRONG_OBJECT_TYPE as the error code, whereas we may want to use
> ERRCODE_FEATURE_NOT_SUPPORTED. Thoughts on that?
ERRCODE_WRONG_OBJECT_TYPE is the right call I thi
On 2019/01/08 11:10, Michael Paquier wrote:
> On Mon, Jan 07, 2019 at 05:28:27PM +0900, Amit Langote wrote:
>> On 2019/01/07 16:35, Michael Paquier wrote:
>>> It seems to me that we may want something more like:
>>> Primary: "could not use \"%s.%s\" as logical replication target".
>>> Detail: "Rela
On Mon, Jan 07, 2019 at 06:31:52PM -0800, Andres Freund wrote:
> Huh? It's absolutely *trivial* from a buildsystem POV to run the tests
> again with a different default AM. That's precisely why I'm talking
> about this. Just setting PGOPTIONS='-c
> default_table_access_method=zheap' in the new make
On Mon, Dec 31, 2018 at 01:21:00PM +0200, David Steele wrote:
> This patch looks good to me.
(Sorry for the delay here)
0001 looks fine to me.
-to the latest timeline found in the archive, which is useful in
-a standby server. Other than that you only need to set this parameter
+
Hi,
On 2019-01-07 21:08:58 -0500, Stephen Frost wrote:
> * Andres Freund (and...@anarazel.de) wrote:
> > On 2019-01-07 20:30:13 -0500, Stephen Frost wrote:
> > > I don't agree with the general assumption that "we did this for
> > > development and therefore it should be done that way forever".
> >
On Mon, Jan 07, 2019 at 05:28:27PM +0900, Amit Langote wrote:
> On 2019/01/07 16:35, Michael Paquier wrote:
>> It seems to me that we may want something more like:
>> Primary: "could not use \"%s.%s\" as logical replication target".
>> Detail: "Relation %s.%s is a foreign table", "not a table", etc
Greetings,
* Andres Freund (and...@anarazel.de) wrote:
> On 2019-01-07 20:30:13 -0500, Stephen Frost wrote:
> > * Andres Freund (and...@anarazel.de) wrote:
> > > On 2019-01-07 19:19:46 -0500, Stephen Frost wrote:
> > > > * Andres Freund (and...@anarazel.de) wrote:
> > > > > Over in [1] we're discu
On Mon, Jan 07, 2019 at 06:10:21PM +0900, Masahiko Sawada wrote:
> 0002 and 0003 are merged and posted by Michael-san and it looks good
> to me, so I've looked at the 0001, 0004, 0005 and 0006 patches. Here
> is a few review comments.
I have done another round on 0002/0003 (PQfinish was lacking af
Hi,
On 2019-01-07 20:30:13 -0500, Stephen Frost wrote:
> * Andres Freund (and...@anarazel.de) wrote:
> > On 2019-01-07 19:19:46 -0500, Stephen Frost wrote:
> > > * Andres Freund (and...@anarazel.de) wrote:
> > > > Over in [1] we're discussing the development of the pluggable storage
> > > > patchs
On 2019/01/07 23:13, Justin Pryzby wrote:
> The issue was this:
>>> It turns out 1050 open()s are due to historic data which is no longer being
>>> loaded and therefor never converted to relkind=p (but hasn't exceeded the
>>> retention interval so not yet DROPped, either).
>
> So there's no eviden
Greetings,
* Andres Freund (and...@anarazel.de) wrote:
> On 2019-01-07 19:19:46 -0500, Stephen Frost wrote:
> > * Andres Freund (and...@anarazel.de) wrote:
> > > Over in [1] we're discussing the development of the pluggable storage
> > > patchset, which allows different ways of storing table data.
On Mon, Jan 07, 2019 at 01:34:08PM -0600, Justin Pryzby wrote:
> I don't see any discussion regarding ALTER (?)
>
> Actually, I ran into this while trying to set pages_per_range.
> But shouldn't it also work for fillfactor ?
Like ALTER TABLE, the take for ALTER INDEX is that we are still
lacking
Hi,
On 2019-01-07 10:32:20 +0100, Christoph Berg wrote:
> Re: To Michael Paquier 2019-01-07 <20190107091734.ga1...@msg.credativ.de>
> > Updated patch attached.
>
> Here's another revision that doesn't add an extra CXXOPT variable but
> just extends CXXFLAGS whenever COPT or PROFILE are set, which
On Mon, Jan 07, 2019 at 10:32:20AM +0100, Christoph Berg wrote:
> Here's another revision that doesn't add an extra CXXOPT variable but
> just extends CXXFLAGS whenever COPT or PROFILE are set, which seems
> more usable.
>
> It also updates the documentation.
The documentation is not fully update
>> On Sat, Jan 5, 2019 at 1:35 AM Tatsuo Ishii wrote:
>>> PostgreSQL includes an implementation of the
>>> standard btree (multi-way binary tree) index data
>>> structure.
>>>
>>> I think the term "btree" here means "multi-way balanced tree", rather
>>> than "multi-way binary tree". In fact
Hi,
On 2019-01-07 19:37:51 -0500, Tom Lane wrote:
> Andres Freund writes:
> > Hm, shouldn't we extract the perfect hash generation into a perl module
> > or such? It seems that there's plenty other possible uses for it.
>
> Such as?
Builtin functions for one, which we'd swatted down last time ro
Andres Freund writes:
> Hm, shouldn't we extract the perfect hash generation into a perl module
> or such? It seems that there's plenty other possible uses for it.
Such as? But in any case, that sounds like a task for someone with
more sense of Perl style than I have.
re
I wrote:
> Probably there's a lot to be criticized about the Perl style below;
> anybody feel a need to rewrite it?
Here's a somewhat better version. I realized that I was being too
slavishly tied to the data structures used in the C version; in Perl
it's easier to manage the lists of edges as ha
Hi,
On 2019-01-07 19:19:46 -0500, Stephen Frost wrote:
> Greetings,
>
> * Andres Freund (and...@anarazel.de) wrote:
> > Over in [1] we're discussing the development of the pluggable storage
> > patchset, which allows different ways of storing table data.
> >
> > One thing I'd like to discuss wit
On Tue, Dec 18, 2018 at 3:53 PM Amit Kapila wrote:
> On Wed, Dec 12, 2018 at 3:54 PM Haribabu Kommi
> wrote:
> >
> > On Thu, Nov 29, 2018 at 1:57 PM Amit Kapila
> wrote:
> >> >
> >>
> >> Agreed. Hari, can you change the patch as per the requirements of
> option-4.
> >
> >
> > Apologies for del
Greetings,
* Andres Freund (and...@anarazel.de) wrote:
> Over in [1] we're discussing the development of the pluggable storage
> patchset, which allows different ways of storing table data.
>
> One thing I'd like to discuss with a wider audience than the
> implementation details is psql and pg_du
Hi,
Over in [1] we're discussing the development of the pluggable storage
patchset, which allows different ways of storing table data.
One thing I'd like to discuss with a wider audience than the
implementation details is psql and pg_dump handling of table access
methods.
Currently the patchset
On 12/15/18 12:32 AM, Andrew Dunstan wrote:
>
> On 12/14/18 4:35 PM, Tomas Vondra wrote:
>> On 12/14/18 4:58 PM, Tom Lane wrote:
>>> ...
>>>
>>> In general, I'm not particularly on board with our valgrind.supp
>>> carrying suppressions for code outside our own code base: I think
>>> that's assumin
Hi,
On 2019-01-07 16:11:04 -0500, Tom Lane wrote:
> I wrote:
> > I took a quick look through the NetBSD nbperf sources at
> > http://cvsweb.netbsd.org/bsdweb.cgi/src/usr.bin/nbperf/
> > and I concur with your judgment that we could manage translating
> > that into Perl, especially if we only imple
Greetings -hackers,
Google Summer of Code is back for 2019! They have a similar set of
requirements, expectations, and timeline as last year.
Now is the time to be working to get together a set of projects we'd
like to have GSoC students work on over the summer. Similar to last
year, we need to
On Sat, Jan 5, 2019 at 6:30 PM Tom Lane wrote:
> Peter Eisentraut writes:
> > Why are you not including a test for \set VERBOSITY verbose?
>
> Stability of the output would be a problem ...
>
> Yes it could moreover the functionality wasn't tested before.
Should I add one ?
I wrote:
> I took a quick look through the NetBSD nbperf sources at
> http://cvsweb.netbsd.org/bsdweb.cgi/src/usr.bin/nbperf/
> and I concur with your judgment that we could manage translating
> that into Perl, especially if we only implement the parts we need.
Here's an implementation of that, us
On 1/6/19, Tom Lane wrote:
> I've pushed that version (v8 + max_kw_len); if the buildfarm doesn't
> fall over, we can move on with looking at hashing.
Thank you. The API adjustment looks good, and I'm glad that splitting
out the aux info led to even further cleanups.
-John Naylor
On 1/3/19, Amit Kapila wrote:
> Yeah, that makes sense, John, can you provide a patch on top of the
> current patch where we check either the last block or every other
> block.
I've attached two patches for testing. Each one applies on top of the
current patch.
Mithun, I'll respond to your other
On Mon, Jan 07, 2019 at 04:23:30PM -0300, Alvaro Herrera wrote:
> On 2019-Jan-05, Justin Pryzby wrote:
>
> > 12dev and 11.1:
> >
> > postgres=# CREATE TABLE t(i int)PARTITION BY RANGE(i);
> > postgres=# CREATE INDEX ON t(i) WITH(fillfactor=11);
> > postgres=# ALTER INDEX t_i_idx SET (fillfactor=1
В письме от понедельник, 7 января 2019 г. 13:56:48 MSK пользователь Alvaro
Herrera написал:
> > Asserts are cool thing. I found some unexpected stuff.
> >
> > parallel_workers option is claimed to be heap-only option.
> >
> > But in src/backend/optimizer/util/plancat.c in get_relation_info
> >
On 2019-Jan-05, Justin Pryzby wrote:
> 12dev and 11.1:
>
> postgres=# CREATE TABLE t(i int)PARTITION BY RANGE(i);
> postgres=# CREATE INDEX ON t(i) WITH(fillfactor=11);
> postgres=# ALTER INDEX t_i_idx SET (fillfactor=12);
> ERROR: 42809: "t_i_idx" is not a table, view, materialized view, or ind
> "Karl" == Karl O Pinc writes:
Karl> Hi,
Karl> Attached is documentation patch: doc_client_min_messages_v1.patch
Karl> Document that INFO severity messages are always sent
Karl> to the client.
Pushed, thanks.
--
Andrew (irc:RhodiumToad)
Hi,
On 11/30/18 2:12 PM, Alvaro Herrera wrote:
Here's a more credible version of this patch series.
The patch series applies with hunks, and passes check-world.
No comments for 0001, 0002, 0003 and 0005.
While I'm still looking at 0004 - should we have a test that updates one
of the constr
В письме от воскресенье, 6 января 2019 г. 17:50:36 MSK пользователь Andrew
Dunstan написал:
> > The correct way to code this is to depend on the exit code,
> > not the text output:
> >
> > if command -v etags >/dev/null
> > then
> > : ok
> > else
> > echo etags not found
> > exit 1
> > fi
On 2019-Jan-07, Nikolay Shaplov wrote:
> Asserts are cool thing. I found some unexpected stuff.
>
> parallel_workers option is claimed to be heap-only option.
>
> But in src/backend/optimizer/util/plancat.c in get_relation_info
> RelationGetParallelWorkers is being called for both heap and toa
Hi Stephen,
Le sam. 5 janv. 2019 à 20:41, Stephen Frost a écrit :
> Greetings Lætitia!
>
> * Lætitia Avrot (laetitia.av...@gmail.com) wrote:
> > When you look at Postgres' SQL reference documentation for `GRANT`, the
> > `ALL TABLES` clause is explained as :
> >
> > > ALL TABLES also affects vie
В письме от четверг, 3 января 2019 г. 17:15:08 MSK пользователь Alvaro Herrera
написал:
> > Can we think about backward compatibility aliases?
.
> > And keep them for as log as needed to avoid #if VERSION in thirdparty
> > code?
> Well, if you do this, at some point you need to tell the exten
On Mon, Jan 7, 2019 at 3:37 PM Masahiko Sawada
wrote:
> On Mon, Jan 7, 2019 at 6:54 PM Magnus Hagander
> wrote:
> >
> > On Mon, Jan 7, 2019 at 9:01 AM Masahiko Sawada
> wrote:
> >>
> >> Hi,
> >>
> >> Logical replication enables us to replicate data changes to different
> >> major version Postgr
On 05/01/2019 16:42, Alvaro Herrera wrote:
>> Yeah. Actually, we already have a solution of this in pg_basebackup,
>> with a bool success variable. I rewrote it like that. At least it's
>> better for uniformity.
>
> Ah, yeah, much better, LGTM.
>
>> I also added an atexit() conversion in isola
On Mon, Jan 7, 2019 at 6:54 PM Magnus Hagander wrote:
>
> On Mon, Jan 7, 2019 at 9:01 AM Masahiko Sawada wrote:
>>
>> Hi,
>>
>> Logical replication enables us to replicate data changes to different
>> major version PostgreSQL as the doc says[1]. However the current
>> logical replication can work
On Mon, Jan 07, 2019 at 09:40:50PM +1300, David Rowley wrote:
> On Fri, 4 Jan 2019 at 04:39, Justin Pryzby wrote:
> > Running 11dev with your v10 patch applied, this takes 2244ms with empty
> > buffer
> > cache after postmaster restarted on a totally untuned instance (and a new
> > backend, with
Hi Peter,
On 1/3/19 7:03 AM, Peter Eisentraut wrote:
Perhaps more documentation would be useful here.
Here is v2 that just notes that the -j option isn't passed down.
Best regards,
Jesper
>From fe0be6c1f5cbcaeb2981ff4dcfceae2e2cb286b7 Mon Sep 17 00:00:00 2001
From: jesperpedersen
Date: Fri
On 1/7/19 6:34 AM, Tsunakawa, Takayuki wrote:
1. Doesn't provide precise data
Sampling could miss intermittent short waits, e.g., buffer content lock waits
during checkpoints. This might make it difficult or impossible to solve
transient performance problems, such as infrequent 100 millisecond
On 06/01/2019 12:59, Surafel Temesgen wrote:
> it is not always the case to have in control of the data importing it
> may came from
> external system
But the problem that David described remains: If your data loading
requirement is so complicated that you need to load the file in chunks,
then do
On 07/01/2019 10:54, Magnus Hagander wrote:
> I assume you are not suggesting a publication with truncation enabled
> should just ignore replicating truncation if the downstream server
> doesn't support it? Because if that's the suggestion, then a strong -1
> from me on that.
Yes, that's the reas
В письме от четверг, 3 января 2019 г. 17:15:08 MSK пользователь Alvaro Herrera
написал:
> I would have liked to get a StaticAssert in the definition, but I don't
> think it's possible. A standard Assert() should be possible, though.
Asserts are cool thing. I found some unexpected stuff.
paral
On Sat, 5 Jan 2019 at 02:09, Andres Freund wrote:
>
> Hi,
>
> On 2019-01-03 13:40:42 -0500, Tom Lane wrote:
> > I noticed that this patch has broken restores of existing dump files:
> >
> > psql:testbed.public.backup:82: ERROR: unrecognized configuration parameter
> > "default_with_oids"
> >
> >
(2018/11/30 19:55), Etsuro Fujita wrote:
One thing we would need to discuss more about this is the name of a new
function added by the patch. IIRC, we have three options so far [1]:
1) perform_one_foreign_dml proposed by Ashutosh
2) execute_dml_single_row proposed by Michael
3) execute_parameter
Thanks very much for your comments.
To the best of my knowledge, smgr is a layer that abstract the storage
operations. Therefore, it is a good place to control or collect information
the storage operations without touching the physical storage layer.
Moreover, smgr is coming with actual disk IO op
On Mon, Jan 7, 2019 at 9:01 AM Masahiko Sawada
wrote:
> Hi,
>
> Logical replication enables us to replicate data changes to different
> major version PostgreSQL as the doc says[1]. However the current
> logical replication can work fine only if replicating to a newer major
> version PostgreSQL su
Re: To Michael Paquier 2019-01-07 <20190107091734.ga1...@msg.credativ.de>
> Updated patch attached.
Here's another revision that doesn't add an extra CXXOPT variable but
just extends CXXFLAGS whenever COPT or PROFILE are set, which seems
more usable.
It also updates the documentation.
Christoph
Re: Michael Paquier 2019-01-04 <20190104133305.gg2...@paquier.xyz>
> On Fri, Jan 04, 2019 at 11:41:15AM +0100, Peter Eisentraut wrote:
> > Note that pgxs supports PG_CPPFLAGS for adding custom pieces to CPPFLAGS
> > in a safe way. Maybe we should add an equivalent for CFLAGS? It's just
> > that i
Thanks Justin for reporting the results of your testing.
On 2019/01/07 17:40, David Rowley wrote:
> On Fri, 4 Jan 2019 at 04:39, Justin Pryzby wrote:
>> Running 11dev with your v10 patch applied, this takes 2244ms with empty
>> buffer
>> cache after postmaster restarted on a totally untuned inst
Hi!
Thanks for working on this feature, I believe it solves actual problem of HA
systems.
> 30 окт. 2018 г., в 8:01, Michael Paquier написал(а):
>
> Another thing I am wondering is: do we actually need something complex?
> What we want to know is what data is necessary to build the file map, s
On Sat, Jan 5, 2019 at 8:50 AM Bossart, Nathan wrote:
>
> On 12/21/18, 11:14 AM, "Bossart, Nathan" wrote:
> > On 12/21/18, 10:51 AM, "Robert Haas" wrote:
> >> On Thu, Dec 20, 2018 at 11:48 AM Bossart, Nathan
> >> wrote:
> >>> Either way, we'll still have to decide whether to fail or to silentl
On Fri, 4 Jan 2019 at 04:39, Justin Pryzby wrote:
> Running 11dev with your v10 patch applied, this takes 2244ms with empty buffer
> cache after postmaster restarted on a totally untuned instance (and a new
> backend, with no cached opened files).
>
> I was curious why it took even 2sec, and why i
Hi!
On Thu, Dec 27, 2018 at 4:57 AM Yugo Nagata wrote:
> I would like to implement Incremental View Maintenance (IVM) on PostgreSQL.
> IVM is a technique to maintain materialized views which computes and applies
> only the incremental changes to the materialized views rather than
> recomputate th
On 2019/01/07 16:35, Michael Paquier wrote:
> On Mon, Jan 07, 2019 at 01:49:49PM +0900, Amit Langote wrote:
>> {
>> /*
>> - * We currently only support writing to regular tables.
>> + * We currently only support writing to regular tables. However, give
>> + * a more specific erro
Hi,
Logical replication enables us to replicate data changes to different
major version PostgreSQL as the doc says[1]. However the current
logical replication can work fine only if replicating to a newer major
version PostgreSQL such as from 10 to 11. Regarding using logical
replication with older
71 matches
Mail list logo
