On Wed, May 6, 2015 at 10:26 AM, Jeff Janes jeff.ja...@gmail.com wrote:
On Wed, May 6, 2015 at 6:16 AM, Pavel Stehule pavel.steh...@gmail.com
wrote:
2015-05-06 15:15 GMT+02:00 Alvaro Herrera alvhe...@2ndquadrant.com:
Pavel Stehule wrote:
Hi
I am working on preparation the migration
a
message when it is complete.
Cheers,
Jeff
':
funcapi.c:890: warning: unused variable 'procStruct'
Adding PG_USED_FOR_ASSERTS_ONLY seems to fix it.
Cheers,
Jeff
transform_unused.patch
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org
]: *** [postgres] Error 1
make[1]: *** [all-backend-recurse] Error 2
make: *** [all-src-recurse] Error 2
make: *** Waiting for unfinished jobs
make: *** [temp-install] Error 2
Cheers,
Jeff
On Tue, Apr 28, 2015 at 9:13 AM, Stephen Frost sfr...@snowman.net wrote:
* Jeff Janes (jeff.ja...@gmail.com) wrote:
On Mon, Mar 30, 2015 at 5:26 PM, Tomas Vondra
tomas.von...@2ndquadrant.com
wrote:
attached is a new version of the patch series. Aside from fixing
various
issues
On Sat, Apr 25, 2015 at 7:23 AM, Michael Paquier michael.paqu...@gmail.com
wrote:
On Sat, Apr 25, 2015 at 7:59 AM, Peter Eisentraut pete...@gmx.net wrote:
On 4/23/15 1:22 PM, Jeff Janes wrote:
Something about this commit (dcae5faccab64776376d354d) broke make
check in parallel conditions
if it's going to
fail.
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
get the problem without using it.
Cheers,
Jeff
literals and unknown type literals
seems promising concept to aid in understanding the difference in the
face of not being able (or wanting) to actually change the behavior.
Not sure I understand that proposal, can you elaborate?
Regards,
Jeff Davis
--
Sent via pgsql-hackers
and gdb)
quite enthusiastically, but still it is a pain to correlate any given
front-end to any given back-end.
Would such an addition to core be welcome?
Cheers,
Jeff
Moving thread to -hackers.
On Wed, Apr 8, 2015 at 11:18 PM, Jeff Davis pg...@j-davis.com wrote:
That example was just for illustration. My other example didn't require
creating a table at all:
SELECT a=b FROM (SELECT ''::text, ' ') x(a,b);
it's fine with me if we want that to fail, but I
this description. Why would queries selecting
data that is not changing have any extra overhead?
Is the idea that the hot part of the table for updates would move around
over time, but the hot part for selects would be even throughout? I'm not
sure how to put that to the test.
Cheers,
Jeff
if finished?
Cheers,
Jeff
On Sun, Apr 19, 2015 at 10:38 PM, Jim Nasby jim.na...@bluetreble.com
wrote:
On 4/19/15 9:09 PM, Jeff Janes wrote:
I did literally the simplest thing I could think of as a proof of
concept patch, to see if it would actually fix things. I just jumped
back a certain number of blocks
range, rather than looping
over each individual block?
What would have to be done to detect people running on SSD and disable the
feature, if anything?
I'll add this to next commitfest as WIP patch.
Cheers,
Jeff
jjprefetch.patch
Description: Binary data
jjprefetch.sh
Description: Bourne
On Tue, Apr 14, 2015 at 11:45 PM, Jeff Janes jeff.ja...@gmail.com wrote:
On Tue, Mar 31, 2015 at 12:02 PM, Tomas Vondra
tomas.von...@2ndquadrant.com wrote:
Hi all,
attached is v4 of the patch implementing adaptive ndistinct estimator.
Hi Tomas,
I have a case here where the adaptive
adminpack does not exist
Command was: COMMENT ON EXTENSION adminpack IS 'administrative
functions for PostgreSQL';
I get the same error whether the source database is 9.2.10 or 9.5.HEAD.
Cheers,
Jeff
1113772 live rows and
0 dead rows; 3 rows in sample, 1113772 estimated total rows
WARNING: ndistinct estimate current=998951.78 adaptive=135819.00
Cheers,
Jeff
for psql? (I will never remember how to spell
BERNOULLI).
Needs a Cat version bump.
Cheers,
Jeff
to automatically
trigger a vacuum freeze in the process.
Cheers,
Jeff
On Mon, Mar 30, 2015 at 8:54 PM, Jeff Janes jeff.ja...@gmail.com wrote:
After freeing up the rows at the end of the table so it is eligible for
truncation, then running a manual VACUUM to actually release the space, I
kept running into the problem that the truncation scan was consistently
.
Thanks, it is obvious once you see it!
Your patch solved the problem for me.
Cheers,
Jeff
On Tue, Mar 31, 2015 at 1:29 AM, Michael Paquier michael.paqu...@gmail.com
wrote:
On Tue, Mar 31, 2015 at 3:42 PM, Jeff Janes jeff.ja...@gmail.com wrote:
On Mon, Mar 30, 2015 at 8:54 PM, Jeff Janes jeff.ja...@gmail.com wrote:
After freeing up the rows at the end of the table so
seen a real-world example of this causing refusal of a fast
shutdown to shutdown fast.
Cheers,
Jeff
compute_index_stats_interrupt.patch
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org
On Sat, Mar 28, 2015 at 3:37 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Jeff Janes jeff.ja...@gmail.com writes:
Analyze on functional indexes cannot be interrupted very easily.
...
The attached patch fixes it, but don't vouch for its safety.
Hm. The other per-sample-row loops in analyze.c
?
Are they independent, or does one depend on the other? row_to_array by
itself applies but doesn't compile.
Cheers,
Jeff
-the-plug test on a massive scale, is to run pg_fsync_test and assuming
that any result inconsistent with the RPM of the spinning rust is obviously
unsafe. Unfortunately that doesn't rule out the possibility that something
is both unsafe and gratuitously slow.
Cheers,
Jeff
When building with LOCK_DEBUG but without casserts, I was getting unused
variable warnings.
I believe this is the correct way to silence them.
Cheers,
Jeff
silence_lwlock_lock_debug.patch
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make
are preserved. I have a large database of security prices. I want
accuracy above all.
I do not have time right now to produce the needed evidence for all
these cases of floating point values. If there is interest I can
produce this in a day or so.
Jeff Anton
BTW: This is my first posting
sleep?
I've certainly regretted the inability to
change autovacuum_vacuum_cost_delay mid-table on more than one occasion.
This was mostly during doing testing work, but still I'm sure other people
have run into this problem, perhaps without knowing it.
Cheers,
Jeff
://www.postgresql.org/message-id/54f0c11d.7000...@2ndquadrant.com/ from
Tomas Vondra tomas.vondra at 2ndquadrant.com
But that patch failed the majority of make check checks in my hands. So
I also don't know what the status is.
Cheers,
Jeff
kind of detectable performance hit?
I don't think I've ever thought myself You know, I really wish I hadn't
included the milliseconds in that timestamp.
Same question for %t, but that ship has already sailed.
Cheers,
Jeff
of synchronous_commit. It is checkpointing and
flush-WAL-before-data where fsync=off does its damage.
Force data to disk when needed for integrity?
Or just don't describe what it is at all, and refer to the documentation
only.
Cheers,
Jeff
not seeing that
happening. Is this a doc bug or an implementation bug?
Cheers,
Jeff
seems to work for me, I did some
testing on it before I realized it was obsolete.)
Cheers,
Jeff
-test.sql)
at 2015-02-23 23:09:06
http://www.postgresql.org/message-id/54ebb312.7090...@2ndquadrant.com/ from
Tomas Vondra tomas.vondra at 2ndquadrant.com (Patch: No)
is misleading.
Cheers,
Jeff
.
If so, it needs a rebase.
Thanks,
Jeff
On Mon, Mar 9, 2015 at 5:34 PM, Peter Geoghegan p...@heroku.com wrote:
On Mon, Mar 9, 2015 at 5:18 PM, Jeff Janes jeff.ja...@gmail.com wrote:
It has a right-link (that's the easiest way to tell).
Meaning that btpo_next is not zero? Should we say that in the patch in
so
many words? I
,
parent_rel-consider_startup);
Cheers,
Jeff
On Wed, Dec 17, 2014 at 12:39 AM, Simon Riggs si...@2ndquadrant.com wrote:
On 15 December 2014 at 20:26, Jeff Janes jeff.ja...@gmail.com wrote:
I still get the compiler error in contrib:
pgstattuple.c: In function 'pgstat_heap':
pgstattuple.c:279: error: too few arguments to function
looking at a non-rightmost page?
Thanks,
Jeff
On Mon, Mar 9, 2015 at 4:06 PM, Peter Geoghegan p...@heroku.com wrote:
On Mon, Mar 9, 2015 at 3:51 PM, Jeff Janes jeff.ja...@gmail.com wrote:
How do I know if I am looking at a non-rightmost page?
It has a right-link (that's the easiest way to tell).
Meaning that btpo_next is not zero
in different orders, for no apparent reason. That is kind of
annoying, but I never traced it back to the cause (nor have I excluded
PEBCAK as the real cause).
Cheers,
Jeff
need to be done for every
input tuple of HashAgg.
Thoughts?
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
for the
next CF.
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
the cleanup at least.
Regards,
Jeff Davis
*** a/src/backend/utils/mmgr/aset.c
--- b/src/backend/utils/mmgr/aset.c
***
*** 438,451 AllocSetContextCreate(MemoryContext parent,
Size initBlockSize,
Size maxBlockSize)
{
! AllocSet context;
/* Do the type
On Sun, 2015-02-22 at 00:07 -0500, Tom Lane wrote:
If you want to have just *one* variable but change its name and type,
I'd be ok with that.
Thank you for taking a quick look. Committed as a simple rename from
context to set.
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing
to the COUNT()? Also, how could that allocate huge amounts of memory and
get killed by OOM, which happens easily with this query?
Oops, I misread that as COUNT(*). Count(x) will force array_agg() to
be executed.
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers
,
Jeff Davis
array_agg_test.sql
Description: application/sql
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
the -n
when I use -f and don't have the default tables in place, than have to
learn new methods for saying no really, I left -n off on purpose when I
have a custom file which does use the default tables and I want them
vacuumed.
Cheers,
Jeff
On Sat, 2015-02-07 at 16:08 -0800, Jeff Davis wrote:
I believe Inclusion Constraints will be important for postgres.
I forgot to credit Darren Duncan with the name of this feature:
http://www.postgresql.org/message-id/4f8bb9b0.5090...@darrenduncan.net
Regards,
Jeff Davis
--
Sent
that deadlocks are not too common
- add tests
Any takers?
Regards,
Jeff Davis
*** a/doc/src/sgml/ref/create_table.sgml
--- b/doc/src/sgml/ref/create_table.sgml
***
*** 63,69 CREATE [ [ GLOBAL | LOCAL ] { TEMPORARY | TEMP } | UNLOGGED ] TABLE [ IF NOT EXI
PRIMARY
From nobody Fri Jan 30 18:20:23 2015
Content-Type: text/plain; charset=utf-8
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Subject: Re: Parallel Seq Scan
To: pgsql-hackers@postgresql.org
From: Jeff Janes jeff.ja...@gmail.com
Date: Fri, 30 Jan 2015 18:20:23 +
User-Agent: pgcommitfest
X
the data it will need
(or at least, the behavior I observe is as-if it did that). But maybe if
the sequential read is a bunch of random reads from different processes
which just happen to add up to sequential, that confuses the algorithm?
Cheers,
Jeff
On Wed, Jan 28, 2015 at 1:13 PM, Jim Nasby jim.na...@bluetreble.com wrote:
My $0.01:
While I sympathize with Noah's sentiments, the only thing that makes sense
to me is that a JSON text field is treated the same way as we treat text.
Right now, that means NUL is not allowed, period.
If no
nearby location will just move the
(expected) checksum a little bit.
Cheers,
Jeff
break the old API, and I'm not suggesting that we do. I was
hoping to find some alternative.
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Tue, Jan 20, 2015 at 6:44 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Jeff Davis pg...@j-davis.com writes:
Tom (tgl),
Is my reasoning above acceptable?
Uh, sorry, I've not been paying any attention to this thread for awhile.
What's the remaining questions at issue?
This patch is trying
be worse than the
disease though.
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Sun, Dec 28, 2014 at 11:53 PM, Jeff Davis pg...@j-davis.com wrote:
On Tue, 2014-04-01 at 13:08 -0400, Tom Lane wrote:
I think a patch that stood a chance of getting committed would need to
detect whether the aggregate was being called in simple or grouped
contexts, and apply different
it be called? I thought
of \dx+, but the + is already used to show the objects associated with the
extensions. (Althought it seems like it would more in keeping with other
usage if \dx+ only listed the objects if it was given a pattern, and did
what I propose if given no pattern)
Cheers,
Jeff
On Fri, Jan 2, 2015 at 9:59 PM, Jeff Janes jeff.ja...@gmail.com wrote:
On Mon, Dec 29, 2014 at 2:15 PM, Alvaro Herrera alvhe...@2ndquadrant.com
wrote:
Here's a patch that tweaks the grammar to use TypeName in COMMENT,
SECURITY LABEL, and DROP for the type and domain cases. The required
are attached
Cheers,
Jeff
pg_upgrade_server.log
Description: Binary data
pg_upgrade_dump_16384.log
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
, you could just compress the whole WAL stream.
Was this point addressed? How much benefit is there to compressing the
data before it goes into the WAL stream versus after?
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
On Sun, Dec 28, 2014 at 12:45 PM, Peter Geoghegan p...@heroku.com wrote:
On Sun, Dec 28, 2014 at 12:37 PM, Jeff Davis pg...@j-davis.com wrote:
Do others have similar numbers? I'm quite surprised at how little
work_mem seems to matter for these plans (HashJoin might be a different
story
On Tue, Dec 30, 2014 at 12:35 AM, Guillaume Lelarge guilla...@lelarge.info
wrote:
Sorry for my very late answer. It's been a tough month.
2014-11-27 0:00 GMT+01:00 Bruce Momjian br...@momjian.us:
On Mon, Nov 3, 2014 at 12:39:26PM -0800, Jeff Janes wrote:
It looked to me that the formula
On Mon, Dec 29, 2014 at 9:12 PM, Peter Geoghegan p...@heroku.com wrote:
On Mon, Dec 29, 2014 at 2:29 PM, Jeff Janes jeff.ja...@gmail.com wrote:
Using the vallock2 version of V1.8, using the test I previously
described, I
get some all-null rows, which my code should never create. Also
On Tue, 2014-12-23 at 01:16 -0800, Jeff Davis wrote:
New patch attached (rebased, as well).
I also see your other message about adding regression testing. I'm
hesitant to slow down the tests for everyone to run through this code
path though. Should I add regression tests, and then remove
On Thu, 2014-12-11 at 02:46 -0800, Jeff Davis wrote:
On Sun, 2014-08-10 at 14:26 -0700, Jeff Davis wrote:
This patch is requires the Memory Accounting patch, or something similar
to track memory usage.
The attached patch enables hashagg to spill to disk, which means that
hashagg
On Sun, 2014-12-28 at 12:37 -0800, Jeff Davis wrote:
I feel like I made a mistake -- can someone please do a
sanity check on my numbers?
I forgot to randomize the inputs, which doesn't matter much for hashagg
but does matter for sort. New data script attached. The results are even
*better
it means a context in shared memory. I see
that the patch itself doesn't use that phrase, which is good, but can
we come up with some other phrase for talking about it?
Common memory context?
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org
.
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
allocation from 64 to some lower
number. But if we're doubling each time, it won't take long to get
there; and because it's the simple context, we only need to do it once.
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
On Tue, Dec 23, 2014 at 11:55 AM, Peter Geoghegan p...@heroku.com wrote:
On Thu, Dec 18, 2014 at 9:20 AM, Jeff Janes jeff.ja...@gmail.com wrote:
I've put this through an adaptation of my usual torture test, and it ran
fine until wraparound shutdown. I'll poke at it more later.
Could you
though. Should I add regression tests, and then remove them later
after we're more comfortable that it works?
Regards
Jeff Davis
*** a/doc/src/sgml/config.sgml
--- b/doc/src/sgml/config.sgml
***
*** 3045,3050 include_dir 'conf.d'
--- 3045,3065
/listitem
On Mon, Dec 15, 2014 at 11:06 PM, Peter Geoghegan p...@heroku.com wrote:
On Mon, Dec 15, 2014 at 4:59 PM, Peter Geoghegan p...@heroku.com wrote:
On Mon, Dec 15, 2014 at 4:22 PM, Jeff Janes jeff.ja...@gmail.com
wrote:
Also, in both Linux and MinGW under option 1 patch I get an OID
conflict
' didn't detect the problem. Now I see that IGNORE is getting turned
to 0.
Your new version 1.7 of the patches fixes that issue, as well as the OID
conflict.
Thanks,
Jeff
.
In addition to the semicolon, it doesn't build under cassert. There are
some pairingheap_empty that need to be pairingheap_is_empty, and snapmgr.c
needs an address of operator near line 355 and something is wrong
in snapmgr.c near line 811.
Cheers,
Jeff
, uses git to be utterly baffling. The git log is
bloated with the same change being listed multiple times, at least once as
a commit and again as a merge. If your suggestion would be to go in that
direction, I don't think that would be an improvement.
Cheers,
Jeff
don't know how to get my hands on the intermediate file after
the preprocessor has done its thing.
Also, in both Linux and MinGW under option 1 patch I get an OID conflict on
OID 3261.
Cheers,
Jeff
On Sun, 2014-08-10 at 14:26 -0700, Jeff Davis wrote:
This patch is requires the Memory Accounting patch, or something similar
to track memory usage.
The attached patch enables hashagg to spill to disk, which means that
hashagg will contain itself to work_mem even if the planner makes a
bad
write down
the steps to reproduce it, and then follow my own instructions to make sure
it does actually reproduce it. If I find no bugs, it is just I did a
bunch of random stuff and nothing bad happened, that I noticed.
Chees,
Jeff
this until
it is fixed then at least the author (and perhaps more important, junior
contributors who are not the author) will know either what argument to make
to lobby for it, what avenue to take when reviewing it, or whether to just
forget it and work on something more important.
Cheers,
Jeff
: warning: 'RegisterWaitForSingleObject' redeclared
without dllimport attribute: previous dllimport ignored [-Wattributes]
input.c:382:1: warning: 'saveHistory' defined but not used
[-Wunused-function]
Does anyone have opinions on how to address these?
Cheers,
Jeff
On Tue, Dec 2, 2014 at 7:41 AM, Robert Haas robertmh...@gmail.com wrote:
On Wed, Nov 26, 2014 at 7:13 PM, Jeff Janes jeff.ja...@gmail.com wrote:
If I do a pg_ctl stop -mf, then both files go away. If I do a pg_ctl
stop
-mi, then neither goes away. It is only with the /sbin/reboot that I
? create index?
Cheers,
Jeff
On Tue, Dec 2, 2014 at 11:41 AM, Andres Freund and...@2ndquadrant.com
wrote:
On 2014-12-02 11:23:31 -0800, Jeff Janes wrote:
I think it would be more promising to work on downgrading lock strengths
so
that fewer things conflict, and it would be not much more work than what
you propose
On Wed, Nov 26, 2014 at 4:13 PM, Jeff Janes jeff.ja...@gmail.com wrote:
On Tue, Nov 25, 2014 at 9:30 PM, Jeff Janes jeff.ja...@gmail.com wrote:
Using both 9.2.9 and 9_2_STABLE 9b468bcec15f1ea7433d4, I get a fairly
reproducible startup failure.
What I was doing is restore a database from
On Sun, 2014-11-30 at 17:49 -0800, Peter Geoghegan wrote:
On Mon, Nov 17, 2014 at 11:39 PM, Jeff Davis pg...@j-davis.com wrote:
I can also just move isReset there, and keep mem_allocated as a uint64.
That way, if I find later that I want to track the aggregated value for
the child contexts
On Wed, Nov 26, 2014 at 5:06 AM, Alvaro Herrera alvhe...@2ndquadrant.com
wrote:
Jeff Janes wrote:
This is what I get in the log from the attempted restart:
PST LOG: database system was interrupted; last known up at 2014-11-25
15:40:33 PST
PST LOG: database system was not properly
On Tue, Nov 25, 2014 at 9:30 PM, Jeff Janes jeff.ja...@gmail.com wrote:
Using both 9.2.9 and 9_2_STABLE 9b468bcec15f1ea7433d4, I get a fairly
reproducible startup failure.
What I was doing is restore a database from a base backup and roll it
forward with a recovery.conf until it completes
a tarball of this particular database. How would I go
about debugging this? Should I track down the source of the FATAL and
convert it to a PANIC so I can get a core dump to look at?
A second attempt to start up the server completes successfully.
Cheers,
Jeff
it now. I disagree. You are assuming that
sharing exclusive heavyweight locks among a group will be a fundamental
part of everything postgres does with parallelism; but not every design
requires it.
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org
is waiting on A2. That's still a deadlock, right?
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
unlink from working, as the file
is still open.
Trivial fix attached.
Thanks,
Jeff
pg_test_fsync_leak.patch
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
.
That way, if I find later that I want to track the aggregated value for
the child contexts as well, I can split it into two uint32s. I'll hold
off any any such optimizations until I see some numbers from HashAgg
though.
Attached new version.
Regards,
Jeff Davis
*** a/src/backend/utils/mmgr
the same strategy here. When we see deadlocks becoming a
problem for any reasonable workload, we make a series of tweaks (perhaps
some to the lock manager itself) to reduce them.
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes
you set that to a non-actual value. I
don't recall of the top of my head which things those are, though.
Cheers,
Jeff
that? It is already done that way under
\pset format aligned.
Cheers,
Jeff
On Thu, Nov 13, 2014 at 11:26 AM, Robert Haas robertmh...@gmail.com wrote:
On Thu, Nov 13, 2014 at 3:38 AM, Jeff Davis pg...@j-davis.com wrote:
If two backends both have an exclusive lock on the relation for a join
operation, that implies that they need to do their own synchronization
601 - 700 of 3173 matches
Mail list logo
