1
00:00:00,060 --> 00:00:02,720
Michael: Hello and welcome to Postgres.FM, a weekly show about

2
00:00:02,720 --> 00:00:03,580
all things PostgreSQL.

3
00:00:03,760 --> 00:00:06,540
I am Michael, founder of pgMustard, and I'm joined as usual by

4
00:00:06,540 --> 00:00:08,040
Nikolay from Postgres.AI.

5
00:00:08,040 --> 00:00:08,660
Hey Nikolay.

6
00:00:08,960 --> 00:00:09,720
Nikolay: Hi Michael.

7
00:00:10,940 --> 00:00:14,540
Michael: And today we are delighted to be joined by 2 excellent

8
00:00:14,540 --> 00:00:17,160
guests who have each contributed a lot to Postgres over many

9
00:00:17,160 --> 00:00:20,340
years now and who both recently published blog posts on the topic

10
00:00:20,340 --> 00:00:21,440
we're going to be discussing.

11
00:00:21,860 --> 00:00:23,540
Let me introduce you both quickly.

12
00:00:23,800 --> 00:00:27,260
First we have Gülçin Yıldırım Jelínek, who co-founded the Prague

13
00:00:27,260 --> 00:00:30,280
PostgreSQL Meetup and is a staff engineer at Xata.

14
00:00:30,380 --> 00:00:31,240
Welcome Gülçin.

15
00:00:32,080 --> 00:00:33,940
Gülçin: Hello, thank you for having me.

16
00:00:34,080 --> 00:00:35,240
Michael: We're delighted to.

17
00:00:35,240 --> 00:00:37,940
And we're also honoured to be joined by Robert Haas, long-serving

18
00:00:38,000 --> 00:00:41,320
PostgreSQL major contributor and committer and VP Chief Architect

19
00:00:41,320 --> 00:00:43,040
Database Service at EDB.

20
00:00:43,280 --> 00:00:44,340
Welcome, Robert.

21
00:00:44,640 --> 00:00:46,220
Robert: Hello, Thank you for having me.

22
00:00:46,560 --> 00:00:48,140
Michael: It's our pleasure as well.

23
00:00:48,340 --> 00:00:52,120
So to kick us off, I've prepared a couple of questions to ask

24
00:00:52,120 --> 00:00:55,240
each of you in turn, but I'd also like to encourage you to ask

25
00:00:55,240 --> 00:00:57,180
each other questions as we go along.

26
00:00:57,180 --> 00:00:59,120
Perhaps we can start with you, Gülçin.

27
00:00:59,340 --> 00:01:03,080
What are your high-level thoughts on the topic of is pg_dump a

28
00:01:03,080 --> 00:01:06,020
backup tool and why is it something you wanted to write about

29
00:01:06,020 --> 00:01:06,520
recently?

30
00:01:07,680 --> 00:01:10,320
Gülçin: It is funny because I didn't actually want to write about

31
00:01:10,320 --> 00:01:10,820
pg_dump.

32
00:01:12,720 --> 00:01:17,500
I just joined my current employer Xata and it was my first week.

33
00:01:17,540 --> 00:01:20,660
And then I noticed something in the discord channel that we have.

34
00:01:20,660 --> 00:01:22,280
Somebody's having an issue with pg_dump.

35
00:01:22,280 --> 00:01:24,200
I was like, Oh, what's happening?

36
00:01:24,200 --> 00:01:27,260
And I saw like some parameter that I didn't recognize, like in

37
00:01:27,260 --> 00:01:31,560
the error message, I was like, restrict non-system relation kind.

38
00:01:31,560 --> 00:01:35,140
I was like, I don't know this configuration option or anything.

39
00:01:35,220 --> 00:01:37,800
And then I noticed it was actually introduced recently at that

40
00:01:37,800 --> 00:01:39,400
time.
And I was like, oh, okay, why?

41
00:01:39,400 --> 00:01:43,220
And then I check it and it is kind of related to the CVE.

42
00:01:43,900 --> 00:01:45,420
I remember the number 2024-734.

43
00:01:47,320 --> 00:01:50,080
It doesn't matter, But there's a blog post about it, so you can

44
00:01:50,080 --> 00:01:51,260
find with this number.

45
00:01:51,300 --> 00:01:54,880
And in there, it explains like, what is this vulnerability and

46
00:01:54,880 --> 00:01:58,580
how can actually people use this vulnerability to actually compromise

47
00:01:58,980 --> 00:02:01,700
when you are, potentially your database, because it affects the

48
00:02:01,700 --> 00:02:02,160
pg_dump.

49
00:02:02,160 --> 00:02:05,960
So people can actually create a non-temporary object in the database.

50
00:02:06,280 --> 00:02:09,960
And then just before pg_dump begins, it changes this object with

51
00:02:09,960 --> 00:02:13,580
a different thing, like a view or a foreign table so people can

52
00:02:13,580 --> 00:02:15,560
INSERT SQL there.

53
00:02:15,660 --> 00:02:20,740
And then when pg_dump attempts to do the backup, then it can run

54
00:02:20,740 --> 00:02:22,320
the injected SQL code.

55
00:02:22,420 --> 00:02:23,500
So why are we there?

56
00:02:23,500 --> 00:02:24,480
Because it affects it.

57
00:02:24,480 --> 00:02:30,140
And then I said, hey, this affects from Postgres 12 to 16, upgrade

58
00:02:30,480 --> 00:02:34,900
the Postgres versions and test if pg_dump scripts are working,

59
00:02:35,200 --> 00:02:38,760
review the user permissions, the standard recommendations when

60
00:02:38,760 --> 00:02:39,900
this kind of thing happens.

61
00:02:40,420 --> 00:02:44,440
And then when we were sharing this blog post on Twitter, I think

62
00:02:44,440 --> 00:02:48,820
our marketing team made like, okay, it's a pg_dump, a tool to

63
00:02:48,820 --> 00:02:50,420
backup Postgres databases.

64
00:02:51,040 --> 00:02:54,500
It was the definition of that tool, basically.

65
00:02:54,640 --> 00:02:57,940
And then I read through it and everything, and I noticed, oh,

66
00:02:57,940 --> 00:03:01,340
people are saying, you know, the usual, when you say something

67
00:03:01,340 --> 00:03:04,040
about pg_dump, it is not a backup tool.

68
00:03:04,340 --> 00:03:05,980
And I was like, okay.

69
00:03:05,980 --> 00:03:07,580
And then basically it kept going.

70
00:03:07,580 --> 00:03:12,280
So I had to write another blog post to say, is it really, or

71
00:03:12,280 --> 00:03:13,220
is it not?

72
00:03:15,060 --> 00:03:16,580
Nikolay: Who first said this?

73
00:03:17,080 --> 00:03:17,900
Gülçin: I don't know.

74
00:03:17,900 --> 00:03:19,780
I didn't know this because there were so many.

75
00:03:19,960 --> 00:03:23,600
And I know that because in Postgres community, whenever pg_dump

76
00:03:24,720 --> 00:03:28,260
topic opens up, somebody will say, you know, pg_dump is not a

77
00:03:28,260 --> 00:03:29,200
backup tool.

78
00:03:29,640 --> 00:03:32,780
But then actually a few days before this discussion happened,

79
00:03:32,920 --> 00:03:36,100
Peter Eisentraut committed a change, which will be in effect

80
00:03:36,100 --> 00:03:41,880
in PG18, that tries to remove the backup terminology and kind

81
00:03:41,880 --> 00:03:46,040
of converts to export so that people are not considering it as

82
00:03:46,040 --> 00:03:47,700
a backup tool in a way.

83
00:03:48,080 --> 00:03:51,880
So this, I think, made people to be more vocal, saying that,

84
00:03:51,880 --> 00:03:55,640
look, this was how it was before, but not anymore, and you should

85
00:03:55,640 --> 00:03:56,980
not say it.

86
00:03:57,380 --> 00:04:00,260
And then I had to write another, I mean, I felt like I should

87
00:04:00,260 --> 00:04:04,940
write something more about it to explain why and why not we cannot

88
00:04:04,940 --> 00:04:07,480
consider pg_dump backup or not.

89
00:04:07,900 --> 00:04:12,100
And in my opinion, it is a tool that can be used to backup a

90
00:04:12,100 --> 00:04:12,600
database.

91
00:04:13,520 --> 00:04:16,880
And it is a logical way of doing a backup.

92
00:04:16,880 --> 00:04:18,180
You can call it a dump.

93
00:04:18,180 --> 00:04:21,980
Maybe you can define, you know, Nikolay was saying is it backup

94
00:04:21,980 --> 00:04:24,260
tool or yes, no, or define backup.

95
00:04:24,400 --> 00:04:25,840
So it can be a backup.

96
00:04:25,840 --> 00:04:29,060
In your case, when I was like working as a DBA for a long time,

97
00:04:29,060 --> 00:04:31,120
I was using it to backup databases.

98
00:04:31,160 --> 00:04:35,260
Depends basically the context of how you use it and the nuances

99
00:04:35,500 --> 00:04:37,780
that you can actually utilize this tool.

100
00:04:37,860 --> 00:04:39,720
So yeah, that's where I stand today.

101
00:04:39,720 --> 00:04:42,180
I don't agree that it is not a backup tool.

102
00:04:42,180 --> 00:04:46,100
It can be a backup tool, but there are maybe later on in the

103
00:04:46,100 --> 00:04:49,180
discussion we can discuss what are the drawbacks with it and

104
00:04:49,540 --> 00:04:52,960
how actually regular backup tools that are out of Postgres can

105
00:04:52,960 --> 00:04:55,540
help like pgBackRest or something.

106
00:04:56,040 --> 00:04:58,160
Nikolay: Can I jump straight away with a question?

107
00:04:58,480 --> 00:04:59,240
Gülçin: Yeah, please.

108
00:05:01,460 --> 00:05:06,380
Nikolay: Yeah, I saw also comments that it's maybe for very large

109
00:05:06,380 --> 00:05:10,320
databases like many terabytes and more it's not a good tool,

110
00:05:10,320 --> 00:05:13,420
backup tool, but at least for small databases it's good and also

111
00:05:13,420 --> 00:05:16,060
partial, you can export only 1 table.

112
00:05:17,240 --> 00:05:20,200
Imagine we have a tiny database, just like, I don't know, like

113
00:05:20,200 --> 00:05:21,800
100 rows, 1 table.

114
00:05:22,360 --> 00:05:27,880
And I SELECT * from this table in psql and just make a picture

115
00:05:27,880 --> 00:05:28,820
on my iPhone.

116
00:05:29,060 --> 00:05:32,940
This is a backup, this picture we can restore from it right

117
00:05:34,000 --> 00:05:37,620
Gülçin: Well maybe it's a snapshot right yeah why not well

