Michael: Hello and welcome to Postgres.FM, a weekly show about

all things PostgreSQL.

I am Michael, founder of pgMustard, and I'm joined as usual by

Nikolay from Postgres.AI.

Hey Nikolay.

Nikolay: Hi Michael.

Michael: And today we are delighted to be joined by 2 excellent

guests who have each contributed a lot to Postgres over many

years now and who both recently published blog posts on the topic

we're going to be discussing.

Let me introduce you both quickly.

First we have Gülçin Yıldırım Jelínek, who co-founded the Prague

PostgreSQL Meetup and is a staff engineer at Xata.

Welcome Gülçin.

Gülçin: Hello, thank you for having me.

Michael: We're delighted to.

And we're also honoured to be joined by Robert Haas, long-serving

PostgreSQL major contributor and committer and VP Chief Architect

Database Service at EDB.

Welcome, Robert.

Robert: Hello, Thank you for having me.

Michael: It's our pleasure as well.

So to kick us off, I've prepared a couple of questions to ask

each of you in turn, but I'd also like to encourage you to ask

each other questions as we go along.

Perhaps we can start with you, Gülçin.

What are your high-level thoughts on the topic of is pg_dump a

backup tool and why is it something you wanted to write about

recently?

Gülçin: It is funny because I didn't actually want to write about

pg_dump.

I just joined my current employer Xata and it was my first week.

And then I noticed something in the discord channel that we have.

Somebody's having an issue with pg_dump.

I was like, Oh, what's happening?

And I saw like some parameter that I didn't recognize, like in

the error message, I was like, restrict non-system relation kind.

I was like, I don't know this configuration option or anything.

And then I noticed it was actually introduced recently at that

time.
And I was like, oh, okay, why?

And then I check it and it is kind of related to the CVE.

I remember the number 2024-734.

It doesn't matter, But there's a blog post about it, so you can

find with this number.

And in there, it explains like, what is this vulnerability and

how can actually people use this vulnerability to actually compromise

when you are, potentially your database, because it affects the

pg_dump.

So people can actually create a non-temporary object in the database.

And then just before pg_dump begins, it changes this object with

a different thing, like a view or a foreign table so people can

INSERT SQL there.

And then when pg_dump attempts to do the backup, then it can run

the injected SQL code.

So why are we there?

Because it affects it.

And then I said, hey, this affects from Postgres 12 to 16, upgrade

the Postgres versions and test if pg_dump scripts are working,

review the user permissions, the standard recommendations when

this kind of thing happens.

And then when we were sharing this blog post on Twitter, I think

our marketing team made like, okay, it's a pg_dump, a tool to

backup Postgres databases.

It was the definition of that tool, basically.

And then I read through it and everything, and I noticed, oh,

people are saying, you know, the usual, when you say something

about pg_dump, it is not a backup tool.

And I was like, okay.

And then basically it kept going.

So I had to write another blog post to say, is it really, or

is it not?

Nikolay: Who first said this?

Gülçin: I don't know.

I didn't know this because there were so many.

And I know that because in Postgres community, whenever pg_dump

topic opens up, somebody will say, you know, pg_dump is not a

backup tool.

But then actually a few days before this discussion happened,

Peter Eisentraut committed a change, which will be in effect

in PG18, that tries to remove the backup terminology and kind

of converts to export so that people are not considering it as

a backup tool in a way.

So this, I think, made people to be more vocal, saying that,

look, this was how it was before, but not anymore, and you should

not say it.

And then I had to write another, I mean, I felt like I should

write something more about it to explain why and why not we cannot

consider pg_dump backup or not.

And in my opinion, it is a tool that can be used to backup a

database.

And it is a logical way of doing a backup.

You can call it a dump.

Maybe you can define, you know, Nikolay was saying is it backup

tool or yes, no, or define backup.

So it can be a backup.

In your case, when I was like working as a DBA for a long time,

I was using it to backup databases.

Depends basically the context of how you use it and the nuances

that you can actually utilize this tool.

So yeah, that's where I stand today.

I don't agree that it is not a backup tool.

It can be a backup tool, but there are maybe later on in the

discussion we can discuss what are the drawbacks with it and

how actually regular backup tools that are out of Postgres can

help like pgBackRest or something.

Nikolay: Can I jump straight away with a question?

Gülçin: Yeah, please.

Nikolay: Yeah, I saw also comments that it's maybe for very large

databases like many terabytes and more it's not a good tool,

backup tool, but at least for small databases it's good and also

partial, you can export only 1 table.

Imagine we have a tiny database, just like, I don't know, like

100 rows, 1 table.

And I SELECT * from this table in psql and just make a picture

on my iPhone.

This is a backup, this picture we can restore from it right

Gülçin: Well maybe it's a snapshot right yeah why not well

