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 op
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
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
table_f
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 exam
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 move
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 there
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
> > Corre
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 p
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 terribly
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 Co
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 th
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.
>
> +
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
>> IsToastClass
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 +120
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 ke
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: i
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 som
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 n
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 i
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
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 a
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 sh
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 rin
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
wro
> 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 disab
Don't we have a build farm animal that runs under valgrind that would
have caught this?
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
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 sup
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
>
> I'
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
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 t
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 ...
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 De
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 of
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 tha
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,
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
387a
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 conveni
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 e
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?
>
--index-
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.
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 tablea
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 rewrite
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 follo
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 sev
> 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 default_explain
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 ca
"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
b
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
On Thu. May. 9, 2019 at 01:48 AM Masao, Fujii
wrote:
> Thanks! Pushed.
Thank you.
Regards
Ryo Matsumura
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 --disable-index-
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
Descri
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 cau
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 FirstNormalO
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
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, ha
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
>
Hi
rebased patch
Regards
Pavel
schema-variables-20190509.patch.gz
Description: application/gzip
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 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 thes
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, b
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.
>
> Thu
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 doesn'
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 rather
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 erro
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
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
> selecting
On Sunday, 27 January 2019 11:20:03 UTC+8, Jeremy Finzel wrote:
>
> I understand it's not fully supported to replicate to a differently
> partitioned setup on a subscriber with either pglogical or the native
> logical replication, however I also know that INSERT triggers can be fired
> in repl
On Thu, May 9, 2019 at 3:32 AM Michael Paquier wrote:
>
> 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 releas
At Wed, 8 May 2019 22:54:14 -0700, Noah Misch wrote in
<20190509055414.gb1066...@rfd.leadboat.com>
> 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 th
On Mon, May 6, 2019 at 5:43 PM Dilip Kumar wrote:
>
> Just for tracking, open comments which still needs to be worked on.
>
> 1. Avoid special case in UndoRecordIsValid.
> > Can we instead eliminate the special case? It seems like the if
> > (log->oldest_data == InvalidUndoRecPtr) case will be t
On Thu, 2019-05-09 at 04:51 +, M Tarkeshwar Rao wrote:
> 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.
>
> [roles "pg_signal_backend" and "postgres"]
>
On 2018-07-25 01:47, Tomas Vondra wrote:
> Add strict_multi_assignment and too_many_rows plpgsql checks
Could you clarify this error message:
/* translator: %s represents a name of an extra check */
errdetail("%s check of %s is active.",
"strict_multi_assignment",
73 matches
Mail list logo