118
00:05:37,620 --> 00:05:39,360
Nikolay: dump is also snapshot right

119
00:05:40,680 --> 00:05:43,740
Gülçin: yeah and that I don't really see like why it can't be

120
00:05:43,740 --> 00:05:44,560
called backup

121
00:05:45,140 --> 00:05:45,520
Nikolay: okay It

122
00:05:45,520 --> 00:05:49,280
Gülçin: is a moment and you can use that moment to do something

123
00:05:49,280 --> 00:05:49,980
with it.

124
00:05:50,580 --> 00:05:52,900
Michael: I thought it was a really good blog post Gülçin, I'll

125
00:05:52,900 --> 00:05:55,680
share it in the show notes as well for anybody that hasn't seen

126
00:05:55,680 --> 00:05:56,180
it.

127
00:05:56,200 --> 00:05:59,540
And speaking of good blog posts on the topic, I think Robert

128
00:05:59,540 --> 00:06:01,160
added a lot of good points as well.

129
00:06:01,160 --> 00:06:04,440
Both of your first blog posts included a lot of technical details

130
00:06:04,440 --> 00:06:08,760
like the technical aspects of why it technically could be considered

131
00:06:08,760 --> 00:06:12,740
a backup tool but also the drawbacks the many drawbacks of it

132
00:06:12,740 --> 00:06:16,640
and why you might recommend for a general purpose backup tool

133
00:06:16,640 --> 00:06:17,820
using something else.

134
00:06:17,980 --> 00:06:20,040
So Robert, how about yourself?

135
00:06:20,280 --> 00:06:22,860
How would you summarize your high-level thoughts on the topic

136
00:06:22,900 --> 00:06:25,280
and why it was something you want, or maybe you didn't want to

137
00:06:25,280 --> 00:06:26,420
write about it either?

138
00:06:27,040 --> 00:06:30,740
Robert: Well I think it just kind of got under my skin because

139
00:06:31,260 --> 00:06:36,340
you know Gülçin's blog post was not the first time that I've

140
00:06:36,340 --> 00:06:41,920
heard people sort of using this pg_dump as not a backup to a line

141
00:06:41,920 --> 00:06:47,400
and to me that kind of came across as shouting at people without

142
00:06:47,640 --> 00:06:53,860
necessarily like giving you know a reasoning right you know The

143
00:06:53,860 --> 00:06:58,580
documentation said for literally 20 years that pg_dump could be

144
00:06:58,580 --> 00:07:01,560
used to make backups, or I don't remember exactly what the wording

145
00:07:01,560 --> 00:07:02,060
was.

146
00:07:02,480 --> 00:07:06,960
When I looked into the history in Git, I actually found that

147
00:07:06,960 --> 00:07:11,680
the language that it's been changed to now with exporting the

148
00:07:11,680 --> 00:07:16,800
database is very similar to the original language that was used

149
00:07:16,800 --> 00:07:21,680
to describe pg_dump when that code was first added to PostgreSQL,

150
00:07:22,120 --> 00:07:26,700
but there was a 2 decade period
in the middle when the documentation

151
00:07:27,140 --> 00:07:30,140
said, hey, you can use this to
take backups.

152
00:07:30,300 --> 00:07:35,780
And from my point of view, it doesn't
even matter whether that's

153
00:07:36,180 --> 00:07:38,940
true or whether you think that's
true.

154
00:07:39,120 --> 00:07:47,140
If the documentation said for 2
decades that X piece of software

155
00:07:47,160 --> 00:07:51,900
could be used to do Y, then nobody
should get in trouble for

156
00:07:51,900 --> 00:07:52,940
saying that.

157
00:07:53,000 --> 00:07:57,320
Like, nobody should get called
out for saying that.

158
00:07:57,340 --> 00:07:59,480
That just doesn't make any sense
to me.

159
00:07:59,480 --> 00:08:05,200
Like, I mean, honestly, I think,
you know, we, some of us, self-included

160
00:08:05,820 --> 00:08:10,020
can be a little too eager to jump
on people's case from time

161
00:08:10,020 --> 00:08:10,640
to time.

162
00:08:10,640 --> 00:08:15,040
And I don't think that's like good
for our community.

163
00:08:15,140 --> 00:08:19,740
I think we wanna be the kind of
community where when people show

164
00:08:19,740 --> 00:08:23,000
up we give them help, we give them
good advice, and we don't

165
00:08:23,000 --> 00:08:25,020
come down on them like a ton of
bricks.

166
00:08:25,320 --> 00:08:29,540
And Gülçin is not the only person
I've seen who seemed to me

167
00:08:29,540 --> 00:08:31,680
to be kind of getting beaten up
a little bit.

168
00:08:31,680 --> 00:08:34,400
And I was just like, why are we
doing this?

169
00:08:34,400 --> 00:08:38,600
Like, clearly, pg_dump isn't right
for every purpose.

170
00:08:38,600 --> 00:08:41,480
And there are lots of situations
where it's probably not what

171
00:08:41,480 --> 00:08:41,940
you want.

172
00:08:41,940 --> 00:08:46,000
But I just the tone is baffling
to me, because it seemed very

173
00:08:46,000 --> 00:08:50,940
hostile to me and I couldn't make
any sense of really why we

174
00:08:50,940 --> 00:08:53,480
should be that hostile about anything,
but especially why we

175
00:08:53,480 --> 00:08:55,680
should be so hostile about that
in particular.

176
00:08:57,740 --> 00:09:00,480
Gülçin: And to that I actually
have something to add, because

177
00:09:00,480 --> 00:09:04,540
after this discussion started to
come up again, and I was looking

178
00:09:04,540 --> 00:09:07,700
at the groups like where people
are actually using this, like

179
00:09:07,900 --> 00:09:09,560
it's not a backup tool rhetoric.

180
00:09:09,940 --> 00:09:13,340
And I seen like few users that
are trying to get help from this

181
00:09:13,340 --> 00:09:16,440
Postgres communities that we have
online, a lot of them.

182
00:09:16,460 --> 00:09:19,240
And there was like, I noted 2 of
them for today.

183
00:09:19,340 --> 00:09:22,700
1 of them is asking, pg_dump can
limit a backup by schema.

184
00:09:22,700 --> 00:09:26,780
I mean, it's like using this sentence
and there's somebody answering

185
00:09:26,780 --> 00:09:27,280
directly.

186
00:09:27,340 --> 00:09:31,160
It's not related there, but pg_dump
is not a backup.

187
00:09:31,560 --> 00:09:34,760
And then there's another user,
can someone send me the command

188
00:09:34,760 --> 00:09:36,540
to take backup of partial Database?

189
00:09:36,740 --> 00:09:38,900
Which actually pg_dump can, right?

190
00:09:39,140 --> 00:09:42,820
We can do the Schema only, we can
do just the Data, whatever,

191
00:09:42,900 --> 00:09:45,540
or we can do a Table, any type
of Object.

192
00:09:45,840 --> 00:09:48,160
And then answer is like, there
is no such command.

193
00:09:48,160 --> 00:09:51,220
The standard backup tools take
backups of the entire Database

194
00:09:51,220 --> 00:09:51,720
cluster.

195
00:09:52,220 --> 00:09:56,780
So basically, it doesn't consider
it as a backup tool, even though

196
00:09:56,780 --> 00:09:59,620
there is a pg_dump command that
can actually do what people are

197
00:09:59,620 --> 00:10:00,120
asking.

198
00:10:00,140 --> 00:10:04,400
So that's what I find very not
helpful, right?

199
00:10:04,400 --> 00:10:07,720
We could just say to people, look,
this is this pg_dump command

200
00:10:07,720 --> 00:10:10,240
that you can actually take this table that you want to take,

201
00:10:10,240 --> 00:10:13,040
or selective restore, whatever you want to do with it, and help

202
00:10:13,040 --> 00:10:16,400
people to the direction that they're actually trying to get there.

203
00:10:16,740 --> 00:10:19,200
Instead, just saying, there is no such a command.

204
00:10:19,200 --> 00:10:22,580
It's not a backup tool anyway, because the standard backup tools

205
00:10:22,580 --> 00:10:24,180
takes the entire database cluster.

206
00:10:24,180 --> 00:10:27,340
So that I don't find helpful, is what Robert is saying.

207
00:10:27,340 --> 00:10:28,580
That is not helpful at all.

208
00:10:28,580 --> 00:10:31,800
You might not agree that it's a good tool for using it as a backup

209
00:10:31,800 --> 00:10:35,280
solution and which we can talk where it could be improved or

210
00:10:35,280 --> 00:10:37,980
why actually people should prefer backup solutions.

211
00:10:38,520 --> 00:10:39,720
But this is still not helpful.

212
00:10:39,720 --> 00:10:42,700
There's a tool that we were all using for a long time and it

213
00:10:42,700 --> 00:10:44,940
can does all the things that these people were asking.

214
00:10:45,120 --> 00:10:48,780
So nuance of the question matters, the context of it.

215
00:10:49,280 --> 00:10:50,900
And that's where I am, basically.

216
00:10:51,780 --> 00:10:55,580
Robert: And you know, if somebody asks about how to use pg_dump,

217
00:10:55,900 --> 00:10:59,340
and you want to tell them, hey, here's how to do that thing with

218
00:10:59,340 --> 00:11:02,300
pg_dump, but maybe you want to consider some other alternatives

219
00:11:02,480 --> 00:11:02,980
instead.

220
00:11:03,340 --> 00:11:05,380
Cool, like I got no problem with that.

221
00:11:05,380 --> 00:11:07,160
That can be helpful advice.

222
00:11:07,640 --> 00:11:11,580
But like pretending that the thing that they're asking about

223
00:11:11,580 --> 00:11:16,960
doesn't exist when it does, that I just don't understand that

224
00:11:16,960 --> 00:11:17,620
at all.

225
00:11:18,980 --> 00:11:21,860
Michael: So yeah, I've definitely got some theories as to why

226
00:11:21,860 --> 00:11:25,120
people are behaving and speaking like that.

227
00:11:25,140 --> 00:11:25,460
But I

228
00:11:25,460 --> 00:11:26,180
Nikolay: do think...

229
00:11:26,200 --> 00:11:28,520
1 of such people is just here.

230
00:11:28,520 --> 00:11:31,320
I can speak to him if you want.

231
00:11:31,620 --> 00:11:33,800
Michael: I wanted to, yeah, I wanted to, I think you've got some

232
00:11:33,800 --> 00:11:37,020
really good language around this Nikolay around logical backups

233
00:11:37,020 --> 00:11:40,480
and physical backups that really helps clarify and I think if

234
00:11:40,480 --> 00:11:44,560
people use that language in those sentences it would immediately