Nikolay: dump is also snapshot right

Gülçin: yeah and that I don't really see like why it can't be

called backup

Nikolay: okay It

Gülçin: is a moment and you can use that moment to do something

with it.

Michael: I thought it was a really good blog post Gülçin, I'll

share it in the show notes as well for anybody that hasn't seen

it.

And speaking of good blog posts on the topic, I think Robert

added a lot of good points as well.

Both of your first blog posts included a lot of technical details

like the technical aspects of why it technically could be considered

a backup tool but also the drawbacks the many drawbacks of it

and why you might recommend for a general purpose backup tool

using something else.

So Robert, how about yourself?

How would you summarize your high-level thoughts on the topic

and why it was something you want, or maybe you didn't want to

write about it either?

Robert: Well I think it just kind of got under my skin because

you know Gülçin's blog post was not the first time that I've

heard people sort of using this pg_dump as not a backup to a line

and to me that kind of came across as shouting at people without

necessarily like giving you know a reasoning right you know The

documentation said for literally 20 years that pg_dump could be

used to make backups, or I don't remember exactly what the wording

was.

When I looked into the history in Git, I actually found that

the language that it's been changed to now with exporting the

database is very similar to the original language that was used

to describe pg_dump when that code was first added to PostgreSQL,

but there was a 2 decade period
in the middle when the documentation

said, hey, you can use this to
take backups.

And from my point of view, it doesn't
even matter whether that's

true or whether you think that's
true.

If the documentation said for 2
decades that X piece of software

could be used to do Y, then nobody
should get in trouble for

saying that.

Like, nobody should get called
out for saying that.

That just doesn't make any sense
to me.

Like, I mean, honestly, I think,
you know, we, some of us, self-included

can be a little too eager to jump
on people's case from time

to time.

And I don't think that's like good
for our community.

I think we wanna be the kind of
community where when people show

up we give them help, we give them
good advice, and we don't

come down on them like a ton of
bricks.

And Gülçin is not the only person
I've seen who seemed to me

to be kind of getting beaten up
a little bit.

And I was just like, why are we
doing this?

Like, clearly, pg_dump isn't right
for every purpose.

And there are lots of situations
where it's probably not what

you want.

But I just the tone is baffling
to me, because it seemed very

hostile to me and I couldn't make
any sense of really why we

should be that hostile about anything,
but especially why we

should be so hostile about that
in particular.

Gülçin: And to that I actually
have something to add, because

after this discussion started to
come up again, and I was looking

at the groups like where people
are actually using this, like

it's not a backup tool rhetoric.

And I seen like few users that
are trying to get help from this

Postgres communities that we have
online, a lot of them.

And there was like, I noted 2 of
them for today.

1 of them is asking, pg_dump can
limit a backup by schema.

I mean, it's like using this sentence
and there's somebody answering

directly.

It's not related there, but pg_dump
is not a backup.

And then there's another user,
can someone send me the command

to take backup of partial Database?

Which actually pg_dump can, right?

We can do the Schema only, we can
do just the Data, whatever,

or we can do a Table, any type
of Object.

And then answer is like, there
is no such command.

The standard backup tools take
backups of the entire Database

cluster.

So basically, it doesn't consider
it as a backup tool, even though

there is a pg_dump command that
can actually do what people are

asking.

So that's what I find very not
helpful, right?

We could just say to people, look,
this is this pg_dump command

that you can actually take this table that you want to take,

or selective restore, whatever you want to do with it, and help

people to the direction that they're actually trying to get there.

Instead, just saying, there is no such a command.

It's not a backup tool anyway, because the standard backup tools

takes the entire database cluster.

So that I don't find helpful, is what Robert is saying.

That is not helpful at all.

You might not agree that it's a good tool for using it as a backup

solution and which we can talk where it could be improved or

why actually people should prefer backup solutions.

But this is still not helpful.

There's a tool that we were all using for a long time and it

can does all the things that these people were asking.

So nuance of the question matters, the context of it.

And that's where I am, basically.

Robert: And you know, if somebody asks about how to use pg_dump,

and you want to tell them, hey, here's how to do that thing with

pg_dump, but maybe you want to consider some other alternatives

instead.

Cool, like I got no problem with that.

That can be helpful advice.

But like pretending that the thing that they're asking about

doesn't exist when it does, that I just don't understand that

at all.

Michael: So yeah, I've definitely got some theories as to why

people are behaving and speaking like that.

But I

Nikolay: do think...

1 of such people is just here.

I can speak to him if you want.

Michael: I wanted to, yeah, I wanted to, I think you've got some

really good language around this Nikolay around logical backups

and physical backups that really helps clarify and I think if

people use that language in those sentences it would immediately

help with clarity and also limitations but I'd love to hear your

