On Mon, Jun 7, 2021 at 2:38 PM Amit Kapila wrote:
>
> On Thu, Jun 3, 2021 at 10:39 PM Tom Lane wrote:
> >
> > "Euler Taveira" writes:
> > > I was checking the GRANT on pg_subscription and noticed that the command
> > > is not
> > > correct. There is a comment that says "All columns of
On Mon, Jun 21, 2021 at 11:26 AM Mark Dilger
wrote:
>
>
>
> > On Jun 20, 2021, at 7:17 PM, Masahiko Sawada wrote:
> >
> > I will submit the patch.
>
> Great, thanks!
I've submitted the patches on that thread[1]. There are three patches:
skipping the transaction on the subscriber side, reporting
On Thu, Jun 17, 2021 at 6:20 PM Masahiko Sawada wrote:
>
> On Thu, Jun 17, 2021 at 3:24 PM Masahiko Sawada wrote:
> >
> > > Now, if this function is used by super
> > > users then we can probably trust that they provide the XIDs that we
> > > can trust to be skipped but OTOH making a restriction
On Thu, Jun 24, 2021 at 7:27 AM David Rowley wrote:
> On Wed, 23 Jun 2021 at 21:07, Amit Kapila wrote:
> > I noticed that while inserting directly into a partition table we
> > compute the PartitionCheckExpr by traversing all the parent partitions
> > via
> >
27.06.2021 23:07, Tom Lane wrote:
>> While trying to use sqlsmith with postgres compiled from the master
>> branch, I've found that the PQerrorMessage() function now returns
>> non-informational but not empty error message after the successful
>> PQconnectdb() call.
> Yeah, see thread here:
>
>
On Fri, Jun 25, 2021 at 10:26 AM David Rowley wrote:
> On Thu, 24 Jun 2021 at 12:32, David Rowley wrote:
> > The overhead of taking these locks is pretty significant for
> > partitioned tables with lots of partitions where only 1 of them
> > survives run-time partition pruning. That's really
On Tue, Jun 22, 2021 at 5:01 PM Thomas Munro wrote:
> On Fri, Jun 18, 2021 at 1:11 PM Justin Pryzby wrote:
> > Thomas, could you comment on this ?
>
> Sorry, I missed that. It is initially a confusing proposal, but after
> trying it out (that is: making recovery_init_sync_method PGC_SIGHUP
>
On Mon, Jun 28, 2021 at 10:17:55AM +1000, Peter Smith wrote:
> IIUC for the case ALTER_SUBSCRIPTION_DROP_PUBLICATION it looks like
> the uninitialized copy_data local stack var would remain uninitialized
> (undefined) still at the time it is passed at
> AlterSubscription_refresh(sub, copy_data);
Hi Tsunakawa-san,
On 2021/06/27 16:41, tsunakawa.ta...@fujitsu.com wrote:
I'm moving to another company from July 1st. I may possibly not be allowed to
do open source activities there, so let me say goodbye once. Thank you all for
your help. I really enjoyed learning PostgreSQL and
On Sun, Jun 27, 2021 at 07:41:19AM +, tsunakawa.ta...@fujitsu.com wrote:
> It's a pity that I may not be able to part of PostgreSQL's great
> history until it becomes the most popular database (in the
> DB-Engines ranking.) However, if possible, I'd like to come back as
> just MauMau.
This
I've just realized that this VM has a strange storage configuration.
It's using LVM thin pools, which I don't use anywhere else.
Someone else set this up, and I think I've literally never used pools before.
Some time ago, the pool ran out of space, and I ran LVM repair on it.
It seems very
>I'm moving to another company from July 1st. I may possibly not be allowed to
>do open source activities there, so let me say >goodbye once. Thank you all
>for your help. I really enjoyed learning PostgreSQL and participating in its
>development.
Thank you for everything, Tsunakawa-san.
On Mon, Jun 28, 2021 at 8:36 AM Peter Geoghegan wrote:
> "The sole disadvantage of increasing autovacuum_freeze_max_age (and
> vacuum_freeze_table_age along with it) is that the pg_xact and
> pg_commit_ts subdirectories of the database cluster will take more
> space..."
Just by the way, if we're
On Fri, Jun 25, 2021 at 11:55 PM Ranier Vilela wrote:
>
>
> https://github.com/postgres/postgres/commit/3af10943ce21450e299b3915b9cad47cd90369e9
> fixes some issues with subscriptioncmds.c, but IMHO still lack this issue.
>
I have not tested this, and gcc gave no warnings about it, but just by
On 6/27/21 4:36 PM, Peter Geoghegan wrote:
> The wraparound failsafe mechanism added by commit 1e55e7d1 had minimal
> documentation -- just a basic description of how the GUCs work. I
> think that it certainly merits some discussion under "25.1. Routine
> Vacuuming" -- more specifically under
On Sun, Jun 27, 2021 at 03:08:13PM -0700, Peter Geoghegan wrote:
> Can you please amcheck all of the indexes?
ts=# SELECT bt_index_check('child.alarms_null_alarm_clear_time_idx'::regclass);
ERROR: item order invariant violated for index
"alarms_null_alarm_clear_time_idx"
DETAIL: Lower index
Did you also change the kernel on upgrade? I recall that that was a factor
on the other recent bug thread.
Peter Geoghegan
(Sent from my phone)
Would also be good to get a raw binary copy of the page image in question.
Hopefully the data isn't confidential. Same gdb procedure as before.
Thanks
Peter Geoghegan
(Sent from my phone)
Can you please amcheck all of the indexes?
Peter Geoghegan
(Sent from my phone)
This is crashing repeatedly during insert/update immediately after upgrading an
instance to v14, from v13.3. In case it matters, the cluster was originally
initdb at 13.2.
TRAP: FailedAssertion("_bt_posting_valid(nposting)", File: "nbtdedup.c", Line:
1062, PID: 28580)
postgres: telsasoft ts
The wraparound failsafe mechanism added by commit 1e55e7d1 had minimal
documentation -- just a basic description of how the GUCs work. I
think that it certainly merits some discussion under "25.1. Routine
Vacuuming" -- more specifically under "25.1.5. Preventing Transaction
ID Wraparound
I wrote:
> ... according to the C99
> spec this code is broken, because the compiler is allowed to assume
> that signed integer overflow doesn't happen, whereupon the second
> if-block is provably unreachable. The failure still represents a gcc
> bug, because we're using -fwrapv which should
Alexander Lakhin writes:
> While trying to use sqlsmith with postgres compiled from the master
> branch, I've found that the PQerrorMessage() function now returns
> non-informational but not empty error message after the successful
> PQconnectdb() call.
Yeah, see thread here:
Hello,
While trying to use sqlsmith with postgres compiled from the master
branch, I've found that the PQerrorMessage() function now returns
non-informational but not empty error message after the successful
PQconnectdb() call.
conn = PQconnectdb(conninfo.c_str());
char *errmsg =
I wrote:
> It sure looks like recovering a prepared
> transaction creates a transient state in which a new backend will
> compute a broken snapshot.
Oh, after further digging this is the same issue discussed here:
I wrote:
> Buildfarm member hornet just reported a failure in this test:
> https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=hornet=2021-06-27%2013%3A40%3A57
> It's not clear whether this is a problem with the test case or an
> actual server bug, but I'm leaning to the latter theory. My gut
Michael Paquier writes:
> I have been working on that over the last couple of days, and applied
> a fix down to 10. One thing that I did not like in the test was the
> use of compare() to check if the contents of the WAL segment before
> and after the timeline jump remained the same as this
Hi,
estimating joins is one of the significant gaps related to extended
statistics, and I've been regularly asked about what we might do about
that. This is an early experimental patch that I think might help us
with improving this, possible even in PG15.
Note: I do not claim this is exactly how
However, if slurp_file fails it raises an exception and aborts the
whole TAP unexpectedly, which is pretty unclean. So I'd suggest to
keep the eval, as attached. I tested it by changing the file name so
that the slurp fails.
Seem quite unnecessary. We haven't found that to be an issue
Seem quite unnecessary. We haven't found that to be an issue elsewhere
in the code where slurp_file is used. And in the present case we know
the file exists because we got its name from list_files().
Agreed. That's an exchange between a hard failure mid-test and a
failure while letting the
On Sat, Jun 26, 2021 at 11:01:07AM -0400, Andrew Dunstan wrote:
> On 6/26/21 2:47 AM, Fabien COELHO wrote:
>> However, if slurp_file fails it raises an exception and aborts the
>> whole TAP unexpectedly, which is pretty unclean. So I'd suggest to
>> keep the eval, as attached. I tested it by
On 6/26/21 2:47 AM, Fabien COELHO wrote:
>
> Hello Andrew & Michaël,
>
> My 0.02€:
>
>> There's a whole lot wrong with this code. To start with, why is that
>> unchecked eval there.
>
> Yep. The idea was that other tests would go on being collected eg if
> the file is not found, but it should
Hello Andrew & Michaël,
My 0.02€:
There's a whole lot wrong with this code. To start with, why is that
unchecked eval there.
Yep. The idea was that other tests would go on being collected eg if the
file is not found, but it should have been checked anyway.
And why is it reading in log
> On the whole this seems pretty cosmetic so I'm inclined to leave it alone.
> But if we were going to do anything I think that adjusting both initdb.c and
> guc.c to use 128MB might be the most appropriate thing.
Thank you for your suggestions. initdb.c and guc.c have been modified together.
moonjelly just reported an interesting failure [1]. It seems that
with the latest bleeding-edge gcc, this code is misoptimized:
/* check random range */
if (imin > imax)
{
pg_log_error("empty range given to random");
On Sun, Jun 27, 2021 at 12:41 AM tsunakawa.ta...@fujitsu.com
wrote:
> I'm moving to another company from July 1st. I may possibly not be allowed
> to do open source activities there, so let me say goodbye once.
It's a pity that you may not be around anymore. I wish you all the best.
--
Peter
Elijah Stone writes:
> On Sat, 26 Jun 2021, Tom Lane wrote:
>> If it still doesn't work, please provide a more concrete example.
> Thanks, unfortunately adding the explicit cast doesn't help. I've
> attached a minimal runnable example.
So your problem is that you're explicitly saying that the
On Sun, Jun 27, 2021 at 11:14:05AM -0400, Tom Lane wrote:
> Julien Rouhaud writes:
>
> > Agreed. One the other hand having such a function in core may ensure that
> > any
> > significant change in those area will keep an API to retrieve the final
> > query
> > representation.
>
> My point is
Julien Rouhaud writes:
> On Sun, Jun 27, 2021 at 10:34:52AM -0400, Tom Lane wrote:
>> It's not very hard to imagine someday moving view
>> expansion into the planner on efficiency grounds, leaving the rewriter
>> handling only the rare uses of INSERT/UPDATE/DELETE rules.
> Agreed. One the other
On Sun, Jun 27, 2021 at 10:34:52AM -0400, Tom Lane wrote:
>
> I'm not really excited by this, as it seems like it's exposing internal
> decisions we could change someday; to wit, first that there is any such
> thing as a separate rewriting pass
Sure, but the fact that views will significantly
I am planning on forking the tree so we can start adding developments
for Postgres 15 in the upcoming commitfest. This will be done tomorrow,
June 28, late morning US East coast time. I will be following the
procedures laid out in src/tools/RELEASE_CHANGES under the heading
"Starting a New
Julien Rouhaud writes:
> As an alternative, maybe we could expose a simple SRF that would take care of
> rewriting the query and deparsing the resulting query tree(s)?
I'm not really excited by this, as it seems like it's exposing internal
decisions we could change someday; to wit, first that
On Sun, Jun 27, 2021 at 10:06:00AM -0300, Ranier Vilela wrote:
>
> 1. strcmp(sql, "") could not be replaced by sql[0] == '\0'?
It's a debugging leftover that I forgot to remove. There's no point trying
to catch an empty string as e.g. a single space would be exactly the same, and
both would be
> Hi,
>
> I sometimes have to deal with queries referencing multiple and/or complex
> views. In such cases, it's quite troublesome to figure out what is the
> query
> really executed. Debug_print_rewritten isn't really useful for non trivial
> queries, and manually doing the view expansion isn't
> 20 марта 2021 г., в 00:35, Mark Dilger
> написал(а):
>
>
>
>> On Jan 21, 2021, at 6:48 PM, Justin Pryzby wrote:
>>
>> @cfbot: rebased
>> <0001-Reorganize-pglz-compression-code.patch>
>
> Review comments.
Thanks for the review, Mark!
And sorry for such a long delay, I've been trying to
On Sun, Jun 27, 2021 at 07:41:19AM +, tsunakawa.ta...@fujitsu.com wrote:
>
> I'm moving to another company from July 1st. I may possibly not be allowed
> to do open source activities there, so let me say goodbye once. Thank you
> all for your help. I really enjoyed learning PostgreSQL and
> Hello all,
>
>
> I'm moving to another company from July 1st. I may possibly not be allowed
> to do open source activities there, so let me say goodbye once. Thank you
> all for your help. I really enjoyed learning PostgreSQL and participating in
> its development.
>
> It's a pity that
Hello all,
I'm moving to another company from July 1st. I may possibly not be allowed to
do open source activities there, so let me say goodbye once. Thank you all for
your help. I really enjoyed learning PostgreSQL and participating in its
development.
It's a pity that I may not be able
48 matches
Mail list logo