235
00:11:44,860 --> 00:11:49,120
help with clarity and also limitations but I'd love to hear your

236
00:11:49,120 --> 00:11:52,440
like high-level thoughts on topic as well and and yeah why is

237
00:11:52,440 --> 00:11:53,540
something you say

238
00:11:54,800 --> 00:11:58,760
Nikolay: so this statement is a dump is not about the capital

239
00:11:59,100 --> 00:12:05,280
is reaction to the statement documentation had 20 years And we

240
00:12:05,280 --> 00:12:10,760
saw so many disastrous situations in many companies who Tried

241
00:12:10,760 --> 00:12:15,660
to rely on this as backup tool while growing So we did like actually

242
00:12:15,660 --> 00:12:17,320
it was not my statement, right?

243
00:12:17,320 --> 00:12:19,040
I just picked it, right?

244
00:12:19,540 --> 00:12:21,820
I think Franck Pachot also mentioned it.

245
00:12:21,820 --> 00:12:26,760
I'm not sure he was the first who reacted to the Gilson's article.

246
00:12:27,580 --> 00:12:31,280
But I joined as well, and I'm sure in many, not only Discord

247
00:12:31,380 --> 00:12:35,860
or Slack or IRC, anywhere many people are picking up this motto

248
00:12:35,860 --> 00:12:40,460
because it's painful to observe how many companies relied on

249
00:12:40,460 --> 00:12:43,780
pg_dump as dumps as backups, right?

250
00:12:43,820 --> 00:12:47,860
If we call dumps And considering
backups, okay, we can do that,

251
00:12:47,860 --> 00:12:48,980
but there are limitations.

252
00:12:49,300 --> 00:12:51,660
There is big power in this, not
only partial.

253
00:12:52,440 --> 00:12:54,840
You can take specific Tables.

254
00:12:55,760 --> 00:12:59,540
These days we have many managed
Postgres offerings and they don't

255
00:12:59,540 --> 00:13:00,980
share backups with us.

256
00:13:02,020 --> 00:13:06,240
If you want multi-cloud backup,
you must use pg_dump.

257
00:13:06,340 --> 00:13:10,800
You cannot get data or copy or
something.

258
00:13:10,800 --> 00:13:15,200
You cannot get physical backups
out of RDS, for example, right?

259
00:13:15,360 --> 00:13:20,700
But this pain observed for a couple
of decades caused me like

260
00:13:20,860 --> 00:13:26,540
joining this Movement saying that
pg_dump is not a backup tool.

261
00:13:26,880 --> 00:13:31,240
At the same time, there is a like
I told Michael there is like

262
00:13:31,240 --> 00:13:36,300
it's There is like a kind of professional
shift in my mind here.

263
00:13:36,380 --> 00:13:40,600
Because when somebody says backups,
I envision only physical

264
00:13:40,600 --> 00:13:41,060
backups.

265
00:13:41,060 --> 00:13:43,380
Although there are logical backups,
of course.

266
00:13:43,380 --> 00:13:47,380
And again, this is not my idea
to introduce this language.

267
00:13:47,380 --> 00:13:50,700
I checked it in Oracle and MySQL
documentation.

268
00:13:51,500 --> 00:13:55,740
I think maybe it's a good idea
to borrow this concept and mention

269
00:13:56,200 --> 00:13:57,180
specifically SQL.

270
00:13:57,180 --> 00:13:59,840
There are 2 kinds of backups, physical
and logical.

271
00:14:01,420 --> 00:14:03,640
They all have pros and cons.

272
00:14:04,120 --> 00:14:08,860
For example, logical backup, If
you rely on pg_dump as a backup

273
00:14:08,860 --> 00:14:14,200
tool, like for example, partial
and escaping from RDS, it's good

274
00:14:14,680 --> 00:14:15,580
pros, right?

275
00:14:15,780 --> 00:14:19,020
Speaking of cons, it's always like
kind of snapshot.

276
00:14:19,640 --> 00:14:23,740
It puts pressure on your Database
in terms of xmin horizon, affecting

277
00:14:23,740 --> 00:14:27,660
autovacuum behavior, which is
unacceptable if you have 10 plus

278
00:14:27,660 --> 00:14:29,760
terabytes and heavy load.

279
00:14:30,160 --> 00:14:34,340
Also, at 1 day, some bug or corruption
might happen, and you

280
00:14:34,340 --> 00:14:37,860
simply cannot read your data at
logical level.

281
00:14:39,100 --> 00:14:42,480
While physical backups are not
affected.

282
00:14:42,660 --> 00:14:44,600
They just copy files, right?

283
00:14:45,060 --> 00:14:49,040
And like, there are many pros and
cons to compare, right?

284
00:14:49,040 --> 00:14:53,640
And I like the idea to split language
between logical and physical.

285
00:14:54,180 --> 00:14:58,780
And for me personally, when somebody
says backups without specification,

286
00:14:59,620 --> 00:15:02,340
I still see by default physical
only.

287
00:15:03,320 --> 00:15:03,820
Right.

288
00:15:04,020 --> 00:15:06,760
Gülçin: If we are considering the
corruption, the logical backups,

289
00:15:06,760 --> 00:15:09,520
the corruption can be also in the
physical level.

290
00:15:09,520 --> 00:15:10,020
Nikolay: Right.

291
00:15:10,240 --> 00:15:13,620
I'm okay with that, but I have
backup, I can restore and deal

292
00:15:13,620 --> 00:15:14,540
with it, right?

293
00:15:15,260 --> 00:15:19,460
Gülçin: Well, then actually you
can maybe keep this corruption

294
00:15:19,780 --> 00:15:22,760
between your physical backups if
you didn't notice, if it's gone

295
00:15:22,760 --> 00:15:23,260
unnoticed.

296
00:15:24,280 --> 00:15:27,040
And then if you had the logical
backup on top of it, maybe, you

297
00:15:27,040 --> 00:15:30,220
know, it could be another tool
to fight this physical corruption

298
00:15:30,220 --> 00:15:30,880
that you have.

299
00:15:30,880 --> 00:15:33,840
Nikolay: Yeah, what I'm trying
to say, if I have physical backups

300
00:15:33,920 --> 00:15:36,380
with corruption, I will deal with
it and so on.

301
00:15:36,380 --> 00:15:40,080
But if I have corruption which
prevents pg_dump from reading data,

302
00:15:40,080 --> 00:15:42,320
it will just fail and I don't have
anything.

303
00:15:43,040 --> 00:15:46,080
Robert: Yeah, so I'd just like
to make a couple of comments here.

304
00:15:46,080 --> 00:15:49,540
I think 1 of the things that I
find really interesting is that

305
00:15:49,540 --> 00:15:52,720
people who work for different companies
that all support and

306
00:15:52,720 --> 00:15:57,540
use Postgres can have very different
experiences of some of this

307
00:15:57,540 --> 00:15:57,720
stuff.

308
00:15:57,720 --> 00:16:00,480
And I've seen that before with
other issues and I'm seeing it

309
00:16:00,480 --> 00:16:01,300
here too.

310
00:16:01,500 --> 00:16:08,860
Because my typical experience with
pg_dump is not the 1 that you

311
00:16:08,860 --> 00:16:10,380
were describing at all.

312
00:16:10,380 --> 00:16:15,480
In fact, since I've worked at EDB,
which is the whole of my professional

313
00:16:15,800 --> 00:16:20,420
Postgres career, I've never had
that situation happen.

314
00:16:20,420 --> 00:16:25,380
Like not once have I run into a
situation where a customer should

315
00:16:25,380 --> 00:16:28,620
have been using something other
than pg_dump and they were just

316
00:16:28,620 --> 00:16:31,720
using pg_dump and then they got
into trouble.

317
00:16:31,920 --> 00:16:37,160
What happens to me rather frequently
is that someone has used

318
00:16:37,200 --> 00:16:42,100
some other kind of backup and things
have gone really badly wrong

319
00:16:42,100 --> 00:16:47,560
for some reason and pg_dump becomes
the way that we can help that

320
00:16:47,560 --> 00:16:50,180
customer to get out from under
that problem.

321
00:16:50,320 --> 00:16:54,840
So just as your experience with
the customers that you've worked

322
00:16:54,840 --> 00:16:58,040
with is informing the way that
you view the issue.

323
00:16:58,140 --> 00:17:01,480
I have a different set of experiences,
a very different set of

324
00:17:01,480 --> 00:17:03,680
experiences from what it sounds
like.

325
00:17:03,680 --> 00:17:08,340
And so this thing that to you feels
like, ah, this is the catastrophe.

326
00:17:08,680 --> 00:17:10,620
We've got to steer clear of this.

327
00:17:10,760 --> 00:17:14,020
In my experience, that's never
the problem.

328
00:17:14,040 --> 00:17:17,320
It's always the thing we reach
for to get out from under the

329
00:17:17,320 --> 00:17:17,800
problem.

330
00:17:17,800 --> 00:17:21,380
And I really just want to highlight
that because I'm not saying

331
00:17:21,380 --> 00:17:25,280
your experience isn't valid and
I hope you'll return the same

332
00:17:25,280 --> 00:17:25,780
courtesy.

333
00:17:26,980 --> 00:17:30,540
Gülçin: I actually understand partially
what Nikolay is trying

334
00:17:30,540 --> 00:17:34,000
to say here because I was before
EDB, before working with Robert,

335
00:17:34,000 --> 00:17:36,960
I was working for Second Quadrant
and we were building our own

336
00:17:36,960 --> 00:17:38,400
backup solution, Barman.

337
00:17:39,000 --> 00:17:40,740
Nikolay: And
now it's EDB owns it.

338
00:17:40,760 --> 00:17:44,880
And then I know, because I was
actually doing remote DBA work

339
00:17:45,040 --> 00:17:47,380
And there was a lot of customers
with backup issues.

340
00:17:47,520 --> 00:17:49,500
They had their own home cook scripts.

341
00:17:49,940 --> 00:17:52,920
In the wrong hands, this can go
wrong, because there are some

342
00:17:52,920 --> 00:17:56,400
things that pg_dump and restore,
you have to know about it.

343
00:17:56,400 --> 00:17:57,940
How do you do the dump process?

344
00:17:57,940 --> 00:17:58,860
How do you do restore?

345
00:17:58,860 --> 00:18:00,560
Do you actually test these things?

346
00:18:00,780 --> 00:18:05,740
Do you copy the whole directory
or do you consider it as just

347
00:18:05,740 --> 00:18:08,680
some logs that we can actually
delete at some point and so on?

348
00:18:08,680 --> 00:18:12,440
So if people don't know how to
maybe put these things together

349
00:18:12,440 --> 00:18:16,320
in a way, it is not really helpful
for some people, then things