like high-level thoughts on topic as well and and yeah why is

something you say

Nikolay: so this statement is a dump is not about the capital

is reaction to the statement documentation had 20 years And we

saw so many disastrous situations in many companies who Tried

to rely on this as backup tool while growing So we did like actually

it was not my statement, right?

I just picked it, right?

I think Franck Pachot also mentioned it.

I'm not sure he was the first who reacted to the Gilson's article.

But I joined as well, and I'm sure in many, not only Discord

or Slack or IRC, anywhere many people are picking up this motto

because it's painful to observe how many companies relied on

pg_dump as dumps as backups, right?

If we call dumps And considering
backups, okay, we can do that,

but there are limitations.

There is big power in this, not
only partial.

You can take specific Tables.

These days we have many managed
Postgres offerings and they don't

share backups with us.

If you want multi-cloud backup,
you must use pg_dump.

You cannot get data or copy or
something.

You cannot get physical backups
out of RDS, for example, right?

But this pain observed for a couple
of decades caused me like

joining this Movement saying that
pg_dump is not a backup tool.

At the same time, there is a like
I told Michael there is like

it's There is like a kind of professional
shift in my mind here.

Because when somebody says backups,
I envision only physical

backups.

Although there are logical backups,
of course.

And again, this is not my idea
to introduce this language.

I checked it in Oracle and MySQL
documentation.

I think maybe it's a good idea
to borrow this concept and mention

specifically SQL.

There are 2 kinds of backups, physical
and logical.

They all have pros and cons.

For example, logical backup, If
you rely on pg_dump as a backup

tool, like for example, partial
and escaping from RDS, it's good

pros, right?

Speaking of cons, it's always like
kind of snapshot.

It puts pressure on your Database
in terms of xmin horizon, affecting

autovacuum behavior, which is
unacceptable if you have 10 plus

terabytes and heavy load.

Also, at 1 day, some bug or corruption
might happen, and you

simply cannot read your data at
logical level.

While physical backups are not
affected.

They just copy files, right?

And like, there are many pros and
cons to compare, right?

And I like the idea to split language
between logical and physical.

And for me personally, when somebody
says backups without specification,

I still see by default physical
only.

Right.

Gülçin: If we are considering the
corruption, the logical backups,

the corruption can be also in the
physical level.

Nikolay: Right.

I'm okay with that, but I have
backup, I can restore and deal

with it, right?

Gülçin: Well, then actually you
can maybe keep this corruption

between your physical backups if
you didn't notice, if it's gone

unnoticed.

And then if you had the logical
backup on top of it, maybe, you

know, it could be another tool
to fight this physical corruption

that you have.

Nikolay: Yeah, what I'm trying
to say, if I have physical backups

with corruption, I will deal with
it and so on.

But if I have corruption which
prevents pg_dump from reading data,

it will just fail and I don't have
anything.

Robert: Yeah, so I'd just like
to make a couple of comments here.

I think 1 of the things that I
find really interesting is that

people who work for different companies
that all support and

use Postgres can have very different
experiences of some of this

stuff.

And I've seen that before with
other issues and I'm seeing it

here too.

Because my typical experience with
pg_dump is not the 1 that you

were describing at all.

In fact, since I've worked at EDB,
which is the whole of my professional

Postgres career, I've never had
that situation happen.

Like not once have I run into a
situation where a customer should

have been using something other
than pg_dump and they were just

using pg_dump and then they got
into trouble.

What happens to me rather frequently
is that someone has used

some other kind of backup and things
have gone really badly wrong

for some reason and pg_dump becomes
the way that we can help that

customer to get out from under
that problem.

So just as your experience with
the customers that you've worked

with is informing the way that
you view the issue.

I have a different set of experiences,
a very different set of

experiences from what it sounds
like.

And so this thing that to you feels
like, ah, this is the catastrophe.

We've got to steer clear of this.

In my experience, that's never
the problem.

It's always the thing we reach
for to get out from under the

problem.

And I really just want to highlight
that because I'm not saying

your experience isn't valid and
I hope you'll return the same

courtesy.

Gülçin: I actually understand partially
what Nikolay is trying

to say here because I was before
EDB, before working with Robert,

I was working for Second Quadrant
and we were building our own

backup solution, Barman.

Nikolay: And
now it's EDB owns it.

And then I know, because I was
actually doing remote DBA work

And there was a lot of customers
with backup issues.

They had their own home cook scripts.

In the wrong hands, this can go
wrong, because there are some

things that pg_dump and restore,
you have to know about it.

How do you do the dump process?

How do you do restore?

Do you actually test these things?

Do you copy the whole directory
or do you consider it as just

some logs that we can actually
delete at some point and so on?

So if people don't know how to
maybe put these things together

in a way, it is not really helpful
for some people, then things

