ension as normal or just before any tables
which rely on it).
Cheers,
James Sewell,
--
The contents of this email are confidential and may be subject to legal or
professional privilege and copyright. No representation is made that this
email is free of viruses or other defects. If you have receive
On Tue, 3 Sep 2019 at 7:15 am, Adrian Klaver
wrote:
> On 9/2/19 2:04 PM, James Sewell wrote:
> Please reply to list also.
> Ccing list.
> >
> >
> > On Mon, 2 Sep 2019 at 11:56 pm, Adrian Klaver > <mailto:adrian.kla...@aklaver.com>> wrote:
> >
On Tue, 3 Sep 2019 at 7:41 am, Adrian Klaver
wrote:
> On 9/2/19 2:20 PM, James Sewell wrote:
>
> >
> > So this is a separate cluster from the one you used pg_upgrade on?
> >
> >
> > In that case yes it was seperate
> >
> >
> >
> >
>
>
>
> > I am going to assume then that it has to do with this:
> > "LINE 39: "location_pt" "public"."geography"(Point,4283), "
> >
> > What is the above pointing to?
> >
> >
> > This needs the PostGIS types and tables to work - they don't exist as
> > they were not created with CR
On Tue, 3 Sep 2019 at 07:55, Adrian Klaver
wrote:
> On 9/2/19 2:45 PM, James Sewell wrote:
> >
> >
> > On Tue, 3 Sep 2019 at 7:41 am, Adrian Klaver > <mailto:adrian.kla...@aklaver.com>> wrote:
> >
> > On 9/2/19 2:20 PM, James Sewell wrote:
> &
On Tue, 3 Sep 2019 at 10:34, Adrian Klaver
wrote:
> On 9/2/19 5:20 PM, James Sewell wrote:
> >
>
> > What is the pg_upgrade command you are using?
> >
> >
> > pg_upgrade --link --username postgres
>
> Where are you in being able to?:
> https://www
ic is wrong. Creating an empty
extension is fine and makes sense but extension owned relations should be
created as the next step, not just at some time later.
>
>
>
> >
> >>
> >> >
> >> > I have set PGBINOLD, PGBINNEW, PGDATAOLD, PGDATANEW correctly.
b.com/postgis/postgis/blob/svn-trunk/postgis/gserialized_typmod.c#L296
)
On Wed, 4 Sep 2019 at 10:03, Adrian Klaver
wrote:
> On 9/3/19 3:45 PM, James Sewell wrote:
> >
> >
>
> >
> > -- For binary upgrade, create an empty extension and insert objects
> >
heers,
James Sewell,
--
The contents of this email are confidential and may be subject to legal or
professional privilege and copyright. No representation is made that this
email is free of viruses or other defects. If you have received this
communication in error, you may not copy or distribut
Is it expected that a lock on a partitioned table will take out 2 locks per
child regardless of the number of children which are excluded at plan time?
For example I can select count(*) from a table with 3500 partitions in
transaction, and see 7000 AccessShareLocks show up till I finish the
transa
re working with massively partitioned tables, increasing
> max_locks_per_transaction is a good idea.
It’s 256 at the moment, with 600 connections - guess I need more.
--
James Sewell,
Chief Architect
Suite 112, Jones Bay Wharf, 26-32 Pirrama Road, Pyrmont NSW 2009
P (+61) 2 8099 9000 W www.
will have been sized for that maximum
> and can't be grown.) See comments for ShmemInitHash.
How much memory is consumed per configured lock? Is this removed from the
shared buffers size or added to it?
Thanks for the follow up!
>
> --
James Sewell,
Chief Architect
Suite 112,
James Sewell,
--
The contents of this email are confidential and may be subject to legal or
professional privilege and copyright. No representation is made that this
email is free of viruses or other defects. If you have received this
communication in error, you may not copy or distribute any part
e across multiple customers and it works very well
(and most importantly at that scale, very efficiently).
I've found the team really responsive to issues / bugs / errors reported
via GitHub when we hit them, which is always a bonus.
James Sewell,
*Chief Architect, Jirotech*
Suite 46, Jones Ba
- wait for shutdown (archiving will finish)
- Identify last archived WAL file name (ensure it’s on backup server.)
- wait till a standby has applied this WAL
- promote that standby
- attach old master to new master
Cheers,
James Sewell
--
James Sewell,
*Chief Architect, Jirotech*
Suite 46, Jones Bay
> - open connection to database
> - smart shutdown master
> - terminate all other connections
> - wait for shutdown (archiving will finish)
>
OK despite what it looked like from the code - upon testing it seems like
even a fast shutdown will wait for logs to be archived *as long as progress
is bei
>
> (2)
>
> I'll use this C code as an example to build an extention in Rust. The
> Postgresql bindings for Rust I have don't contain a definition of
> `FirstLowInvalidHeapAttributeNumber` for some reason. I can define it
> since it's simply single digit constant.
>
Not an answer to your question
>
> Right, the first step would be for a WSL user to figure out what's
> wrong with builds on the WSL and show us how to fix it; I heard
> through the grapevine that if you try it, initdb doesn't work (it must
> be something pretty subtle in the configure phase or something like
> that, since the U
> What do you mean by "not being included by #ifdef blocks"? The only
> guard in issue_xlog_fsync() is #ifdef HAVE_FDATASYNC, which ought to be
> independent of any includes? I can see how this'd go wrong if configure
> did *not* detect fdatasync, because then
>
And now this looks like it works a
> Here's a starter patch that shows one of the approaches discussed. It
> gets WSL users to a better place than they were before, by suppressing
> further warnings after the first one.
>
This wasn't quite right, updated to check erro for ENOSYS (not rc)
This compiles and stops the panic on WSL (
Hi,
This is a bit of an odd one - I'm on PostgreSQL 11.9 with a single
streaming replica.
The system handles a lot of connections - we have a max_connections of 600.
Most are long lived JDBC, but there are a lot of ETL / ad-hoc jobs etc.
Connections normally sit at 300ish, with 70 active at the
>
> What are you looking at to claim the number of connections is under 600?
> Maybe there's some disconnect between what you're measuring and what the
> database thinks.
>
> A different line of thought is that ProcArray slots can be consumed by
> things that aren't client connection processes, in
>
> > Sorry, I could have been clearer - pg_stat_activity is what I'm looking
> > at - I'm recording connection info from here every 15 seconds (from a
> > superuser account so I don't get locked out). It never peaks above 300
> > (in fact when the incident happens no new connections can come in so
>
>
> So I guess the question becomes why are they spending so much time in
> the startup state. That should take mere milliseconds, unless the
> clients are being slow to handle the authentication exchange?
>
> I'm also wondering a bit about whether they're being blocked on a lock,
> eg. due to s
> The enterprisedb is one of their customized versions?
>
> rundeck_cluster below refers to https://digital.ai/technology/rundeck?
>
>
re: EnterpriseDB yes it is - I'm having this same discussion with them in
parallel
re: rundeck, yes - but this is only one of many things connecting. it's not
doing
> > re: EnterpriseDB yes it is - I'm having this same discussion with them
> > in parallel
>
> What version of theirs?
>
PostgreSQL 11.9 (EnterpriseDB Advanced Server 11.9.18) on
x86_64-pc-linux-gnu, compiled by gcc (GCC) 4.8.5 20150623 (Red Hat
4.8.5-36), 64-bit
>
>
> > re: rundeck, yes - but th
>
>
> > It's used to trigger ETL jobs. There are other bigger consumers of
> > connections - the issue isn't the stream of jobs, that works fine under
> > normal operation. The issue is that when jobs stay in "startup" and
> > don't enter pg_stat_activity the system spirals downwards and no new
> >
>
> The hypothesis I'm thinking of is that incoming sessions are being blocked
> somewhere before they can acquire a ProcArray entry; if so, they'd not
> show up in either pg_stat_activity or pg_locks. What we have to look for
> then is evidence of somebody holding a strong lock on a shared relati
> > Seems like some of the processes are taking a long time or stuck while
> > reading/writing SLRU pages, and due to that while creating a new
> > connection the backend process is not able to check the transaction
> > status (from pg_xlog) of the pg_class tuple and gets stuck/taking a
> > long ti
>
> How did you verify that, maybe some process started IO and stuck
> there? Can we check pg_stat_activity that is there some process that
> shows in the wait event as SLRURead/SLRUWrite and not coming out of
> that state?
There are no interesting entries in pg_stat_activity, and no wait events
> Looking again into the back trace[1], it appeared that the backend is
> getting stuck while getting the subtransaction's parent information,
> and that can only happen if the snapshot is getting marked as
> overflowed. So it seems that some of the scripts are using a lot of
> sub-transaction (>
>
> I expect my 'vote' counts for naught, but I fully expect seeing these show
> up in the logs would have helped me much more quickly have insight into
> what was going on during times of very high concurrency and extreme
> slowness with many processes showing as waiting on LwLocks.
>
Is there an
>
> Agreed with both points. What about we add, subxid count and overflow
> status in LocalPgBackendStatus and through that, we can show in
> pg_stat_activity. That way we don't have to report it ever and
> whenever the user is running pg_stat_activity they can fetch it
> directly from "proc->sub
+1, I too like the idea. The patch doesn't seem to be doing any heavy
> lifting, I think that much overhead should be acceptable.
>
I'm guessing this won't be back-patched? Is it possible to somehow read
this information from a C function?
- James
--
The contents of this email are confidential
>
>
> I'm guessing this won't be back-patched? Is it possible to somehow read
> this information from a C function?
>
>
Ok it is possible, I've got a C extension up and running which hooks
ExecutorStart, then once for each TX ( I monitor the nesting depth like in
pg_stat_statements, and only attac
> Ok it is possible, I've got a C extension up and running which hooks
> ExecutorStart, then once for each TX ( I monitor the nesting depth like in
> pg_stat_statements, and only attach at the top level) attaches a sub
> transaction callback, tracking start subtransaction events and incrementing
>
36 matches
Mail list logo