350
00:18:16,320 --> 00:18:17,040
can go wrong.

351
00:18:17,040 --> 00:18:19,380
And I seen that things actually
went wrong.

352
00:18:19,740 --> 00:18:22,540
That's why we were steering people,
you know, if you just do

353
00:18:22,540 --> 00:18:26,440
regular backups and restores, use
this tool that we have or any

354
00:18:26,440 --> 00:18:30,680
other tool that can be used for
backups and you can keep the

355
00:18:30,680 --> 00:18:34,460
retention period, you can keep
your backups for X days, you can

356
00:18:34,460 --> 00:18:37,200
restore them and test and you can
have continuous backups that

357
00:18:37,200 --> 00:18:37,700
edit.

358
00:18:37,840 --> 00:18:41,480
So it's not like partial, you know,
it can be just like a continuous

359
00:18:41,480 --> 00:18:43,860
thing that you don't need to worry
and you can do point in time

360
00:18:43,860 --> 00:18:45,480
recovery and so on and so on.

361
00:18:45,480 --> 00:18:49,300
So I understand this rhetoric and
I was the advocacy of it, but

362
00:18:49,300 --> 00:18:53,360
then I also feel like it went too
far saying, you know, this

363
00:18:53,360 --> 00:18:57,420
is not, this is not usable and
that I, I oppose basically.

364
00:18:57,440 --> 00:18:58,540
Nikolay: Yeah.
It's like pendulum.

365
00:18:58,780 --> 00:18:59,360
I agree.

366
00:19:00,400 --> 00:19:00,420
Yeah.

367
00:19:00,420 --> 00:19:04,280
The start of this pendulum is these
20 years of documentation.

368
00:19:04,900 --> 00:19:08,200
So you raised a very good point
about restore.

369
00:19:09,340 --> 00:19:13,080
When I hear backup, full-fledged
backup, it's not only physical

370
00:19:13,080 --> 00:19:15,140
to me, it's also verified.

371
00:19:16,420 --> 00:19:20,700
And if we have physical backup
which we test, that's great.

372
00:19:21,280 --> 00:19:25,520
While with dumps, I'm very curious,
while Robert, you didn't

373
00:19:25,520 --> 00:19:30,860
see an ability of pg_dump to read
some, I don't know, some database

374
00:19:30,860 --> 00:19:34,900
which is corrupted and we cannot
get dump out of it.

375
00:19:34,900 --> 00:19:37,520
But second question like here.

376
00:19:38,720 --> 00:19:39,220
Okay.

377
00:19:39,520 --> 00:19:41,620
Robert: That actually happens all
the time.

378
00:19:41,840 --> 00:19:48,480
And one of the things that I often
end up helping people do is

379
00:19:48,700 --> 00:19:53,300
fixing the database enough that
we can use pg_dump to get the

380
00:19:53,300 --> 00:19:54,440
data out of it.

381
00:19:54,520 --> 00:20:00,100
Because if the database has incurred
a lot of damage at a physical

382
00:20:00,100 --> 00:20:04,000
level for some reason, we're never
going to be able to repair

383
00:20:04,000 --> 00:20:09,000
that well enough to give confidence
that everything is the way

384
00:20:09,000 --> 00:20:10,120
that it should be.

385
00:20:10,680 --> 00:20:15,560
So a dump and restore in my professional
opinion is absolutely

386
00:20:16,320 --> 00:20:20,140
essential in that situation to
get back to a clean state.

387
00:20:20,200 --> 00:20:25,520
Now you are 100% correct that the
dump may also fail or the restore

388
00:20:25,520 --> 00:20:29,320
may also fail, but those are problems
that we can understand

389
00:20:29,440 --> 00:20:30,140
and fix.

390
00:20:30,480 --> 00:20:35,060
We can look and say, ah, well you
have a pg_class entry, but

391
00:20:35,060 --> 00:20:39,280
you're missing a pg_index entry,
so we need to create the one or

392
00:20:39,280 --> 00:20:40,380
delete the other.

393
00:20:40,460 --> 00:20:44,480
That's a problem where we can say,
ah-ha, that's something that

394
00:20:44,480 --> 00:20:48,900
we as Postgres experts can look
into and understand what needs

395
00:20:48,900 --> 00:20:52,160
to be done to bring this back to
a state where pg_dump is going

396
00:20:52,160 --> 00:20:52,860
to run.

397
00:20:53,000 --> 00:20:56,480
But the blocks being messed up
at a physical level or out of

398
00:20:56,480 --> 00:20:59,340
sync with each other because we've
had some time travel of some

399
00:20:59,340 --> 00:21:02,600
kind or something like that, Those
are problems we won't be able

400
00:21:02,600 --> 00:21:05,200
to get out from under that ever.

401
00:21:05,400 --> 00:21:06,400
Does that make sense?

402
00:21:06,400 --> 00:21:07,800
Nikolay: Yeah, it makes total sense.

403
00:21:07,800 --> 00:21:15,040
And moreover, it's a very popular
approach to use pg_dump to test

404
00:21:15,060 --> 00:21:21,160
physical backups to see that we
can read all except indexes.

405
00:21:21,300 --> 00:21:24,960
For indexes, we use amcheck,
but to test physical backups,

406
00:21:24,960 --> 00:21:29,220
we use pg_dump to /dev/null, for example,
just to see that there

407
00:21:29,220 --> 00:21:33,140
is no corruption, like We can read
it for sure.

408
00:21:34,300 --> 00:21:36,260
And the second, like you mentioned
restore.

409
00:21:36,600 --> 00:21:40,840
I remember a couple of times I
saw a dump could not be restored

410
00:21:40,840 --> 00:21:43,820
because of a unique key violation,
right?

411
00:21:43,820 --> 00:21:47,620
Because of corruption of uniqueness
constraint.

412
00:21:48,180 --> 00:21:51,740
Because some duplicates happened
and unique key didn't save us

413
00:21:51,740 --> 00:21:53,240
due to some bugs or something.

414
00:21:53,300 --> 00:21:55,940
Maybe somebody disabled something,
I don't know.

415
00:21:56,200 --> 00:21:58,260
Or foreign keys, foreign keys as
well.

416
00:21:58,260 --> 00:22:02,360
If you disable triggers, you can
corrupt your data easily, right?

417
00:22:02,540 --> 00:22:05,780
You disable triggers, you load
something and you enable triggers

418
00:22:06,040 --> 00:22:07,580
and Postgres won't check it.

419
00:22:07,800 --> 00:22:11,580
And during pg_dump, pg_dump you can
have, but you cannot restore

420
00:22:11,580 --> 00:22:12,260
from it.

421
00:22:12,600 --> 00:22:13,100
Right?

422
00:22:13,260 --> 00:22:17,280
So yeah, we see some mutual points
definitely here.

423
00:22:18,100 --> 00:22:20,500
And the question is just about
language I guess.

424
00:22:20,640 --> 00:22:21,360
That's it.

425
00:22:21,660 --> 00:22:24,440
Michael: Well I think it's also
about experience Nikolay, you

426
00:22:24,440 --> 00:22:28,380
mentioned some disasters, is it
my right and understanding this

427
00:22:28,380 --> 00:22:33,280
is folks who have come to you with
some issue and they've only...

428
00:22:33,420 --> 00:22:36,700
It's not just that they're using
pg_dump as a backup tool, it's

429
00:22:36,700 --> 00:22:38,180
their only form of backup.

430
00:22:38,520 --> 00:22:40,820
And what kind of issues is that
causing?

431
00:22:40,840 --> 00:22:44,060
Nikolay: Remember the first managed
service, managed Postgres

432
00:22:44,060 --> 00:22:46,360
service created, popular at least.

433
00:22:46,680 --> 00:22:47,940
It was called Heroku.

434
00:22:48,120 --> 00:22:52,200
I think it still exists, but not
being actively developed these

435
00:22:52,200 --> 00:22:52,700
days.

436
00:22:52,920 --> 00:22:55,220
And they offer backups as dumps.

437
00:22:55,360 --> 00:22:56,520
You can download them.

438
00:22:56,520 --> 00:22:57,680
That's great actually.

439
00:22:58,820 --> 00:23:03,580
If a managed service, Postgres service
provider allows you to download

440
00:23:03,820 --> 00:23:05,100
backups, that's great.

441
00:23:05,500 --> 00:23:06,720
But it was just backups.

442
00:23:07,720 --> 00:23:09,480
And nobody does this.

443
00:23:09,480 --> 00:23:13,220
I mean, nobody among very popular
managed Postgres providers

444
00:23:13,220 --> 00:23:13,880
do this.

445
00:23:14,020 --> 00:23:16,500
They rely on physical backups these
days, right?

446
00:23:16,500 --> 00:23:18,480
And also on snapshots and so on.

447
00:23:18,480 --> 00:23:20,940
I mean, cloud snapshots, full disk
snapshots.

448
00:23:22,280 --> 00:23:29,020
And this also shows evolution of
backup concept in many people's

449
00:23:29,440 --> 00:23:31,260
minds, Not only us.

450
00:23:32,220 --> 00:23:37,160
So I think it would be great just
to agree on the language and

451
00:23:37,200 --> 00:23:37,700
discuss.

452
00:23:38,160 --> 00:23:43,060
I'm okay to be alone thinking that
backup is just physical backup.

453
00:23:43,060 --> 00:23:46,400
Backup could include both logical
and physical, and we could

454
00:23:46,400 --> 00:23:50,420
clarify documentation and language
articles and so on.

455
00:23:51,500 --> 00:23:53,000
And I see it's a pendulum, right?

456
00:23:53,000 --> 00:23:54,560
Again, this is my point.

457
00:23:55,640 --> 00:23:59,160
Too long documentation was claiming
this is a backup tool.

458
00:23:59,680 --> 00:24:01,240
This language was super harsh.

459
00:24:02,940 --> 00:24:06,820
And I remember I was trying to
explain at least a couple of times

460
00:24:06,820 --> 00:24:11,120
in my life, I was trying to explain
to some customers with growing

461
00:24:11,120 --> 00:24:15,340
Postgres databases, exceeding terabytes
and approaching 10 terabytes.

462
00:24:15,460 --> 00:24:20,460
I'm saying, don't rely on pg_dump
as a backup solution And they

463
00:24:20,460 --> 00:24:23,460
just showed me documentation saying,
this is like, this is what

464
00:24:23,460 --> 00:24:24,180
they say.

465
00:24:24,580 --> 00:24:26,180
Vendor is saying this, right?

466
00:24:26,820 --> 00:24:27,127
Robert: Yeah.

467
00:24:27,127 --> 00:24:33,340
I mean, I think that there is a,
maybe a difference between something

468
00:24:33,340 --> 00:24:35,860
that creates a backup and a backup
tool.