can go wrong.

And I seen that things actually
went wrong.

That's why we were steering people,
you know, if you just do

regular backups and restores, use
this tool that we have or any

other tool that can be used for
backups and you can keep the

retention period, you can keep
your backups for X days, you can

restore them and test and you can
have continuous backups that

edit.

So it's not like partial, you know,
it can be just like a continuous

thing that you don't need to worry
and you can do point in time

recovery and so on and so on.

So I understand this rhetoric and
I was the advocacy of it, but

then I also feel like it went too
far saying, you know, this

is not, this is not usable and
that I, I oppose basically.

Nikolay: Yeah.
It's like pendulum.

I agree.

Yeah.

The start of this pendulum is these
20 years of documentation.

So you raised a very good point
about restore.

When I hear backup, full-fledged
backup, it's not only physical

to me, it's also verified.

And if we have physical backup
which we test, that's great.

While with dumps, I'm very curious,
while Robert, you didn't

see an ability of pg_dump to read
some, I don't know, some database

which is corrupted and we cannot
get dump out of it.

But second question like here.

Okay.

Robert: That actually happens all
the time.

And one of the things that I often
end up helping people do is

fixing the database enough that
we can use pg_dump to get the

data out of it.

Because if the database has incurred
a lot of damage at a physical

level for some reason, we're never
going to be able to repair

that well enough to give confidence
that everything is the way

that it should be.

So a dump and restore in my professional
opinion is absolutely

essential in that situation to
get back to a clean state.

Now you are 100% correct that the
dump may also fail or the restore

may also fail, but those are problems
that we can understand

and fix.

We can look and say, ah, well you
have a pg_class entry, but

you're missing a pg_index entry,
so we need to create the one or

delete the other.

That's a problem where we can say,
ah-ha, that's something that

we as Postgres experts can look
into and understand what needs

to be done to bring this back to
a state where pg_dump is going

to run.

But the blocks being messed up
at a physical level or out of

sync with each other because we've
had some time travel of some

kind or something like that, Those
are problems we won't be able

to get out from under that ever.

Does that make sense?

Nikolay: Yeah, it makes total sense.

And moreover, it's a very popular
approach to use pg_dump to test

physical backups to see that we
can read all except indexes.

For indexes, we use amcheck,
but to test physical backups,

we use pg_dump to /dev/null, for example,
just to see that there

is no corruption, like We can read
it for sure.

And the second, like you mentioned
restore.

I remember a couple of times I
saw a dump could not be restored

because of a unique key violation,
right?

Because of corruption of uniqueness
constraint.

Because some duplicates happened
and unique key didn't save us

due to some bugs or something.

Maybe somebody disabled something,
I don't know.

Or foreign keys, foreign keys as
well.

If you disable triggers, you can
corrupt your data easily, right?

You disable triggers, you load
something and you enable triggers

and Postgres won't check it.

And during pg_dump, pg_dump you can
have, but you cannot restore

from it.

Right?

So yeah, we see some mutual points
definitely here.

And the question is just about
language I guess.

That's it.

Michael: Well I think it's also
about experience Nikolay, you

mentioned some disasters, is it
my right and understanding this

is folks who have come to you with
some issue and they've only...

It's not just that they're using
pg_dump as a backup tool, it's

their only form of backup.

And what kind of issues is that
causing?

Nikolay: Remember the first managed
service, managed Postgres

service created, popular at least.

It was called Heroku.

I think it still exists, but not
being actively developed these

days.

And they offer backups as dumps.

You can download them.

That's great actually.

If a managed service, Postgres service
provider allows you to download

backups, that's great.

But it was just backups.

And nobody does this.

I mean, nobody among very popular
managed Postgres providers

do this.

They rely on physical backups these
days, right?

And also on snapshots and so on.

I mean, cloud snapshots, full disk
snapshots.

And this also shows evolution of
backup concept in many people's

minds, Not only us.

So I think it would be great just
to agree on the language and

discuss.

I'm okay to be alone thinking that
backup is just physical backup.

Backup could include both logical
and physical, and we could

clarify documentation and language
articles and so on.

And I see it's a pendulum, right?

Again, this is my point.

Too long documentation was claiming
this is a backup tool.

This language was super harsh.

And I remember I was trying to
explain at least a couple of times

in my life, I was trying to explain
to some customers with growing

Postgres databases, exceeding terabytes
and approaching 10 terabytes.

I'm saying, don't rely on pg_dump
as a backup solution And they

just showed me documentation saying,
this is like, this is what

they say.

Vendor is saying this, right?

Robert: Yeah.

I mean, I think that there is a,
maybe a difference between something

that creates a backup and a backup
tool.

I mean, this does get down a little
bit to what you think words

mean, so it almost seems like a
silly thing to argue about, right?

