On Tue, Dec 22, 2020 at 4:16 PM Amit Langote wrote:
> On Mon, Dec 21, 2020 at 11:30 PM Arne Roland wrote:
> > thanks for the quick reply! Sadly I have been busy and the second part of
> > your patch does no longer apply in src/include/nodes/execnodes.h:497.
>
> I don't see any problem with
Dear All
In startup process we only launch bgwriter when ArchiveRecoveryRequested is
true, which means we will not lauch bgwriter in master node.
The bgwriters can write the dirty buffers to disk which helps startup process
to do less IO when we complete xlog replay and request to do
Hi,
On Mon, Dec 21, 2020 at 11:30 PM Arne Roland wrote:
> thanks for the quick reply! Sadly I have been busy and the second part of
> your patch does no longer apply in src/include/nodes/execnodes.h:497.
I don't see any problem with applying the patch. Are you sure you're
applying the patch
Hi Andrey,
There is an error report in your patch as follows. Please take a check.
https://travis-ci.org/github/postgresql-cfbot/postgresql/jobs/750682857#L1519
>copyfrom.c:374:21: error: ‘save_cur_lineno’ is used uninitialized in this
>function [-Werror=uninitialized]
Regards,
Tang
On Mon, Dec 21, 2020 at 8:16 AM Hou, Zhijie wrote:
> The cfbost seems complains about the testcase:
>
> Command exited with code 1
> perl dumpregr.pl
> === $path ===\ndiff -w -U3
> C:/projects/postgresql/src/test/regress/expected/write_parallel.out
>
On Wed, Dec 16, 2020 at 10:01:11AM +0900, Michael Paquier wrote:
> On Tue, Dec 15, 2020 at 09:45:17PM -0300, Alvaro Herrera wrote:
> > I don't like this idea too much, because adding an option causes an ABI
> > break. I don't think we commonly add options in backbranches, but it
> > has happened.
On Monday, December 21, 2020 10:25 PM, Amit Kapila wrote:
> I have started doing minor edits to the patch especially planning to write a
> theory why is this optimization safe and here is what I can come up with:
> "To
> remove all the pages of the specified relation forks from the buffer pool,
As I did last 2 years, I reviewed docs for v14...
This year I've started early, since it takes more than a little effort and it's
not much fun to argue the change in each individual hunk.
--
Justin Pryzby
System Administrator
Telsasoft
+1-952-707-8581
>From
On Mon, Dec 21, 2020 at 04:35:14PM -0500, Bruce Momjian wrote:
> On Sun, Dec 20, 2020 at 05:59:09PM -0500, Stephen Frost wrote:
> OK, here it the updated patch. The major change, as Stephen pointed
> out, is that the cluser_key_command (was cluster_passphrase_command) now
> returns a hex-string
From: Kyotaro Horiguchi
> Mmm. If that is true, doesn't the unoptimized path also need the
> rechecking?
Yes, the traditional processing does the recheck after acquiring the buffer
header spinlock.
Regards
Takayuki Tsunakawa
At Tue, 22 Dec 2020 02:48:22 +, "tsunakawa.ta...@fujitsu.com"
wrote in
> From: Amit Kapila
> > Why would all client backends wait for AccessExclusive lock on this
> > relation? Say, a client needs a buffer for some other relation and
> > that might evict this buffer after we release the
On Tue, Dec 22, 2020 at 8:12 AM Kyotaro Horiguchi
wrote:
>
> At Tue, 22 Dec 2020 08:08:10 +0530, Amit Kapila
> wrote in
>
> > Why would all client backends wait for AccessExclusive lock on this
> > relation? Say, a client needs a buffer for some other relation and
> > that might evict this
On Tue, Dec 22, 2020 at 8:18 AM tsunakawa.ta...@fujitsu.com
wrote:
>
> From: Amit Kapila
> > Why would all client backends wait for AccessExclusive lock on this
> > relation? Say, a client needs a buffer for some other relation and
> > that might evict this buffer after we release the lock on
From: Amit Kapila
> Why would all client backends wait for AccessExclusive lock on this
> relation? Say, a client needs a buffer for some other relation and
> that might evict this buffer after we release the lock on the
> partition. In StrategyGetBuffer, it is important to either have a pin
> on
At Tue, 22 Dec 2020 08:08:10 +0530, Amit Kapila wrote
in
> On Tue, Dec 22, 2020 at 7:13 AM tsunakawa.ta...@fujitsu.com
> wrote:
> >
> > From: Amit Kapila
> > > This answers the second part of the question but what about the first
> > > part (We hold a buffer partition lock, and have done a
At Tue, 22 Dec 2020 01:42:55 +, "tsunakawa.ta...@fujitsu.com"
wrote in
> From: Amit Kapila
> > This answers the second part of the question but what about the first
> > part (We hold a buffer partition lock, and have done a lookup in th
> > mapping table. Why are we then rechecking the
> >
On Tue, Dec 22, 2020 at 7:13 AM tsunakawa.ta...@fujitsu.com
wrote:
>
> From: Amit Kapila
> > This answers the second part of the question but what about the first
> > part (We hold a buffer partition lock, and have done a lookup in th
> > mapping table. Why are we then rechecking the
> >
On Mon, Dec 21, 2020 at 03:02:40PM -0500, Tom Lane wrote:
> Justin Pryzby writes:
> > I found that our largest tables are 40% smaller and 20% faster to pipe
> > pg_dump -Fc -Z0 |zstd relative to native zlib
>
> The patch might be a tad smaller if you hadn't included a core file in it.
About 89%
Thanks for your comments.
On 2020-12-22 09:39, Andres Freund wrote:
Hi,
On 2020-12-21 13:16:50 -0800, Andres Freund wrote:
On 2020-12-02 13:52:43 +0900, Fujii Masao wrote:
> Pushed. Thanks!
Why are wal_records/fpi long, instead of uint64?
longwal_records;/* # of WAL
From: Amit Kapila
> This answers the second part of the question but what about the first
> part (We hold a buffer partition lock, and have done a lookup in th
> mapping table. Why are we then rechecking the
> relfilenode/fork/blocknum?)
>
> I think we don't need such a check, rather we can have
On Tue, Dec 22, 2020 at 3:13 AM Tom Lane wrote:
> Up to now, if you shut down the database with "pg_ctl stop -m immediate"
> then clients get a scary message claiming that something has crashed,
> because backends can't tell whether the SIGQUIT they got was sent for
> a crash-and-restart
On Fri, Dec 18, 2020 at 6:36 PM Fujii Masao wrote:
>
>
>
> On 2020/12/17 2:15, Fujii Masao wrote:
> >
> >
> > On 2020/12/16 23:28, Drouvot, Bertrand wrote:
> >> Hi,
> >>
> >> On 12/16/20 2:36 PM, Victor Yegorov wrote:
> >>>
> >>> *CAUTION*: This email originated from outside of the organization.
Hi,
I've pushed (and backpatched) all the fixes posted to this thread. I
believe that covers all the incremental sort fixes, so I've marked [1]
as committed.
[1] https://commitfest.postgresql.org/31/2754/
regards
--
Tomas Vondra
EnterpriseDB: http://www.enterprisedb.com
The Enterprise
From: k.jami...@fujitsu.com
> I understand that protocol 2.0 is still supported, but it is only used for
> PostgreSQL versions 7.3 and earlier, which is not updated by fixes anymore
> since we only backpatch up to previous 5 versions. However I am not sure if
> it's a good idea, but how about if
Hi,
On 2020-12-21 13:16:50 -0800, Andres Freund wrote:
> On 2020-12-02 13:52:43 +0900, Fujii Masao wrote:
> > Pushed. Thanks!
>
> Why are wal_records/fpi long, instead of uint64?
> longwal_records;/* # of WAL records produced */
> longwal_fpi;
On Mon, Dec 21, 2020 at 03:00:32PM -0700, David G. Johnston wrote:
> I agree with Stephen; so maybe that part of the Wiki needs to be updated
> instead of having it sit there for use as a hammer when someone disagrees with
> a proffered patch.
>
> Or maybe consider that "a patch" doesn't only
On Mon, Dec 21, 2020 at 2:44 PM Bruce Momjian wrote:
> On Sun, Dec 20, 2020 at 09:38:55PM -0500, Stephen Frost wrote:
> > > I'll have a go at adding another keyring and/or abstracting the key
> > > wrap and see how well a true peer to the passphrase approach fits in.
> >
> > Having patches to
On Sun, Dec 20, 2020 at 05:59:09PM -0500, Stephen Frost wrote:
> I do generally like the idea of having the single command able to be
> used to either provide the KEK (where PG manages the keyring
> internally), or called multiple times to retrieve the DEKs (in which
> case PG wouldn't be managing
On Sun, Dec 20, 2020 at 09:38:55PM -0500, Stephen Frost wrote:
> > I'll have a go at adding another keyring and/or abstracting the key
> > wrap and see how well a true peer to the passphrase approach fits in.
>
> Having patches to review and consider definitely helps, imv.
I disagree. Our order
Up to now, if you shut down the database with "pg_ctl stop -m immediate"
then clients get a scary message claiming that something has crashed,
because backends can't tell whether the SIGQUIT they got was sent for
a crash-and-restart situation or because of an immediate-stop command.
This isn't
On Sun, Dec 20, 2020 at 05:59:09PM -0500, Stephen Frost wrote:
> However, after chatting with Bruce about it for a bit this weekend, I'm
> not sure that we need to tackle the second case today. I don't think
> there's any doubt that there will be users who will want PG to manage
> the keyring and
On Mon, Dec 21, 2020 at 8:25 PM Jakub Wartak wrote:
> > > I'm drawing a blank on trivial candidate uses for preadv(), without
> > > infrastructure from later patches.
> >
> > Can't immediately think of something either.
>
> This might be not that trivial , but maybe acquire_sample_rows() from
>
On Fri, Dec 18, 2020 at 6:04 AM Heikki Linnakangas wrote:
> BTW, it's a bit weird that the pg_cryptohash_init/update/final()
> functions return success, if the ctx argument is NULL. It would seem
> more sensible for them to return an error. That way, if a caller forgets
> to check for NULL result
Hi,
On 2020-12-02 13:52:43 +0900, Fujii Masao wrote:
> Pushed. Thanks!
Why are wal_records/fpi long, instead of uint64?
longwal_records;/* # of WAL records produced */
longwal_fpi;/* # of WAL full page images
produced */
uint64
Justin Pryzby writes:
> I found that our largest tables are 40% smaller and 20% faster to pipe
> pg_dump -Fc -Z0 |zstd relative to native zlib
The patch might be a tad smaller if you hadn't included a core file in it.
regards, tom lane
Greetings,
* Magnus Hagander (mag...@hagander.net) wrote:
> On Mon, Dec 21, 2020 at 8:06 PM Stephen Frost wrote:
> > * Magnus Hagander (mag...@hagander.net) wrote:
> > > On Mon, Dec 21, 2020 at 7:44 PM Tom Lane wrote:
> > > > BTW, do we have a client-side setting to insist that passwords not be
On Mon, Dec 21, 2020 at 8:06 PM Stephen Frost wrote:
>
> Greetings,
>
> * Magnus Hagander (mag...@hagander.net) wrote:
> > On Mon, Dec 21, 2020 at 7:44 PM Tom Lane wrote:
> > > BTW, do we have a client-side setting to insist that passwords not be
> > > sent in MD5 hashing either? A person who
Greetings,
* Magnus Hagander (mag...@hagander.net) wrote:
> On Mon, Dec 21, 2020 at 7:44 PM Tom Lane wrote:
> > BTW, do we have a client-side setting to insist that passwords not be
> > sent in MD5 hashing either? A person who is paranoid about this would
> > likely want to disable that code
On 12/21/20, 1:51 AM, "Noah Misch" wrote:
> Backends reflect "GRANT role_name" changes rather quickly, due to a syscache
> invalidation callback. Let's register an additional callback to reflect
> "ALTER ROLE ... [NO]INHERIT" with equal speed. I propose to back-patch this.
> While pg_authid
Greetings,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > * Tom Lane (t...@sss.pgh.pa.us) wrote:
> >> Jeff Janes writes:
> >>> I would suggest going further. I would make the change on the client
> >>> side,
> >>> and have libpq refuse to send unhashed passwords without
On Mon, Dec 21, 2020 at 7:44 PM Tom Lane wrote:
>
> Stephen Frost writes:
> > * Tom Lane (t...@sss.pgh.pa.us) wrote:
> >> Jeff Janes writes:
> >>> I would suggest going further. I would make the change on the client
> >>> side,
> >>> and have libpq refuse to send unhashed passwords without
Stephen Frost writes:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>> Jeff Janes writes:
>>> I would suggest going further. I would make the change on the client side,
>>> and have libpq refuse to send unhashed passwords without having an
>>> environment variable set which allows it.
>> As noted,
Greetings,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Jeff Janes writes:
> > On Sun, Dec 20, 2020 at 7:58 PM Stephen Frost wrote:
> >> * Magnus Hagander (mag...@hagander.net) wrote:
> >>> Maybe we should do the same for LDAP (and RADIUS)? This seems like a
> >>> better place to put it than to log
Jeff Janes writes:
> On Sun, Dec 20, 2020 at 7:58 PM Stephen Frost wrote:
>> * Magnus Hagander (mag...@hagander.net) wrote:
>>> Maybe we should do the same for LDAP (and RADIUS)? This seems like a
>>> better place to put it than to log it at every time it's received?
>> A dollar short and a
po 21. 12. 2020 v 17:23 odesílatel Tom Lane napsal:
> Pavel Stehule writes:
> > some Orafce's user reported problems with pg_upgrade. I checked this
> issue
> > and it looks like pg_dump problem:
> > ...
> > the supporting function should be dumped first before function where
> > supporting
"Joel Jacobson" writes:
> On Sat, Dec 19, 2020, at 21:35, Tom Lane wrote:
>> Here is a proposed patch for that.
> In addition, to the user wondering how to append a json array-value "as is",
> I think it would be useful to provide an example on how to do this
> in the documentation.
Done in v13
Thanks Tom, Andrew
I’ll try out logging_collector facility
thanks again
dm
> On Dec 20, 2020, at 12:04 PM, Andrew Dunstan wrote:
>
>
> On 12/20/20 11:31 AM, Tom Lane wrote:
>> Dmitry Markman writes:
>>> suppose I started the server with the following command
>>> pg_ctl -D . . . start -l
Hi Ryan,
On Fri, Dec 18, 2020 at 10:28 PM Ryan Lambert
wrote:
> On Thu, Nov 19, 2020 at 11:04 AM Surafel Temesgen
> wrote:
>
> The docs have two instances of "EndtTime" that should be "EndTime".
>
Since my first language is not english i'm glad you find only this error
on doc. I will send
Hi,
On 2020-12-20 15:54:31 -0800, Peter Geoghegan wrote:
> On Sun, Dec 20, 2020 at 3:13 PM Andres Freund wrote:
> > Hm. Do I understand correctly that this problem is hit solely because
> > the parallel mode code relies on there already have been a transaction
> > snapshot set, thus avoiding the
On Sun, Dec 20, 2020 at 7:58 PM Stephen Frost wrote:
>
> * Magnus Hagander (mag...@hagander.net) wrote:
>
>
Changed from bugs to hackers.
> > For the old plaintext "password" method, we log a warning when we parse
> the
> > configuration file.
>
Like Stephen, I don't see such a warning
Pavel Stehule writes:
> some Orafce's user reported problems with pg_upgrade. I checked this issue
> and it looks like pg_dump problem:
> ...
> the supporting function should be dumped first before function where
> supporting function is used.
I tried to reproduce this and could not. It should
James Coleman writes:
> On Mon, Dec 21, 2020 at 2:59 AM Michael Paquier wrote:
>> On Mon, Dec 21, 2020 at 04:02:29PM +0900, Masahiko Sawada wrote:
>>> Is it a bug? Since the created schema obviously depends on the
>>> extension when we created the schema specified in the schema option, I
>>>
Hi hackers,
The following sequence of statements:
CREATE SCHEMA testschema;
CREATE TABLE testschema.part (a int) PARTITION BY LIST (a);
SET default_tablespace TO pg_global;
ALTER TABLE testschema.part SET TABLESPACE pg_default;
CREATE TABLE testschema.part_78 PARTITION OF testschema.part FOR
Hi Amit,
thanks for the quick reply! Sadly I have been busy and the second part of your
patch does no longer apply in src/include/nodes/execnodes.h:497.
I'm sorry, I should have been more careful rereading my posts. The case I meant
is the one below. I checked the thread again. I can barely
On Fri, 2020-12-18 at 11:33 -0600, Justin Pryzby wrote:
> > > > > This makes toast tables a bit less special and easier to inspect.
> >
> > I wonder why the modification in "listPartitionedTables" is necessary.
> > Surely there cannot be any partitioned toast tables, can there?
>
> The comment
On Mon, Dec 21, 2020 at 2:59 AM Michael Paquier wrote:
>
> On Mon, Dec 21, 2020 at 04:02:29PM +0900, Masahiko Sawada wrote:
> > Is it a bug? Since the created schema obviously depends on the
> > extension when we created the schema specified in the schema option, I
> > think we might want to
On Thu, Nov 19, 2020 at 12:37 PM tsunakawa.ta...@fujitsu.com
wrote:
>
> From: Andres Freund
>
> > Smaller comment:
> >
> > +static void
> > +FindAndDropRelFileNodeBuffers(RelFileNode rnode, ForkNumber *forkNum,
> > int nforks,
> > +
On Mon, Dec 21, 2020 at 3:17 PM Peter Smith wrote:
>
> On Mon, Dec 21, 2020 at 4:23 PM Amit Kapila wrote:
>
> > Few other comments:
> > ==
>
> Thanks for your feedback.
>
> > 1.
> > * FIXME 3 - Crashed tablesync workers may also have remaining slots
> > because I don't think
> >
ExecBuildAggTrans has this sequence:
if (pertrans->deserialfn.fn_strict)
scratch.opcode = EEOP_AGG_STRICT_DESERIALIZE;
else
scratch.opcode = EEOP_AGG_DESERIALIZE;
scratch.d.agg_deserialize.fcinfo_data =
On 2020-12-18 21:54, Pavel Borisov wrote:
I've realized one strange effect in current grammar parsing: if I do
CREATE TABLE foo (a int) PARTITION BY LIST (a) CONFIGURATION (a 1);
ERROR: unrecognized auto partition bound specification "a"
I consulted the patch code and realized that in fact,
On 20.12.2020 10:04, Pavel Stehule wrote:
čt 17. 12. 2020 v 19:30 odesílatel Pavel Stehule
mailto:pavel.steh...@gmail.com>> napsal:
čt 17. 12. 2020 v 14:04 odesílatel Konstantin Knizhnik
mailto:k.knizh...@postgrespro.ru>> napsal:
On 17.12.2020 9:31, Pavel Stehule
Backends reflect "GRANT role_name" changes rather quickly, due to a syscache
invalidation callback. Let's register an additional callback to reflect
"ALTER ROLE ... [NO]INHERIT" with equal speed. I propose to back-patch this.
While pg_authid changes may be more frequent than pg_auth_members
On Mon, Dec 21, 2020 at 4:23 PM Amit Kapila wrote:
> Few other comments:
> ==
Thanks for your feedback.
> 1.
> * FIXME 3 - Crashed tablesync workers may also have remaining slots
> because I don't think
> + * such workers are even iterated by this loop, and nobody else is
>
On Sun, Dec 20, 2020 at 03:54:31PM -0800, Peter Geoghegan wrote:
> On Sun, Dec 20, 2020 at 3:13 PM Andres Freund wrote:
> > Hm. Do I understand correctly that this problem is hit solely because
> > the parallel mode code relies on there already have been a transaction
> > snapshot set, thus
On Sat, Dec 19, 2020 at 5:38 PM Amit Kapila wrote:
>
> On Fri, Dec 18, 2020 at 6:41 PM Peter Smith wrote:
> >
> > TODO / Known Issues:
> >
> > * the current implementation of tablesync drop slot (e.g. from
> > DropSubscription or finish_sync_worker) regenerates the tablesync slot
> > name so it
Hi Amit.
PSA my v5 WIP patch for the Solution1.
This patch still applies onto the v30 patch set [1] from other 2PC thread:
[1]
https://www.postgresql.org/message-id/CAFPTHDYA8yE6tEmQ2USYS68kNt%2BkM%3DSwKgj%3Djy4AvFD5e9-UTQ%40mail.gmail.com
(I understand you would like this to be delivered as a
Hi
some Orafce's user reported problems with pg_upgrade. I checked this issue
and it looks like pg_dump problem:
pg_restore: creating FUNCTION "public.nvarchar2("public"."nvarchar2",
integer, boolean)"
pg_restore: while PROCESSING TOC:
pg_restore: from TOC entry 612; 1255 33206 FUNCTION
At Tue, 01 Dec 2020 10:03:42 -0500, Tom Lane wrote in
> I think it should be "needs review" now.
Conflicted with some commit(s) uncertain to me. Rebased.
regards.
--
Kyotaro Horiguchi
NTT Open Source Software Center
>From 26d9edeccf3f3111a7e0ff049aa6e3ba3746dce9 Mon Sep 17 00:00:00 2001
On Sun, Dec 20, 2020 at 10:57 PM Masahiko Sawada wrote:
>
> On Sun, Dec 20, 2020 at 10:27 PM Magnus Hagander wrote:
> >
> > On Sat, Dec 19, 2020 at 6:00 AM Michael Paquier wrote:
> > >
> > > On Sat, Dec 19, 2020 at 10:03:47AM +0530, Amit Kapila wrote:
> > > > Glad to hear. I am confident that
On Tuesday, December 15, 2020 8:12 PM, Iwata-san wrote:
> > There are some things still to do:
> I worked on some to do.
Hi Iwata-san,
Thank you for updating the patch.
I would recommend to register this patch in the upcoming commitfest
to help us keep track of it. I will follow the thread to
70 matches
Mail list logo
