On 2019-12-10 17:16, Tom Lane wrote:
Peter Eisentraut writes:
Good point. Fixed in attached patch.
This one LGTM.
done, thanks
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
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 - IT DMA
-Message d'origine-
De : tsunakawa.ta...@fujitsu.com
From: Koichi Suzuki
> 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 function. Argument to get_database_name() looks
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
function. Argument to get_database_name() looks correct.
On Tue, 2019-12-10 at 15:50 -0700, Jim Finnerty wrote:
> As a proof of concept, I hacked around a bit today to re-purpose one of the
> bits of the Cost structure to mean "is_disabled" so that we can distinguish
> 'disabled' from 'non-disabled' paths without making the Cost structure any
> bigger.
On Tue, Dec 10, 2019 at 9:27 PM Tom Lane wrote:
>
> Amit Kapila writes:
> > On Sun, Dec 8, 2019 at 10:27 PM Tom Lane wrote:
> >> Doing it like this seems attractive to me because it gets rid of two
> >> different failure modes: inability to create a new thread and inability
> >> to create a new
> I found couple of crashes in reorderbuffer while review/testing of
> logical_work_mem and logical streaming of large in-progress
> transactions. Stack trace of the same are given below:
> Issue 1:
> #0 0x7f985c7d8337 in raise () from /lib64/libc.so.6
> #1 0x7f985c7d9a28 in abort ()
At Tue, 10 Dec 2019 10:40:53 -0800, Ashwin Agrawal wrote
in
> On Tue, Dec 10, 2019 at 3:06 AM jiankang liu wrote:
>
> > Start Walreceiver completely before shut down it on standby server.
> >
> > The walreceiver will be shut down, when read an invalid record in the
> > WAL streaming from
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.
> > */
> > Assert(!pgxact->overflowed);
> >
> > A solution could be either we remove this assert
On Thu, Sep 26, 2019 at 07:20:46PM +0200, Jehan-Guillaume de Rorthais wrote:
> If this solution is accepted, some other function of the same family might be
> good candidates as well, for the sake of homogeneity:
>
> * pg_current_wal_insert_lsn
> * pg_current_wal_flush_lsn
> *
At Fri, 6 Dec 2019 11:22:14 +0300, Konstantin Knizhnik
wrote in
>
>
> On 06.12.2019 4:57, Michael Paquier wrote:
> > On Thu, Dec 05, 2019 at 12:23:40PM +0300, Konstantin Knizhnik wrote:
> > Please see pgstat.h, close to pgstat_report_wait_start().
>
> Sorry, I do not understand what should I
On Wed, Dec 11, 2019 at 4:02 AM Andres Freund wrote:
>
> Hi,
>
> Amit, Robert, IIRC that's mostly your feature?
>
I will look into this today.
--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
> On December 6, 2019 at 3:06 PM Andres Freund wrote:
...
> > crash
> > smgrtruncate - Not reached
>
> This seems like a somewhat confusing description to me, because
> smgrtruncate() is what calls DropRelFileNodeBuffers(). I assume what you
> mean by "smgrtruncate" is not the function, but the
On Tue, Oct 15, 2019 at 4:50 AM Tom Lane wrote:
> > Filed at
> > https://bugzilla.kernel.org/show_bug.cgi?id=205183
For the curious-and-not-subscribed, there's now a kernel patch
proposed for this. We guessed pretty close, but the problem wasn't
those dodgy looking magic numbers, it was that
On Tue, Dec 10, 2019 at 10:29 PM Noah Misch wrote:
> On Tue, Dec 10, 2019 at 03:41:15PM +1300, Thomas Munro wrote:
> > I ran a variation of your program on Appveyor's Studio/Server 2019
> > image, and the result was the same: it thinks that cmp(s1, s2) == 0,
> > cmp(s2, s3) == 0, but cmp(s1, s3)
"Bossart, Nathan" writes:
> I noticed that pg_control_init() is failing an assertion on 13devel:
Hmm, yeah. In a non-assert build I get
regression=# select * from pg_control_init();
ERROR: function return row and query-specified return row do not match
DETAIL: Returned row contains 12
Hi,
On 2019-12-10 12:56:56 +0100, Tomas Vondra wrote:
> On Mon, Dec 09, 2019 at 04:04:40PM -0800, Andres Freund wrote:
> > On 2019-12-10 00:44:09 +0100, Tomas Vondra wrote:
> > > I think there's a minor bug in pg_stat_activity tracking of walsender
> > > processes. The issue is that xact_start is
Hi,
Amit, Robert, IIRC that's mostly your feature?
On 2019-12-10 13:55:40 +0530, Dilip Kumar wrote:
> While testing, my colleague Vignesh has hit an assert in
> TransactionGroupUpdateXidStatus. But that is not reproducible. After
> some analysis and code review, I have found the reason for the
Hi,
On 2019-12-10 22:44:17 +0100, Jens-Wolfhard Schicke-Uffmann wrote:
> On Tue, Dec 10, 2019 at 08:44:17AM -0800, Andres Freund wrote:
> > > today I observed (on a r5.24xlarge AWS RDS instance, i.e. 96 logical
> > > cores) lock contention on a buffer content lock due to taking of a
> > > SHARED
On 2019-Dec-10, Jens-Wolfhard Schicke-Uffmann wrote:
> More troubling (to me) is that I already know of another table in the
> system which should be next-in-line for the same problem, but only on
> some rows: It represents accounting entities, of which a very (nearly
> static) few are payment
Hi,
On Tue, Dec 10, 2019 at 03:07:05PM -0300, Alvaro Herrera wrote:
> I'd rather have the ability to mark a table READ ONLY (or similar).
> Then any FK references can skip the row locks altogether. For the rare
> cases where you need to modify the referenced table, have it marked READ
> WRITE,
Hi,
Neat!
On 2019-12-10 13:07:02 -0500, Robert Haas wrote:
> I recently became annoyed while working on patch A that I could not
> use simplehash in shared memory, and then I became annoyed again while
> working on patch B that I could not use simplehash in frontend code.
> So here are a few
Hi,
On Tue, Dec 10, 2019 at 08:44:17AM -0800, Andres Freund wrote:
> > today I observed (on a r5.24xlarge AWS RDS instance, i.e. 96 logical
> > cores) lock contention on a buffer content lock due to taking of a
> > SHARED lock (I think):
> When you say "7000 active transactions" - do you mean to
On Wed, Dec 04, 2019 at 10:57:51PM -0800, Jeff Davis wrote:
> > About the `TODO: project needed attributes only` in your patch, when
> > would the input tuple contain columns not needed? It seems like
> > anything
> > you can project has to be in the group or aggregates.
>
> If you have a table
Alexey: I would appreciate it if you give this patch a spin. Let me
know if it does what you wanted it to do.
On 2019-Dec-10, Alvaro Herrera wrote:
> Here's a curious thing that happens with this patch. If you have
> log_duration set so that parameters are logged during the bind phase,
> and
Here's a curious thing that happens with this patch. If you have
log_duration set so that parameters are logged during the bind phase,
and then an error occurs during the execution phase but you don't have
log_parameters_on_error set true, the second error will log the
parameters nonetheless ...
On 2019-Dec-10, Alvaro Herrera wrote:
> On 2019-Dec-10, Alvaro Herrera wrote:
>
> > On 2019-Dec-09, Tom Lane wrote:
> >
> > > Some quick review of v19:
> >
> > Here's v20 with all these comments hopefully addressed.
>
> Grr, I had forgotten to git add the stringinfo.h -> pg_wchar.h changes,
>
On Tue, Dec 10, 2019 at 6:40 AM Suraj Kharage
wrote:
> Please find attached patch for backup validator implementation (0004 patch).
> This patch is based
> on Rushabh's latest patch for backup manifest.
>
> There are some functions required at client side as well, so I have moved
> those
On 2019-Dec-07, Tom Lane wrote:
> 0002:
Here's a version of this part with fixes for these comments. It applies
on top of the stringinfo_mb.c patch sent elsewhere in the thread.
(If we were to add a "log_parameters_on_error_max_length" GUC to decide
the length to log, we would get rid of the
On 2019-Dec-10, Alvaro Herrera wrote:
> On 2019-Dec-09, Tom Lane wrote:
>
> > Some quick review of v19:
>
> Here's v20 with all these comments hopefully addressed.
Grr, I had forgotten to git add the stringinfo.h -> pg_wchar.h changes,
so the prototype isn't anywhere in v20. However, after
On Tue, Dec 10, 2019 at 3:06 AM jiankang liu wrote:
> Start Walreceiver completely before shut down it on standby server.
>
> The walreceiver will be shut down, when read an invalid record in the
> WAL streaming from master.And then, we retry from archive/pg_wal again.
>
> After that, we start
On Sun, Dec 8, 2019 at 7:12 PM Mark Dilger wrote:
> I think the words "IF AND ONLY IF AUTOVACUUM WOULD" should be
> replaced with a single word and added to the grammar where
> vacuum_option_elem lists VERBOSE, FREEZE and FULL. Perhaps
> "OPTIONALLY", or "AUTOVACUUMESQUE", though I'm really
On Sun, Dec 8, 2019 at 1:24 PM Jeff Janes wrote:
> Is there a way to force a meaningful parallel seq scan, or at least the
> planning of one, when the planner wants a non-parallel one?
>
> Usually I can do things like with with enable_* setting, but if I `set
> enable_seqscan to off`, it
On 2019-Dec-10, Tomas Vondra wrote:
> On Tue, Dec 10, 2019 at 09:42:17AM +0900, Kyotaro Horiguchi wrote:
> > At Tue, 10 Dec 2019 00:44:09 +0100, Tomas Vondra
> > wrote in
> > I'm not sure how much xact_start for walsender is useful and we really
> > is not running a statement there. Also
On 2019-Dec-10, Andres Freund wrote:
> >The hard part would probably be to ensure that an
> >attempt to obtain an EXCLUSIVE lock would finally succeed against a
> >SHARE lock held by "everyone".
>
> Note that this is a seriously complicated area of the code. It's very
> easy to
I recently became annoyed while working on patch A that I could not
use simplehash in shared memory, and then I became annoyed again while
working on patch B that I could not use simplehash in frontend code.
So here are a few patches for discussion.
A significant problem in either case is that a
Greetings,
* Ranier Vilela (ranier_...@hotmail.com) wrote:
> >For someone that expounds consistency - this patch is the furthest thing
> >from it.
> >In some places names are randomly changed to have an underscore
> >>(authmethodlocal to authmethod_local with the obvious inconsistency as
>
De: John W Higgins
Enviado: terça-feira, 10 de dezembro de 2019 15:58
>For someone that expounds consistency - this patch is the furthest thing from
>it.
>In some places names are randomly changed to have an underscore
>>(authmethodlocal to authmethod_local with the obvious inconsistency as
Hi,
On 2019-12-09 23:10:36 +0100, Jens-Wolfhard Schicke-Uffmann wrote:
> today I observed (on a r5.24xlarge AWS RDS instance, i.e. 96 logical
> cores) lock contention on a buffer content lock due to taking of a
> SHARED lock (I think):
> Three tables were involved, simplified case:
>
> CREATE
On Mon, Dec 9, 2019 at 5:10 PM Jens-Wolfhard Schicke-Uffmann <
drahf...@gmx.de> wrote:
> Hi,
>
> today I observed (on a r5.24xlarge AWS RDS instance, i.e. 96 logical
> cores) lock contention on a buffer content lock due to taking of a
> SHARED lock (I think):
>
What version of PostgreSQL are you
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 old
> function separate.)
Peter Eisentraut writes:
> Good point. Fixed in attached patch.
This one LGTM.
regards, tom lane
On Tue, Dec 10, 2019 at 5:21 AM Ranier Vilela
wrote:
> New version the global patch, with the considerations.
> Unfortunately WalReceiverConn cannot be used because it is currently the
> typedef name for the structure.
> I switched to WalReceiverConnection, it was long but it looks good.
>
Amit Kapila writes:
> On Sun, Dec 8, 2019 at 10:27 PM Tom Lane wrote:
>> Doing it like this seems attractive to me because it gets rid of two
>> different failure modes: inability to create a new thread and inability
>> to create a new pipe handle. Now on the other hand, it means that
>>
On Fri, Nov 8, 2019 at 2:24 AM Thomas Munro wrote:
>
> On Thu, Nov 7, 2019 at 10:20 PM Julien Rouhaud wrote:
> >
> > I didn't do anything for the spurious warning when running a reindex,
> > and kept original approach of pg_depend catalog.
>
> I see three options:
>
> 1. Change all or some of
On 2019-Dec-09, Tom Lane wrote:
> Some quick review of v19:
Here's v20 with all these comments hopefully addressed.
--
Álvaro Herrerahttps://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
>From
On Thu, Nov 28, 2019 at 12:57 AM Robert Haas wrote:
> On Wed, Nov 27, 2019 at 3:38 AM Jeevan Chalke
> wrote:
> > I am still not sure why we need SEND_BACKUP_FILELIST as a separate
> command.
> > Can't we return the file list with START_BACKUP itself?
>
> I had the same thought, but I think it's
On Wed, Nov 27, 2019 at 1:38 PM Jeevan Chalke <
jeevan.cha...@enterprisedb.com> wrote:
>
>
> On Wed, Nov 13, 2019 at 7:04 PM Asif Rehman
> wrote:
>
>>
>> Sorry, I sent the wrong patches. Please see the correct version of the
>> patches (_v6).
>>
>
> Review comments on these patches:
>
> 1.
> +
On Tue, Dec 10, 2019 at 12:09 AM Tom Lane wrote:
> Yeah. The reported behavior can mostly be explained if we assume
> that there's some HOT chain in the table that involves an update
> of this particular column, so that if we build an index on that
> column we see a broken HOT chain, but
út 10. 12. 2019 v 13:56 odesílatel Karl O. Pinc napsal:
> On Tue, 10 Dec 2019 07:11:59 +0100
> Pavel Stehule wrote:
>
> > út 10. 12. 2019 v 0:03 odesílatel Karl O. Pinc napsal:
> > > I also wonder whether all the trim_scale() tests
> > > are now necessary, but not enough to make any
New version the global patch, with the considerations.
Unfortunately WalReceiverConn cannot be used because it is currently the
typedef name for the structure.
I switched to WalReceiverConnection, it was long but it looks good.
RedoRecPtr proper name has no consensus yet, so it was still
You are checking file->dirty twice, first before calling the function and
within the function too. Same for the Assert. For example.
size_t
BufFileRead(BufFile *file, void *ptr, size_t size)
{
size_t nread = 0;
size_t nthistime;
if (file->dirty)
{
On Tue, 10 Dec 2019 07:11:59 +0100
Pavel Stehule wrote:
> út 10. 12. 2019 v 0:03 odesílatel Karl O. Pinc napsal:
> > I also wonder whether all the trim_scale() tests
> > are now necessary, but not enough to make any suggestions.
> I don't think so tests should be minimalistic - there can be
On 2019-12-05 00:16, Tom Lane wrote:
Seems reasonable. The argument for making this an exception to
allow_system_table_mods was always more about expediency than logical
cleanliness. After the recent changes I think it's okay to remove the
special case (especially since nobody has griped about
On 2019-12-09 23:22, Tom Lane wrote:
Peter Eisentraut writes:
There appear to be several off-by-more-than-one errors in norm_test.c
print_wchar_str(). Attached is a patch to fix this (and make the output
a bit prettier). Result afterwards:
I concur that this looks broken and your patch
On Tue, Dec 10, 2019 at 09:42:17AM +0900, Kyotaro Horiguchi wrote:
At Tue, 10 Dec 2019 00:44:09 +0100, Tomas Vondra
wrote in
Hi,
I think there's a minor bug in pg_stat_activity tracking of walsender
processes. The issue is that xact_start is only updated at the very
beginning when the
On Mon, Dec 09, 2019 at 04:04:40PM -0800, Andres Freund wrote:
Hi,
On 2019-12-10 00:44:09 +0100, Tomas Vondra wrote:
I think there's a minor bug in pg_stat_activity tracking of walsender
processes. The issue is that xact_start is only updated at the very
beginning when the walsender starts (so
Hi,
Please find attached patch for backup validator implementation (0004
patch). This patch is based
on Rushabh's latest patch for backup manifest.
There are some functions required at client side as well, so I have moved
those functions
and some data structure at common place so that they can
De: Alvaro Herrera
Enviado: segunda-feira, 9 de dezembro de 2019 22:06
>I find this choice a bit ugly and even more confusing than the original.
>I'd change this to be just "segsize".
Ok.
>I would tend to name the GUC variable as if it were a global in the
>sense that I proposed in my previous
Start Walreceiver completely before shut down it on standby server.
The walreceiver will be shut down, when read an invalid record in the
WAL streaming from master.And then, we retry from archive/pg_wal again.
After that, we start walreceiver in RequestXLogStreaming(), and read
record from the
On Tue, Dec 10, 2019 at 3:29 PM Rushabh Lathia
wrote:
>
> Attaching another version of 0002 patch, as my collogue Jeevan Chalke
> pointed
> few indentation problem in 0002 patch which I sent earlier. Fixed the
> same in
> the latest patch.
>
I had a look over the new patch and see no issues.
Hi Amul,
On Tue, Dec 10, 2019 at 3:49 PM amul sul wrote:
> On Mon, Dec 9, 2019 at 3:08 PM amul sul wrote:
>> Attached is the rebase version atop the latest master head(2d0fdfaccec).
Thanks for that!
> I have been through your changes proposed in [1] -- the changes make sense to
> me &
> I
On Tue, Dec 10, 2019 at 3:26 AM Michael Paquier wrote:
>
> On Mon, Dec 09, 2019 at 07:02:43PM +0100, Julien Rouhaud wrote:
> > On Mon, Dec 9, 2019 at 5:21 PM Robert Haas wrote:
> >> Some people might prefer notices, because you can get those while the
> >> thing is still running, rather than a
On Mon, Dec 9, 2019 at 2:52 PM Rushabh Lathia
wrote:
>
> Thanks Jeevan for reviewing the patch and offline discussion.
>
> On Mon, Dec 9, 2019 at 11:15 AM Jeevan Chalke <
> jeevan.cha...@enterprisedb.com> wrote:
>
>>
>>
>> On Fri, Dec 6, 2019 at 12:05 PM Rushabh Lathia
>> wrote:
>>
>>>
>>>
>>>
On Tue, Dec 10, 2019 at 03:41:15PM +1300, Thomas Munro wrote:
> On Fri, Dec 6, 2019 at 8:33 PM Noah Misch wrote:
> > On Fri, Dec 06, 2019 at 07:56:08PM +1300, Thomas Munro wrote:
> > > On Fri, Dec 6, 2019 at 7:34 PM Noah Misch wrote:
> > > > We use system UTF-16 collation to implement UTF-8
While testing, my colleague Vignesh has hit an assert in
TransactionGroupUpdateXidStatus. But that is not reproducible. After
some analysis and code review, I have found the reason for the same.
As shown in the below code, there is an assert in
TransactionGroupUpdateXidStatus, which assumes
66 matches
Mail list logo