But I think, you know, you asked
Gotcha at the beginning, like,

if I take a snapshot of all of
my data on a cell phone, is that

a backup?

And I think the answer is obviously
yes, but equally obviously,

that's a silly way to do a backup
because your restore procedure

is going to be very unpleasant,
which is not what you want.

I think sometimes when people talk
about a backup or a tool that

can take a backup or a backup tool,
sometimes they mean like,

can I get a copy of my data from
which I could recover?

Right, and that's 1 question.

And pg_dump will give you that,
right?

The other question, sometimes what
people mean is, they mean,

is this like, and they may have
some particular commercial product

in mind that offers a certain feature
set and their question

is am I going to get this feature
set where for example my retention

times will be managed and my my
actual process of orchestrating

the backup and orchestrating the
recovery will be managed.

And then the answer is no, pg_dump
is not going to do that for

you.

And you probably do want those
things in most cases.

So I don't know, like, I think
there's a lot of nuance that's

possible in the language here.

But for me, the important thing
is to make sure that we're clearly

able to explain what the benefits
and drawbacks of the different

approaches are rather than, you
know, spending too much time

fighting about the specific language,
which for me, it gets a

little bit silly.

Nikolay: I agree.

Yeah.

Michael: I agree as well, Robert.

In your blog post, you make a really
good case for the tone of

the statement being difficult,
and I think you actually use some

language that is that like waters
it down a little bit or explains

a little bit more it doesn't take
many more extra words to do

so but I also wanted to ask do
you see this problem in other

statements in the Postgres community
like are there other things

people are saying that remind you
of the tone of this kind of

statement as well?

Robert: I don't have specific examples
in mind off the top of

my head, but definitely yes.

I mean, it's a chronic problem
on Hackers.

You know, I think I wrote a blog
post about the sort of tone

of dialogue in the Postgres community
towards the end of last

year.

And it's always a problem because
when you post your patch on

Postgres Hackers, you're essentially
soliciting review.

And people are rarely going to
write you a review where they're

like, you know what, this patch
is amazing and I love it.

I mean, it happens.

People actually do get those kinds
of reviews, and it's a great

day when you do.

But generally, when you're reviewing
a patch, you're picking

something that you actually like
and would like to see go forward.

And then you're saying the worst
things about it that you can

think of to say.

You're like, so here's all the
problems.

Here's all of the stuff that I
think needs to be better in order

for this to become part of the
product, which I hope it will,

but these things are the things
that I think need to be fixed

first.

And so what I see is that actually
for a lot of committers, in

particular, people's mental health
is not in a great place.

You know, I kinda thought my mental
health was not in a great

place around some of this stuff,
and then I talked to some other

people and found that they were
feeling worse about it than I

was feeling by like significant
margins.

And it's, in my opinion, it's rarely
because of bad intent.

I mean, obviously people get frustrated.

People say things that they shouldn't
have said or they don't

say it in the right way or they're
pissed off.

I mean, those things happen and
I don't wanna pretend like they

don't.

But I think very, very often it's
a case of the nature of the

workflow and the nature of the
process and the kind of engineering

that we're doing.

It's difficult and it's error prone
And even the absolute smartest

people in the community make all
kinds of mistakes, you know,

over and over again, right?

Like we were doing a rewrap of
a scheduled minor release that

happened last week.

We're doing that this week because
somebody committed a fix for

a bug and the fix contained another
bug.

And it doesn't matter who made
the mistake or who didn't catch

the mistake, that's not relevant.

It happens all the time.

And I think it's really challenging
to people because we work

in a very open environment where
everybody sees every email we

write, every patch we commit, every
patch we thought about committing.

You know, it's out there constantly
and you just realize that

there are so many ways for you
to screw up and every time you

make a mistake, everybody sees
it.

So I think it's a struggle for
everybody.

As far as I can tell, every single
person who works on Hackers

encounters this problem of getting
the tone right all the time.

And I am certainly not going to
sit here and pretend like I get

it right more often than average.

I think a lot of people would say
I am below average in that

way, but I can tell you I'm very
aware of the problem and I am

trying to figure out how to do
it better because at the end of

the day, it's not enough for us
to deliver great software.

We need to deliver great software
while also creating a community

that people want to participate
in.

And that applies for me, first
of all, to the developer community

because that's where I spent most
of my time, but it also I think

applies more much more broadly
to the user community.

And I think that is part of the
reason this issue set me off

a little bit, because, you know,
it's the sort of thing that

I'm struggling, often in vain,
to do right on a daily basis.

But instead of being targeted at
other developers who at least

kind of know that the negative
feedback is coming.

Some of this felt to me like it
was targeted toward users who

like they don't realize that they're
about to get jumped on for

you know wading into a flame war
about whether something is or