469
00:24:35,940 --> 00:24:39,240
I mean, this does get down a little
bit to what you think words

470
00:24:39,240 --> 00:24:43,580
mean, so it almost seems like a
silly thing to argue about, right?

471
00:24:43,580 --> 00:24:46,960
But I think, you know, you asked
Gotcha at the beginning, like,

472
00:24:46,960 --> 00:24:51,680
if I take a snapshot of all of
my data on a cell phone, is that

473
00:24:51,680 --> 00:24:52,380
a backup?

474
00:24:52,660 --> 00:24:57,380
And I think the answer is obviously
yes, but equally obviously,

475
00:24:57,600 --> 00:25:00,980
that's a silly way to do a backup
because your restore procedure

476
00:25:01,220 --> 00:25:05,400
is going to be very unpleasant,
which is not what you want.

477
00:25:07,540 --> 00:25:11,520
I think sometimes when people talk
about a backup or a tool that

478
00:25:11,520 --> 00:25:15,360
can take a backup or a backup tool,
sometimes they mean like,

479
00:25:15,360 --> 00:25:20,100
can I get a copy of my data from
which I could recover?

480
00:25:20,560 --> 00:25:22,260
Right, and that's 1 question.

481
00:25:22,660 --> 00:25:25,100
And pg_dump will give you that,
right?

482
00:25:25,600 --> 00:25:29,820
The other question, sometimes what
people mean is, they mean,

483
00:25:29,820 --> 00:25:33,940
is this like, and they may have
some particular commercial product

484
00:25:33,940 --> 00:25:37,180
in mind that offers a certain feature
set and their question

485
00:25:37,180 --> 00:25:41,340
is am I going to get this feature
set where for example my retention

486
00:25:41,380 --> 00:25:46,220
times will be managed and my my
actual process of orchestrating

487
00:25:46,500 --> 00:25:50,420
the backup and orchestrating the
recovery will be managed.

488
00:25:50,820 --> 00:25:54,840
And then the answer is no, pg_dump
is not going to do that for

489
00:25:54,840 --> 00:25:55,040
you.

490
00:25:55,040 --> 00:25:58,400
And you probably do want those
things in most cases.

491
00:25:58,520 --> 00:26:02,700
So I don't know, like, I think
there's a lot of nuance that's

492
00:26:02,720 --> 00:26:04,600
possible in the language here.

493
00:26:04,600 --> 00:26:08,160
But for me, the important thing
is to make sure that we're clearly

494
00:26:08,680 --> 00:26:12,100
able to explain what the benefits
and drawbacks of the different

495
00:26:12,100 --> 00:26:16,520
approaches are rather than, you
know, spending too much time

496
00:26:16,780 --> 00:26:20,140
fighting about the specific language,
which for me, it gets a

497
00:26:20,140 --> 00:26:21,000
little bit silly.

498
00:26:21,560 --> 00:26:22,260
Nikolay: I agree.

499
00:26:22,360 --> 00:26:22,860
Yeah.

500
00:26:23,160 --> 00:26:24,440
Michael: I agree as well, Robert.

501
00:26:24,520 --> 00:26:29,220
In your blog post, you make a really
good case for the tone of

502
00:26:29,220 --> 00:26:32,440
the statement being difficult,
and I think you actually use some

503
00:26:32,440 --> 00:26:36,380
language that is that like waters
it down a little bit or explains

504
00:26:36,380 --> 00:26:39,140
a little bit more it doesn't take
many more extra words to do

505
00:26:39,140 --> 00:26:42,500
so but I also wanted to ask do
you see this problem in other

506
00:26:42,500 --> 00:26:44,760
statements in the Postgres community
like are there other things

507
00:26:44,760 --> 00:26:47,440
people are saying that remind you
of the tone of this kind of

508
00:26:47,440 --> 00:26:48,540
statement as well?

509
00:26:49,020 --> 00:26:52,840
Robert: I don't have specific examples
in mind off the top of

510
00:26:52,840 --> 00:26:54,620
my head, but definitely yes.

511
00:26:54,620 --> 00:26:57,460
I mean, it's a chronic problem
on Hackers.

512
00:26:58,080 --> 00:27:01,840
You know, I think I wrote a blog
post about the sort of tone

513
00:27:01,840 --> 00:27:06,000
of dialogue in the Postgres community
towards the end of last

514
00:27:06,000 --> 00:27:06,380
year.

515
00:27:06,380 --> 00:27:10,320
And it's always a problem because
when you post your patch on

516
00:27:10,320 --> 00:27:14,660
Postgres Hackers, you're essentially
soliciting review.

517
00:27:15,240 --> 00:27:18,640
And people are rarely going to
write you a review where they're

518
00:27:18,640 --> 00:27:22,480
like, you know what, this patch
is amazing and I love it.

519
00:27:22,480 --> 00:27:23,500
I mean, it happens.

520
00:27:23,540 --> 00:27:27,100
People actually do get those kinds
of reviews, and it's a great

521
00:27:27,100 --> 00:27:28,400
day when you do.

522
00:27:28,400 --> 00:27:32,560
But generally, when you're reviewing
a patch, you're picking

523
00:27:32,560 --> 00:27:38,140
something that you actually like
and would like to see go forward.

524
00:27:38,240 --> 00:27:41,580
And then you're saying the worst
things about it that you can

525
00:27:41,580 --> 00:27:42,640
think of to say.

526
00:27:42,640 --> 00:27:44,700
You're like, so here's all the
problems.

527
00:27:44,700 --> 00:27:48,040
Here's all of the stuff that I
think needs to be better in order

528
00:27:48,040 --> 00:27:51,100
for this to become part of the
product, which I hope it will,

529
00:27:51,100 --> 00:27:54,360
but these things are the things
that I think need to be fixed

530
00:27:54,400 --> 00:27:54,900
first.

531
00:27:55,260 --> 00:28:00,920
And so what I see is that actually
for a lot of committers, in

532
00:28:00,920 --> 00:28:05,440
particular, people's mental health
is not in a great place.

533
00:28:05,440 --> 00:28:09,220
You know, I kinda thought my mental
health was not in a great

534
00:28:09,220 --> 00:28:12,180
place around some of this stuff,
and then I talked to some other

535
00:28:12,180 --> 00:28:16,160
people and found that they were
feeling worse about it than I

536
00:28:16,160 --> 00:28:19,400
was feeling by like significant
margins.

537
00:28:19,540 --> 00:28:23,540
And it's, in my opinion, it's rarely
because of bad intent.

538
00:28:23,540 --> 00:28:26,460
I mean, obviously people get frustrated.

539
00:28:26,720 --> 00:28:29,240
People say things that they shouldn't
have said or they don't

540
00:28:29,240 --> 00:28:31,400
say it in the right way or they're
pissed off.

541
00:28:31,400 --> 00:28:34,640
I mean, those things happen and
I don't wanna pretend like they

542
00:28:34,640 --> 00:28:35,080
don't.

543
00:28:35,080 --> 00:28:40,760
But I think very, very often it's
a case of the nature of the

544
00:28:40,760 --> 00:28:44,700
workflow and the nature of the
process and the kind of engineering

545
00:28:45,040 --> 00:28:46,080
that we're doing.

546
00:28:46,740 --> 00:28:51,760
It's difficult and it's error prone
And even the absolute smartest

547
00:28:51,820 --> 00:28:55,080
people in the community make all
kinds of mistakes, you know,

548
00:28:55,080 --> 00:28:56,380
over and over again, right?

549
00:28:56,380 --> 00:29:00,920
Like we were doing a rewrap of
a scheduled minor release that

550
00:29:00,920 --> 00:29:01,880
happened last week.

551
00:29:01,880 --> 00:29:05,160
We're doing that this week because
somebody committed a fix for

552
00:29:05,160 --> 00:29:07,820
a bug and the fix contained another
bug.

553
00:29:07,820 --> 00:29:11,820
And it doesn't matter who made
the mistake or who didn't catch

554
00:29:11,820 --> 00:29:13,440
the mistake, that's not relevant.

555
00:29:13,520 --> 00:29:15,060
It happens all the time.

556
00:29:15,060 --> 00:29:18,600
And I think it's really challenging
to people because we work

557
00:29:18,600 --> 00:29:23,040
in a very open environment where
everybody sees every email we

558
00:29:23,040 --> 00:29:26,620
write, every patch we commit, every
patch we thought about committing.

559
00:29:26,680 --> 00:29:31,120
You know, it's out there constantly
and you just realize that

560
00:29:31,120 --> 00:29:34,480
there are so many ways for you
to screw up and every time you

561
00:29:34,480 --> 00:29:36,660
make a mistake, everybody sees
it.

562
00:29:36,660 --> 00:29:39,860
So I think it's a struggle for
everybody.

563
00:29:40,080 --> 00:29:44,620
As far as I can tell, every single
person who works on Hackers

564
00:29:45,300 --> 00:29:49,040
encounters this problem of getting
the tone right all the time.

565
00:29:49,280 --> 00:29:53,720
And I am certainly not going to
sit here and pretend like I get

566
00:29:53,720 --> 00:29:55,400
it right more often than average.

567
00:29:55,400 --> 00:29:59,500
I think a lot of people would say
I am below average in that

568
00:29:59,500 --> 00:30:04,240
way, but I can tell you I'm very
aware of the problem and I am

569
00:30:04,240 --> 00:30:09,000
trying to figure out how to do
it better because at the end of

570
00:30:09,000 --> 00:30:13,220
the day, it's not enough for us
to deliver great software.

571
00:30:13,640 --> 00:30:17,640
We need to deliver great software
while also creating a community

572
00:30:17,900 --> 00:30:19,860
that people want to participate
in.

573
00:30:19,860 --> 00:30:23,740
And that applies for me, first
of all, to the developer community

574
00:30:23,760 --> 00:30:27,940
because that's where I spent most
of my time, but it also I think

575
00:30:27,940 --> 00:30:30,600
applies more much more broadly
to the user community.

576
00:30:30,600 --> 00:30:34,080
And I think that is part of the
reason this issue set me off

577
00:30:34,080 --> 00:30:36,580
a little bit, because, you know,
it's the sort of thing that

578
00:30:36,580 --> 00:30:41,540
I'm struggling, often in vain,
to do right on a daily basis.

579
00:30:41,880 --> 00:30:45,060
But instead of being targeted at
other developers who at least

580
00:30:45,060 --> 00:30:47,860
kind of know that the negative
feedback is coming.

581
00:30:47,860 --> 00:30:52,540
Some of this felt to me like it
was targeted toward users who

582
00:30:52,540 --> 00:30:56,280
like they don't realize that they're
about to get jumped on for

583
00:30:56,280 --> 00:31:00,300
you know wading into a flame war
about whether something is or

