s us
> > from overriding another user's callback?
>
> The password callback pointer is stored in a static variable in NSS (in the
> file lib/pk11wrap/pk11auth.c).
But, uh, how is that not a problem? What happens if a backend imports
libpq? What if plpython imports curl which then also uses nss?
> + /*
> + * Finally we must configure the socket for being a server by setting
> the
> + * certificate and key.
> + */
> + status = SSL_ConfigSecureServer(model, server_cert, private_key,
> kt_rsa);
> + if (status != SECSuccess)
> + ereport(ERROR,
> + (errmsg("unable to configure secure server: %s",
> +
> pg_SSLerrmessage(PR_GetError();
> + status = SSL_ConfigServerCert(model, server_cert, private_key, NULL, 0);
> + if (status != SECSuccess)
> + ereport(ERROR,
> + (errmsg("unable to configure server for TLS
> server connections: %s",
> +
> pg_SSLerrmessage(PR_GetError();
Why do both of these need to get called? The NSS docs say:
/*
** Deprecated variant of SSL_ConfigServerCert.
**
...
SSL_IMPORT SECStatus SSL_ConfigSecureServer(
PRFileDesc *fd, CERTCertificate *cert,
SECKEYPrivateKey *key, SSLKEAType kea);
Greetings,
Andres Freund
On 2020-10-28 16:20:03 +0100, Magnus Hagander wrote:
> I would personally prefer a completely seprate page
Same.
s a few references, even just within debian
packages (some are incorrect hits, others aren't):
https://codesearch.debian.net/search?q=CASHOID&literal=1&perpkg=1
Greetings,
Andres Freund
SHOID and LSNOID available as aliases, and renaming
> the rest.
I don't really have an opinion on wether it's worth keepign the other
aliases or not...
Greetings,
Andres Freund
,20 @@ build_startup_packet(const PGconn *conn, char *packet,
> ADD_STARTUP_OPTION("replication", conn->replication);
> if (conn->pgoptions && conn->pgoptions[0])
> ADD_STARTUP_OPTION("options", conn->pgoptions);
> + if (conn->compression && conn->compression[0])
> + {
> + bool enabled;
> + /*
> + * If compressoin is enabled, then send to the server list of
> compression algorithms
> + * supported by client
> + */
s/compressoin/compression/
> + if (parse_bool(conn->compression, &enabled))
> + {
> + char compression_algorithms[ZPQ_MAX_ALGORITHMS];
> + zpq_get_supported_algorithms(compression_algorithms);
> + ADD_STARTUP_OPTION("compression",
> compression_algorithms);
> + }
> + }
I think this needs to work in a graceful manner across server
versions. You can make that work with an argument, using the _pq_
parameter stuff, but as I said earlier, I think it's a mistake to deal
with this in the startup packet anyway.
Greetings,
Andres Freund
On 2020-10-28 15:24:20 -0400, Tom Lane wrote:
> Nah. What I'm imagining is just that pg_type.h contains
>
> #ifdef EXPOSE_TO_CLIENT_CODE
>
> /*
> * Backwards compatibility for ancient random spellings of OID macros.
> * Don't use these macros in new code.
> */
> #define CASHOID MONEYOID
> #d
y each time round.
> - */
> - v_aggnop = l_ptr_const(&aggref->aggno,
> -
>l_ptr(LLVMInt32Type()));
> - v_aggno = LLVMBuildLoad(b, v_aggnop,
> "v_aggno");
> + v_aggno = l_int32_const(aggref->aggno);
Yay!
> +/*
> + * get_agg_clause_costs
> + * Recursively find the Aggref nodes in an expression tree, and
> + * accumulate cost information about them.
Think this comment is out of date now.
Greetings,
Andres Freund
Hi,
On 2020-10-14 13:31:03 -0700, Andres Freund wrote:
> I was thinking about this a bit more, and I think the answer might be to
> use Min(latestCompletedXid, MyProc->xid). That would, as far as I can
> tell, never miss something vacuumable in a temporary table, doesn't
> req
Hi,
On 2020-10-27 20:51:10 -0700, Andres Freund wrote:
> On 2020-10-15 01:37:35 -0700, Andres Freund wrote:
> > Attached is a *prototype* implemention of this concept, which clearly is
> > lacking some comment work (and is intentionally lacking some
> > re-indentation).
&g
The likelihood of ending up with
something that makes it hard to to eventually implement proper
postgresql.conf seems high.
Greetings,
Andres Freund
On 2020-10-28 18:13:44 -0700, Andres Freund wrote:
> Just pushed this. Let's see what the BF says...
It says that apparently something is unstable about my new test. It
first passed on a few animals, but then failed a lot in a row. Looking.
Hi,
On 2020-10-28 19:09:14 -0700, Andres Freund wrote:
> On 2020-10-28 18:13:44 -0700, Andres Freund wrote:
> > Just pushed this. Let's see what the BF says...
>
> It says that apparently something is unstable about my new test. It
> first passed on a few animals, but the
Hi,
On 2020-10-28 21:00:30 -0700, Andres Freund wrote:
> On 2020-10-28 19:09:14 -0700, Andres Freund wrote:
> > On 2020-10-28 18:13:44 -0700, Andres Freund wrote:
> > > Just pushed this. Let's see what the BF says...
> >
> > It says that apparently somethin
Hi,
On 2020-10-29 10:17:20 +0200, Heikki Linnakangas wrote:
> On 28/10/2020 21:59, Andres Freund wrote:
> > It wouldn't surprise me to see a small execution time speedup here -
> > I've seen the load of the aggno show up in profiles.
>
> I think you'd be ha
Hi,
On 2020-10-29 12:27:53 -0400, Tom Lane wrote:
> Maybe put a check into vacuum_delay_point, and poll the pipe when we're
> about to sleep anyway?
Perhaps we should just replace the pg_usleep() with a latch wait?
Greetings,
Andres Freund
unaligned buffers.) We include both "double" and "int64" in the
* union to ensure that the compiler knows the value must be MAXALIGN'ed
* (cf. configure's computation of MAXIMUM_ALIGNOF).
*/
typedef union PGAlignedBlock
I think this needs to be quickly reworked or reverted.
Greetings,
Andres Freund
Hi,
On 2020-10-29 11:17:29 -0700, Andres Freund wrote:
> LWLockAcquire(BufferDescriptorGetIOLock(bufdesc), LW_SHARED);
> buf_state = LockBufHdr(bufdesc);
> UnlockBufHdr(bufdesc, buf_state);
>
> /* If the page is dirty or i
Hi,
On 2020-10-29 11:17:29 -0700, Andres Freund wrote:
> The code does IO while holding the buffer mapping lock. That seems
> *entirely* unacceptable to me. That basically locks 1/128 of shared
> buffers against concurrent mapping changes, while reading data that is
> likely not t
ption set, but track_io_timing seems common
enough?
Greetings,
Andres Freund
)));
> +
> + PG_RETURN_TEXT_P(cstring_to_text(version));
> }
There's quite a few copies of this code that look exactly the same,
except for the be_tls_get_* call. Do you see a way to have fewer copies
of the same code?
Greetings,
Andres Freund
Hi,
On 2020-10-30 10:01:08 +0800, Julien Rouhaud wrote:
> On Fri, Oct 30, 2020 at 2:17 AM Andres Freund wrote:
> > The code does IO while holding the buffer mapping lock. That seems
> > *entirely* unacceptable to me. That basically locks 1/128 of shared
> > buffers again
On 2020-10-30 11:58:13 +0800, Julien Rouhaud wrote:
> So I'm assuming that the previous optimization to avoid almost every
> time doing an IO while holding a buffer mapping lock isn't an option?
> In that case, I don't see any other option than reverting the patch
> and discussing a new approach.
gt; > > +zpq_get_supported_algorithms(char algorithms[ZPQ_MAX_ALGORITHMS])
> > > +{
> > > + int i;
> > > + for (i = 0; zpq_algorithms[i].name != NULL; i++)
> > > + {
> > > + Assert(i < ZPQ_MAX_ALGORITHMS);
> > > + algorithms[i] = zpq_algorithms[i].name();
> > > + }
> > > + Assert(i < ZPQ_MAX_ALGORITHMS);
> > > + algorithms[i] = '\0';
> > > +}
> > Uh, doesn't this bake ZPQ_MAX_ALGORITHMS into the ABI? That seems
> > entirely unnecessary?
>
> I tried to avoid use of dynamic memory allocation because zpq is used both
> in client and server environments with different memory allocation
> policies.
We support palloc in both(). But even without that, you can just have
one function to get the number of algorithms, and then have the caller
pass in a large enough array.
> And I afraid that using the _pq_ parameter stuff makes enabling of
> compression even less user friendly.
I didn't intend to suggest that the _pq_ stuff should be used in a
client facing manner. What I suggesting is that if the connection string
contains compression=, the driver would internally translate that to
_pq_.compression to pass that on to the server, which would allow the
connection establishment to succeed, even if the server is a bit older.
Greetings,
Andres Freund
Hi,
I'm a bit limited writing - one handed for a while following an injury
on Friday...
On 2020-11-02 10:05:25 +0900, Michael Paquier wrote:
> On Thu, Oct 29, 2020 at 10:08:52PM -0700, Andres Freund wrote:
> > I think its pretty much *never* OK to do IO while holding a buffer
&g
Hi
On 2020-11-02 10:45:00 +0900, Michael Paquier wrote:
> On Sun, Nov 01, 2020 at 05:39:40PM -0800, Andres Freund wrote:
> > I'm a bit limited writing - one handed for a while following an injury
> > on Friday...
>
> Oops. Take care.
Thanks!
> > On 2020-11-02
ble AM.
As far as I can tell you have not acually attached the patch.
Greetings,
Andres Freund
Hi,
On 2020-11-02 11:03:29 +0200, Heikki Linnakangas wrote:
> While looking at the parallel copy patches, it started to annoy me how large
> copy.c is.
Agreed.
> There isn't much common code between COPY FROM and COPY TO, so I propose
> that we split copy.c into two: copyfrom.c and copyto.c. Se
On 2020-11-02 19:43:38 +0200, Heikki Linnakangas wrote:
> On 02/11/2020 19:23, Andres Freund wrote:
> > On 2020-11-02 11:03:29 +0200, Heikki Linnakangas wrote:
> > > There isn't much common code between COPY FROM and COPY TO, so I propose
> > > that we split
Hi,
On 2020-11-02 10:28:33 -0800, Jesse Zhang wrote:
> On Thu, Oct 15, 2020 at 6:12 PM Andres Freund wrote:
> > There will be a breaking API change for JIT related API in LLVM
> > 12. Mostly about making control over various aspects easier, and then
> > building on top
Hi,
On 2020-11-02 12:35:30 -0500, Robert Haas wrote:
> On Thu, Oct 29, 2020 at 2:17 PM Andres Freund wrote:
> > I think this needs to be quickly reworked or reverted.
I think it's fairly clear by now that revert is appropriate for now.
> I don't like this patch, eithe
ve works. Thanks
If there are failures - you mentioned that there are some - check-world
will not even start the isolation tests. You could use -k, to contuniue
after failures, but that makes it harder to see the erors.
With -j xx it'll be a bit scheduling dependant whether you'd e.g. see
the isolation test results if e.g. the "main" tests fail.
Greetings,
Andres Freund
be handled by one core at a time in the pooler. So it's easy to slow
down peak throughput if you also have to deal with TLS etc.
Greetings,
Andres Freund
}
Why just libpq?
> +# Handle makefile rules for when file to be added to the project
> +# does not exist. Returns 1 when the original file add should be
> +# skipped.
> +sub AdditionalFileRules
> +{
> + my $self = shift;
> + my $fname = shift;
> + my ($ext) = $fname =~ /(\.[^.]+)$/;
> +
> + # For missing .c files, check if a .l file of the same name
> + # exists and add that too.
> + if ($ext eq ".c")
> + {
> + my $filenoext = $fname;
> + $filenoext =~ s{\.[^.]+$}{};
> + if (-e "$filenoext.l")
> + {
> + AddFile($self, "$filenoext.l", 0);
> + return 1;
> + }
> + if (-e "$filenoext.y")
> + {
> + AddFile($self, "$filenoext.y", 0);
> + return 0;
> + }
> + }
Aren't there related rules for .h?
Greetings,
Andres Freund
hat in the next few days (was plannin to last week,
but due to a hand injury I was typing one handed last week - makes it
pretty annoying to clean up code. But I just started being able to at
least use my left thumb again...).
Greetings,
Andres Freund
Hi,
On 2020-11-08 18:22:50 -0500, Tom Lane wrote:
> Andres Freund writes:
> > Yea, I'll try to do that in the next few days
I pushed the change to master. If that doesn't show any problems, I'll
backpatch in a week or so. Seawasp runs only on master, so it should
satisf
f we ought to redesign the column default logic to
really be a property of the Attr, instead of the constraint stuff it is
now.
> So I'll go see about back-patching 20d3fe900.
Thanks.
Is it worth adding Bertrand's testcase to the regression suite in some
form?
Greetings,
Andres Freund
ly a no-go. I think you might be able to address this if
you accept that the command cannot be run in a transaction (like
CONCURRENTLY). Then you can first do the catalog changes, change the
persistence level, and commit.
Greetings,
Andres Freund
because
we need a way to stress it to see whether it has unnecessary
bottlenecks.
Greetings,
Andres Freund
ocks rather
> than inventing workarounds?
Perhaps - I just don't think it's related to this thread. And how you're
going to address the overhead.
Greetings,
Andres Freund
Hi,
On 2020-11-17 00:09:34 +0300, Marina Polyakova wrote:
> Sorry I'm not familiar with the internal architecture of snapshots, locks
> etc. in postgres, but I wanted to ask - what exact kind of patch for fair
> lwlocks do you want to offer to the community? I applied the 6-th version of
> the pat
en
rechecking the relfilenode/fork/blocknum? And why are we doing so
holding the buffer header lock, which is essentially a spinlock, so
should only ever be held for very short portions?
This looks like it's copying logic from DropRelFileNodeBuffers() etc,
but there the situation is different: We haven't done a buffer mapping
lookup, and we don't hold a partition lock!
Greetings,
Andres Freund
nitely wrong to relax things here, but I'm not
sure we've evaluated it sufficiently.
Greetings,
Andres Freund
inal
> formulation from commit acac68b2bca, which had this message as DEBUG2
> without any string formatting.
I don't really have an opinion on this.
Greetings,
Andres Freund
Hi
On Wed, Nov 18, 2020, at 09:51, Alvaro Herrera wrote:
> On 2020-Nov-14, Daniel Verite wrote:
>
> > The patch I posted in [1] was pretty simple, but at the time, query
> > results were always discarded. Now that pgbench can instantiate
> > variables from query results, a script can do:
> > se
see how clobbering the left arg would work
reliably. That's easy enough for in-place modifications of types that
have a fixed width, but for an arbitrary width type that's much
harder. You could probably hack something together by inquiring about
the actual memory allocation size in aset.c etc, but that's pretty ugly.
Greetings,
Andres Freund
Hi,
On 2020-11-19 14:25:36 +0900, Kyotaro Horiguchi wrote:
> # Creation, searching and expiration
> master : 6393.23(100.0)
> patched-off: 6527.94(102.1)
> patched-on : 15880.01(248.4)
What's the deal with this massive increase here?
Greetings,
Andres Freund
ore detail of what you actually are precisely doing, and what
the hooks / integration you'd like would look like, it's hard to comment
usefully here.
Greetings,
Andres Freund
Hi,
On 2020-11-15 17:10:53 +0200, Heikki Linnakangas wrote:
> Yep, quite right. Fixed that way, thanks for the debugging!
I locally, on a heavily modified branch (AIO support), started to get
consistent failures in this test. I *suspect*, but am not sure, that
it's the test's fault, not the fault
- don't we possibly need *both*? Since post pg_rewind recovery starts
at the previous checkpoint, it's quite possible for C to get ready to
answer queries before that record has been replayed?
Thanks,
Andres Freund
Hi,
+1 for getting rid of whatever we can without too much trouble.
On 2020-11-21 13:13:35 -0500, Tom Lane wrote:
> Michael Paquier writes:
> > Indeed, this could go. There is a recursive call for views, but in
> > order to maintain compatibility with that we can just remove one
> > function an
is so that the flag is read first, and we read the xid only
> afterwards, with a read barrier.
Which we don't want, because that'd mean slowing down the *extremely*
common case of the majority of backends neither having an xid assigned
nor doing logical decoding / vacuum. We'd be reading two cachelines
instead of one.
Greetings,
Andres Freund
Hi,
On 2020-11-29 20:33:41 -0800, Rosen Penev wrote:
> GCC 4.8.5 does not default to gnu99 or gnu11 like the newer versions.
We require C99 support since postgres 12, and configure should end up
choosing flags to make the compiler support that if possible.
As far as I can tell the code you chang
found this before as well:
https://postgr.es/m/CAB7nPqTB3VcKSSrW2Qj59tYYR2H4+n=5pzbdwou+x9iqvnm...@mail.gmail.com
I did put a hastily rebased version of that commit in my aio branch
during development:
https://github.com/anarazel/postgres/commit/b3cc8adacf7860add8cc62ec373ac955d9d12992
Greetings,
Andres Freund
On 2021-01-12 13:03:14 -0500, Bruce Momjian wrote:
> I think one big question is that, since we are using a streaming cipher,
> do we care about hint bit changes showing to users? I actually don't
> know. If we do, some kind of dummy LSN record might be required, as you
> suggested.
That'd lead
if (PageIsNew(page) || !PageNeedsToBeEncrypted(forknum))
> + return (char *) page;
Why is it OK to not encrypt new pages?
> +#define PageEncryptOffsetoffsetof(PageHeaderData, pd_special)
> +#define SizeOfPageEncryption (BLCKSZ - PageEncryptOffset)
I think you need a detailed explanation somewhere about what you're
doing here, and why it's a good idea.
Greetings,
Andres Freund
y() to the
write time makes it nearly useless until you're at the point the
checkpoint can't be completed in time. Similarly, the "sync" time"
covers many things that aren't syncing...
Greetings,
Andres Freund
On 2021-01-15 09:53:05 +0100, Peter Eisentraut wrote:
> On 2020-12-08 10:38, vignesh C wrote:
> > I have implemented printing of backtrace based on handling it in
> > CHECK_FOR_INTERRUPTS. This patch also includes the change to allow
> > getting backtrace of any particular process based on the sugg
='-c default_table_access_method=foo' pgbench ...
I don't think adding pgbench options for individual GUCs really is a
useful exercise?
Greetings,
Andres Freund
; > errmsg("cannot access temporary or unlogged
> > relations during recovery")));
>
> It works as expected accidentally, but the meaning is off.
> WAL-skipping optmization is irrelevant to the condition for the error.
>
> I found five misues in the tree. Please find the attached.
Noah?
Greetings,
Andres Freund
e we
didn't yet tell the kernel to flush dirty data more aggressively.
Greetings,
Andres Freund
hat point the value
could be just about arbitrarily out of date - but that doesn't really
matter because GetStandbyFlushRecPtr() updates it. And for the
!am_cascading_walsender it's trivial to compute.
Has anybody dug out the thread leading to the commit?
Greetings,
Andres Freund
- retrieve_cluster_keys() is missing (void).
I think this is at the very least a month away from being committable,
even if the design were completely correct (which I do not know, see
above).
Greetings,
Andres Freund
[1] https://www.postgresql.org/message-id/20210115204926.GD8740%40momjian.us
lp is that it
condenses the period of unrealiable performance into one short time,
rather than spreading it over the whole checkpoint...
Greetings,
Andres Freund
Hi,
On 2021-01-15 19:21:32 -0500, Bruce Momjian wrote:
> On Fri, Jan 15, 2021 at 02:37:56PM -0800, Andres Freund wrote:
> > On 2021-01-15 16:47:19 -0500, Bruce Momjian wrote:
> > > > I am not even sure there is a consensus on the design, without which
> > > &g
Hi,
On 2021-01-15 20:49:10 -0500, Bruce Momjian wrote:
> On Fri, Jan 15, 2021 at 04:56:24PM -0800, Andres Freund wrote:
> > On 2021-01-15 19:21:32 -0500, Bruce Momjian wrote:
> > > You have to understand cryptography and Postgres internals to understand
> > > the desi
Hi,
On Sat, Jan 16, 2021, at 09:34, vignesh C wrote:
> On Sat, Jan 16, 2021 at 1:40 AM Andres Freund wrote:
> >
> > On 2021-01-15 09:53:05 +0100, Peter Eisentraut wrote:
> > > On 2020-12-08 10:38, vignesh C wrote:
> > > > I have implemented printing
d but I hope that
> will give you some clue.
>
> [1] -
> https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=d168b666823b6e0bcf60ed19ce24fb5fb91b8ccf
This is a great example.
Greetings,
Andres Freund
here's legitimate reasons to differ on
that note, I don't think it's reasonable for a feature this invasive to
commit preliminary patches without the major subsequent patches being in
a shape that allows reviewing the whole picture.
Greetings,
Andres Freund
On 2021-01-18 13:58:20 -0500, Bruce Momjian wrote:
> On Mon, Jan 18, 2021 at 09:42:54AM -0800, Andres Freund wrote:
> > Personally, but I admit that there's legitimate reasons to differ on
> > that note, I don't think it's reasonable for a feature this invasive to
.
I think you don't event need checkpointer to be involved, normal buffer
replacement would do the trick. We briefly pin the page in BufferAlloc()
even if the page is clean. Longer when it's dirty, of course.
Greetings,
Andres Freund
tanding open transactions.
There's a lot of workloads that never set LP_DEAD because all scans are
bitmap index scans. And there's no obvious way to address that. So I
don't think it's wise to purely rely on LP_DEAD.
Greetings,
Andres Freund
smgrextend/smgrwrite.
2) redo point falls between write() and register_dirty_segment()
But both of these are fine in the context of initially filling a newly
created relfilenode, as far as I can tell? Otherwise the current
smgrimmedsync() approach wouldn't be safe either, as far as I can te
Hi,
On 2021-01-21 23:54:04 +0200, Heikki Linnakangas wrote:
> On 21/01/2021 22:36, Andres Freund wrote:
> > A quick hack (probably not quite correct!) to evaluate the benefit shows
> > that the attached script takes 2m17.223s with the smgrimmedsync and
> > 0m22.870s passi
binary upgrade mode / -b, error out on all wal writes in
sessions that don't explicitly set a session-level GUC to allow
writes.
Greetings,
Andres Freund
o squeeze out space: make groupLeader be an
integer index into allProcs instead. That requires only 4 bytes...
Alternatively, I think it'd be reasonably easy to add the scope as a bit
in LOCKMASK - there's plenty space.
Greetings,
Andres Freund
s this in SnapBuildNextPhaseAt():
>
> > /*
> > * For backward compatibility reasons this has to be stored in the
> > wrongly
> > * named field. Will be fixed in next major version.
> > */
> > return builder->was_running.was_xmax;
>
> We could fix that now... Andres, what did you have in mind for a proper
> name?
next_phase_at seems like it'd do the trick?
> P.P.S. Two thinkos in comments in snapbuild.c: s/write for/wait for/.
Will push a fix.
Greetings,
Andres Freund
Hi,
On 2021-01-25 12:00:08 -0800, Andres Freund wrote:
> > > /*
> > >* For backward compatibility reasons this has to be stored in the
> > > wrongly
> > >* named field. Will be fixed in next major version.
> > >*/
> > > retu
is in the caller, allowing this
function to be used outside of signal triggered backtraces.
>
> +extern void LogBackTrace(void); /* Called from EmitProcSignalPrintCallStack
> */
I don't think this comment is correct anymore?
Greetings,
Andres Freund
think what you would have to do instead is to ensure that the
expression is "simple enough", and then process it into a cheaply
executable format in get_rel_sync_entry(). I'd suggest that in the first
version you just allow a simple ANDed list of 'foo.bar op constant'
expressions.
Does that make sense?
Greetings,
Andres Freund
Hi,
On 2021-01-29 12:40:18 -0300, Alvaro Herrera wrote:
> On 2020-Aug-31, Andres Freund wrote:
>
> > Wouldn't the better fix here be to allow reading of individual members
> > without a lock? E.g. by wrapping each in a 64bit atomic.
>
> So I've been playi
t's not really useful - the path that actually updates already
implies a barrier. It'd probably be better to add a barrier to a "never
executed cmpxchg" fastpath.
> @@ -2905,6 +2909,7 @@ XLogFlush(XLogRecPtr record)
> WriteRqstPtr = pg_atomic_read_u64(&XLogCtl->LogwrtRqst.Write);
> LogwrtResult.Write =
> pg_atomic_read_u64(&XLogCtl->LogwrtResult.Write);
> LogwrtResult.Flush =
> pg_atomic_read_u64(&XLogCtl->LogwrtResult.Flush);
> + pg_read_barrier();
I'm not sure you really can get away with just a read barrier in these
places. We can't e.g. have later updates to other shared memory
variables be "moved" to before the barrier (which a read barrier
allows).
Greetings,
Andres Freund
add a trivial DEBUG message to XLogWrite(),
and run anything involving logical rep using a low enough log
level. There might even be enough messages with a low enough level
already somewhere in the relevant paths.
Greetings,
Andres Freund
grcloseall(void)
> smgrclose(reln);
> }
>
> +void
> +smgrrelease(void)
> +{
> + mdrelease();
> +}
Probably should be something like
for (i = 0; i < NSmgr; i++)
{
if (smgrsw[i].smgr_release)
smgrsw[i].smgr_release();
}
Greetings,
Andres Freund
read the variables
separately.
> @@ -3064,8 +3063,10 @@ XLogBackgroundFlush(void)
> WriteRqst.Write -= WriteRqst.Write % XLOG_BLCKSZ;
>
> /* if we have already flushed that far, consider async commit records */
> + LogwrtResult.Flush = pg_atomic_read_u64(&XLogCtl->LogwrtResult.Flush);
> if (WriteRqst.Write <= LogwrtResult.Flush)
> {
> + pg_memory_barrier();
> SpinLockAcquire(&XLogCtl->info_lck);
> WriteRqst.Write = XLogCtl->asyncXactLSN;
> SpinLockRelease(&XLogCtl->info_lck);
A SpinLockAcquire() is a full memory barrier on its own I think. This'd
probably better solved by just making asyncXactLSN atomic...
Greetings,
Andres Freund
ableScanDesc sscan, TableScanTidRange* range);
would work better? That'd allow an AM to have arbitrarily large state
for a tid range scan, would make it clear what the lifetime of the
ItemPointer mintid, ItemPointer maxtid are etc. Wouldn't, on the API
level, prevent multiple tid range scans from being in progress at the
same times though :(. Perhaps we could add a TableScanTidRange* pointer
to TableScanDesc which'd be checked/set by tableam.h which'd prevent that?
Greetings,
Andres Freund
ng any LSN generated
after 4 (preferrably already flushed to disk) - but that seems somewhat
ugly from a debuggability POV :/. Alternatively you could just create
tiny WAL record to get a new LSN, but that'll sometimes trigger new WAL
flushes when the pages are dirtied.
Greetings,
Andres Freund
Hi,
On 2021-02-03 16:35:29 +0530, Bharath Rupireddy wrote:
> On Sat, Jan 30, 2021 at 8:23 AM Andres Freund wrote:
> > On 2021-01-28 11:14:03 +0530, Amit Kapila wrote:
> > > On Wed, Jan 27, 2021 at 9:38 AM Bharath Rupireddy
> > > wrote:
> > > >
> > &
Hi,
On 2021-02-03 19:21:25 -0500, Bruce Momjian wrote:
> On Wed, Feb 3, 2021 at 03:29:13PM -0800, Andres Freund wrote:
> > Changing this is *completely* infeasible. In a lot of workloads it'd
> > cause a *massive* explosion of WAL volume. Like quadratically. You'll
>
Hi,
On 2021-02-04 15:08:42 +0530, Bharath Rupireddy wrote:
> On Thu, Feb 4, 2021 at 5:16 AM Andres Freund wrote:
> > > > > About 0001, have we tried to reproduce the actual bug here which means
> > > > > when the error_callback is called we should face some p
any
times. Want me to push the fix?
Greetings,
Andres Freund
tion.
+
Until the commit *has completed*, nothing guarantees that anything
bearing the transaction's xid has made it to disk. And we surely don't
want to force a WAL flush when assigning a transaction id, right?
Greetings,
Andres Freund
ump and psql. This probably includes being able to run make
> installcheck and use pg_dump and psql against the regression database.
I think we should explicitly limit the number of platforms we care about for
this purpose. I don't think we should even try to keep 8.2 compile on AIX or
whatnot.
Greetings,
Andres Freund
erage of the relevant code without any
measurable speed gain. -0.5 from here.
Greetings,
Andres Freund
Hi,
On 2021-12-03 10:28:34 +0900, Tatsuo Ishii wrote:
> It seems there are no environment variables corresponding to keepalives
> etc. connection parameters in libpq. Is there any reason for this?
PGOPTIONS='-c tcp_keepalive_*=foo' should work.
Greetings,
Andres Freund
se-port that I can see.
Is it perhaps time to to use unix sockets on windows by default
(i.e. PG_TEST_USE_UNIX_SOCKETS), at least when on a new enough windows?
Greetings,
Andres Freund
Hi,
On 2021-12-08 14:45:50 -0800, Andres Freund wrote:
> Is it perhaps time to to use unix sockets on windows by default
> (i.e. PG_TEST_USE_UNIX_SOCKETS), at least when on a new enough windows?
On its own PG_TEST_USE_UNIX_SOCKETS doesn't work at all on windows - it fails
trying to u
Hi,
On 2021-12-08 16:36:14 -0800, Andres Freund wrote:
> On 2021-12-08 14:45:50 -0800, Andres Freund wrote:
> > Is it perhaps time to to use unix sockets on windows by default
> > (i.e. PG_TEST_USE_UNIX_SOCKETS), at least when on a new enough windows?
>
> On its own PG_
Hi,
On 2021-12-08 17:03:07 -0800, Andres Freund wrote:
> On 2021-12-08 16:36:14 -0800, Andres Freund wrote:
> > On 2021-12-08 14:45:50 -0800, Andres Freund wrote:
> > > Is it perhaps time to to use unix sockets on windows by default
> > > (i.e. PG_TEST_USE_UNIX_SOCKE
Hi,
On 2021-12-09 14:35:37 +0100, Peter Eisentraut wrote:
> On 09.12.21 03:44, Thomas Munro wrote:
> > On Thu, Dec 9, 2021 at 11:46 AM Andres Freund wrote:
> > > Is it perhaps time to to use unix sockets on windows by default
> > > (i.e. PG_TEST_USE_UNIX_SOCKETS), at
5742..67447f997a 100644
> --- a/src/backend/storage/buffer/bufmgr.c
> +++ b/src/backend/storage/buffer/bufmgr.c
> @@ -2164,7 +2164,6 @@ BufferSync(int flags)
> if (SyncOneBuffer(buf_id, false, &wb_context) &
> BUF_WRITTEN)
> {
> TRACE_POSTGRESQL_BUFFER_SYNC_WRITTEN(buf_id);
> -
> PendingCheckpointerStats.m_buf_written_checkpoints++;
> num_written++;
> }
> }
> @@ -2273,9 +2272,6 @@ BgBufferSync(WritebackContext *wb_context)
>*/
> strategy_buf_id = StrategySyncStart(&strategy_passes, &recent_alloc);
>
> - /* Report buffer alloc counts to pgstat */
> - PendingBgWriterStats.m_buf_alloc += recent_alloc;
> -
> /*
>* If we're not running the LRU scan, just stop after doing the stats
>* stuff. We mark the saved state invalid so that we can recover sanely
> @@ -2472,8 +2468,6 @@ BgBufferSync(WritebackContext *wb_context)
> reusable_buffers++;
> }
>
> - PendingBgWriterStats.m_buf_written_clean += num_written;
> -
Isn't num_written unused now, unless tracepoints are enabled? I'd expect some
compilers to warn... Perhaps we should just remove information from the
tracepoint?
Greetings,
Andres Freund
401 - 500 of 9955 matches
Mail list logo