isn't something you know and I
just don't want you I don't want

users that I don't want anybody
to have that experience I certainly

don't want users to have that experience.

Michael: I personally think that
only from having you articulate

that I've thought of 1 that I that
annoys me a little bit and

that's the correction of people
pronouncing or spelling Postgres

wrongly or missing the S off sometimes
happens if people are

new to the community and immediately
they get jumped on.

I think, oh, come on, they're clearly
new.

So yeah, I can definitely see that.

Robert: It also happens a lot with
people based on their language

of origin.

Like the fact that we pronounce
it PostgreSQL, I believe that's

at least 1 of the canonical pronunciations,
that is much more

natural for somebody who learned
to speak English in the United

States Than it is for somebody
who learned to speak English and

for example India, right?

Like it is English, But the way
that English is spoken in India,

it's a distinct dialect.

It has its own ways that people
say things, ways that people

communicate characteristic patterns
of speech.

And that's not the only place,
certainly.

I think actually there are probably
other countries that where

the problem is even more acute
because English isn't even used

as a common language communication
in many parts of the world

But even when it is it's not necessarily
the same as your English

and people aren't necessarily going
to be You know starting from

the same point, right?

If I read a word that is unfamiliar
and my wife reads the same

word, we're likely to pronounce
it the same way in most cases.

But if a colleague from halfway
around the world reads the same

word, their instinct may not be
the same as mine.

And that's not necessarily a question
of me being right and them

being wrong.

That's the question of we went
to different schools.

We were taught different things.

Gülçin: Yeah, I think it also points
out to the wider problem

in many communities, like the longevity
of the projects will

depend on people.

And if you are hostile to people
or like, because we all come

from different parts of the world,
I didn't learn English until

I was like, you know, an older
kid.

And that is always a problem when
I give a talk or when I write

an email.

It is still in the back of my mind
that I try to correct myself,

I use multiple tools, I try to
present myself as good as I can,

but there are limits.

I still confuse the propositions
I use in and at, all around,

randomly.

I could never fix this.

And that doesn't mean that I can't
contribute to the project,

and I could and I do.

And that's what I believe, like
these little statements, maybe

we took it to a philosophical approach
through, it's not about

pg_dump, backup or not, but like
as, you know, saying Postgres,

but we should do better in how
we handle communication because

this is the way that people interact
with today, report issues.

And if you don't accept the problems,
well, people will not report

it or they will not actually use
this and report back what they

use so that you don't actually
get the feedback from people.

And because you cut these channels
that people actually try to

communicate to you, instead of
opening all these channels that

we should actually amplify, we
should have more channels for

people to bring stuff that they
interact with Postgres or ecosystem

in general.

So that's where I was really impressed
by Robert's blog about

how open he was about this.

And I appreciate the efforts that
going on towards this, because

when I started, I also felt scared,
almost reading some of the

emails.

I was like, I wouldn't want this
reaction to come to me, for

example.

So it shouldn't be like that.

Robert: And I think it's not just
an issue of dialect either.

You know, like that is definitely
part of it.

But 1 thing that I've noticed on
Hackers is that clarity and

extreme precision of expression
is very, very highly valued,

right?

Like someone can come along with
a worse idea and because they

explain it extremely clearly and
precisely either it gets accepted

or they get feedback on how it
should be changed or positive

comments.

Welcome to the community.

Hey, great to have you, right?

Somebody else writes a worse email
about a better idea, and it

actually gets a worse response.

And I do understand some of why
that happens, right?

We value people whose style of
expression is similar to our own,

where we feel like we can freely
and easily communicate with

those people, and everybody's busy,
so you don't wanna spend

a huge amount of time trying to
understand email A if you could

very quickly and easily understand
email B But it's obviously

super off-putting to people when
you may have proposed something

that was actually great And if
somebody had given you 5 minutes

of their time, they could have
understood exactly what you were

trying to say, but they just flip
through the email really fast.

And then they moved on because
they're busy.

And that's obviously going to be
demoralizing to people.

Michael: To play devil's advocate
a little bit, I personally

err on the side of being polite
and trying to be kind and trying

to be welcoming, but I also think
sometimes that approach doesn't

always land, people don't always
take the lesson from it or learn

from the statement or realise that
maybe what I'm really trying

to say or I'm not being clear enough,
that kind of thing.

And I do think, for example, with
the comment that we started

with, I feel like there's a certain
amount of trying to save

people from themselves or trying
to shock people, deliberately

trying to be provocative in order
to make people think, oh we

shouldn't only be relying on this
tool for this purpose or you

know we maybe I should be rethinking
my thoughts, you know that

it doesn't apply to all of these
cases like mispronouncing the

project name but I've seen this
specific comment come mostly

from consultants, some experienced
consultants, some who are