584
00:31:00,300 --> 00:31:03,940
isn't something you know and I
just don't want you I don't want

585
00:31:03,940 --> 00:31:06,260
users that I don't want anybody
to have that experience I certainly

586
00:31:06,260 --> 00:31:08,220
don't want users to have that experience.

587
00:31:09,020 --> 00:31:13,340
Michael: I personally think that
only from having you articulate

588
00:31:13,340 --> 00:31:16,080
that I've thought of 1 that I that
annoys me a little bit and

589
00:31:16,080 --> 00:31:19,100
that's the correction of people
pronouncing or spelling Postgres

590
00:31:19,200 --> 00:31:22,600
wrongly or missing the S off sometimes
happens if people are

591
00:31:22,600 --> 00:31:26,280
new to the community and immediately
they get jumped on.

592
00:31:26,280 --> 00:31:29,000
I think, oh, come on, they're clearly
new.

593
00:31:29,340 --> 00:31:31,740
So yeah, I can definitely see that.

594
00:31:32,160 --> 00:31:35,860
Robert: It also happens a lot with
people based on their language

595
00:31:35,860 --> 00:31:36,540
of origin.

596
00:31:38,180 --> 00:31:43,640
Like the fact that we pronounce
it PostgreSQL, I believe that's

597
00:31:43,660 --> 00:31:48,280
at least 1 of the canonical pronunciations,
that is much more

598
00:31:48,280 --> 00:31:52,840
natural for somebody who learned
to speak English in the United

599
00:31:52,840 --> 00:31:56,320
States Than it is for somebody
who learned to speak English and

600
00:31:56,320 --> 00:31:58,380
for example India, right?

601
00:31:58,380 --> 00:32:03,120
Like it is English, But the way
that English is spoken in India,

602
00:32:03,120 --> 00:32:04,660
it's a distinct dialect.

603
00:32:04,780 --> 00:32:09,340
It has its own ways that people
say things, ways that people

604
00:32:09,340 --> 00:32:12,140
communicate characteristic patterns
of speech.

605
00:32:12,400 --> 00:32:14,700
And that's not the only place,
certainly.

606
00:32:14,700 --> 00:32:17,040
I think actually there are probably
other countries that where

607
00:32:17,040 --> 00:32:21,080
the problem is even more acute
because English isn't even used

608
00:32:21,080 --> 00:32:24,860
as a common language communication
in many parts of the world

609
00:32:24,860 --> 00:32:28,580
But even when it is it's not necessarily
the same as your English

610
00:32:28,580 --> 00:32:32,580
and people aren't necessarily going
to be You know starting from

611
00:32:32,580 --> 00:32:34,060
the same point, right?

612
00:32:34,160 --> 00:32:38,440
If I read a word that is unfamiliar
and my wife reads the same

613
00:32:38,440 --> 00:32:42,380
word, we're likely to pronounce
it the same way in most cases.

614
00:32:42,660 --> 00:32:45,760
But if a colleague from halfway
around the world reads the same

615
00:32:45,760 --> 00:32:48,840
word, their instinct may not be
the same as mine.

616
00:32:48,840 --> 00:32:51,980
And that's not necessarily a question
of me being right and them

617
00:32:51,980 --> 00:32:52,640
being wrong.

618
00:32:52,640 --> 00:32:54,640
That's the question of we went
to different schools.

619
00:32:54,640 --> 00:32:56,020
We were taught different things.

620
00:32:56,520 --> 00:32:59,440
Gülçin: Yeah, I think it also points
out to the wider problem

621
00:32:59,440 --> 00:33:02,320
in many communities, like the longevity
of the projects will

622
00:33:02,320 --> 00:33:03,160
depend on people.

623
00:33:03,160 --> 00:33:07,640
And if you are hostile to people
or like, because we all come

624
00:33:07,640 --> 00:33:11,380
from different parts of the world,
I didn't learn English until

625
00:33:11,380 --> 00:33:13,760
I was like, you know, an older
kid.

626
00:33:14,380 --> 00:33:17,400
And that is always a problem when
I give a talk or when I write

627
00:33:17,400 --> 00:33:17,960
an email.

628
00:33:17,960 --> 00:33:21,040
It is still in the back of my mind
that I try to correct myself,

629
00:33:21,040 --> 00:33:25,760
I use multiple tools, I try to
present myself as good as I can,

630
00:33:25,760 --> 00:33:26,580
but there are limits.

631
00:33:26,580 --> 00:33:31,220
I still confuse the propositions
I use in and at, all around,

632
00:33:31,300 --> 00:33:31,800
randomly.

633
00:33:32,160 --> 00:33:33,480
I could never fix this.

634
00:33:33,620 --> 00:33:36,180
And that doesn't mean that I can't
contribute to the project,

635
00:33:36,220 --> 00:33:37,700
and I could and I do.

636
00:33:37,900 --> 00:33:41,580
And that's what I believe, like
these little statements, maybe

637
00:33:41,580 --> 00:33:44,540
we took it to a philosophical approach
through, it's not about

638
00:33:44,540 --> 00:33:48,000
pg_dump, backup or not, but like
as, you know, saying Postgres,

639
00:33:48,000 --> 00:33:51,180
but we should do better in how
we handle communication because

640
00:33:51,180 --> 00:33:54,340
this is the way that people interact
with today, report issues.

641
00:33:54,520 --> 00:33:58,940
And if you don't accept the problems,
well, people will not report

642
00:33:58,940 --> 00:34:02,200
it or they will not actually use
this and report back what they

643
00:34:02,200 --> 00:34:04,640
use so that you don't actually
get the feedback from people.

644
00:34:04,640 --> 00:34:07,080
And because you cut these channels
that people actually try to

645
00:34:07,080 --> 00:34:09,900
communicate to you, instead of
opening all these channels that

646
00:34:09,900 --> 00:34:13,700
we should actually amplify, we
should have more channels for

647
00:34:13,700 --> 00:34:17,620
people to bring stuff that they
interact with Postgres or ecosystem

648
00:34:17,800 --> 00:34:18,460
in general.

649
00:34:18,840 --> 00:34:23,540
So that's where I was really impressed
by Robert's blog about

650
00:34:23,760 --> 00:34:25,160
how open he was about this.

651
00:34:25,160 --> 00:34:28,700
And I appreciate the efforts that
going on towards this, because

652
00:34:28,700 --> 00:34:33,040
when I started, I also felt scared,
almost reading some of the

653
00:34:33,040 --> 00:34:33,480
emails.

654
00:34:33,480 --> 00:34:36,480
I was like, I wouldn't want this
reaction to come to me, for

655
00:34:36,480 --> 00:34:36,980
example.

656
00:34:37,040 --> 00:34:38,860
So it shouldn't be like that.

657
00:34:39,380 --> 00:34:42,980
Robert: And I think it's not just
an issue of dialect either.

658
00:34:43,260 --> 00:34:47,600
You know, like that is definitely
part of it.

659
00:34:47,880 --> 00:34:54,720
But 1 thing that I've noticed on
Hackers is that clarity and

660
00:34:54,720 --> 00:35:00,360
extreme precision of expression
is very, very highly valued,

661
00:35:00,720 --> 00:35:01,220
right?

662
00:35:01,240 --> 00:35:07,480
Like someone can come along with
a worse idea and because they

663
00:35:08,360 --> 00:35:13,460
explain it extremely clearly and
precisely either it gets accepted

664
00:35:13,580 --> 00:35:17,020
or they get feedback on how it
should be changed or positive

665
00:35:17,040 --> 00:35:17,540
comments.

666
00:35:17,900 --> 00:35:18,980
Welcome to the community.

667
00:35:19,400 --> 00:35:21,520
Hey, great to have you, right?

668
00:35:21,780 --> 00:35:27,100
Somebody else writes a worse email
about a better idea, and it

669
00:35:27,100 --> 00:35:29,420
actually gets a worse response.

670
00:35:30,180 --> 00:35:35,040
And I do understand some of why
that happens, right?

671
00:35:35,220 --> 00:35:40,160
We value people whose style of
expression is similar to our own,

672
00:35:40,160 --> 00:35:43,580
where we feel like we can freely
and easily communicate with

673
00:35:43,580 --> 00:35:46,920
those people, and everybody's busy,
so you don't wanna spend

674
00:35:46,920 --> 00:35:50,640
a huge amount of time trying to
understand email A if you could

675
00:35:50,640 --> 00:35:54,640
very quickly and easily understand
email B But it's obviously

676
00:35:54,860 --> 00:35:58,340
super off-putting to people when
you may have proposed something

677
00:35:58,340 --> 00:36:02,360
that was actually great And if
somebody had given you 5 minutes

678
00:36:02,360 --> 00:36:05,380
of their time, they could have
understood exactly what you were

679
00:36:05,380 --> 00:36:08,680
trying to say, but they just flip
through the email really fast.

680
00:36:08,680 --> 00:36:10,940
And then they moved on because
they're busy.

681
00:36:11,600 --> 00:36:14,180
And that's obviously going to be
demoralizing to people.

682
00:36:14,640 --> 00:36:17,920
Michael: To play devil's advocate
a little bit, I personally

683
00:36:17,920 --> 00:36:20,940
err on the side of being polite
and trying to be kind and trying

684
00:36:20,940 --> 00:36:25,800
to be welcoming, but I also think
sometimes that approach doesn't

685
00:36:25,840 --> 00:36:29,120
always land, people don't always
take the lesson from it or learn

686
00:36:29,120 --> 00:36:33,600
from the statement or realise that
maybe what I'm really trying

687
00:36:33,600 --> 00:36:36,220
to say or I'm not being clear enough,
that kind of thing.

688
00:36:36,220 --> 00:36:39,680
And I do think, for example, with
the comment that we started

689
00:36:39,680 --> 00:36:42,720
with, I feel like there's a certain
amount of trying to save

690
00:36:42,720 --> 00:36:46,300
people from themselves or trying
to shock people, deliberately

691
00:36:46,360 --> 00:36:49,940
trying to be provocative in order
to make people think, oh we

692
00:36:49,940 --> 00:36:54,440
shouldn't only be relying on this
tool for this purpose or you

693
00:36:54,440 --> 00:36:58,720
know we maybe I should be rethinking
my thoughts, you know that

694
00:36:59,080 --> 00:37:01,960
it doesn't apply to all of these
cases like mispronouncing the

695
00:37:01,960 --> 00:37:04,740
project name but I've seen this
specific comment come mostly

696
00:37:04,740 --> 00:37:07,260
from consultants, some experienced
consultants, some who are

697
00:37:07,260 --> 00:37:10,300
very kind and also involved in
like diversity initiatives.

698
00:37:10,600 --> 00:37:13,780
I've definitely seen this from
people that you wouldn't necessarily

