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, dbcomman
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 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
27;t change, right?
> > 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 dep
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 https://gitlab.com/dep
> > 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 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 almo
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
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 now
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 th
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 other con
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 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 w
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
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
backup-20190225074600.10361-db
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
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 t
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
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
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 th
Hi,
up to parallel executions, when we had node in explain analyze showing
"loops=x" with x more than 1, it meant that the "actual time" had to be
multiplied by loops to get real time spent in a node.
For example, check step 13 in https://explain.depesz.com/s/gNBd
It shows time of 3ms, but loops
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 exampl
On Mon, Nov 27, 2017 at 05:24:49PM +0530, Amit Kapila wrote:
> I think it is "actual_time * 1" for anything below Gather.
Well, I think I found another problem.
Please take a look at:
https://explain.depesz.com/s/Bs8c
Node 15 is Gather with loops = 2974 (because it was ran by nested loop).
Ther
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 dat
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
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 that
26 matches
Mail list logo