very kind and also involved in
like diversity initiatives.

I've definitely seen this from
people that you wouldn't necessarily

expect to be direct and unkind
so the exact phrase pg_dump is

not a backup tool.

So I think that's coming from a
place of having seen people shoot

themselves in the foot and wanting
to save people from that and

wanting to be quite direct to avoid
it.

So I don't know for sure, but I
believe their intent is good,

but maybe they're deliberately
choosing to be provocative or

direct or I'm not sure.

I'm not sure.

Maybe I'm putting words in their
mouths basically.

Gülçin: I think it's like we are
not calling out people for just

saying, you know, this is not a
backup too, because we understand

where they come from, because we
are in the same industry, working

for ages.

We know these people, we all had
the customer stories and so

on.

But I think the general idea from
here that when somebody shares

a blog post, let's say we all wrote
about it.

I had wrote 2 blog posts and Robert
wrote 2 more.

And we just got together and talking
about it.

Let's say he's pointing out why
pg_dump is good at dependency

management, let's say.

We take it for granted, which I
wanted to bring up in today's

call to just actually showcase
that there are things we should

appreciate in this tool, why he
says it is an amazing tool.

Then towards this, somebody writes
like, but it is not a backup

tool.

Then I don't get it, because it's
not what is the discussion

about.

We are trying to discuss that there
are ways you can make this

tool in your tool set.

It's not the only tool.

There are professional solutions
for backing up your database

against disaster recovery, as we
mentioned, the retention and

the whole orchestration of the
database backups and recovery.

But when we are discussing this
tool specifically, which I feel

that is important here because
there's nuance to be discussed,

and just shutting down the discussion
saying, but it's not a

backup tool, this is where I feel
that this needs to be improved

better because then you don't really
contribute to this because

you need to say then why it is
not in this case, why don't you

agree with this?

Let's say, is it dependency management
thing is not for you or

why it could be improved?

You could say that pg_dump could
be improved because let's say

we could run vacuum after it, or
we can do, I don't know, like

do statistics better or something.

I mean, to contribute where a pg_dump
might have been improved,

because I've seen people like in
the discussions that they struggle

with mapping, let's say, pg_dump
options to pg_restore options

because they assume the order will
be the same and they don't

get it and so on.

So there are things maybe we could
get input from why people

complain about these things and
to improve.

That's where I go for issues.

I see these comments in the forums
and like, oh, OK, this is

a good idea.

Maybe I can actually talk about
this.

But then when we are discussing
this and coming with like, okay,

this is not a backup tool, it kind
of brings back to the 0 and

doesn't really improve anything.

Nikolay: But your second article
was basically agreeing that

it's not a backup tool.

Gülçin: No, in the sense that people
say, as I'm saying, as a

solution, if you want to orchestrate
your backups, use a, I don't

know, a tool that is like, you
know, Barman, Baker's or something.

But then another discussion we
have, why it can't be?

Why pg_dump?

We are discussing the, because
in the second blog post of Robert,

for example, he gives up like this,
you know, why it could be

a nice tool for these of the use
cases that he lists.

And they're getting the question
of again, that I don't agree

basically, like, okay, use a better
maybe solution if you are

managing production databases in
multiple environments that are

giant databases and you really
don't need to deal with, you know,

home run.

But he's still historically, it
is still a tool that we use,

you know, it could be used for
different cases.

Nikolay: What, what I hear is you're
saying when people come

to you to comment to your first
blog post saying, I think it

was Franck Pachot and I'm joining
him, still joining.

And he said, pg_dump is not
a backup tool.

You think it's like shuts down
some discussion and so on.

But I just explained that this
is a pain from a lot of experience

and we are just reacting and what
I hear you still try to judge

him, right?

Let's just...

Gülçin: No, no, that's definitely
not for it.

I'm just saying we discussed that,
but the second blog post was

about, you know, there's backup
tools, you should use it.

But then when Robert was describing
a part of why pg_dump is

good, in my opinion, it was like
very valuable points.

And there it was not even relevant.

We were not even discussing, should
you use this tool or not?

And I'm not targeting anybody.

I'm not targeting anybody.

So be clear about it.

Nikolay: Yeah.
So the change happened only now.

It's in Postgres 18.

And recently I had discussion this
like claiming, oh, it's not

backup tool.

Somebody said, oh, what is this
about then?

And sending me a link to pg_dump
documentation.

So I think I would not judge people
who are saying pg_dump is

not a backup tool until we have
this change in documentation

and start recovering from this
stress we had 20 years.

This is my point.

I stay on this point very strong.

And common ground is let's start
distinguishing physical and

logical backups.

We can clarify this on documentation
as Oracle and MySQL did.

And there is already part of documentation
speaking of backups,

