On Wed, May 08, 2019 at 02:32:46PM -0400, Tom Lane wrote:
> Just now, while running a parallel check-world on HEAD according to the
> same script I've been using for quite some time, one of the TAP tests
> died during initdb:
>
> selecting dynamic shared memory implementation ... posix
>
On Tue, May 07, 2019 at 10:31:59AM +0900, Kyotaro HORIGUCHI wrote:
> The patch seems to be using the tablespace directory in backups
> directly from standbys. In other words, multiple standbys created
> from A backup shares the tablespace directory in the backup.
Yes, I noticed that, and I am not
Thanks you Tom and Robert! I tried valgrind, and looks it help me fix
the issue.
Someone add some code during backend init which used palloc. but at that
time, the CurrentMemoryContext is PostmasterContext. at the end of
backend initialization, the PostmasterContext is deleted, then the
On Fri, Mar 22, 2019 at 04:25:53PM +0800, Shaoqi Bai wrote:
> Deleted the test for group permissions in updated patch.
Well, there are a couple of things I am not really happy about in this
patch:
- There is not much point to have has_tablespace_mapping as it is not
extensible. Instead I'd
On Thu, May 2, 2019 at 1:39 AM Robert Haas wrote:
>
> On Wed, May 1, 2019 at 12:14 PM Andres Freund wrote:
> > On 2019-04-06 16:13:53 +0900, Michael Paquier wrote:
> > > On Sat, Apr 06, 2019 at 11:31:31AM +0900, Masahiko Sawada wrote:
> > > > Yes, but Fujii-san pointed out that this option
At Thu, 09 May 2019 11:17:46 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI
wrote in
<20190509.111746.217492977.horiguchi.kyot...@lab.ntt.co.jp>
> Valgrind doesn't detect the overruning read since the block
> doesn't has 'MEMNOACCESS' region, since the requested size is
> just 64 bytes.
>
>
On Mon, May 6, 2019 at 4:21 PM Paul Jungwirth
wrote:
> I need to write some docs and do
> some cleanup and I'll have a CF entry.
Here is an initial patch. I'd love to have some feedback! :-)
One challenge was handling polymorphism, since I want to have this:
anyrange[] range_agg(anyrange,
Hi all,
We would need to integrate Postgres Users Authentication with our own LDAP
Server.
Basically as of now we are able to login to Postgress DB with a user/password
credential.
[cid:image001.png@01D50650.D807AE30]
These user objects are the part of Postgres DB server. Now we want that
Er, ping. Nobody has reviewed the latest patchs.
Next CF is in July, two months away.
You might consider reviewing other people patches, that is expected to
make the overall process work. There are several documentation or
comment patches in the queue.
--
Fabien.
Hi
rebased patch
Regards
Pavel
schema-variables-20190509.patch.gz
Description: application/gzip
On Friday, 25 January 2019 04:57:15 UTC+8, Jeremy Finzel wrote:
>
> We are working to migrate several large tables from the timestamp to the
> timestamptz data type by using logical replication (so as to avoid long
> downtime for type conversions). We are using pglogical but curious if what
On Wed, May 08, 2019 at 11:28:35PM -0400, Tom Lane wrote:
> Michael Paquier writes:
>> No problem to do that. I'll brush up all that once you commit the
>> first piece you have come up with, and reuse the new API of catalog.c
>> you are introducing based on the table OID.
>
> Pushed my stuff,
Michael Paquier writes:
> No problem to do that. I'll brush up all that once you commit the
> first piece you have come up with, and reuse the new API of catalog.c
> you are introducing based on the table OID.
Pushed my stuff, have at it.
regards, tom lane
I wrote:
> is_publishable_class has a test "relid >= FirstNormalObjectId",
> which I think we should drop, for two reasons:
> ...
> So what is the motivation for this test? If there's an important
> reason for it, we need to find a less fragile way to express it.
I tried removing the
Hello. There is an unfortunate story on this issue.
At Wed, 8 May 2019 14:56:25 -0400, Andrew Dunstan
wrote in
<7969b496-096a-bf9b-2a03-4706baa4c...@2ndquadrant.com>
>
> On 5/8/19 12:41 PM, Greg Stark wrote:
> > Don't we have a build farm animal that runs under valgrind that would
> > have
On Sat, May 04, 2019 at 11:48:53AM -0400, Tom Lane wrote:
> +1, waiting till after the minor releases are tagged seems wisest.
> We can still push it before 12beta1, so it will get tested in the beta
> period.
The new minor releases have been tagged, so committed.
--
Michael
signature.asc
On Wed, May 08, 2019 at 06:21:09PM -0300, Euler Taveira wrote:
> Em qua, 8 de mai de 2019 às 14:19, Fujii Masao
> escreveu:
>> The question is; we should support vacuumdb option for (1), i.e.,,
>> something like --index-cleanup option is added?
>> Or for (2), i.e., something like
On Thu. May. 9, 2019 at 01:48 AM Masao, Fujii
wrote:
> Thanks! Pushed.
Thank you.
Regards
Ryo Matsumura
On Wed, May 8, 2019 at 2:51 PM Andres Freund wrote:
>
> Hi,
>
> On 2019-05-08 00:32:22 -0700, Ashwin Agrawal wrote:
> > The general theme for table function names seem to be
> > "table_". For example table_scan_getnextslot() and its
> > corresponding callback scan_getnextslot(). Most of the table
"Nasby, Jim" writes:
> The problem is that pg_dump --binary-upgrade intentionally does not
> simply issue a `CREATE EXTENSION` command the way a normal dump does, so
> that it can control the OIDs that are assigned to objects[1].
That's not the only reason. The original concerns were about not
On Tue, May 7, 2019 at 6:15 PM Peter Geoghegan wrote:
> I suppose I'm biased, but I prefer the new approach anyway. Adding the
> left high key first, and then the right high key seems simpler and
> more logical. It emphasizes the similarities and differences between
> leftpage and rightpage.
I
> On May 8, 2019, at 4:22 PM, Vik Fearing wrote:
>
> On 07/05/2019 09:30, David Fetter wrote:
>> Folks,
>>
>> It can get a little tedious turning on (or off) all the boolean
>> options to EXPLAIN, so please find attached a shortcut.
>
> I would rather have a set of gucs such as
pgTap has a view that references pg_proc; to support introspection of functions
and aggregates. That view references proisagg in versions < 11, and prokind in
11+. pgtap's make process understands how to handle this; modifying the
creation scripts as necessary. It actually has to do this for
Hi,
On 2019-05-08 00:32:22 -0700, Ashwin Agrawal wrote:
> The general theme for table function names seem to be
> "table_". For example table_scan_getnextslot() and its
> corresponding callback scan_getnextslot(). Most of the table functions and
> callbacks follow mentioned convention except
Hi,
On 2019-05-07 23:18:39 -0700, Ashwin Agrawal wrote:
> On Mon, May 6, 2019 at 1:39 PM Ashwin Agrawal wrote:
> > Also wish to point out, while working on Zedstore, we realized that
> > TupleDesc from Relation object can be trusted at AM layer for
> > scan_begin() API. As for ALTER TABLE
Hi,
On 2019-04-29 16:17:41 -0700, Ashwin Agrawal wrote:
> On Thu, Apr 25, 2019 at 3:43 PM Andres Freund wrote:
> > Hm. I think some of those changes would be a bit bigger than I initially
> > though. Attached is a more minimal fix that'd route
> > RelationGetNumberOfBlocksForFork() through
On 07/05/2019 09:30, David Fetter wrote:
> Folks,
>
> It can get a little tedious turning on (or off) all the boolean
> options to EXPLAIN, so please find attached a shortcut.
I would rather have a set of gucs such as default_explain_buffers,
default_explain_summary, and default_explain_format.
Em qua, 8 de mai de 2019 às 14:19, Fujii Masao escreveu:
>
> The question is; we should support vacuumdb option for (1), i.e.,,
> something like --index-cleanup option is added?
> Or for (2), i.e., something like --disable-index-cleanup option is added
> as your patch does? Or for both?
>
Er, ping. Nobody has reviewed the latest patchs.
They still apply to master...
I am re-attaching the patches. See descriptions
below.
On Mon, 11 Mar 2019 15:32:14 -0500
"Karl O. Pinc" wrote:
> On Sun, 10 Mar 2019 08:15:35 +0100 (CET)
> Fabien COELHO What's causing problems here is that the
On 2019-May-08, Justin Pryzby wrote:
> I noticed you added release notes at bdf595adbca195fa54a909c74a5233ebc30641a1,
> thanks for writing them.
>
> I reviewed notes; find proposed changes attached+included.
>
> I think these should also be mentioned?
>
> a6da004 Add index_get_partition
I noticed you added release notes at bdf595adbca195fa54a909c74a5233ebc30641a1,
thanks for writing them.
I reviewed notes; find proposed changes attached+included.
I think these should also be mentioned?
f7cb284 Add plan_cache_mode setting
a6da004 Add index_get_partition convenience function
On Tue, May 7, 2019 at 12:31 PM David Fetter wrote:
> If you're tuning a query interactively, it's a lot simpler to prepend,
> for example,
>
> EXPLAIN (ALL, FORMAT JSON)
>
> to it than to prepend something along the lines of
>
> EXPLAIN(ANALYZE, VERBOSE, COSTS, BUFFERS, SETTINGS, TIMING,
On Tue, May 7, 2019 at 6:25 PM Tom Lane wrote:
> Meh --- I don't especially care for non-orthogonal behaviors like that.
> If you wanted JSON but *not* all of the additional info, how would you
> specify that? (The implementation I had in mind would make VERBOSE OFF
> more or less a no-op, so
I found what appears to be a dangling reference to old "hidden" OID behavior.
Justin
>From 1c6712c0ade949648dbc415dfd7ea80312360ef7 Mon Sep 17 00:00:00 2001
From: Justin Pryzby
Date: Wed, 8 May 2019 13:57:12 -0500
Subject: [PATCH v1] Cleanup/remove/update references to OID column...
..in wake
On 5/8/19 12:41 PM, Greg Stark wrote:
> Don't we have a build farm animal that runs under valgrind that would
> have caught this?
>
>
There are two animals running under valgrind: lousyjack and skink.
cheers
andrew
--
Andrew Dunstanhttps://www.2ndQuadrant.com
PostgreSQL
Just now, while running a parallel check-world on HEAD according to the
same script I've been using for quite some time, one of the TAP tests
died during initdb:
selecting dynamic shared memory implementation ... posix
selecting default max_connections ... 100
selecting default shared_buffers ...
Hi,
On 2019-05-08 21:35:06 +0500, Andrey Borodin wrote:
> > 8 мая 2019 г., в 1:16, Andres Freund написал(а):
> >
> > We probably can't remove the ringbuffer concept from these places, but I
> > think we should allow users to disable them. Forcing bulk-loads, vacuum,
> > analytics queries to go
Hi,
On 2019-05-08 10:08:03 -0400, Robert Haas wrote:
> On Tue, May 7, 2019 at 4:16 PM Andres Freund wrote:
> > Just to attach some numbers for this. On my laptop, with a pretty fast
> > disk (as in ~550MB/s read + write, limited by SATA, not the disk), I get
> > these results.
> >
> > [ results
On Wed, May 8, 2019 at 10:34 AM Tom Lane wrote:
> Alex writes:
> > I can get the following log randomly and I am not which commit caused it.
>
> > 2019-05-08 21:37:46.692 CST [60110] WARNING: problem in alloc set index
> > info: req size > alloc size for chunk 0x2a33a78 in block 0x2a33a18
>
>
On Wed, May 8, 2019 at 9:32 AM Masahiko Sawada wrote:
>
> On Wed, May 8, 2019 at 2:41 AM Fujii Masao wrote:
> >
> > Hi,
> >
> > vacuumdb command supports the corresponding options to
> > any VACUUM parameters except INDEX_CLEANUP and TRUNCATE
> > that were added recently. Should vacuumdb also
On Fri, Apr 26, 2019 at 10:52 AM Matsumura, Ryo
wrote:
>
> On Wed. Apr. 24, 2019 at 11:40 PM Masao, Fujii
> wrote:
>
> Thank you for the comment.
> I understand about REPLICATION privilege and notice my unecessary words.
> I update the patch.
Thanks! Pushed.
Regards,
--
Fujii Masao
Don't we have a build farm animal that runs under valgrind that would
have caught this?
> 8 мая 2019 г., в 1:16, Andres Freund написал(а):
>
> We probably can't remove the ringbuffer concept from these places, but I
> think we should allow users to disable them. Forcing bulk-loads, vacuum,
> analytics queries to go to the OS/disk, just because of a heuristic that
> can't be
On Wed, May 08, 2019 at 01:09:23PM +0900, Kyotaro HORIGUCHI wrote:
At Wed, 08 May 2019 13:06:36 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI
wrote in
<20190508.130636.184826233.horiguchi.kyot...@lab.ntt.co.jp>
At Tue, 07 May 2019 20:47:28 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI
On Wed, May 08, 2019 at 10:08:03AM -0400, Robert Haas wrote:
On Tue, May 7, 2019 at 4:16 PM Andres Freund wrote:
Just to attach some numbers for this. On my laptop, with a pretty fast
disk (as in ~550MB/s read + write, limited by SATA, not the disk), I get
these results.
[ results showing
On Tue, May 07, 2019 at 05:30:27PM -0700, Melanie Plageman wrote:
On Mon, May 6, 2019 at 8:15 PM Tomas Vondra
wrote:
Nope, that's not how it works. It's the array of batches that gets
sliced, not the batches themselves.
It does slightly increase the amount of data we need to
On Tue, 2019-05-07 at 13:06 +0900, Michael Paquier wrote:
> On Fri, May 03, 2019 at 08:14:35AM +0200, Laurenz Albe wrote:
> > On Thu, 2019-05-02 at 22:43 +0200, Peter Eisentraut wrote:
> >> I think the proper way to address this would be to create some kind of
> >> dependency between the sequence
Alex writes:
> I can get the following log randomly and I am not which commit caused it.
> 2019-05-08 21:37:46.692 CST [60110] WARNING: problem in alloc set index
> info: req size > alloc size for chunk 0x2a33a78 in block 0x2a33a18
I've had success in finding memory stomp causes fairly quickly
Robert Haas writes:
> I think it's unjustifiable to show this in \d output. But maybe in
> \d+ output it could be justified, or perhaps in the \d++ which I seem
> to recall Alvaro proposing someplace recently.
Yeah, if we're going to do that (show a table's toast table) I would
want to bury it
On Tue, May 7, 2019 at 6:03 PM Stephen Frost wrote:
> Alright, maybe I'm not the best representation of our user base, but I
> sure type 'select oid,* from pg_class where relname = ...' with some
> regularity, mostly to get the oid to then go do something else. Having
> the relfilenode would be
On Tue, May 7, 2019 at 4:16 PM Andres Freund wrote:
> Just to attach some numbers for this. On my laptop, with a pretty fast
> disk (as in ~550MB/s read + write, limited by SATA, not the disk), I get
> these results.
>
> [ results showing ring buffers massively hurting performance ]
Links to
I can get the following log randomly and I am not which commit caused it.
I spend one day but failed at last.
2019-05-08 21:37:46.692 CST [60110] WARNING: problem in alloc set index
info: req size > alloc size for chunk 0x2a33a78 in block 0x2a33a18
2019-05-08 21:37:46.692 CST [60110] WARNING:
On Tue, May 7, 2019 at 2:10 AM Masahiko Sawada wrote:
> > > That better not be true. If you have a design where reading the WAL
> > > lets you get *any* encryption key, you have a bad design, I think.
>
> How does the startup process decrypt WAL during recovery without
> getting any encryption
On Tue, May 07, 2019 at 05:43:56PM -0700, Melanie Plageman wrote:
On Tue, May 7, 2019 at 6:59 AM Tomas Vondra
wrote:
On Tue, May 07, 2019 at 04:28:36PM +1200, Thomas Munro wrote:
>On Tue, May 7, 2019 at 3:15 PM Tomas Vondra
> wrote:
>> On Tue, May 07, 2019 at 01:48:40PM
On Wed, May 08, 2019 at 08:31:54AM -0400, Tom Lane wrote:
> Michael Paquier writes:
>> With IsCatalogClass() removed, the only dependency with Form_pg_class
>> comes from IsToastClass() which is not used at all except in
>> IsSystemClass(). Wouldn't it be better to remove entirely
>>
On 2019-05-07 05:07, Michael Paquier wrote:
> On Sat, May 04, 2019 at 09:59:20PM +0900, Michael Paquier wrote:
>> The result should be no deadlocks happening in the two sessions
>> running the reindex. I can see the deadlock easily with three psql
>> sessions, running manually the queries.
>
> +
Michael Paquier writes:
> On Tue, May 07, 2019 at 05:19:38PM -0400, Tom Lane wrote:
>> With this, the Form_pg_class argument to IsCatalogClass becomes
>> vestigial. I'm tempted to get rid of that function altogether in
>> favor of direct calls to IsCatalogRelationOid, but haven't done so
>> in
On Wed, May 8, 2019 at 12:09 AM Kyotaro HORIGUCHI
wrote:
> By the way, as mentioned above, this issue exists since 11 but
> harms at 12. Is this an open item, or older bug?
Sounds more like an open item to me.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL
On Mon, May 6, 2019 at 3:30 PM Thomas Munro wrote:
> I put the second sentence back and tweaked it thus: s/fails/might
> fail/. Maybe I'm being too pedantic here, but binding to 127.0.0.2
> works on other OSes too, as long as you've configured an interface or
> alias for it (and it's not
On Wed, May 8, 2019 at 9:06 AM Michael Paquier wrote:
>
> On Wed, May 08, 2019 at 09:26:35AM +0900, Masahiko Sawada wrote:
> > I think it's a good idea to add new options of these parameters for
> > vacuumdb. While making INDEX_CLEANUP option patch I also attached the
> > patch for INDEX_CLEANUP
At Tue, 7 May 2019 10:55:06 +0900, Michael Paquier wrote
in <20190507015506.gc1...@paquier.xyz>
> On Tue, May 07, 2019 at 10:16:54AM +0900, Kyotaro HORIGUCHI wrote:
> > The fake symlinks need correction after the data directory and
> > tablespsce directory are moved. Maybe needs to call
> >
On Wed, May 08, 2019 at 03:59:36PM +0800, John Naylor wrote:
> In the attached, I've used your language, and also moved the comments
> closer to the code they are describing. That seems more logical and
> future proof.
Good idea to move the comments so what you proposes looks fine to me.
Are
On Wed, May 8, 2019 at 3:10 PM Michael Paquier wrote:
>
> On Tue, May 07, 2019 at 04:12:31PM +0800, John Naylor wrote:
> > That's probably better.
>
> Would you like to send an updated patch? Perhaps you have a better
> idea?
> --
> Michael
In the attached, I've used your language, and also
On Tue, May 07, 2019 at 05:19:38PM -0400, Tom Lane wrote:
> That's nothing but a hack, and the reason it's necessary is that
> index_create will throw error if IsCatalogRelation is true, which
> it will be for information_schema TOAST tables --- but not for their
> parent tables that are being
The general theme for table function names seem to be
"table_". For example table_scan_getnextslot() and its
corresponding callback scan_getnextslot(). Most of the table functions and
callbacks follow mentioned convention except following ones
table_beginscan
table_endscan
table_rescan
On Tue, May 07, 2019 at 04:12:31PM +0800, John Naylor wrote:
> That's probably better.
Would you like to send an updated patch? Perhaps you have a better
idea?
--
Michael
signature.asc
Description: PGP signature
On Wed, May 08, 2019 at 09:26:35AM +0900, Masahiko Sawada wrote:
> I think it's a good idea to add new options of these parameters for
> vacuumdb. While making INDEX_CLEANUP option patch I also attached the
> patch for INDEX_CLEANUP parameter before[1], although it adds
> --disable-index-cleanup
Hi, Thomas
>-Original Message-
>From: Thomas Munro [mailto:thomas.mu...@gmail.com]
>Subject: Re: Copy data to DSA area
>
>On Wed, May 8, 2019 at 5:29 PM Ideriha, Takeshi
>
>wrote:
>> >From: Ideriha, Takeshi [mailto:ideriha.take...@jp.fujitsu.com]
>> >Sent: Friday, April 26, 2019 11:50
In commit d50d172e51, which adds support for FINAL relation pushdown
in postgres_fdw, I forgot to update the FDW documentation about
GetForeignUpperPaths to mention that the extra parameter of that
function points to a FinalPathExtraData structure introduced by that
commit in the case of FINAL
Hello hackers,
On another thread, lots of undo log-related patches have been traded.
Buried deep in the stack is one that I'd like to highlight and discuss
in a separate thread, because it relates to a parallel thread of
development and it'd be good to get feedback on it.
In commit 3eb77eba,
On Mon, May 6, 2019 at 1:39 PM Ashwin Agrawal wrote:
>
> Also wish to point out, while working on Zedstore, we realized that
> TupleDesc from Relation object can be trusted at AM layer for
> scan_begin() API. As for ALTER TABLE rewrite case (ATRewriteTables()),
> catalog is updated first and
On Wed, May 8, 2019 at 5:29 PM Ideriha, Takeshi
wrote:
> >From: Ideriha, Takeshi [mailto:ideriha.take...@jp.fujitsu.com]
> >Sent: Friday, April 26, 2019 11:50 PM
> >Well, after developing PoC, I realized that this PoC doesn't solve the local
> >process is
> >crashed before the context becomes
72 matches
Mail list logo
