> > Well, if it's possible to deduce what is the meaning in given line,
> > I can add the logic to do the deduction to parser.
> > Also, I want to say that I appreciate being looped in the discussion.
> I lost sight of this thread, so my apologies for the delay. The patch
> to fix the description
On Tue, Oct 31, 2023 at 08:17:52AM +0900, Michael Paquier wrote:
> Thanks for the input. I was looking yesterday if this code was
> available somewhere, but couldn't find it.. Until this morning:
> https://gitlab.com/depesz/explain.depesz.com.git
Well, the parser itself is
> > Also, if we keep 'shared/local' there could be similar complaints to
> > this thread in the future; so, at least adding comments can be
> > helpful.
>
> The problem is that it may impact existing tools that do explain
> output deparsing. One of them is https:
On Tue, Oct 11, 2022 at 08:31:53PM +0800, jiye wrote:
> But, as follow, if txn1 not commit (just like long term readonly txn), it
> will block txn2's ddl job, why alt add/drop column can not concurrently with
> read only access?
> txn1： long term txn not commit access t1.
> txn2 waiting txn1 to
On Tue, Oct 11, 2022 at 05:43:03PM +0800, jiye wrote:
> As we know postgres using high level lock when do alter table or other ddl
> commands,
> It will block any dml operation, while it also will block by long term dml
> operation.
Most of the things can be already done in non-blocking (or
On Tue, Mar 15, 2022 at 09:31:19AM +0800, lupeng wrote:
> Dear Hackers
> When I audit the Postgresql database recently, I found that after
> configuring the log type as csv, the output log content is as follows:
> "database ""lp_db1"" does not exist","DROP DATABASE
> lp_db1;",,"dropdb,
On Tue, Aug 31, 2021 at 03:06:25PM -0400, Tom Lane wrote:
> Agreed, but as I said upthread, fixing that looks like it will be
> rather invasive. Meanwhile, I went ahead and pushed the two
> simple improvements discussed so far.
Great. Thank you very much.
Best regards,
depesz
On Tue, Aug 31, 2021 at 04:00:14PM +0530, Amit Kapila wrote:
> One possibility could be there are quite a few DDLs happening in this
> application at some particular point in time which can lead to high
While not impossible, I'd rather say it's not very likely. We don't use
temporary tables, and
On Mon, Aug 30, 2021 at 08:15:24PM -0400, Joe Conway wrote:
> It would be interesting to step through a few times to see if it is really
> stuck in that loop. That would be consistent with 100% CPU and not checking
> for interrupts I think.
If the problem will happen again, will do my best to get
On Mon, Aug 30, 2021 at 09:09:20PM +0200, Laurenz Albe wrote:
> On Mon, 2021-08-30 at 17:18 +0200, hubert depesz lubaczewski wrote:
> > The thing is - I can't close it with pg_terminate_backend(), and I'd
> > rather not kill -9, as it will, I think, close all ot
On Mon, Aug 30, 2021 at 08:11:00PM -0400, Tom Lane wrote:
> [ redirecting to -hackers ]
>
> I wrote:
> > I experimented with the attached, very quick-n-dirty patch to collect
> > format_type results during the initial scan of pg_type, instead. On the
> > regression database in HEAD, it reduces
Hi,
Originally I posted it on -general, but Joe Conway suggested I repost in
here for greater visibility...
We hit a problem with Pg 12.6 (I know, we should upgrade, but that will
take long time to prepare).
Anyway - it's 12.6 on aarm64.
Couple of days there was replication slot started, and
On Sat, Oct 17, 2020 at 12:26:08PM +0800, Julien Rouhaud wrote:
> >> - -> Nested Loop (actual rows=N loops=N)
> >> + -> Nested Loop (actual min_rows=0 rows=0 max_rows=0
> >> loops=2)
> > This interface is ok - there is not too much space for creativity.
> Yes I also
On Fri, Aug 21, 2020 at 07:54:13AM +0200, Pierre Giraud wrote:
> It looks good to me too. Thanks a lot!
> Let's not forget to notify Hubert (depesz) once integrated.
Thanks a lot, and sorry for not responding earlier - vacation.
Best regards,
depesz
On Sun, Feb 02, 2020 at 11:48:32AM -0500, Tom Lane wrote:
> > Does that prevent backpatching this, or are we Ok with EXPLAIN text output
> > not
> > being stable across minors? AFAICT Pg::Explain still works fine with this
> > change, but mileage may vary for other parsers.
> I'm not sure about
On Mon, Feb 25, 2019 at 08:45:39AM +0100, hubert depesz lubaczewski wrote:
> Hi,
> I did upgrade of my test pg. Part of this is pg_dump -Fd of each
> database, then upgrade binaries, then initdb, and pg_restore.
Sorry, please disregard this problem.
Error was sitting on a chair.
Bes
Hi,
I did upgrade of my test pg. Part of this is pg_dump -Fd of each
database, then upgrade binaries, then initdb, and pg_restore.
But - I can't restore any database that has any data - I get segfaults.
For example, with gdb:
=$ gdb --args pg_restore -v -C -Fd
On Tue, Aug 28, 2018 at 08:33:11AM +0200, Alexander Kukushkin wrote:
> There is the archive_status directory in pg_wal, and if there are
> files with suffixes ".ready", you can archive not only the file which
> was requested, but quite a few more if there are ".ready" files
> available. After
Hi,
I'm in a situation where we quite often generate more WAL than we can
archive. The thing is - archiving takes long(ish) time but it's
multi-step process and includes talking to remote servers over network.
I tested that simply by running archiving in parallel I can easily get
2-3 times higher
Hi
I just noticed that when I called a procedure that commits and rollbacks
- the xact_start in pg_stat_activity is not updated. Is it intentional?
I'm on newest 12devel, built today.
Best regards,
depesz
--
Hubert Lubaczewski (depesz) | DBA
hlubaczew...@instructure.com
Instructure.com
Hi
I just noticed that when I called a procedure that commits and rollbacks
- the xact_start in pg_stat_activity is not updated. Is it intentional?
I'm on newest 12devel, built today.
Best regards,
depesz
On Wed, Jan 17, 2018 at 05:47:16PM +0200, Graham Leggett wrote:
> I need to test whether a database is empty, in other words “createdb”
> has been executed but no data of any kind appears in that database.
> What is the correct postgresql way to do this?
There is none, because it highly depends
On Tue, Nov 28, 2017 at 12:53:41PM +0530, Amit Kapila wrote:
> Is it possible for you to test the attached patch and see if you are
> still seeing any unexpected values?
well, not really. the explains i had were posted by people on
explain.depesz.com, so i don't have original queries nor their
On Sat, Nov 25, 2017 at 07:08:03AM +0530, Amit Kapila wrote:
> > For example, check step 13 in https://explain.depesz.com/s/gNBd
> >
> > It shows time of 3ms, but loops of 1873, so the actual time is ~ 5600ms.
> >
> > But with parallel execution it seems to be no longer the case.
> >
> > For
24 matches
Mail list logo