it describes dumps, I mean, pg_dump
and then file system snapshots

and then point-in-time recovery,
full-fledged backups.

And just if we clarify documentation
and I will stop seeing customers

sending me this link saying you're
wrong, this is documentation

saying you are wrong.

Robert: But like, I think, you
know, I don't know, like, if you

can't win an argument against a
documentation link, I don't know,

it feels like something's not right
there, you know, like, I'm

not trying to be harsh.

And I just feel like, you know,
if somebody hires you to give

them good advice, and you give
them advice that is actually good,

and their response is...

Nikolay: Robert, let me interrupt
you.

Sorry.

I'm just like, I feel judgment
in you and Galaxian's words.

Like, you tell me now how you want
to be welcoming, and now you

judge me like I cannot win.

I cannot win 2 things.

pg_dump is a backup tool.

Sometimes I cannot.

They say they trust documentation
more because many more minds

behind it.

And also pg_stat_statements, documentation
says you cannot say

set it to positive value, keep
it 0 globally because globally

it's a bad idea.

I already like some customers I
win, some customers I don't.

I'm not genius, right?

But I feel in both of you, I feel
judgment.

Why don't we stop judging people
and sentiment and so on?

I bring you like improvement.

Let's say there are 2 types of
backups, logical and physical.

And then we, we develop language
from there.

And this joins us.

Right?

When you judge people saying they
came to me with this statement,

or you say, you cannot win your
customer authentication, This

splits us.

And I start fighting with you.

I don't want to fight with you.

Robert: But I mean, that's also my complaint about the language

that you were using.

So I don't know how to have this discussion without having opinions

about whether certain language is good or bad.

And I don't think I mean, you can't write like we have to be

able to talk about what the language does and to what extent

it helps or hurts.

And yeah, of course, there's some judgment there I don't know

like I definitely have been in the situation of having a customer

who?

Wouldn't listen and I The frustration that you feel with that

situation feels very genuine to me like I I can totally imagine

that happening and being a bad experience, but I don't know.

I'm not even saying it's a bad thing that we changed the language

in the documentation.

I was only reacting against sort of like conclusory statement

pg_dump is a backup tool and now I don't want to talk about it

anymore I think we should always be talking about it more I think

we should be trying to as you say bring clarity to it and bring

precision to it

Nikolay: I agree with you totally like I hear you now well and

I think we will stop saying this actually, if documentation will

be, it's already fixed, I think it can be fixed even better if

we say it's a logical backup tool, for example.

Everyone will be happy, I think, right?

And we will stop saying it's not a backup tool.

We will start saying it's not a physical backup tool, which is

obvious, right?

And this will join everything and so on, right?

I agree with your reaction, actually, which says this statement

it's not a backup tool it's like too like far from balance right

it's off balance I agree with this so it's not a good statement

actually I admit but again it's a reaction to another not a good

statement which we had in documentation which didn't say logical

backup it said just just backup okay

Michael: we're pretty much out of time okay I wanted to thank

you all for your thoughts on this I think is a difficult subject

and I think actually it's really nice to have 3 people that all

care about educating folks and teaching people how to do things

well with different opinions on how to do so or you know slightly

different approaches on how to do so but as Nikolay says, as

Gülçin pointed out in her blog post, the language around this

has been changed in the documentation.

Robert, keep fighting the good fight on the hacker, the tone

on things on Hackers.

Is there any last words anybody else wants to add?

Let's start Gülçin, did you want to say anything else at the

end?

Gülçin: No, I'm happy that we are discussing it and I don't take

things personally.

I mean, we are here just to discuss technically why this could

be useful in some cases and why not.

And Yeah, that was anyway the summary of what I said in the blog

post as well.

So if people like to read it and comment on it, and I'm happy

to discuss more.

Thanks.

Michael: Wonderful.

Well, we're looking forward to your future blog posts, whether

you want to write them or not.

Robert, any last words from you?

Robert: I just think, you know, on Nikolay's comment about making

the documentation better, what I would encourage, and of course

this is much longer than we can actually do in this forum, is,

you know, let's get down beyond the headline, right?

Like saying in the headline that it is a backup tool or that

it's not a backup tool, it's an export, it's a dump, it's a lot.

We got to get beyond that subject line and think about what we

say down deeper.

I think one of the areas where the Postgres documentation is sometimes

weak is it doesn't always do a good job listing pros and cons.

Pros and cons very often don't get listed for things.

So you know that that's probably an area where we could we could

grow as a community.

Nikolay: Big time.

Michael: Brilliant.

Well thank you so much everybody and thanks Nikolay, catch you

next week.

Nikolay: Thank you.

Thank you for coming.

Gülçin: Thanks.

Bye-bye.
Robert: Ciao.

Nikolay: Bye.

Gülçin: Ciao.