On Wed, Dec 11, 2019 at 11:00 AM Amit Kapila wrote:
>
> On Wed, Dec 11, 2019 at 4:02 AM Andres Freund wrote:
> > On 2019-12-10 13:55:40 +0530, Dilip Kumar wrote:
> >
> > > /*
> > > * Overflowed transactions should not use group XID status update
> > > * mechanism.
> > > */
> > >
On Thu, Dec 12, 2019 at 12:23:42AM -0500, Tom Lane wrote:
> David Fetter writes:
> > I've found myself writing a lot of boilerplate pg_hba.conf entries
> > along the lines of
> > hostnosslall all 0.0.0.0/0 reject
> > hostssl all all 0.0.0.0/0 md5
> > so
On Thu, 12 Dec 2019 at 11:34, Amit Khandekar wrote:
> So max_changes_in_memory is the one
> that allows us to reduce the number of transactions required, so we
> can cut down on the outer loop iterations and make the test finish
> much earlier.
>
> But also note that, we can't use the test
On Thu, Dec 12, 2019 at 6:32 PM Tom Lane wrote:
> Thomas Munro writes:
> > Erm, but I shouldn't have to reindex my hash indexes (at least not
> > until someone invents collation-based equality and therefore
> > necessarily also collation-based hashing). How can we exclude that?
>
> Um, we
On Thu, 12 Dec 2019 at 09:49, Amit Kapila wrote:
>
> On Wed, Dec 11, 2019 at 4:17 PM Amit Khandekar wrote:
> >
> > On Sat, 7 Dec 2019 at 11:37, Amit Kapila wrote:
> > >
> > > On Fri, Dec 6, 2019 at 5:00 PM Amit Khandekar
> > > wrote:
> > > >
> > > > On Fri, 6 Dec 2019 at 15:40, Amit Kapila
I wrote:
> Alvaro Herrera writes:
>> I don't quite understand why a readline library that doesn't have
>> rl_filename_completion_function is known to have a
>> filename_completion_function, ie. this bit
>> #ifdef HAVE_RL_FILENAME_COMPLETION_FUNCTION
>> #define filename_completion_function
Thomas Munro writes:
> Erm, but I shouldn't have to reindex my hash indexes (at least not
> until someone invents collation-based equality and therefore
> necessarily also collation-based hashing). How can we exclude that?
Um, we already invented that with nondeterministic collations, no?
David Fetter writes:
> I've found myself writing a lot of boilerplate pg_hba.conf entries
> along the lines of
> hostnosslall all 0.0.0.0/0 reject
> hostssl all all 0.0.0.0/0 md5
> so I thought I'd make it easier to do that from initdb.
> What say?
I'm
On Thu, Dec 12, 2019 at 5:00 PM Thomas Munro wrote:
> Then, as a special case, there is the collation of the actual indexed
> value, because that will implicitly be used as input to the btree ops
> that would be collation sensitive. [...]
Erm, but I shouldn't have to reindex my hash indexes (at
Hello.
At Wed, 11 Dec 2019 17:32:05 -0500, Robert Haas wrote
in
> While reviewing the first patch in Asif Rehman's series of patches for
> parallel backup over at
> http://postgr.es/m/CADM=Jeg3ZN+kPQpiSfeWCXr=xgplrq4cbqe5zviuxygkq3v...@mail.gmail.com
> I discovered that commit
Hello Surafel,
I'm very interested in this patch.
Although I'm a beginner,I would like to participate in the development of
PostgreSQL.
1. I want to suggest new output format.
In my opinion, it's kind to display description of output and add "line number"
and "error" to output.
For example,
On Wed, Dec 11, 2019 at 4:17 PM Amit Khandekar wrote:
>
> On Sat, 7 Dec 2019 at 11:37, Amit Kapila wrote:
> >
> > On Fri, Dec 6, 2019 at 5:00 PM Amit Khandekar
> > wrote:
> > >
> > > On Fri, 6 Dec 2019 at 15:40, Amit Kapila wrote:
> > > >
> > > > 1.
> > > > + /* Now that the state fields are
On Wed, Dec 11, 2019 at 5:22 PM Amit Kapila wrote:
>
> On Mon, Dec 9, 2019 at 1:27 PM Dilip Kumar wrote:
> >
> > I have review the patch set and here are few comments/questions
> >
> > 1.
> > +static void
> > +pg_decode_stream_change(LogicalDecodingContext *ctx,
> > + ReorderBufferTXN *txn,
> >
Folks,
I've found myself writing a lot of boilerplate pg_hba.conf entries
along the lines of
hostnosslall all 0.0.0.0/0 reject
hostssl all all 0.0.0.0/0 md5
so I thought I'd make it easier to do that from initdb.
What say?
Best,
David.
--
David
On Thu, Dec 12, 2019 at 2:45 AM Julien Rouhaud wrote:
> Hearing no objection in [1], attached v5 with following changes:
>
> - fix the spurious warnings by doing the version check in
> get_relation_info and vacuum_open_relation, and add a flag in
> RelationData to mark the check as already being
On Fri, 6 Dec 2019 at 09:57, Michael Paquier wrote:
> On Thu, Dec 05, 2019 at 12:23:40PM +0300, Konstantin Knizhnik wrote:
> > Concerning keeping PGPROC size as small as possible, I agree that it is
> > reasonable argument.
> > But even now it is very large (816 bytes) and adding extra 8 bytes
On Wed, 11 Dec 2019 at 14:38, Koichi Suzuki wrote:
> Hello PG hackers;
>
> I'm writing an extension running on background workers and found
> get_database_name() causes SEGV and found internally resource owner was wet
> to NULL. Could anybody let me know how it happens and how I can use this
>
From: Koichi Suzuki
> I'm not using this. Is this the must to use get_database_name()?
I don't think pg_background is a must, but the system catalog access by
get_database_name() should require database connection and transaction. See
src/test/modules/worker_spi/worker_spi.c for an example
I wrote:
> OK, so here's a finished set of patches for this issue.
> 0001 is the same patch I posted on Tuesday; I kept it separate just
> because it seemed like a largely separable set of changes. (Note that
> the undesirable regression test output changes are undone by 0002.)
> 0002 implements
On Mon, December 9, 2019 at 11:05 AM Finnerty, Jim wrote:
> If you have BEFORE triggers, and a BEFORE trigger signaled failure with
> RETURN NULL, then this is one known (and documented) issue that I think could
> cause the behavior you're reporting:
>
>
On Thu., December 5, 2019 at 5:45 PM, Tomas Vondra wrote:
> At first I thought maybe this might be due to collations
> changing and breaking the index silently. What collation are you using?
We're using en_US.utf8. We did not make any collation changes to my knowledge.
> 1) When you do the
On Thu, December 5, 2019 at 5:34 PM Peter Geoghegan wrote:
> > We have a Postgres 10 database that we recently upgraded to Postgres 12
> > using pg_upgrade. We recently discovered that there are rows in one of the
> > tables that have duplicate primary keys:
>
> What's the timeline here? In
While reviewing the first patch in Asif Rehman's series of patches for
parallel backup over at
http://postgr.es/m/CADM=Jeg3ZN+kPQpiSfeWCXr=xgplrq4cbqe5zviuxygkq3v...@mail.gmail.com
I discovered that commit 7117685461af50f50c03f43e6a622284c8d54694
introduced a use of cancel_before_shmem_exit which
Greetings,
* Ranier Vilela (ranier_...@hotmail.com) wrote:
> 1.So I would like to ask you if at least what has consensus could be used.
> Or is it better to leave everything as it is?
As I tried to say before- I'm all for working to eliminate the shadow
variables, but it should be on a
De: Stephen Frost
Enviadas: Quarta-feira, 11 de Dezembro de 2019 18:57
>I really don't have any doubts that it's going to lead to confusion,
>particularly in a case like the numTables vs. nTables thing you're
>proposing in the one case that I spent some time looking at, and that
>confusion
Amit Kapila writes:
> I am convinced by your points. So +1 for your proposed patch. I have
> already reviewed it yesterday and it appears fine to me.
OK, pushed. Thanks for reviewing!
regards, tom lane
Greetings,
* Ranier Vilela (ranier_...@hotmail.com) wrote:
> De: Stephen Frost
> Enviadas: Quarta-feira, 11 de Dezembro de 2019 15:34
>
> >I agree with not breaking things but that doesn't mean the only
> >reasonable approach is to do the absolute minimum- you might not be
> >breaking something
On Wed, Dec 11, 2019 at 12:38 PM Andres Freund wrote:
> I just don't buy this argument. There's a difference in between an
> unpatched version of postgres suddenly potentially running hooks
> everywhere CFI() etc is called, and some user patching postgres to
> behave differently. In the former
On Wed, Dec 11, 2019 at 9:46 AM Ranier Vilela
wrote:
> I am the author of the patch.
> I'm repeating myself, but come on, I don't have confidence in proposing
> logic-altering changes for now.
>
>
Then you need to stop and patch the holes and not just throw paint on the
wall to cover things up.
On Mon, Dec 2, 2019 at 3:32 AM Dilip Kumar wrote:
> I have rebased the patch set on the latest head.
0001 looks like a clever approach, but are you sure it doesn't hurt
performance when many small XLOG records are being inserted? I think
XLogRecordAssemble() can get pretty hot in some workloads.
I have not used .editorconfig that much, but would it makes sense to add
the below?
[*]
end_of_line = lf
--
Andreas Karlsson
De: Stephen Frost
Enviadas: Quarta-feira, 11 de Dezembro de 2019 15:34
>I agree with not breaking things but that doesn't mean the only
>reasonable approach is to do the absolute minimum- you might not be
>breaking something today, but it's going to confuse people later on down
>the road and may
Hi,
On 2019-12-11 09:12:49 -0500, Robert Haas wrote:
> On Mon, Dec 9, 2019 at 7:37 PM Daniel Gustafsson wrote:
> > I sort of like the callback idea conceptually, but Andres is making a good
> > point about the extensibility actually making it harder to reason about.
>
> That objection doesn't
Hi,
On 2019-12-11 12:11:03 -0500, Tom Lane wrote:
> I don't think you can make that conclusion. Perhaps the table once
> needed a toast table because of some wide column that got dropped;
> if so, it'd still have one. It'd be safer to look at
> pg_class.reltoastrelid to verify existence (or
On Wed, Dec 11, 2019 at 12:11 PM Tom Lane wrote:
> I don't think you can make that conclusion. Perhaps the table once
> needed a toast table because of some wide column that got dropped;
> if so, it'd still have one. It'd be safer to look at
> pg_class.reltoastrelid to verify existence (or not)
Andres Freund writes:
> This indicates that a toast record was present for that relation,
> despite:
> [ \d that looks like the table isn't wide enough for that ]
> I think we need to see pg_waldump output for the preceding records. That
> might allow us to see why there's a toast record that's
Hi,
Thanks for working on this!
On 2019-12-11 08:36:48 -0600, Justin Pryzby wrote:
> On Wed, Dec 11, 2019 at 09:15:07PM +0900, Michael Paquier wrote:
> > On Fri, Dec 06, 2019 at 10:23:25AM -0600, Justin Pryzby wrote:
> > > Find attached updated patch:
> > > . Use structure to include relation
Alvaro Herrera writes:
> I tested this on libreadline 7.x (where #define
> HAVE_RL_FILENAME_COMPLETION_FUNCTION 1). I noticed that if I enter a
> filename that doesn't exist and then , it adds a closing quote.
> Bash manages to do nothing somehow, which is the desired behavior IMO.
Hmm. I'll
Robert Haas writes:
> On Wed, Dec 11, 2019 at 10:52 AM Tom Lane wrote:
>> I think it's Debian's problem, not ours, if that doesn't work. It is
>> not unreasonable for a package to probe existence of a library function
>> at configure time. It's up to them to make sure that the headers match
>>
Hi,
On 2019-12-11 08:17:01 +, Drouvot, Bertrand wrote:
> >>Core was generated by `postgres: walsender
> >>(31712)'.
> >>Program terminated with signal 11, Segmentation fault.
> >>#0 ReorderBufferToastReplace (rb=0x3086af0, txn=0x3094a78,
> >>relation=0x2b79177249c8,
On Wed, Dec 11, 2019 at 7:29 PM Robert Haas wrote:
> On Mon, Dec 9, 2019 at 2:02 PM Ibrar Ahmed wrote:
> >> Did you see this thread?
> >>
> https://postgr.es/m/CAGTBQpbDCaR6vv9=scXzuT8fSbckf=a3ngzdwfwzbdvugvh...@mail.gmail.com
> >>
> > Yes, and somehow did what is explained.
>
> Did you modify
On 2019-12-11 17:09, Daniel Gustafsson wrote:
On 11 Dec 2019, at 17:00, Peter Eisentraut
wrote:
There were a couple of recent threads that wanted to add an .editorconfig file
but never actually ended up doing so.[0][1] Here is a patch. It is meant to
match more or less what's in
> On 11 Dec 2019, at 17:00, Peter Eisentraut
> wrote:
>
> There were a couple of recent threads that wanted to add an .editorconfig
> file but never actually ended up doing so.[0][1] Here is a patch. It is
> meant to match more or less what's in .dir-locals.el.
+[*.{c,h,l,y,pl,pm}]
What
There were a couple of recent threads that wanted to add an
.editorconfig file but never actually ended up doing so.[0][1] Here is
a patch. It is meant to match more or less what's in .dir-locals.el.
I have only tested this with the GitHub view, not with an actual editor.
[0]:
On Wed, Dec 11, 2019 at 10:52 AM Tom Lane wrote:
> I think it's Debian's problem, not ours, if that doesn't work. It is
> not unreasonable for a package to probe existence of a library function
> at configure time. It's up to them to make sure that the headers match
> the actual library.
That
On Wed, Dec 11, 2019 at 3:17 AM Drouvot, Bertrand wrote:
>Here it is:
>
> \d+ rel_having_issue
You did a heck of a job choosing the name of that table. I bet nobody
was surprised when it had an issue!
:-)
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL
Alvaro Herrera writes:
> On 2019-Dec-11, Robert Haas wrote:
>> Are people still compiling against libedit and then redirecting to
>> libreadline at runtime? I seem to recall some discussion about this
>> being a thing, many years ago.
> Yeah, Debian did that out of licensing concerns. It seems
On Tue, Dec 10, 2019 at 4:59 PM Andres Freund wrote:
> 3) For lots of one-off uses of hashtables that aren't performance
>critical, we want a *simple* API. That IMO would mean that key/value
>end up being separately allocated pointers, and that just a
>comparator is provided when
Andrey Lepikhov writes:
> During NestLoop execution we have bad corner case: if outer subtree
> contains tuples the join node will scan inner subtree even if it does
> not return any tuples.
So the first question about corner-case optimizations like this is always
"how much overhead does it
On 2019-12-06 08:48, Amit Langote wrote:
0001: Adding a partitioned table to a publication implicitly adds all
its partitions. The receiving side must have tables matching the
published partitions, which is typically the case, because the same
partition tree is defined on both nodes.
This
Greetings,
* Michael Paquier (mich...@paquier.xyz) wrote:
> On Wed, Dec 11, 2019 at 10:16:29AM -0500, Stephen Frost wrote:
> > I've not followed this discussion very closely but I agree entirely that
> > it's really nice to have the timeline be able to be queried in a more
> > timely manner than
Greetings,
Didn't see this previously (it's our typical approach to 'reply-all' to
people), though I don't think it changes my feelings about the latest
proposed patch.
* Ranier Vilela (ranier_...@hotmail.com) wrote:
> De: Stephen Frost
> Enviadas: Terça-feira, 10 de Dezembro de 2019 17:52
>
>
On 2019-Dec-11, Justin Pryzby wrote:
> @@ -635,6 +644,15 @@ lazy_scan_heap(Relation onerel, VacuumParams *params,
> LVRelStats *vacrelstats,
> else
> skipping_blocks = false;
>
> + /* Setup error traceback support for ereport() */
> + errcallback.callback =
On Wed, Dec 11, 2019 at 10:16:29AM -0500, Stephen Frost wrote:
> I've not followed this discussion very closely but I agree entirely that
> it's really nice to have the timeline be able to be queried in a more
> timely manner than asking through pg_control_checkpoint() gives you.
>
> I'm not sure
On 2019-Dec-11, Alvaro Herrera wrote:
> On 2019-Dec-11, Robert Haas wrote:
> > If it were being done it would be
> > advantageous to have the checks be runtime rather than compile-time,
> > although I guess that would probably be tough to make work.
>
> Yeah. On the other hand, I suppose
Greetings,
* Ranier Vilela (ranier_...@hotmail.com) wrote:
> New version the global patch unshadow.
> * names more consistent and readable.
> * without big changes.
> * goal,, unshadow all global variables, only, even the simplest.
This didn't address any of the comments that I raised elsewhere
Greetings,
* Michael Paquier (mich...@paquier.xyz) wrote:
> I would be actually tempted to do the following: one single SRF
> function, say pg_wal_info which takes a text argument in input with
> the following values: flush, write, insert, receive, replay. Thinking
> more about it that would be
On 2019-Dec-11, Robert Haas wrote:
> On Sun, Nov 3, 2019 at 5:40 PM Tom Lane wrote:
> > Of course, this only works if we have those hooks :-(. So far as
> > I can tell, all libreadline variants that might still exist in the wild
> > do have them; but libedit doesn't, at least not in the version
On Tue, Dec 10, 2019 at 4:59 PM Andres Freund wrote:
> Neat!
Thanks.
> > A significant problem in either case is that a simplehash wants to
> > live in a memory context; no such thing exists either for data in
> > shared memory nor in frontend code. However, it seems to be quite easy
> > to
On Wed, Dec 11, 2019 at 09:15:07PM +0900, Michael Paquier wrote:
> On Fri, Dec 06, 2019 at 10:23:25AM -0600, Justin Pryzby wrote:
> > Find attached updated patch:
> > . Use structure to include relation name.
> > . Split into a separate patch rename of "StringInfoData buf".
> >
> > 2019-11-27
On Mon, Dec 9, 2019 at 2:02 PM Ibrar Ahmed wrote:
>> Did you see this thread?
>> https://postgr.es/m/CAGTBQpbDCaR6vv9=scXzuT8fSbckf=a3ngzdwfwzbdvugvh...@mail.gmail.com
>>
> Yes, and somehow did what is explained.
Did you modify Claudio's patch or write a totally new one? In either
case, why did
On Mon, Dec 9, 2019 at 4:37 PM Greg Stark wrote:
> On Mon, 9 Dec 2019 at 14:03, Ibrar Ahmed wrote:
> > I'd
> > actually argue that the segment size should be substantially smaller
> > than 1 GB, like say 64MB; there are still some people running systems
> > which are small enough that allocating
On Sun, Nov 3, 2019 at 5:40 PM Tom Lane wrote:
> Of course, this only works if we have those hooks :-(. So far as
> I can tell, all libreadline variants that might still exist in the wild
> do have them; but libedit doesn't, at least not in the version Apple
> is shipping. Hence, what the
On Mon, Dec 9, 2019 at 7:37 PM Daniel Gustafsson wrote:
> I've read through the patchset and played around with it to try and break it
> and understand it (not in that order). Being a bit out of my comfort zone, I
> can't offer the deep insights that Andres has done; but in reading the code it
>
During NestLoop execution we have bad corner case: if outer subtree
contains tuples the join node will scan inner subtree even if it does
not return any tuples.
To reproduce the problem see 'problem.sql' in attachment:
Out of explain analyze see in 'problem_explain.txt'
As you can see,
New version the global patch unshadow.
* names more consistent and readable.
* without big changes.
* goal,, unshadow all global variables, only, even the simplest.
regards,
Ranier Vilela
diff --git a/src/backend/access/transam/xlog.c b/src/backend/access/transam/xlog.c
index
On Fri, Dec 06, 2019 at 10:23:25AM -0600, Justin Pryzby wrote:
> Find attached updated patch:
> . Use structure to include relation name.
> . Split into a separate patch rename of "StringInfoData buf".
>
> 2019-11-27 20:04:53.640 CST [14244] ERROR: canceling statement due to
> statement
All in all, after testing this for a bit, I think this patch is a clear
improvement over the statu quo. Thanks for working on this.
I suggest to indicate in complete_from_files where to find the hook
functions it refers to (say "see quote_file_name, below", or something.)
I tested this on
On Mon, Dec 9, 2019 at 1:27 PM Dilip Kumar wrote:
>
> I have review the patch set and here are few comments/questions
>
> 1.
> +static void
> +pg_decode_stream_change(LogicalDecodingContext *ctx,
> + ReorderBufferTXN *txn,
> + Relation relation,
> + ReorderBufferChange *change)
> +{
> +
Adding patch written for 13dev from git
"Michael Paquier" skrev 1. desember 2019 kl. 03:08:
> On Fri, Nov 22, 2019 at 11:26:59AM +, Leif Gunnar Erlandsen wrote:
>
>> No it does not. It works well to demonstrate its purpose though.
>> And it might be to stop with FATAL would be more
De: Stephen Frost
Enviadas: Terça-feira, 10 de Dezembro de 2019 17:52
>There's multiple ways to get there though and I think what you're seeing
>is that the "just change it to something else" answer isn't necessairly
>going to be viewed as an improvement (or, at least, not enough of an
On Wed, Dec 11, 2019 at 04:06:26PM +0800, jiankang liu wrote:
> During my use of PG, I encountered such errors "incorrect resource manager
> data checksum in record at 0/5013730",
> it will keeps printing this error message and never stops on standby
> server，at same time, the walreceier process
On Wed, Dec 11, 2019 at 05:17:00PM +0900, Koichi Suzuki wrote:
> Not using this extension, sorry.
I have no idea what you are trying to do, but get_database_name()
accesses the system cache, which means two things:
- The access needs to be done in the context of a transaction. That's
a trick we
On Sat, 7 Dec 2019 at 11:37, Amit Kapila wrote:
>
> On Fri, Dec 6, 2019 at 5:00 PM Amit Khandekar wrote:
> >
> > On Fri, 6 Dec 2019 at 15:40, Amit Kapila wrote:
> > >
> > >
> > > Few comments:
> > > --
> > >
> > > 1.
> > > + /* Now that the state fields are initialized, it
On 11.12.2019 7:26, Kyotaro Horiguchi wrote:
Still I'm not sure non-atomic write is acceptable, but I agree on the
necessity of updating it during a transaction. Couldn't we update
shared stats every n bytes (XLOG_BLCKSZ or such) or every command end?
I think we should refrain from inserting
So, What are you using to create background workers ? Can you show me an
extract of your code ?
TIA
Best Regards
Didier
De : koi...@2ndquadrant.com [mailto:koi...@2ndquadrant.com]
Envoyé : mercredi 11 décembre 2019 09:16
À : ROS Didier
Cc : tsunakawa.ta...@fujitsu.com;
I'm sorry I did not say it clearly.
During my use of PG, I encountered such errors "incorrect resource manager
data checksum in record at 0/5013730",
it will keeps printing this error message and never stops on standby
server，at same time, the walreceier process is lost.
In a few months, we
On 12/9/19, 10:10 AM, "Tomas Vondra" wrote:
>On Wed, Dec 04, 2019 at 05:36:16PM -0800, Jeremy Schneider wrote:
>>On 9/8/19 14:01, Tom Lane wrote:
>>> Fix RelationIdGetRelation calls that weren't bothering with error
checks.
>>>
>>> ...
>>>
>>> Details
>>> ---
On 2019-12-10 17:23, Tom Lane wrote:
Peter Eisentraut writes:
Good point. Done in the attached patch.
(If someone wanted to revive the original functionality, it would
nowadays probably be easier to add a flag ATT_SYSTEM_TABLE to
ATSimplePermissions(), so there is really no reason to keep the
Not using this extension, sorry.
---
Koichi Suzuki
2019年12月11日(水) 16:26 ROS Didier :
> Hi
> I would like to know : Are you using pg_background extension to
> work with backgroud workers ?
>
> Thanks in advance
>
> Best Regards
>
> Didier ROS
> Expertise SGBD
> EDF - DTEO - DSIT
I'm not using this. Is this the must to use get_database_name()?
---
Koichi Suzuki
2019年12月11日(水) 16:26 ROS Didier :
> Hi
> I would like to know : Are you using pg_background extension to
> work with backgroud workers ?
>
> Thanks in advance
>
> Best Regards
>
> Didier ROS
>
81 matches
Mail list logo
