On Tue, Feb 27, 2018 at 4:18 AM, Tom Kazimiers wrote:
> On Mon, Feb 26, 2018 at 11:15:44PM +1300, Thomas Munro wrote:
>> On Sat, Feb 24, 2018 at 4:47 PM, Tom Kazimiers
>> wrote:
>> Thanks for the reproducer. Yeah, that seems to be a bug.
>> nodeNamedTuplestorescan.c a
On Wed, Feb 28, 2018 at 9:58 AM, Tom Lane wrote:
> Thomas Munro writes:
>> Here's a new version with tuplestore_select_read_pointer() added in
>> another place where it was lacking, and commit message. Moving to
>> -hackers, where patches go.
>
> Pushed, along
arity is
that the various sub-plans can finish at different times leaving some
CPU cores with nothing to do while others are still working, whereas
block granularity keeps everyone busy until the work is done and
should finish faster.
--
Thomas Munro
http://www.enterprisedb.com
On Thu, Apr 5, 2018 at 5:16 PM, David G. Johnston
wrote:
> On Wed, Apr 4, 2018 at 10:12 PM, Thomas Munro
> wrote:
>>
>> Parallel query can't be used for CTE queries currently.
>
> A pointer to the location in the docs covering this limitation would be
> app
3 members, etc... so
that's n - 1 multixacts and (n * (n + 1)) / 2 - 1 members.
--
Thomas Munro
http://www.enterprisedb.com
nk about
pg_flush_data() in fd.c? It does mmap(), msync(), munmap() to try to
influence writeback? I wonder if at least on some operating systems
that schlepps a bunch of data out of ZFS ARC into OS page cache, kinda
trashing the latter?
--
Thomas Munro
http://www.enterprisedb.com
finishes up slurping it back
into memory even though we're just going to overwrite it, and it can't see
that because our writes don't line up with the ZFS record size, possibly
unlike ye olde write-in-place 4k block filesystems, but that's just my
guess). Does your machine have ECC RAM?
--
Thomas Munro
http://www.enterprisedb.com
KD4SuX06wa4ATsesaqg%40mail.gmail.com
There was a ZoL bug that made headlines recently but that was in 0.7.7
so not relevant to your case.
--
Thomas Munro
http://www.enterprisedb.com
org/message-id/flat/87sh48ffhb@news-spur.riddles.org.uk
[1] https://www.postgresql.org/docs/10/static/parallel-safety.html
--
Thomas Munro
http://www.enterprisedb.com
che .
> I know pg_buffercache ,but it just examine the table in the shared buffer of
> Postgresql, not the table in the OS cache.
This is a quick and dirty hack, but it might do what you want:
https://github.com/macdice/pgdata_mincore
Tested on FreeBSD, not sure how well it'll travel.
--
Thomas Munro
http://www.enterprisedb.com
On Wed, Sep 19, 2018 at 7:44 PM Cédric Villemain wrote:
> Le 19/09/2018 à 05:29, Thomas Munro a écrit :
> > On Wed, Sep 19, 2018 at 1:35 PM jimmy wrote:
> >> I use select pg_prewarm('table1','read','main') to load data of table1
> >> int
lly we only overwrite that
file, so after creation it should stay the same size.
--
Thomas Munro
http://www.enterprisedb.com
hink it's impossible to choose a single value for work_mem if you
have a mixture of types of queries that hit wildly different numbers
of partitions and workers. I think this is an ongoing topic for
-hackers.
--
Thomas Munro
https://enterprisedb.com
r each node you see in the
EXPLAIN plan, and for each process, so it can be quite a lot if you
have lots of parallel worker processes and/or lots of
tables/partitions being sorted or hashed in your query.
--
Thomas Munro
https://enterprisedb.com
is used by individual
operations. Usually it's regular private anonymous memory, but for
Parallel Hash it's /dev/shm memory.
--
Thomas Munro
https://enterprisedb.com
Parallel Hash (cost=636676233.38..636676233.38
> rows=20353804801 width=31)
> -> Parallel Seq Scan on my_table
> (cost=0.00..636676233.38 rows=20353804801 width=31)
>Filter: (flag = ''::bit(16))
It's s
ans do seem to exist in the wild; I don't recall exactly
why). I think we need a bit of a redesign so that if there are
multiple Gather nodes, they share the same main DSM segment, instead
of blowing through this limit.
--
Thomas Munro
https://enterprisedb.com
On Tue, Oct 29, 2019 at 9:23 PM ZhenHua Cai wrote:
> No, it doesn't call any in-core code.
I wondered if this could be coming from the new code in
src/port/pg_p{read,write}.c. ERROR_HANDLE_EOF is a documented
GetLastError() return value after ReadFile() fails[1], but only for
asynchronous files.
On Wed, Nov 6, 2019 at 12:02 PM Adrian Klaver wrote:
> On 11/5/19 3:00 PM, Chris Withers wrote:
> > Hmm. Is there any option to use the system timezone packages?
>
> https://www.postgresql.org/docs/11/install-procedure.html
>
> --with-system-tzdata=DIRECTORY
By the way, you can see if your instal
On Wed, Nov 6, 2019 at 2:20 PM Tom Lane wrote:
> Thomas Munro writes:
> > On Wed, Nov 6, 2019 at 12:02 PM Adrian Klaver
> > wrote:
> >> On 11/5/19 3:00 PM, Chris Withers wrote:
> >>> Hmm. Is there any option to use the system timezone packages?
>
>
On Wed, Nov 13, 2019 at 3:40 AM Palle Girgensohn wrote:
> The decision to use postgresql's tzdata is quite old. It was based on the
> assumption that postgres is updated more frequently than the operating
> system, and that for that reason it was better to use postgresql's tzdata,
> since it wo
On Sat, Nov 16, 2019 at 8:38 AM Tom Lane wrote:
> Palle Girgensohn writes:
> >> 6 nov. 2019 kl. 03:03 skrev Thomas Munro :
> >>> *It looks like FreeBSD's port uses the copy of tzdata from the
> >>> PostgreSQL source tree by default and thus that is wha
On Sat, Nov 16, 2019 at 7:13 PM Tom Lane wrote:
> Palle Girgensohn writes:
> > 15 nov. 2019 kl. 21:32 skrev Thomas Munro :
> >> Ugh. It doesn't have the old backward compatibility names like
> >> US/Pacific installed by default, which is a problem if that&#x
On Wed, Oct 30, 2019 at 12:13 AM Thomas Munro wrote:
> On Tue, Oct 29, 2019 at 9:23 PM ZhenHua Cai wrote:
> > No, it doesn't call any in-core code.
>
> I wondered if this could be coming from the new code in
> src/port/pg_p{read,write}.c. ERROR_HANDLE_EOF is a documented
On Wed, Dec 11, 2019 at 4:17 AM Fabio Ugo Venchiarutti
wrote:
> On 10/12/2019 15:06, Tom Lane wrote:
> > =?utf-8?B?0J7Qu9C10LMg0KHQsNC80L7QudC70L7Qsg==?= writes:
> >> According to the documentation
> >> https://www.postgresql.org/docs/12/runtime-config-connection.html
> >> A backend must check co
On Fri, Dec 13, 2019 at 5:00 AM Dave Halter wrote:
> I have worked quite a bit with serializable transactions. I'm trying
> to understand when predicate locks are freed. I read the whole
> README-SSI [1], but I'm still not sure when a predicate lock gets
> dropped.
>
> What I learned from that REA
On Wed, Dec 18, 2019 at 5:12 AM Steven Winfield
wrote:
> * I observe this even if I crank up the transaction isolation level to
> repeatable read and serializable.
Huh. SERIALIZABLE shouldn't allow two transactions to see no result
row for a given ID and then insert a result row for that ID. O
On Wed, Jan 8, 2020 at 4:32 AM İlyas Derse wrote:
> I want to register C code to PostgreSql on Windows. So I think, I have to
> make a extension for PostgreSql. But I did not find to written extension on
> windows. Do you have an idea ?
I don't do Windows myself but this blog from Craig Ringer
On Wed, Jan 22, 2020 at 4:06 AM Nicola Contu wrote:
> after a few months, we started having this issue again.
> So we revert the work_mem parameter to 600MB instead of 2GB.
> But the issue is still there. A query went to segmentation fault, the DB went
> to recovery mode and our app went to read
On Wed, Jan 29, 2020 at 10:37 PM Nicola Contu wrote:
> This is the error on postgres log of the segmentation fault :
>
> 2020-01-21 14:20:29 GMT [] [4]: [108-1] db=,user= LOG: server process
> (PID 2042) was terminated by signal 11: Segmentation fault
> 2020-01-21 14:20:29 GMT [] [4]: [1
On Wed, Jan 29, 2020 at 11:24 PM Julian Backes wrote:
> we only had the "too many shared too many dynamic shared memory segments"
> error but no segmentation faults. The error started occurring after upgrading
> from postgres 10 to postgres 12 (server has 24 cores / 48 threads, i.e. many
> para
On Wed, Jan 29, 2020 at 11:53 PM Thomas Munro wrote:
> On Wed, Jan 29, 2020 at 10:37 PM Nicola Contu wrote:
> > This is the error on postgres log of the segmentation fault :
> >
> > 2020-01-21 14:20:29 GMT [] [4]: [108-1] db=,user= LOG: server process
> > (
On Thu, Jan 30, 2020 at 12:26 AM Thomas Munro wrote:
> On Wed, Jan 29, 2020 at 11:24 PM Julian Backes wrote:
> > we only had the "too many shared too many dynamic shared memory segments"
> > error but no segmentation faults. The error started occurring after
> >
On Fri, Jan 31, 2020 at 11:05 PM Nicola Contu wrote:
> Do you still recommend to increase max_conn?
Yes, as a workaround of last resort. The best thing would be to
figure out why you are hitting the segment limit, and see if there is
something we could tune to fix that. If you EXPLAIN your queri
On Fri, Feb 7, 2020 at 1:47 AM Nick Renders wrote:
> Thank you for the feedback, Alvaro.
>
> Unfortunately, the database is no longer "dumpable". We were able to do
> a pg_dump yesterday morning (12 hours after the crash + purging the
> pg_clog) but if we try one now, we get the following error:
>
On Sun, Feb 9, 2020 at 11:46 AM Tom Lane wrote:
> "Nick Renders" writes:
> > When we do the following statement:
> > SELECT * FROM f_gsxws_schedule WHERE UPPER(gwsc_dossier) = 'TEST'
> > the Postgres service restarts.
>
> Hm.
>
> > Here is what is logged:
> > 2020-02-08 20:21:19.942 CET [83
On Mon, Feb 10, 2020 at 4:35 AM Marc wrote:
> We will keep the 12.1 in place so that we can run additional tests to assist
> to pin-point the issue.
>
> Feel free to ask but allow us to recover from these hectic days ;-)
Here's how to get a stack so we can see what it was doing, assuming
you hav
On Wed, Feb 26, 2020 at 7:37 AM Adrian Klaver wrote:
> On 2/25/20 10:23 AM, Mani Sankar wrote:
> > Hi Adrian,
> >
> > Both the machines are in same network and both are pointing towards the
> > same LDAP server
>
> I don't see any errors in the Postgres logs.
>
> You probably should take a look at
On Sat, Mar 28, 2020 at 4:46 AM Tom Lane wrote:
> Matthias Apitz writes:
> > In short, it there a way to let \COPY accept such broken ISO bytes, just
> > complaining about, but not stopping the insert of the row?
>
> No. We don't particularly believe in the utility of invalid data.
>
> If you do
On Thu, Apr 2, 2020 at 9:25 PM Kyotaro Horiguchi
wrote:
> I provided the subject, and added -hackers.
>
> > Hello,
> > I am running postgres 11.5 and we were having issues with shared segments.
> > So I increased the max_connection as suggested by you guys and reduced my
> > work_mem to 600M.
> >
On Tue, Apr 7, 2020 at 8:58 PM Nicola Contu wrote:
> So that seems to be a bug, correct?
> Just to confirm, I am not using NFS, it is directly on disk.
>
> Other than that, is there a particular option we can set in the postgres.conf
> to mitigate the issue?
Hi Nicola,
Yeah, I think it's a bug.
On Wed, Oct 9, 2019 at 3:59 PM Guy Burgess wrote:
> The manual says:
> https://www.postgresql.org/docs/current/sql-createtrigger.html
>
> A column list cannot be specified when requesting transition relations.
>
> And (I think the same point):
>
> The standard allows transition tables to be used
On Tue, May 5, 2020 at 10:13 AM Peter wrote:
> BTW, I would greatly appreciate if we would reconsider the need for
> the server to read the postmaster.pid file every few seconds (probably
> needed for something, I don't know).
> That makes it necessary to set atime=off to get a spindown, and I
> u
On Tue, May 12, 2020 at 2:52 PM Tory M Blue wrote:
> It took the change but didn't help. So 10GB of shared_buffers in 12 is still
> a no go. I'm down to 5GB and it works, but this is the same hardware, the
> same exact 9.5 configuration. So I'm missing something. WE have not had to
> mess with
On Sun, May 17, 2020 at 10:45 AM Hugh wrote:
> While this doesn't appear to be a bug that causes problems of any kind, I do
> have a question about its cause.
>
> The "error" listed in the Subject: line is basically what I'm seeing. The
> entire message is below, particularly the 'N:' at the end
On Fri, May 22, 2020 at 7:48 AM Mike Klaas wrote:
> locktype: page
> relation::regclass::text: _pkey
> virtualtransaction: 36/296299968
> granted:t
> pid:2263461
That's an unusually high looking pid. Is that expected, for example
did you crank Linux's pid_max right up, or is this AIX, or somethi
On Fri, May 22, 2020 at 7:48 AM Mike Klaas wrote:
> It's my understanding that these locks should be cleared when there are no
> conflicting transactions. These locks had existed for > 1 week and we have
> no transactions that last more than a few seconds (the oldest transaction in
> pg_stat_a
On Thu, Jun 4, 2020 at 4:26 PM Ron wrote:
> On 6/3/20 2:57 PM, Rob Sargent wrote:
> >> On Jun 3, 2020, at 1:46 PM, Tom Lane wrote:
> >> Guyren Howe writes:
> >>> Is it practical to provide the SQL Server-like feature in Postgres?
> >> No.
> > That got me chuckling.
> > I had just decided not to
On Thu, Jun 4, 2020 at 6:18 AM Sonam Sharma wrote:
>>> 1) Postgres version : 11.2
FYI This is missing over a year's worth of bugfixes. That said, I
don't know of anything fixed that has this symptom.
>>> 4) Is this only with one query and if so what is it doing? : No , few
>>> queries work, fe
>> Do you see any other errors around this one, in the PostgreSQL logs?
> No , only this is the error from db and jdbc end .. and queries are failing
If you need a workaround right now you could always set
max_parallel_workers_per_gather=0 so that it doesn't try to use
parallel query. That could
On Fri, Jun 5, 2020 at 1:00 AM Sonam Sharma wrote:
> The dynamic_shared_memory_type was set to POSIX . Because of this it was
> using tmpfs /dev/shm. When the query was running I saw the file system was
> filling. So I extended the file system and luckily the query worked for that
> time
Oh,
On Tue, Jun 9, 2020 at 9:05 AM Chris Stephens wrote:
> hostsslall all 0.0.0.0/0 ldap
> ldapserver="ldaps://xxx" ldapbasedn="yyy" ldaptls=1
> does anyone know what might be causing "LDAP: Bad parameter to an ldap
> routine"
You probably want ldapurl="lda
On Mon, Jun 22, 2020 at 12:25 AM Peter J. Holzer wrote:
> I've read http://jepsen.io/analyses/postgresql-12.3 which reports a
> problem in PostgreSQL's SERIALIZABLE isolation leven (which has since been
> fixed) and also shows an example of a violation of what they consider to
> be the correct def
On Tue, Jul 14, 2020 at 9:27 PM Vishwa Kalyankar
wrote:
> Function Scan on kseb_geometry_trace_with_barrier_partition
> (cost=0.25..10.25 rows=1000 width=169) (actual time=11626.548..11626.568
> rows=254 loops=1)
> Function Scan on kseb_geometry_trace_with_barrier_partition
> (cost=0.25..1
On Sun, Jul 19, 2020 at 11:01 PM Abraham, Danny wrote:
> Segmentation fault in _alloc_initial_pthread at 0x9521474
> 0x9521474 (_alloc_initial_pthread+0x1d4) e803 ld
> r0,0x0(r3)
> (dbx) where
> _alloc_initial_pthread(??) at 0x9521474
> __pth_init(??) at
On Thu, Aug 6, 2020 at 7:02 AM Sreejith P wrote:
> IN SYNC mode of replication what would be the impact on Master DB server in
> terms of over all performance ?
The pg_stat_replication columns write_lag, flush_lag and replay_lag
are designed tell you how long to expect commits to take for
synch
On Wed, Sep 23, 2020 at 10:53 PM Alessandro Dentella
wrote:
> Thanks Pavel, but psycopg2 (that I always use is just for Python). T
> hey claim/complain that from c# there's no native solution.
Maybe https://www.npgsql.org/?
On Mon, Nov 16, 2020 at 10:10 PM Laurenz Albe wrote:
> On Mon, 2020-11-16 at 09:15 +0200, Condor wrote:
> > collationcmds.c: In function ‘get_icu_language_tag’:
> > collationcmds.c:467:51: error: ‘TRUE’ undeclared (first use in this
> > function); did you mean ‘IS_TRUE’?
> >467 | uloc_toLangu
On Tue, Nov 17, 2020 at 8:02 PM Condor wrote:
> I try to compile postgres again with (cd src/backend/commands; sed
> 's/TRUE/true/' collationcmds.c > collationcmds.c; ) and it's compiled
> but get new error on linking:
Doesn't that produce an empty file collationcmds.c? I think you want:
sed 's/
On Fri, Feb 5, 2021 at 12:43 PM Ian Lawrence Barwick wrote:
> 2021年2月5日(金) 3:52 Pavan Pusuluri :
>> We are trying to drop a table space on RDS Postgres . We have removed the
>> objects etc, but it still won't drop.
>>
>> I have checked and there's no reference anywhere to this tablespace but it
On Fri, Jan 29, 2021 at 4:27 AM Alvaro Herrera wrote:
> On 2021-Jan-28, Ravi Krishna wrote:
> > I recollect there use to be a website from where one can reply from web.
>
> The community does not maintain such a service.
>
> There used to be a Gmane archive of this list that you could use to
> pos
On Tue, Feb 16, 2021 at 4:32 AM Laurenz Albe wrote:
> What I would do is experiment with the "ldapsearch" executable from OpenLDAP
> and see
> if you can reproduce the problem from the command line.
Also, maybe try doing this as the "postgres" user (or whatever user
PostgreSQL runs as), just in
On Sun, Apr 24, 2022 at 8:00 AM Peter wrote:
> More than a million files in a single directory, this is
> inacceptable.
You didn't show EXPLAIN (ANALYZE) but if [Parallel] Hash is making
insane numbers of temporary files then something is not working as
intended... and I can take a guess at what
On Wed, May 25, 2022 at 6:17 AM Aleš Zelený wrote:
> SELECT format('REINDEX SCHEMA CONCURRENTLY %I;', n.nspname)
This may be related to bug #17485, discussed at:
https://www.postgresql.org/message-id/flat/17485-396609c6925b982d%40postgresql.org
On Sun, May 29, 2022 at 4:29 AM 浩辰 何 wrote:
> Furthermore, the results above are also related to IO API supported by OS.
> MySQL support synchronized IO and Linux libaio. It seems
> that PostgreSQL only supports synchronized IO, so shall we support more IO
> engines? like io_uring which is very
On Fri, May 6, 2022 at 6:20 PM hubert depesz lubaczewski
wrote:
> when defining statement triggers on update I can use:
>
> REFERENCING OLD TABLE AS xxx NEW TABLE as YYY
>
> these "pseudo" tables contain rows that were before and after.
>
> Is the order guaranteed?
>
> Can I assume that "first" ro
On Mon, Jun 20, 2022 at 9:53 PM Christoph Berg
wrote:
> IBM's reply to the issue back in December 2020 was this:
>
> The man page / infocenter document is not intended as an exhaustive
> list of all possible error codes returned and their circumstances.
> "Resource temporarily unavailable" m
On Wed, Aug 3, 2022 at 1:43 AM Tom Lane wrote:
> I believe most if not all variants of Unix are
> permissive about the spelling of the encoding part.
I've only seen glibc doing that downcase-and-strip-hyphens thing to
the codeset part of a locale name when looking for locale definition
files. Ot
On Tue, Nov 8, 2022 at 11:45 AM Willian Colognesi
wrote:
> root@ip-10-x-x-x:/home/ubuntu# pg_config --configure
> ... --with-extra-version= (Ubuntu 14.5-2.pgdg20.04+2)' ...
> ... '--with-llvm' 'LLVM_CONFIG=/usr/bin/llvm-config-10' ...
> There is no llvm installed on ubuntu server, postgresql was
On Tue, Nov 15, 2022 at 10:54 AM Christoph Moench-Tegeder
wrote:
> ## klaus.mailingli...@pernau.at (klaus.mailingli...@pernau.at):
> > On several servers we see the error message: PANIC: could not flush
> > dirty data: Cannot allocate memory
> Of these three places, there's an sync_file_range(),
On Wed, Nov 16, 2022 at 1:24 AM wrote:
> Filesystem is ext4. VM technology is mixed: VMware, KVM and XEN PV.
> Kernel is 5.15.0-52-generic.
>
> We have not seen this with Ubutnu 18.04 and 20.04 (although we might not
> have noticed it).
>
> I guess upgrading to postgresql 13/14/15 does not help as
On Tue, Nov 22, 2022 at 4:25 AM Kirk Wolak wrote:
> In researching this problem, it appears that the decision was made like
> 17yrs ago, when windows did not have a realistic "terminal" type interface.
> Assuming we target Windows 8.1 or higher, I believe this goes away.
FWIW PostgreSQL 16 w
On Wed, Mar 1, 2023 at 12:09 AM Eugene M. Zheganin wrote:
> 3) how do I fix it ? Should I take locale sources for ru_RU.utf8 on Linux and
> compile it on FreeBSD - will it help ?
Out of curiosity (I'm not saying it's a good idea!), do you know if
FreeBSD's localedef can compile glibc's collatio
On Mon, Feb 27, 2023 at 8:26 PM PALAYRET Jacques
wrote:
> # PostgreSQL does not take into account the additional second (leap second)
> in some calendar days ; eg. 2016, 31 dec. :
> SELECT to_timestamp('20170102 10:11:12','mmdd hh24:mi:ss') -
> to_timestamp('20161230 00:00:00','mmdd hh24
On Wed, Mar 1, 2023 at 10:30 AM Thomas Munro wrote:
> On Wed, Mar 1, 2023 at 12:09 AM Eugene M. Zheganin wrote:
> > 3) how do I fix it ? Should I take locale sources for ru_RU.utf8 on Linux
> > and compile it on FreeBSD - will it help ?
>
> Out of curiosity (I'm n
On Fri, Mar 17, 2023 at 7:48 PM jian he wrote:
> Hi,
> playing around with $[0] testlibpq2.c example. I wondered where
> HAVE_SYS_SELECT_H is defined?
>
> I searched on the internet, founded that people also asked the same question
> in $[1].
>
> In my machine, I do have .
> system version: Ubun
probably the instructions from
https://github.com/timescale/timescaledb, using ./bootstrap
-DPG_CONFIG=~/tmp_install/bin/pgconfig but i haven't tried that
myself.
(You don't have to run initdb again or reload data when switching
between tags/branches in the 10.x series).
--
Thomas Munro
http://www.enterprisedb.com
rk_mem etc) and query. Maybe start with a build of
REL_10_5 and try to reproduce the problem, and if you can get that to
happen reliably, then switch to a build of REL_10_STABLE to confirm
that the problem goes away?
--
Thomas Munro
http://www.enterprisedb.com
believe that should
succeed if you have that privilege and enough contiguous chunks of
physical memory are available. If you set huge_pages=off does it
revert to the old behaviour?
--
Thomas Munro
http://www.enterprisedb.com
that extracts the
relfilenode + block references from the output of pg_waldump (one file
ahead, or whatever), sorts and uniques them, merges them into block
ranges, converts the relfilenode reference to relation OID, and then
calls pg_prewarm() for each range.
--
Thomas Munro
http://www.enterprisedb.com
er
formally dead and buried or in this case, a zombie.
>From personal observations, I know that we have developers and
committers doing their primary development work on at least Debian,
Fedora, FreeBSD, macOS, Ubuntu and Windows.
--
Thomas Munro
http://www.enterprisedb.com
xposed, and we promised that old and new ORDINALTITY numbers
will line up, and then we made the ORDINALITY column a pathkey of the
scan. Now you could join old and new tables by the ORDINALITY column,
and get a merge join without any sorting. That's... pretty weird
though, and the syntax would be outside the SQL spec, and the
semantics might be questionable.
--
Thomas Munro
http://www.enterprisedb.com
l.org/docs/current/runtime-config-logging.html#GUC-LOG-TEMP-FILES
--
Thomas Munro
http://www.enterprisedb.com
On Tue, Dec 11, 2018 at 3:58 PM Ron wrote:
> On 12/10/2018 06:24 PM, Thomas Munro wrote:
> > On Tue, Dec 11, 2018 at 2:56 AM Ron wrote:
> >> 2018-12-07 06:21:55.504 EST 10.140.181.89(35868) CDS CDSLBXW 13748 SELECT
> >> PostgreSQL JDBC Driver 53100 ERROR: co
ays replay the same effects again if we're interrupted. The WAL is
a magic source of reliability (we can do it again if things go wrong)
and also performance (IO becomes serial, optimised for the storage
hardware).
https://www.postgresql.org/docs/current/wal-intro.html
--
Thomas Munro
http://www.enterprisedb.com
for
physical servers I wonder if you can still get DIMMs that small.
--
Thomas Munro
http://www.enterprisedb.com
ypes, registering undo log action
functions that are invoked during rollback, rollback of aborted but
not yet rolled back transaction at startup, ...) without having to
understand the whole zheap sandwich at once, but it's also a solution
to an age old problem. More on that soon.
--
Thomas Munro
http://www.enterprisedb.com
tergoogling, but probably
appears as present to our configure script. I find it harder to
believe they didn't implement fsync().
--
Thomas Munro
http://www.enterprisedb.com
On Fri, Feb 15, 2019 at 3:56 PM Thomas Munro
wrote:
> On Fri, Feb 15, 2019 at 2:56 PM Bruce Klein wrote:
> > > In 11.1 did you see the message "WARNING: could not flush dirty data:
> > > Function not implemented"
> > Yes
>
> I wonder if this is
On Fri, Feb 15, 2019 at 5:29 PM Tom Lane wrote:
> Thomas Munro writes:
> >> On Fri, Feb 15, 2019 at 2:56 PM Bruce Klein wrote:
> >>> In 11.1 did you see the message "WARNING: could not flush dirty data:
> >>> Function not implemented"
> >>
;s not too
surprising that we didn't consider this case before. A bit like the
nightjar case, the PANIC patch revealed a pre-existing problem that
had gone unreported and needs some work, but it doesn't seem like a
very good reason to roll back that part of the change completely IMHO.
--
Thomas Munro
http://www.enterprisedb.com
On Sun, Feb 17, 2019 at 4:56 AM Tom Lane wrote:
> Thomas Munro writes:
> >>> Really? The specification says that it starts I/O, not that it waits
> >>> around for any to finish.
>
> > Right, there was some discussion of that, and I didn't (and still
On Mon, Feb 18, 2019 at 2:19 PM Michael Paquier wrote:
> On Sun, Feb 17, 2019 at 10:54:54AM -0800, Andres Freund wrote:
> > On 2019-02-17 23:29:09 +1300, Thomas Munro wrote:
> >> Hmm. Well, at least ENOSPC should be treated the same way as EIO.
> >> Here's an
s discussed. It
gets WSL users to a better place than they were before, by suppressing
further warnings after the first one.
--
Thomas Munro
http://www.enterprisedb.com
--
<https://postgresvision.com/>
<https://postgresvision.com/>
0001-Tolerate-ENOSYS-failure-from-sync_file_range.patch
Description: Binary data
ensus on whether this is the right approach, so I don't feel like
I can commit it yet. Does any want to make another concrete proposal?
--
Thomas Munro
https://enterprisedb.com
On Tue, Feb 19, 2019 at 5:31 PM Thomas Munro wrote:
> On Tue, Feb 19, 2019 at 5:16 PM James Sewell
> wrote:
> >> 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
&g
ll in pg_flush_data() ignores the return code too.
This inconsistency should be fixed; I'll think about which direction
it should be fixed in (either we are convinced that
sync_file_range(SYNC_FILE_RANGE_WRITE) is non-destructive of error
state or we aren't, and should handle it everywhere), and maybe start
a new -hackers thread.
--
Thomas Munro
https://enterprisedb.com
linking in threading libraries.
FreeBSD and CentOS systems near me have separate libraries still.
[1]
https://www.postgresql.org/message-id/flat/20140612210219.GA705509%40tornado.leadboat.com
[2] https://www.openldap.org/lists/openldap-technical/201608/msg00094.html
--
Thomas Munro
https://enterprisedb.com
Red Hat-derived distro, but I
doubt that's the kind of advice you were looking for. We need to
figure out a proper solution here, though I'm not sure what. Question
for the list: other stuff in the server needs libpthread (SSL, LLVM,
...), so why are we insisting on using non-MT LDAP?
--
On Tue, Feb 26, 2019 at 9:11 PM Thomas Munro wrote:
> On Tue, Feb 26, 2019 at 8:17 PM Mike Yeap wrote:
> > Hi Thomas, does that mean the bug is still there?
> I haven't tried to repro this myself, but it certainly sounds like it.
> It also sounds like it would probably go
1 - 100 of 208 matches
Mail list logo