699
00:37:13,780 --> 00:37:18,700
expect to be direct and unkind
so the exact phrase pg_dump is

700
00:37:18,700 --> 00:37:19,840
not a backup tool.

701
00:37:19,960 --> 00:37:24,620
So I think that's coming from a
place of having seen people shoot

702
00:37:24,620 --> 00:37:27,940
themselves in the foot and wanting
to save people from that and

703
00:37:27,940 --> 00:37:30,020
wanting to be quite direct to avoid
it.

704
00:37:30,020 --> 00:37:33,100
So I don't know for sure, but I
believe their intent is good,

705
00:37:33,640 --> 00:37:37,720
but maybe they're deliberately
choosing to be provocative or

706
00:37:37,720 --> 00:37:39,780
direct or I'm not sure.

707
00:37:39,780 --> 00:37:40,440
I'm not sure.

708
00:37:40,440 --> 00:37:42,320
Maybe I'm putting words in their
mouths basically.

709
00:37:42,380 --> 00:37:45,040
Gülçin: I think it's like we are
not calling out people for just

710
00:37:45,040 --> 00:37:48,300
saying, you know, this is not a
backup too, because we understand

711
00:37:48,360 --> 00:37:51,300
where they come from, because we
are in the same industry, working

712
00:37:51,300 --> 00:37:52,000
for ages.

713
00:37:52,240 --> 00:37:55,560
We know these people, we all had
the customer stories and so

714
00:37:55,560 --> 00:37:56,060
on.

715
00:37:56,120 --> 00:38:00,220
But I think the general idea from
here that when somebody shares

716
00:38:00,220 --> 00:38:02,360
a blog post, let's say we all wrote
about it.

717
00:38:02,360 --> 00:38:05,040
I had wrote 2 blog posts and Robert
wrote 2 more.

718
00:38:05,280 --> 00:38:07,580
And we just got together and talking
about it.

719
00:38:07,580 --> 00:38:11,180
Let's say he's pointing out why
pg_dump is good at dependency

720
00:38:11,200 --> 00:38:12,420
management, let's say.

721
00:38:12,540 --> 00:38:16,280
We take it for granted, which I
wanted to bring up in today's

722
00:38:16,360 --> 00:38:19,400
call to just actually showcase
that there are things we should

723
00:38:19,400 --> 00:38:22,580
appreciate in this tool, why he
says it is an amazing tool.

724
00:38:22,960 --> 00:38:26,680
Then towards this, somebody writes
like, but it is not a backup

725
00:38:26,680 --> 00:38:27,180
tool.

726
00:38:27,180 --> 00:38:29,640
Then I don't get it, because it's
not what is the discussion

727
00:38:29,640 --> 00:38:30,040
about.

728
00:38:30,040 --> 00:38:33,000
We are trying to discuss that there
are ways you can make this

729
00:38:33,000 --> 00:38:35,240
tool in your tool set.

730
00:38:35,240 --> 00:38:36,500
It's not the only tool.

731
00:38:36,600 --> 00:38:40,120
There are professional solutions
for backing up your database

732
00:38:40,120 --> 00:38:43,520
against disaster recovery, as we
mentioned, the retention and

733
00:38:43,520 --> 00:38:47,220
the whole orchestration of the
database backups and recovery.

734
00:38:47,220 --> 00:38:50,280
But when we are discussing this
tool specifically, which I feel

735
00:38:50,280 --> 00:38:53,860
that is important here because
there's nuance to be discussed,

736
00:38:54,060 --> 00:38:57,240
and just shutting down the discussion
saying, but it's not a

737
00:38:57,240 --> 00:39:00,800
backup tool, this is where I feel
that this needs to be improved

738
00:39:00,800 --> 00:39:03,840
better because then you don't really
contribute to this because

739
00:39:03,840 --> 00:39:06,760
you need to say then why it is
not in this case, why don't you

740
00:39:06,760 --> 00:39:07,440
agree with this?

741
00:39:07,440 --> 00:39:11,500
Let's say, is it dependency management
thing is not for you or

742
00:39:12,100 --> 00:39:13,180
why it could be improved?

743
00:39:13,180 --> 00:39:16,400
You could say that pg_dump could
be improved because let's say

744
00:39:16,400 --> 00:39:20,380
we could run vacuum after it, or
we can do, I don't know, like

745
00:39:20,380 --> 00:39:22,200
do statistics better or something.

746
00:39:22,200 --> 00:39:26,940
I mean, to contribute where a pg_dump
might have been improved,

747
00:39:26,940 --> 00:39:31,920
because I've seen people like in
the discussions that they struggle

748
00:39:31,920 --> 00:39:35,240
with mapping, let's say, pg_dump
options to pg_restore options

749
00:39:35,420 --> 00:39:38,160
because they assume the order will
be the same and they don't

750
00:39:38,160 --> 00:39:39,060
get it and so on.

751
00:39:39,060 --> 00:39:42,080
So there are things maybe we could
get input from why people

752
00:39:42,080 --> 00:39:44,120
complain about these things and
to improve.

753
00:39:44,140 --> 00:39:46,040
That's where I go for issues.

754
00:39:46,500 --> 00:39:49,280
I see these comments in the forums
and like, oh, OK, this is

755
00:39:49,280 --> 00:39:49,920
a good idea.

756
00:39:49,920 --> 00:39:52,620
Maybe I can actually talk about
this.

757
00:39:52,740 --> 00:39:55,320
But then when we are discussing
this and coming with like, okay,

758
00:39:55,320 --> 00:39:58,020
this is not a backup tool, it kind
of brings back to the 0 and

759
00:39:58,020 --> 00:39:59,740
doesn't really improve anything.

760
00:40:00,560 --> 00:40:05,600
Nikolay: But your second article
was basically agreeing that

761
00:40:05,600 --> 00:40:07,020
it's not a backup tool.

762
00:40:08,520 --> 00:40:12,980
Gülçin: No, in the sense that people
say, as I'm saying, as a

763
00:40:12,980 --> 00:40:16,500
solution, if you want to orchestrate
your backups, use a, I don't

764
00:40:16,500 --> 00:40:19,940
know, a tool that is like, you
know, Barman, Baker's or something.

765
00:40:20,200 --> 00:40:22,860
But then another discussion we
have, why it can't be?

766
00:40:22,860 --> 00:40:23,740
Why pg_dump?

767
00:40:23,740 --> 00:40:26,600
We are discussing the, because
in the second blog post of Robert,

768
00:40:26,600 --> 00:40:29,620
for example, he gives up like this,
you know, why it could be

769
00:40:29,620 --> 00:40:33,400
a nice tool for these of the use
cases that he lists.

770
00:40:33,820 --> 00:40:37,540
And they're getting the question
of again, that I don't agree

771
00:40:37,540 --> 00:40:41,140
basically, like, okay, use a better
maybe solution if you are

772
00:40:41,140 --> 00:40:44,540
managing production databases in
multiple environments that are

773
00:40:44,540 --> 00:40:48,260
giant databases and you really
don't need to deal with, you know,

774
00:40:48,260 --> 00:40:48,980
home run.

775
00:40:49,120 --> 00:40:51,960
But he's still historically, it
is still a tool that we use,

776
00:40:51,960 --> 00:40:54,120
you know, it could be used for
different cases.

777
00:40:54,640 --> 00:40:59,800
Nikolay: What, what I hear is you're
saying when people come

778
00:40:59,800 --> 00:41:03,000
to you to comment to your first
blog post saying, I think it

779
00:41:03,000 --> 00:41:06,180
was Franck Pachot and I'm joining
him, still joining.

780
00:41:06,580 --> 00:41:09,480
And he said, pg_dump is not
a backup tool.

781
00:41:09,520 --> 00:41:13,280
You think it's like shuts down
some discussion and so on.

782
00:41:13,280 --> 00:41:17,740
But I just explained that this
is a pain from a lot of experience

783
00:41:18,480 --> 00:41:22,200
and we are just reacting and what
I hear you still try to judge

784
00:41:22,200 --> 00:41:23,340
him, right?

785
00:41:23,560 --> 00:41:23,940
Let's just...

786
00:41:23,940 --> 00:41:25,760
Gülçin: No, no, that's definitely
not for it.

787
00:41:25,760 --> 00:41:29,020
I'm just saying we discussed that,
but the second blog post was

788
00:41:29,020 --> 00:41:32,220
about, you know, there's backup
tools, you should use it.

789
00:41:32,220 --> 00:41:36,140
But then when Robert was describing
a part of why pg_dump is

790
00:41:36,140 --> 00:41:39,120
good, in my opinion, it was like
very valuable points.

791
00:41:39,380 --> 00:41:41,340
And there it was not even relevant.

792
00:41:41,400 --> 00:41:45,600
We were not even discussing, should
you use this tool or not?

793
00:41:45,600 --> 00:41:47,300
And I'm not targeting anybody.

794
00:41:47,640 --> 00:41:48,920
I'm not targeting anybody.

795
00:41:48,920 --> 00:41:50,960
So be clear about it.

796
00:41:51,020 --> 00:41:54,380
Nikolay: Yeah.
So the change happened only now.

797
00:41:54,380 --> 00:41:55,460
It's in Postgres 18.

798
00:41:55,840 --> 00:41:59,100
And recently I had discussion this
like claiming, oh, it's not

799
00:41:59,100 --> 00:41:59,700
backup tool.

800
00:41:59,700 --> 00:42:02,080
Somebody said, oh, what is this
about then?

801
00:42:02,080 --> 00:42:04,620
And sending me a link to pg_dump
documentation.

802
00:42:05,460 --> 00:42:10,840
So I think I would not judge people
who are saying pg_dump is

803
00:42:10,840 --> 00:42:14,180
not a backup tool until we have
this change in documentation

804
00:42:15,060 --> 00:42:18,620
and start recovering from this
stress we had 20 years.

805
00:42:19,700 --> 00:42:20,780
This is my point.

806
00:42:21,100 --> 00:42:23,740
I stay on this point very strong.

807
00:42:26,240 --> 00:42:29,980
And common ground is let's start
distinguishing physical and

808
00:42:29,980 --> 00:42:31,200
logical backups.

809
00:42:31,240 --> 00:42:35,780
We can clarify this on documentation
as Oracle and MySQL did.

810
00:42:36,220 --> 00:42:40,000
And there is already part of documentation
speaking of backups,

811
00:42:40,840 --> 00:42:45,900
it describes dumps, I mean, pg_dump
and then file system snapshots

812
00:42:46,060 --> 00:42:49,780
and then point-in-time recovery,
full-fledged backups.

813
00:42:50,060 --> 00:42:54,560
And just if we clarify documentation
and I will stop seeing customers

