ly grasp all the details here.
>
> [0] https://postgr.es/m/flat/1423433.1652722406%40sss.pgh.pa.us
>
I agree with blocking it for now. The patch LGTM, all tests pass and seems
to cover all the changes.
Not sure if it is worth having some dump/restore tap tests for tables with
regdatabase type.
Regards,
--
Fabrízio de Royes Mello
ferent Postgres version. This change lowers the log level
> of these messages to DEBUG5, so that they can be ignored while still
> showing other (more predictable) DEBUG messages.
>
This is a very good idea. In TimescaleDB we filter out such kind of output
in order to not end up with fla
to try to ease this for whoever comes
> next.
>
>
LGTM
> Tested with GNU Make 3.81 (the compilation of which was slightly
> painful; does anyone want to debate pulling that minimum version up
> sometime soon?) and 4.3.
>
>
Not sure if all animals have a minimum 4.3 make version. Do you?
--
Fabrízio de Royes Mello
On Fri, Apr 11, 2025 at 5:26 PM Jonathan S. Katz
wrote:
> The Core Team would like to extend our congratulations to Jacob
> Champion, who has accepted an invitation to become our newest PostgreSQL
> committer.
>
>
This is awesome news... congrats Jacob!!!
Regards,
--
Fabrízio de Royes Mello
>
> https://www.postgresql.org/message-id/40663fc5-edac-4b45-a2aa-a76976700ed9%40tantorlabs.com
>
>
LGTM
--
Fabrízio de Royes Mello
not applying:
main on main [$]
➜ git apply /tmp/fix_explain_analyze_spacing.diff
error: patch failed: src/backend/commands/explain.c:2075
error: src/backend/commands/explain.c: patch does not apply
On the current main your change should be on line 2041 and not 2075
according to your patch.
Regards,
--
Fabrízio de Royes Mello
t; not used since schemaName is sufficient.
>
LGTM.
--
Fabrízio de Royes Mello
On Tue, Jan 7, 2025 at 12:42 PM Dave Cramer wrote:
> Greetings,
>
> Previously we have replaced the use of literal characters with pqMsg*. Not
> sure how this one escaped detection.
>
> Patch attached.
>
>
LGTM... looks like a leftover from f4b54e1e.
Regards,
--
Fabrízio de Royes Mello
yet prove useful. Therefore, I'm only removing the
> parameter from this static function.
>
>
LGTM looks like a leftover from a4d75c86.
Regards,
--
Fabrízio de Royes Mello
5392
bytes_total | 2921579128
tuples_processed | 18605306
tuples_excluded | 0
tuples_skipped | 0
Regards,
--
Fabrízio de Royes Mello
> (src/backend/access/transam/xlogbackup.c)
> Where *appendStringInfo* expects a string with null-termination.
>
> appendStringInfo(result, "LABEL: %s\n", state->name);
>
> To fix, copy strlen size plus one byte, to include the null-termination.
>
>
Doesn’t “sizeof”
quot;, so I've done that.
>
> > Shouldn't "mem_tableam_handler" be "my_tableam_handler"?
>
> Sorry about that, fixed.
>
> [0] https://www.postgresql.org/docs/current/extend-extensions.html
>
> Phil
>
Nice... LGTM!
--
Fabrízio de Royes Mello
* [GNUmakefile:11: all-src-recurse] Error 2
> It's worth pointing out that this, quite fundamentally, can only work
when the
> log message is triggered directly by the extension. If the extension code
> calls some postgres function and that function then errors out, it'll be
seens
woman committer... Congrats to
you both Melanie and Richard!!!
Regards,
--
Fabrízio de Royes Mello
is
tool was exactly what Amit described so IMHO we should make it easier for
users to subscribe to all existing user databases.
Regards,
--
Fabrízio de Royes Mello
few days.
>
Also did some tests locally and everything went well. Patches apply to the
main branch without issues and all regression (including checkworld) pass!!
Regards
--
Fabrízio de Royes Mello
x27;5432'
wal_level = 'logical'
max_wal_senders = '8'
max_replication_slots = '6'
hot_standby_feedback = 'on'
max_prepared_transactions = '10'
max_locks_per_transaction = '512'
Regards,
--
Fabrízio de Royes Mello
On Wed, Jan 31, 2024 at 11:35 AM Euler Taveira wrote:
>
> On Wed, Jan 31, 2024, at 11:25 AM, Fabrízio de Royes Mello wrote:
>
> Jumping into this a bit late here... I'm trying a simple
pg_createsubscriber but getting an error:
>
>
> Try v11. It seems v12-0002 is n
ssion_attrs=any load_balance_hosts=disable
dbname=fabrizio' PUBLICATION pg_createsubscriber_16384 WITH (create_slot =
false, copy_data = false, enabled = false)
Seems we need to escape connection params similar we do in dblink [1]
Regards,
[1]
https://git.postgresql.org/gitweb/?p=postgresql.git;a=blob;f=contrib/dblink/dblink.c;h=19a362526d21dff5d8b1cdc68b15afebe7d40249;hb=HEAD#l2882
--
Fabrízio de Royes Mello
there are other ideas.
>
I've mentioned it upthread because of this pet project [1] that is one of
the motivations behind upstream this facility.
[1] https://github.com/fabriziomello/pg_create_subscriber
--
Fabrízio de Royes Mello
t unless there's good reason to do so.
Hey folks,
There is a previous patch [1] around the same topic. What about joining
efforts on pointing these documentation changes to the proposed test module?
[1] https://commitfest.postgresql.org/46/4588/
--
Fabrízio de Royes Mello
| 1
relname | pg_toast_17787
toast_pages | 97
relname | pg_toast_17787_index
toast_index_pages | 1
toast_index_size | 16384
Are there any reasons for toast index relpages not to be updated? Or is it
a bug?
Regards,
--
Fabrízio de Royes Mello
On Mon, Jun 5, 2023 at 1:24 PM Fabrízio de Royes Mello <
fabriziome...@gmail.com> wrote:
>
> On Sat, Jun 3, 2023 at 7:42 PM Fabrízio de Royes Mello <
fabriziome...@gmail.com> wrote:
> >
> >
> > Hi all,
> >
> > During the PGCon Unconference session ab
attached.
>
+1 for replacing it with StringInfo. And the patch LGTM!
>
> Given the infrequency of complaints, I'm inclined to apply
> the more thorough fix only in HEAD, and to just raise MAX_TOKEN
> in the back branches. Thoughts?
>
It makes sense to change it only in HEAD.
Regards,
--
Fabrízio de Royes Mello
pq/pg_plugins/tree/main/blackhole_am
>
And based on your `blackhole_am` I've sent a patch [1] to add a
`dummy_table_am` for testing purposes.
Regards,
[1]
https://www.postgresql.org/message-id/CAFcNs+pcU2ib=jvjnznbod+m2tho+vd77c_yzj2rsgr0tp3...@mail.gmail.com
--
Fabrízio de Royes Mello
On Sat, Jun 3, 2023 at 7:42 PM Fabrízio de Royes Mello <
fabriziome...@gmail.com> wrote:
>
>
> Hi all,
>
> During the PGCon Unconference session about Table Access Method one
missing item pointed out is that currently we lack documentation and
examples of TAM.
>
> So i
ready have for Index
Access Method.
This code is based on the "blackhole_am" implemented by Michael Paquier:
https://github.com/michaelpq/pg_plugins/tree/main/blackhole_am
Regards,
--
Fabrízio de Royes Mello
From 217b84f21ec1cdb0ede271d24b7a5863713db949 Mon Sep 17 00:00:00 2001
From: =?
ts passed and were built without warnings.
Regards
--
Fabrízio de Royes Mello
issuing COPY for each relation (even all is
empty) and evidence the difference due to roundtrip for LOCK TABLE. This
patch will also improve the pg_upgrade execution over database with
thousands of relations.
Regards,
--
Fabrízio de Royes Mello
N ACCESS SHARE MODE;
>
> The proposed patch makes this change. It's pretty straightforward and
> as a side effect saves a bit of network traffic too.
>
+1 for that change. It will improve the dump for databases with thousands
of relations.
The code LGTM and it passes in all tests and compiles without any warning.
Regards,
--
Fabrízio de Royes Mello
> >
> > That should make the example shorter and clearer, and preserve the
output
> > tested by the regression test. Trying to show much more than that
involves
> > assumptions about what the PL's target language syntax looks like, how
its
> > execution engine works and parameters are bound, and so on, and that is
> > likely to just be distracting, IMV.
>
> I think I've applied all of these suggestions and attached a new patch.
>
Cool... I also have a look into the code. To me everything is also ok!!!
Regards,
--
Fabrízio de Royes Mello
think that this will not upset the
> buildfarm.
Also LGTM.
Regards,
--
Fabrízio de Royes Mello
to a subscriber.
>
>
Some time ago I did a POC on it [1] and I used the name pg_create_subscriber
[1]
https://github.com/fabriziomello/pg_create_subscriber
--
Fabrízio de Royes Mello
; > 0, so wouldn't it be enough to stick some > 0 in your test queries?
>
> I edited the previous patch file.
> Am I correct in understanding that?
>
I think what Michael meant is something like attached.
Regards,
--
Fabrízio de Royes Mello
diff --git a/contrib/pg_freespace
ons r
join pg_class on pg_class.oid = r.relid
)
select
total_bytes, heap_bytes, index_bytes, toast_bytes,
(total_bytes = (heap_bytes+index_bytes+toast_bytes)) as "Equal?",
(total_bytes - (heap_bytes+index_bytes+toast_bytes)) as "Diff"
from sizes;
total_bytes | heap_bytes | index_bytes | toast_bytes | Equal? | Diff
-++-+-++--
14622720 | 65536 | 40960 |14516224 | t |0
(1 row)
Regards,
--
Fabrízio de Royes Mello
13688832 | f | 180224
(1 row)
I want to calculate separately HEAP, INDEXES and TOAST (including indexes)
sizes but it seems it's a bit inconsistent with pg_total_relation_size.
Is it correct or am I missing something?
Regards,
[1]
https://www.postgresql.org/docs/current/functions-admin.html#FUNCTIONS-ADMIN-DBSIZE
--
Fabrízio de Royes Mello
le of this
> function, it switches to the oldcontext and immediately switches back to
> COPY memory context, IMO, this is redundant, and can be removed safely.
>
LGTM (it passed all regression without any issue)
--
Fabrízio de Royes Mello Timbira - http://www.timbira.com.
On Wed, Jan 5, 2022 at 2:19 PM Julien Rouhaud wrote:
>
> On Thu, Jan 6, 2022 at 12:19 AM Bruce Momjian wrote:
> >
> > On Tue, Jan 4, 2022 at 10:47:47AM -0300, Fabrízio de Royes Mello wrote:
> > >
> > >
> > > What we did was decode the 9.6 wal files a
On Tue, Jan 4, 2022 at 9:22 AM Michael Paquier wrote:
>
> On Wed, Dec 29, 2021 at 08:50:23AM -0300, Fabrízio de Royes Mello wrote:
> > Try this:
> > https://github.com/michaelpq/pg_plugins/tree/main/decoder_raw
>
> You may want to be careful with this, and I don't kn
looking for a way to convert
> WAL to sql statements.
>
>
>
Try this:
https://github.com/michaelpq/pg_plugins/tree/main/decoder_raw
--
Fabrízio de Royes Mello Timbira - http://www.timbira.com.br/
PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento
table public.pgbench_branches: UPDATE: bid[integer]:9
bbalance[integer]:1277609 filler[character]:null
table public.pgbench_history: INSERT: tid[integer]:86 bid[integer]:9
aid[integer]:989789 delta[integer]:-2934 mtime[timestamp without time
zone]:'2021-09-17 17:25:19.811244' filler[
b.c#L726
[2]
https://github.com/timescale/timescaledb/blob/master/tsl/src/bgw_policy/job.c#L741
[3] https://github.com/timescale/timescaledb/issues/3545
[4]
https://github.com/fabriziomello/timescaledb/blob/issue/3545/tsl/src/bgw_policy/job.c#L824
--
Fabrízio de Royes Mello
diff --git a/src/test/modules/
36:43.571 -03 [23838] LOG: background worker "worker_spi"
(PID 23846) exited with exit code 1
I changed the worker_spi example (attached) a bit to execute a simple
procedure. Even using SPI_connect_ext(SPI_OPT_NONATOMIC) I'm getting the
error "invalid transaction termination&qu
tlab.com/konskov/pljulia/-/blob/main/README.md
>
> Currently the extension works for version 13 and Julia versions >= 1.6
(Thanks to Imre Samu for testing!)
>
Awesome Konstantina, it was a pleasure working with you in this project.
Looking forward to your next contributions to Pos
On Wed, Mar 24, 2021 at 3:57 AM Drouvot, Bertrand
wrote:
>
> Thanks for pointing out, fixed in v14 attached.
>
Thanks... now everything is working as expected... changed the status to
Ready for Commiter:
https://commitfest.postgresql.org/32/2968/
Regards,
--
Fabrízio de Ro
ed result.
Regards,
--
Fabrízio de Royes Mello
PostgreSQL Developer at OnGres Inc. - https://ongres.com
On Tue, Mar 23, 2021 at 10:18 AM Fabrízio de Royes Mello <
fabriziome...@gmail.com> wrote:
>
> LGTM too... Reviewing new changes now to move it forward and make this
patch set ready for commiter review.
>
According to the feature LGTM and all tests passed. Documentation is also
o me.
>
LGTM too... Reviewing new changes now to move it forward and make this
patch set ready for commiter review.
Regards,
--
Fabrízio de Royes Mello
PostgreSQL Developer at OnGres Inc. - https://ongres.com
le thread to check if there is anything else
waiting in the pipe regarding this feature, unless some of you know off the
top of their head?
>
Will do the same!!! But as far I remember last time I checked it everything
discussed is covered in this patch set.
Regards,
--
Fabrízio de R
ou think about such a feature? is it worth
it?
>
Make total sense since we already have --function=NAME(args) on pg_restore
and it doesn't solve dependencies... so we can add it to also export
function/procedure contents.
+1 for general idea.
--
Fabrízio de Royes Mello
of tools and proxies (like Envoy)
that
would do wonders with this. You could safely query a db from a web page
(passing
through proxies that would do auth, TLS, etc). Or maybe a higher performing
gRPC
version (which is also HTTP2 and is amazing), but this makes it a bit more
difficult
to query from a we
sn't my first choice.
As far I understood Jan's proposal is to add enough hooks on PostgreSQL to
enable us to extend the wire protocol and add a contrib module as an
example (maybe TDS, HTTP or just adding new capabilities to current
implementation).
Regards,
--
Fabrízio de Royes Mello
PostgreSQL Developer at OnGres Inc. - https://ongres.com
ndby_logical_decoding_conflicts.pl PROVE_FLAGS=-v"
>
Perfect thanks... will review ASAP!
> wouldn't that make sense to (re)add this patch in the commitfest?
>
Added to next commitfest: https://commitfest.postgresql.org/32/2968/
Regards,
--
Fabrízio de Royes Mello
PostgreSQL Developer at OnGres Inc. - https://ongres.com
he "DROP DATABASE
should drops it's slots, including active slots" section)
>
Awesome and thanks a lot.
Seems your patch series is broken... can you please `git format-patch` and
send again?
Regards,
--
Fabrízio de Royes Mello
PostgreSQL Developer at OnGres Inc. - https://ongres.com
t/023_standby_logical_decoding_conflicts.pl line 67.
# got: 'logical'
# expected: ''
not ok 4 - activeslot on standby dropped
# Failed test 'activeslot on standby dropped'
# at t/023_standby_logical_decoding_conflicts.pl line 68.
# got: '
lly agree... thanks a lot Bruce to help us don’t
miss it.
Regards,
--
Fabrízio de Royes Mello Timbira - http://www.timbira.com.br/
PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento
quot;old" and "new" for the
> copy from the old to a new relation in the new function, so I have
> replaced that by "from" and "to".
>
>
Awesome thanks!!
Regards,
--
Fabrízio de Royes Mello Timbira - http://www.timbira.com.br/
PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento
se. Perhaps others have an opinion on that?
>
Even if we won't use it now, IMHO it is more legible to separate this
responsibility into its own CopyStatistics function as attached.
Regards,
--
Fabrízio de Royes Mello
PostgreSQL Developer at OnGres Inc. - https://ongres.com
diff --git
7;d likely be a more complicated patch than it might seem
> at first glance.
>
If we think about a way to kick AutoAnalyze for sure it will be a more
complicated task but IMHO for now we can do it simply just by copying
statistics like I mentioned above.
Regards,
--
Fabrízio de Royes
On Wed, Oct 28, 2020 at 2:15 AM Michael Paquier wrote:
>
> On Tue, Oct 27, 2020 at 11:06:22AM -0300, Fabrízio de Royes Mello wrote:
> > When we create a new table or index they will not have statistics until
an
> > ANALYZE happens. This is the default behaviour and I
On Tue, Oct 27, 2020 at 4:12 AM Nikolay Samokhvalov
wrote:
>
> On Mon, Oct 26, 2020 at 3:08 PM Fabrízio de Royes Mello <
fabriziome...@gmail.com> wrote:
>>
>> Would be nice if add some information about it into our docs but not
sure where. I'm thinking
the statistics.
fabrizio=# REINDEX INDEX CONCURRENTLY t_idx2;
REINDEX
fabrizio=# SELECT count(*) FROM pg_statistic WHERE starelid =
't_idx2'::regclass;
count
---
0
(1 row)
-- But the REINDEX CONCURRENTLY loses.
So IMHO here is the place we should rework a bit to execut
ndex.sgml
- doc/src/sgml/maintenance.sgml (routine-reindex)
Thoughts?
[1]
https://gitlab.com/gitlab-com/gl-infra/production/-/issues/2885#note_436310499
--
Fabrízio de Royes Mello
PostgreSQL Developer at OnGres Inc. - https://ongres.com
ale discussion, please send a short summary
> update about its current state, open questions, and TODOs. I hope, it
> will encourage reviewers to pay more attention to the thread.
>
Awesome!
--
Fabrízio de Royes Mello Timbira - http://www.timbira.com.br/
PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento
t;
Adding a TOAST can cause circular dependencies between those relations?? If
you don't mind can you explain more about it?
Regards,
--
Fabrízio de Royes Mello Timbira - http://www.timbira.com.br/
PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento
4ddff04-f122-784b-b6c5-3536804495f8%40joeconway.com
--
Fabrízio de Royes Mello Timbira - http://www.timbira.com.br/
PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento
diff --git a/src/include/catalog/toasting.h b/src/include/catalog/toasting.h
index 51491c4513..729bc2cc
On Fri, Sep 4, 2020 at 3:00 PM Andrew Dunstan <
andrew.duns...@2ndquadrant.com> wrote:
>
>
> Thanks, Committed. Further investigation shows this was introduced in
> release 12, so that's how far back I went.
>
Thanks!
--
Fabrízio de Royes Mello Timbira -
On Mon, Jul 13, 2020 at 6:18 PM Fabrízio de Royes Mello <
fabriziome...@gmail.com> wrote:
>
> On Mon, Jul 13, 2020 at 5:05 PM Andrew Dunstan <
> andrew.duns...@2ndquadrant.com> wrote:
> >
> >
> > On 7/13/20 2:46 PM, Fabrízio de Royes Mello wrote:
> > &
On Mon, Jul 13, 2020 at 5:05 PM Andrew Dunstan <
andrew.duns...@2ndquadrant.com> wrote:
>
>
> On 7/13/20 2:46 PM, Fabrízio de Royes Mello wrote:
> >
> >
> > >
> > > yeah, that's the fix I came up with too. The only thing I added was
> &
On Mon, Jul 13, 2020 at 3:29 PM Andrew Dunstan <
andrew.duns...@2ndquadrant.com> wrote:
>
>
> On 7/13/20 10:52 AM, Fabrízio de Royes Mello wrote:
> >
> > On Sat, Jul 11, 2020 at 8:07 PM Andrew Dunstan
> > > <mailto:andrew.duns...@2ndquadrant.com>>
On Mon, Jul 13, 2020 at 11:52 AM Fabrízio de Royes Mello <
fabriziome...@gmail.com> wrote:
>
>
> On Sat, Jul 11, 2020 at 8:07 PM Andrew Dunstan <
andrew.duns...@2ndquadrant.com> wrote:
> >
> >
> > On 6/26/20 2:10 PM, Fabrízio de Royes Mello wrote:
>
On Sat, Jul 11, 2020 at 8:07 PM Andrew Dunstan <
andrew.duns...@2ndquadrant.com> wrote:
>
>
> On 6/26/20 2:10 PM, Fabrízio de Royes Mello wrote:
> >
> > On Fri, Jun 26, 2020 at 11:55 AM Fabrízio de Royes Mello
> > mailto:fabriziome...@gmail.com>> wrote:
>
On Fri, Jun 26, 2020 at 11:55 AM Fabrízio de Royes Mello <
fabriziome...@gmail.com> wrote:
>
>
> On Fri, Jun 26, 2020 at 11:24 AM Andrew Dunstan <
andrew.duns...@2ndquadrant.com> wrote:
> >
> >
> > On 6/26/20 9:57 AM, Andrew Dunstan wrote:
> >
TABLE, which is line
> > 2109 in git tip, is failing.
> >
> >
>
> Should have mentioned this is in src/bin/pg_dump/pg_dump.c
>
Having a look on it.
--
Fabrízio de Royes Mello Timbira - http://www.timbira.com.br/
PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento
e project ideas over ther. My question is that do we have
to select a project from
> there or come up with an idea of our own.
>
If you have a good idea and that idea fit to GSoC felt free to propose
it... the listed ideas are just ideas.
Regards,
--
Fabrízio de Royes Mello
esql.org/wiki/GSoC_2020
As an old PostgreSQL GSoC student I can tell you it's an amazing experience.
Regards,
--
Fabrízio de Royes Mello Timbira - http://www.timbira.com.br/
PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento
On Sun, Mar 15, 2020 at 7:32 AM Peter Eisentraut <
peter.eisentr...@2ndquadrant.com> wrote:
>
>
> I have committed that last one also, after some corrections.
>
IMHO we should also update file_fdw documentation. See attached!
Regards,
--
Fabrízio de Royes Mello
riginal complain. I was just trying to
> > understand completely what you pointed out before and I agree with you.
> > Thanks for the clear explanation.
>
> OK, thanks for confirming that this solves your issue in practice.
>
> > About the patch LGTM and IMHO we sh
t's hard to consider that that pain isn't
> self-inflicted.
>
The proposed patch solve the original complain. I was just trying to
understand completely what you pointed out before and I agree with you.
Thanks for the clear explanation.
About the patch LGTM and IMHO we should back-p
>
IMHO EventTriggers can't be fired during pg_restore under any circumstances
because can lead us to a different database state than the dump used.
> So that leads me to the attached, which renames the "RESTORE_PASS_REFRESH"
> symbol for clarity, and updates the pg_
based on a tag match?
>
By error I meant the weird behavior I described before that pg_restore
create the event triggers in parallel mode and after that other objects are
created then the event trigger is fired during the restore...
Have a look at the new attached patch.
Regards,
--
Fabrízio
On Thu, Feb 13, 2020 at 12:52 AM Michael Paquier
wrote:
> On Wed, Feb 12, 2020 at 01:59:05PM -0300, Fabrízio de Royes Mello wrote:
> > In parallel mode it's firing the EventTrigger and it can't be happen.
> > Poking around it I did some test with attached just to lea
invent
a new RestorePass to take care of it like RESTORE_PASS_ACL and
RESTORE_PASS_REFRESH. I can provide a more polished patch if it'll be a
good way to do that.
Regards,
--
Fabrízio de Royes Mello Timbira - http://www.timbira.com.br/
PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x
r: No!
Long answer: try use the pg_dump binary from your new version (12)
connecting to your old version... is the best practice when you want to
upgrade your PostgreSQL using dump/restore strategy.
Regards,
--
Fabrízio de Royes Mello Timbira - http://www.timbira.com.br/
PostgreSQ
but for now I'm can't imagine a use case
for sessions different than listed above.
Regards,
--
Fabrízio de Royes Mello Timbira - http://www.timbira.com.br/
PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento
check-world) and everything is ok. Changed status to "ready for
commiter".
Regards,
--
Fabrízio de Royes Mello Timbira - http://www.timbira.com.br/
PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento
erything is ok. Your check for normal
backend on test_session_hooks is much simpler than I did before:
+/* just consider normal backends */
+if (MyBackendId == InvalidBackendId)
+return;
But one thing came to my mind, why not in this first version we hook just
normal bac
On Fri, Jul 5, 2019 at 12:22 AM Michael Paquier wrote:
>
> On Thu, Jul 04, 2019 at 01:48:24PM -0300, Fabrízio de Royes Mello wrote:
> > On Thu, Jul 4, 2019 at 10:57 AM Robert Haas
wrote:
> >> It would be pretty silly to have one and not the other, regardless of
> >&
On Thu, Jul 4, 2019 at 5:17 AM Michael Paquier wrote:
>
> On Tue, Jul 02, 2019 at 11:31:49AM -0300, Fabrízio de Royes Mello wrote:
> > New version attached.
>
> This looks in pretty good shape to me, and no objections from me to
> get those functions as the min() flavor is
nd out how much has been replayed at most.
>
> It would be pretty silly to have one and not the other, regardless of
> whether we can think of an immediate use case.
>
+1
--
Fabrízio de Royes Mello Timbira - http://www.timbira.com.br/
PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento
lt;
> +
> + result = ((lsn1 > lsn2) ? lsn1 : lsn2);
> +
> + PG_RETURN_LSN(result);
> +}
>
> rather than using additional variable its more readable and effective to
return the argument
> itself like we do in date data type and other place
>
Fixed.
New version a
On Thu, Jun 6, 2019 at 6:38 AM Peter Eisentraut <
peter.eisentr...@2ndquadrant.com> wrote:
>
> On 2019-06-05 22:31, Fabrízio de Royes Mello wrote:
> > On Wed, Jun 5, 2019 at 5:17 PM Peter Eisentraut
> > > <mailto:peter.eisentr...@2ndquadrant.com>> wrote:
>
ATE COLLATION, and createdb.
>
> With collation providers other than libc, having separate lc_collate and
> lc_ctype settings is not necessarily applicable, so this is also
> preparation for such future functionality.
>
Cool... would be nice also add some test cases.
Regards,
--
Fabríz
is can help distinguish which command is running and thus
> > which phases to expect. It seems reasonable to keep these views
> > consistent, too. (They are both new in PG12.) Patch attached.
>
> +1.
>
+1
--
Fabrízio de Royes Mello Timbira - http://www.timbira.co
blishable tables you have ...
>
> Given that this change impacts the regression test results, project
> rules say that it should come with a catversion bump. Since we are
> certainly going to have a catversion bump before beta2 because of
> the pg_statistic_ext permissions business
0x25ed850) at
postmaster.c:1376
#17 0x00977de8 in main (argc=3, argv=0x25ed850) at main.c:228
Isn't better raise an exception as you did in other functions??
static void
toyam_relation_vacuum(Relation onerel,
struct VacuumParams *params,
BufferAccessStrategy bstrategy)
{
ereport(ERROR,
(errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
errmsg("function %s not implemented yet", __func__)));
}
Regards,
--
Fabrízio de Royes Mello Timbira - http://www.timbira.com.br/
PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento
Hi all,
The attached patch just a very minor adjustment to
src/bin/pg_checksums/pg_checksums.c to add new line between some IF
statements.
Regards,
--
Fabrízio de Royes Mello Timbira - http://www.timbira.com.br/
PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento
On Fri, Mar 22, 2019 at 10:27 PM Michael Paquier
wrote:
>
> On Fri, Mar 22, 2019 at 04:49:57PM -0300, Fabrízio de Royes Mello wrote:
> > So attached patch aims to introduce MIN/MAX aggregate functions to
pg_lsn
>
> Fine by me. This looks helpful for monitoring.
>
> Plea
value in column "id" for relation "nn" violates not-null
constraint
>
> It causes breakage in multiple tests, which is easy to fix once/if we
agree to change.
>
I totally agree with that change because I already get some negative
feedback from users about this me
/MAX aggregate functions to pg_lsn
datatype.
Regards,
--
Fabrízio de Royes Mello Timbira - http://www.timbira.com.br/
PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento
diff --git a/doc/src/sgml/func.sgml b/doc/src/sgml/func.sgml
index 1a01473..490f3a8 100644
--- a
1 - 100 of 125 matches
Mail list logo
