ing the work done in the time available.
I don't see any problems with that as a feature, but AFAIK there are
no plans for that.
--
Simon Riggshttp://www.EnterpriseDB.com/
might
> meet your goals.
The overhead of Bucardo has been measured as being more than 3x that
of logical replication.
--
Simon Riggshttp://www.EnterpriseDB.com/
e it further.
>
The max value is much higher than 30. Why can you not increase it further?
--
Simon Riggshttp://www.EnterpriseDB.com/
<http://www.enterprisedb.com/>
ng to
> eliminate them
> But if there is no way, ok
They might be optimized away one day, but for now, they are essential.
--
Simon Riggshttp://www.EnterpriseDB.com/
On Tue, 13 Sept 2022 at 12:45, Marcos Pegoraro wrote:
> So, there is a way to eliminate these useless toast tables ?
What problem do they cause you?
--
Simon Riggshttp://www.EnterpriseDB.com/
On Mon, 12 Sept 2022 at 16:00, Tom Lane wrote:
>
> Simon Riggs writes:
> > On Sun, 21 Aug 2022 at 19:04, Tom Lane wrote:
> >> There are existing equations for calculating Gregorian month/day/year from
> >> Julian day count [1]. They work back to Julian day zero, a
n of 1 day.
Could we allow dates earlier than that, as long as we fix them to the
1st day of any particular month, so the effective resolution becomes
"1 month" before 4713BC? (With various and appropriate restrictions).
--
Simon Riggshttp://www.EnterpriseDB.com/
values ('-5000 years');
select * from arch;
i
-
-5000 years
This can also be used in a column specification like this INTERVAL
YEAR TO MONTH, which would store only years and months.
e.g.
CREATE TABLE arch (age INTERVAL YEAR TO MONTH);
Will that be sufficient, or do you need or want more?
--
Simon Riggshttp://www.EnterpriseDB.com/
en when a missed interrupt was triggered.
>
> I'm convinced your patch improves robustness under the scenario we saw.
Cool, thanks
--
Simon Riggshttp://www.EnterpriseDB.com/
at it is needed for all cases.
ISTM that we could take a temporary/not-for-whole-transaction lock to
inspect whether the required trigger is already there and if so, avoid
taking the lock on the referenced table each time.
--
Simon Riggshttp://www.EnterpriseDB.com/
ation and a new
call to check/reset any missing alarms? Or alternatively, contribute
the function library that fetches remote resources, so that can become
an optional part of Postgres, in contrib.
--
Simon Riggshttp://www.EnterpriseDB.com/
On Wed, 12 Jan 2022 at 13:17, Simon Riggs wrote:
>
> On Wed, 12 Jan 2022 at 10:31, Julien Rouhaud wrote:
> >
> > On Wed, Jan 12, 2022 at 10:22:38AM +, Simon Riggs wrote:
> > > On Wed, 12 Jan 2022 at 03:03, Julien Rouhaud wrote:
> > > >
> >
On Wed, 12 Jan 2022 at 10:31, Julien Rouhaud wrote:
>
> On Wed, Jan 12, 2022 at 10:22:38AM +, Simon Riggs wrote:
> > On Wed, 12 Jan 2022 at 03:03, Julien Rouhaud wrote:
> > >
> > > Unfortunately this is a known limitation.
> >
> > I see this as a b
e some previous discussions (e.g. [1] and [2] more recently), but I
> don't think there was a real consensus on how to solve that problem.
To differentiate, run each schema using a different user, so you can
tell them apart.
--
Simon Riggshttp://www.EnterpriseDB.com/
On Tue, 12 Oct 2021 at 23:07, Tomas Vondra
wrote:
> So yeah, there's an explicit 1GB limit per value, but having rows close
> to the 1GB limit is going to cause all sorts of unpredictable and rather
> painful issues :-(
Sounds worth mentioning in doc/src/sgml/limits.sgml
-
On Tue, 12 Oct 2021 at 18:53, Michael Lewis wrote:
>
> On Tue, Oct 12, 2021 at 1:43 AM Simon Riggs
> wrote:
>>
>> On Tue, 12 Oct 2021 at 08:14, Ram Pratap Maurya
>> wrote:
>>
>> > Confirm what is Avg/max size of these JSON docs in Postgres.
>>
&g
On Tue, 12 Oct 2021 at 08:14, Ram Pratap Maurya
wrote:
> Confirm what is Avg/max size of these JSON docs in Postgres.
JSON and JSONB datatypes can both be max 1GB in size.
--
Simon Riggshttp://www.EnterpriseDB.com/
ata or the data model may be performed?
PostgreSQL doesn't require you to eject all other users while such
actions are performed, so we haven't spent a lot of time thinking
about how to deny people access.
What maintenance actions are you thinking are a problem?
--
Simon
> > creating roles in one Database, they are visible in other Databases.
>
> You can't, roles are global objects in a cluster.
Roles are global objects that are visible in all databases.
But you can GRANT the CONNECT privilege for a role to only specific databases.
--
Simon Riggshttp://www.EnterpriseDB.com/
That's not the way the APIs are defined.
Creating 2 publications should not be a problem.
Specifying the metadata for your situation would be about the same
complexity in all cases.
--
Simon Riggshttp://www.EnterpriseDB.com/
t giving
> following
> core. When we increase the max_connections then core come again but
> it take more hours to come.
>
> Program terminated with signal 11, Segmentation fault.
Sounds like a memory leak. In libpq programs this is often caused by
forgettin
= minimal then this might work.
The total number indicates you are using too many partitions and
should probably lower that by a factor of about 100.
If you do that, you probably won't need to set wal_level.
--
Simon Riggshttp://www.EnterpriseDB.com/
returns integer
language sql as $$ select 1; $$ set search_path = 'public';
CREATE FUNCTION
postgres=# \timing
Timing is on.
postgres=# select sum(proconfig1()) from generate_series(1,1);
sum
---
10000
(1 row)
Time: 2.818 ms
postgres=# select sum(proconfig2()) from generate_series(1,1);
sum
---
1
(1 row)
Time: 41.750 ms
So the overhead would be 4us per call? Other tests show that is
roughly the same situation for PLpgSQL functions.
Can't see anything to document as yet.
--
Simon Riggshttp://www.EnterpriseDB.com/
On Wed, 4 Nov 2020 at 23:29, Steve Singer wrote:
>
>
> It is with much sadness that I am letting the community know that Chris
> Browne passed away recently.
Sad news. He was a good man and a valued contributor.
--
Simon Riggshttp://www.EnterpriseDB.com/
On Mon, 6 Jul 2020 at 21:49, David Rowley wrote:
> On Tue, 7 Jul 2020 at 00:43, Simon Riggs wrote:
> >
> > On Mon, 6 Jul 2020 at 12:37, Robins Tharakan wrote:
> >
> >>
> >> When an SQL needs to UNION constants on either side, it should be
> possible
1) UNION (SELECT 1 FROM pg_class limit 1);
> -- Faster
>
Those two queries aren't logically equivalent, so you can't apply the LIMIT
1 as an optimization.
First query returns lots of random rows, the second query returns just one
random row.
--
Simon Riggs
to open source PostgreSQL. We will continue to contribute
features from BDR to open source PostgreSQL over time, subject to community
acceptance.
--
Simon Riggshttp://www.2ndQuadrant.com/
<http://www.2ndquadrant.com/>
Mission Critical Databases
ly matter when that will
> happen - but with my docker image which is automatically build it would
> be nice to have a deterministic way of trigger that to reduce the final
> size image.
The size of the task varies, so sometimes takes longer than 60s, depending
upon your hardware.
--
Sim
e max_id too quickly, and remember which ones
you've already checked. Or wait for the next monontonic value each time,
accepting the lag.
--
Simon Riggshttp://www.2ndQuadrant.com/
<http://www.2ndquadrant.com/>
PostgreSQL Solutions for the Enterprise
o back and check for trends
on that.
Having said all of that, its easy to point at some of these things and use
them as FUD - fear, uncertainty and doubt. No doubt unintentionally.
I'd go and learn more from your lecturer. Your disagreement has made you
think, so he helped you. Learning fr
but its clear that you can do multiple
detaches in one command at present.
But it sounds like a great feature.
--
Simon Riggshttp://www.2ndQuadrant.com/
<http://www.2ndquadrant.com/>
PostgreSQL Solutions for the Enterprise
x that doesn't overlap partition keys would be
* unfeasibly huge
* likely to hit the 32TB limit on relations
* unable to cope with dropping partitions
It sounds like you want it, cos its just a line of DDL, but in practice
your colleagues wouldn't want those things.
--
Simon Riggshttp://www.2ndQuadrant.com/
<http://www.2ndquadrant.com/>
PostgreSQL Solutions for the Enterprise
On 4 August 2018 at 07:56, Michael Paquier wrote:
> On Sat, Aug 04, 2018 at 07:44:59AM +0100, Simon Riggs wrote:
>> I think the problem is that writing the online checkpoint is deferred
>> after promotion, so this is a timing issue that probably doesn't show
>&g
probably doesn't show
in our regression tests.
Sounds like we should write a pending timeline change to the control
file and have pg_rewind check that instead.
I'd call this a timing bug, not a doc issue.
--
Simon Riggshttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
ssary to counter-complain in order
for the alleged violator to get their say.
Would it not be better to consider arbitration as the first step in
dispute resolution? Do we need judgement by a committee as the first
step? Do we even have time for judges to judge?
Thanks for working on this.
-
>
> I don't think it would be safe to do PITR on a backup taken in this way.
If you have all the WAL files, then it would be safe.
> The WAL diverges even if you suppress a timeline switch.
Which is exactly why we have timelines.
--
Simon Riggshttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
stgresql.org/contact.php
>
> Just to follow this up: I pushed pgaudit12_10 (pgaudit 1.2 for PostgreSQL 10)
> 2
> weeks ago.
Very good, thank you Devrim.
--
Simon Riggshttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
oreign keys nowadays during selectivity
> estimation.
>
> I do still have all the code I wrote all those years ago, and possibly
> it will still apply to master as I rebased it just several months ago.
> I've just not yet come up with any bright ideas on how to solve t
38 matches
Mail list logo