814
00:42:54,560 --> 00:42:57,840
sending me this link saying you're
wrong, this is documentation

815
00:42:58,040 --> 00:42:59,160
saying you are wrong.

816
00:43:00,720 --> 00:43:05,320
Robert: But like, I think, you
know, I don't know, like, if you

817
00:43:05,320 --> 00:43:09,720
can't win an argument against a
documentation link, I don't know,

818
00:43:09,720 --> 00:43:13,780
it feels like something's not right
there, you know, like, I'm

819
00:43:13,780 --> 00:43:15,060
not trying to be harsh.

820
00:43:15,060 --> 00:43:21,740
And I just feel like, you know,
if somebody hires you to give

821
00:43:21,740 --> 00:43:27,320
them good advice, and you give
them advice that is actually good,

822
00:43:27,380 --> 00:43:28,260
and their response is...

823
00:43:28,260 --> 00:43:29,720
Nikolay: Robert, let me interrupt
you.

824
00:43:29,720 --> 00:43:30,080
Sorry.

825
00:43:30,080 --> 00:43:35,340
I'm just like, I feel judgment
in you and Galaxian's words.

826
00:43:35,900 --> 00:43:40,280
Like, you tell me now how you want
to be welcoming, and now you

827
00:43:40,280 --> 00:43:41,760
judge me like I cannot win.

828
00:43:41,760 --> 00:43:43,260
I cannot win 2 things.

829
00:43:43,260 --> 00:43:44,600
pg_dump is a backup tool.

830
00:43:44,600 --> 00:43:45,600
Sometimes I cannot.

831
00:43:45,600 --> 00:43:48,820
They say they trust documentation
more because many more minds

832
00:43:48,820 --> 00:43:49,400
behind it.

833
00:43:49,400 --> 00:43:52,900
And also pg_stat_statements, documentation
says you cannot say

834
00:43:52,900 --> 00:43:56,100
set it to positive value, keep
it 0 globally because globally

835
00:43:56,100 --> 00:43:57,100
it's a bad idea.

836
00:43:57,540 --> 00:44:01,820
I already like some customers I
win, some customers I don't.

837
00:44:01,920 --> 00:44:04,140
I'm not genius, right?

838
00:44:04,240 --> 00:44:06,900
But I feel in both of you, I feel
judgment.

839
00:44:07,300 --> 00:44:11,440
Why don't we stop judging people
and sentiment and so on?

840
00:44:11,720 --> 00:44:13,420
I bring you like improvement.

841
00:44:13,700 --> 00:44:16,920
Let's say there are 2 types of
backups, logical and physical.

842
00:44:16,920 --> 00:44:20,220
And then we, we develop language
from there.

843
00:44:20,460 --> 00:44:21,840
And this joins us.

844
00:44:22,420 --> 00:44:22,920
Right?

845
00:44:22,940 --> 00:44:26,980
When you judge people saying they
came to me with this statement,

846
00:44:27,100 --> 00:44:31,060
or you say, you cannot win your
customer authentication, This

847
00:44:31,060 --> 00:44:31,860
splits us.

848
00:44:32,920 --> 00:44:34,700
And I start fighting with you.

849
00:44:34,700 --> 00:44:36,440
I don't want to fight with you.

850
00:44:36,660 --> 00:44:39,960
Robert: But I mean, that's also my complaint about the language

851
00:44:39,960 --> 00:44:40,940
that you were using.

852
00:44:40,940 --> 00:44:46,100
So I don't know how to have this discussion without having opinions

853
00:44:46,260 --> 00:44:48,820
about whether certain language is good or bad.

854
00:44:48,820 --> 00:44:52,920
And I don't think I mean, you can't write like we have to be

855
00:44:52,920 --> 00:44:59,240
able to talk about what the language does and to what extent

856
00:44:59,240 --> 00:45:01,020
it helps or hurts.

857
00:45:01,020 --> 00:45:04,480
And yeah, of course, there's some judgment there I don't know

858
00:45:04,480 --> 00:45:08,460
like I definitely have been in the situation of having a customer

859
00:45:08,680 --> 00:45:09,180
who?

860
00:45:09,640 --> 00:45:13,940
Wouldn't listen and I The frustration that you feel with that

861
00:45:13,940 --> 00:45:18,760
situation feels very genuine to me like I I can totally imagine

862
00:45:18,840 --> 00:45:23,720
that happening and being a bad experience, but I don't know.

863
00:45:23,800 --> 00:45:27,720
I'm not even saying it's a bad thing that we changed the language

864
00:45:27,720 --> 00:45:28,540
in the documentation.

865
00:45:29,380 --> 00:45:33,660
I was only reacting against sort of like conclusory statement

866
00:45:33,940 --> 00:45:36,940
pg_dump is a backup tool and now I don't want to talk about it

867
00:45:36,940 --> 00:45:40,440
anymore I think we should always be talking about it more I think

868
00:45:40,440 --> 00:45:44,380
we should be trying to as you say bring clarity to it and bring

869
00:45:44,380 --> 00:45:45,640
precision to it

870
00:45:45,900 --> 00:45:49,740
Nikolay: I agree with you totally like I hear you now well and

871
00:45:49,740 --> 00:45:53,160
I think we will stop saying this actually, if documentation will

872
00:45:53,160 --> 00:45:56,680
be, it's already fixed, I think it can be fixed even better if

873
00:45:56,680 --> 00:45:59,700
we say it's a logical backup tool, for example.

874
00:46:00,060 --> 00:46:02,060
Everyone will be happy, I think, right?

875
00:46:02,220 --> 00:46:05,580
And we will stop saying it's not a backup tool.

876
00:46:05,580 --> 00:46:08,720
We will start saying it's not a physical backup tool, which is

877
00:46:08,720 --> 00:46:09,560
obvious, right?

878
00:46:09,620 --> 00:46:13,020
And this will join everything and so on, right?

879
00:46:13,200 --> 00:46:19,040
I agree with your reaction, actually, which says this statement

880
00:46:19,060 --> 00:46:24,100
it's not a backup tool it's like too like far from balance right

881
00:46:24,100 --> 00:46:28,680
it's off balance I agree with this so it's not a good statement

882
00:46:28,780 --> 00:46:33,380
actually I admit but again it's a reaction to another not a good

883
00:46:33,380 --> 00:46:37,680
statement which we had in documentation which didn't say logical

884
00:46:37,700 --> 00:46:40,860
backup it said just just backup okay

885
00:46:41,380 --> 00:46:44,640
Michael: we're pretty much out of time okay I wanted to thank

886
00:46:44,640 --> 00:46:47,400
you all for your thoughts on this I think is a difficult subject

887
00:46:47,400 --> 00:46:50,860
and I think actually it's really nice to have 3 people that all

888
00:46:50,860 --> 00:46:55,280
care about educating folks and teaching people how to do things

889
00:46:55,280 --> 00:46:58,740
well with different opinions on how to do so or you know slightly

890
00:46:58,740 --> 00:47:02,580
different approaches on how to do so but as Nikolay says, as

891
00:47:02,580 --> 00:47:05,140
Gülçin pointed out in her blog post, the language around this

892
00:47:05,140 --> 00:47:06,440
has been changed in the documentation.

893
00:47:07,280 --> 00:47:10,840
Robert, keep fighting the good fight on the hacker, the tone

894
00:47:10,840 --> 00:47:12,040
on things on Hackers.

895
00:47:13,380 --> 00:47:15,840
Is there any last words anybody else wants to add?

896
00:47:15,840 --> 00:47:18,480
Let's start Gülçin, did you want to say anything else at the

897
00:47:18,480 --> 00:47:18,980
end?

898
00:47:19,540 --> 00:47:22,560
Gülçin: No, I'm happy that we are discussing it and I don't take

899
00:47:22,560 --> 00:47:23,380
things personally.

900
00:47:23,560 --> 00:47:27,340
I mean, we are here just to discuss technically why this could

901
00:47:27,340 --> 00:47:29,620
be useful in some cases and why not.

902
00:47:29,620 --> 00:47:33,180
And Yeah, that was anyway the summary of what I said in the blog

903
00:47:33,180 --> 00:47:33,800
post as well.

904
00:47:33,800 --> 00:47:36,880
So if people like to read it and comment on it, and I'm happy

905
00:47:36,880 --> 00:47:38,260
to discuss more.

906
00:47:38,440 --> 00:47:38,800
Thanks.

907
00:47:38,800 --> 00:47:39,280
Michael: Wonderful.

908
00:47:39,280 --> 00:47:41,380
Well, we're looking forward to your future blog posts, whether

909
00:47:41,380 --> 00:47:42,840
you want to write them or not.

910
00:47:42,840 --> 00:47:44,620
Robert, any last words from you?

911
00:47:45,040 --> 00:47:48,440
Robert: I just think, you know, on Nikolay's comment about making

912
00:47:48,440 --> 00:47:51,900
the documentation better, what I would encourage, and of course

913
00:47:51,900 --> 00:47:55,940
this is much longer than we can actually do in this forum, is,

914
00:47:56,000 --> 00:47:59,060
you know, let's get down beyond the headline, right?

915
00:47:59,060 --> 00:48:01,920
Like saying in the headline that it is a backup tool or that

916
00:48:01,920 --> 00:48:04,940
it's not a backup tool, it's an export, it's a dump, it's a lot.

917
00:48:05,140 --> 00:48:10,840
We got to get beyond that subject line and think about what we

918
00:48:10,840 --> 00:48:11,820
say down deeper.

919
00:48:11,840 --> 00:48:15,980
I think one of the areas where the Postgres documentation is sometimes

920
00:48:16,120 --> 00:48:20,200
weak is it doesn't always do a good job listing pros and cons.

921
00:48:20,200 --> 00:48:23,140
Pros and cons very often don't get listed for things.

922
00:48:23,440 --> 00:48:28,460
So you know that that's probably an area where we could we could

923
00:48:28,460 --> 00:48:29,840
grow as a community.

924
00:48:30,200 --> 00:48:30,940
Nikolay: Big time.

925
00:48:31,300 --> 00:48:31,780
Michael: Brilliant.

926
00:48:31,780 --> 00:48:35,180
Well thank you so much everybody and thanks Nikolay, catch you

927
00:48:35,180 --> 00:48:35,820
next week.

928
00:48:36,540 --> 00:48:37,080
Nikolay: Thank you.

929
00:48:37,080 --> 00:48:38,060
Thank you for coming.

930
00:48:39,280 --> 00:48:39,780
Gülçin: Thanks.

931
00:48:40,240 --> 00:48:41,020
Bye-bye.
Robert: Ciao.

932
00:48:41,720 --> 00:48:42,220
Nikolay: Bye.

933
00:48:42,752 --> 00:48:43,252
Gülçin: Ciao.