>
>
> > I mean, could random bytes appear as a valid record (very unlikely, but
> > possible)?
>
> Yes, that could be possible if some memory or disk is broken. That's
> why, while it is important to take backups, it is more important to
> make sure that they are able to restore correctly before de
s that user
to start with; a magic one-way privilege switch doesn't really help.
We've discussed this problem repeatedly (you might want to search the
archives a bit) and never found a solution that was both fully secure
and did much of anything for connection-pooling scenarios.
27;s happening inside
a stored procedure from these examples ... especially if the procedure's
query is only "sort of similar". Parameter references don't act quite
like either constants or CURRENT_TIMESTAMP so far as the planner is
concerned.
But I think pulling out the is-null test
sage)
regression=#
What this should produce is an error similar to the one you get in
plpgsql. COPY to stdout/from stdin can't be executed from inside an
already-running query, because the wire protocol can't support
nesting those operations.
regards, tom lane
--
the output?
This is a matter for how your client code presents the message data.
So far as psql is concerned, the answer would be "no", but a custom
application could deconstruct the notice message however it wanted.
regards, tom lane
--
Sent via pgsql-gen
ml
If you don't actually care about the PG docs, don't use "make world".
"make all" at the top level, followed by "make all" in the contrib
subdir, should cover what you need.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
suggest
reconfigure with --with-perl (and all else the same as before), build,
then cd to src/pl/plperl and do "make install" only in that subdirectory.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make chang
uote marks. How are you entering
this SQL command, exactly?
Also, you can't just write double commas to leave out a item in the
value list. You could write DEFAULT there, ie
... VALUES (1,'AG Spray Inc.',DEFAULT,'PO Box 12129','Salem', ...
d a function to apply like_escape
to each member of an array.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
age-id/flat/0A3221C70F24FB45833433255569204D1F5F1751@G01JPEXMBYT05
Looks like it's blocked on the question of what privileges are required
to use the feature.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgre
s this, and can I change something so I, as a user, can copy tables
> directly to ~/?
Use psql's \copy instead.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
black boxes, it's hard to see
how it could be done in a way that wasn't a ugly kluge.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
Hi,
I've two threads countinuously updataing rows in the same table.
Each one does: BEGIN, UPDATE,UPDATECOMMIT
There can't be two active transactions updating the same row (my bug apart
but I don't think so).
I'm using default_transaction_isolation = 'serializable'
I get "could not serialize ac
rwritten by package upgrades, or they
fail to track changes in the script, and either result is bad.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
ostgresql fix?
You can't really get around the fact that if your application
looks at system catalog or view columns that change, your
application is going to need changes too.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
I suspect it has something to do with one
installation being configured with different default socket directory
than the other, but I don't have enough facts.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
up
the data before you try to put the constraint back on. And this time,
express it as something like time_stamp >= '2010-12-01 00:00+00' etc ...
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
ey are failing because of
the other side of the range constraint (the <= 2012-01-01 end),
implying that they were stored under a zone setting west of UTC.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
onally equal values, but
they're stored with different dscale fields, and that in turn has
consequences for subsequent arithmetic operations.
If you're willing to live with different dscales in the column, I'd
suggest just going to unconstrained numeric.
regar
trying to store a pointer in an integer, say. Can't debug it for
you though. I'd suggest recompiling with full warnings (gcc -Wall
at least) and paying close attention to anything the compiler warns
about.
regards, tom lane
--
Sent via pgsql-general mailing li
ion explicitly.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
ows when
bleating that it can't connect.
Usually this isn't operator error per se, but inconsistent defaults
between builds obtained from different sources.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make change
mezone() some function you've
> defined? I'm not aware of any built in function by that name.
That's the internal spelling of "d_date AT TIME ZONE 'Etc/UTC'".
It's still a pretty good question why index that and not just d_date.
ps, and the ordering you happen to get
isn't the one you want. But it's not a bug because you did not do what
you're supposed to do to specify the ordering you want.
In short: write the required ORDER BY.
regards, tom lane
--
Sent via pgsql-general mailing list
o your requirement really
has to be that the extension deviate in just limited ways from the base
--- but you've not said in just what ways you want it to deviate.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your
have some
easy way to turn on this behavior, complain to the vendor ...
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
ask about specific changes you want to make
in the compiler and flag choices (and explaining why you want to make
those specific changes wouldn't be a bad thing either).
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make
sions against Postgres on CentOS are there
> any dangers of doing that?
Doesn't matter if the core system itself doesn't work, which it wouldn't
in cross-platform cases.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgres
e like
USING (check_valid_promoter(promoter))
with that function being defined in the obvious way. There's little
reason to enumerate the entire set of valid promoters if you only
need to find out whether one specific value is one.
regards, tom lane
--
Sen
en't outer-level anymore, which is probably not
what we want it to be.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
a BBU (and writeBack mode)
Right offhand, I wonder whether the weak link in that isn't OpenVZ.
Virtualization technologies have a long and ugly reputation for not
providing strong filesystem-integrity guarantees.
regards, tom lane
--
Sent via pgsql-g
es || '%');
which while it might look less "constant" is actually more so from the
planner's perspective, because there is no question of whether "i" has
got a field of that name.
regards, tom lane
--
Sent via pgsql-general mailing list
nce(). What I think is going on here is that you've
got some cron job that aggressively connects to the database and runs a
pg_dump the moment you start it. It's unsurprising that that would
deadlock against a pg_restore -C.
regards, tom lane
--
Sent via pg
27;s quite unclear to me what threat model such a behavior would add
useful protection against.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
ith some sample file like that. You'll lose the configuration values
selected by initdb, which typically isn't a good idea.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
d then
redirecting stderr to go where stdout goes. So all output is
going to the bit bucket, not the pipe.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
alues reflect whether *explicit* huge pages are enabled. They do
not control *transparent* huge pages.
Red Hat's version of all this is documented here:
https://access.redhat.com/solutions/46111
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-genera
ionally. Extremely long transactions
like this will cause you headaches in a number of other ways too, like
inability to reclaim disk space.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www
l, maybe. But there's no way to *guarantee* it will work. And
> apparently it doesn't.
AFAICT, backwards compatibility is not something the gcc boys care about.
I suspect the particular complaint here is related to
Author: Tom Lane
Branch: REL9_1_STABLE Release: REL9_1_10 [649839
it.
> In the post below the OP shows the tables involved(they where inherited):
> http://www.postgresql.org/message-id/cadbmknm_y9ewdawdq_8dj1muc0z_fgwtyad2rwchgexj2jv...@mail.gmail.com
Inherited eh? Maybe related to 074c5cfbf.
regards, tom lane
--
Sent via pgsq
Hello:
Is there a plan for 9.6 to resolve the issue of very slow query/retrieval
of jsonb fields
when there are large number (maybe several thousands) of top level keys.
Currently, if I save a large json document with top level keys of thousands
and query/retrieve
field values, the whole document
-as-number-of-keys-increase
below url mentions the potential issue.
https://www.reddit.com/r/PostgreSQL/comments/36rdlr/improving_select_performance_with_jsonb_vs_hstore/
Thanks
On Sun, Nov 29, 2015 at 7:35 AM, Thomas Kellerer wrote:
> Tom Smith schrieb am 29.11.2015 um 03:27:
>
>> Hello:
>
document data.
On Sun, Nov 29, 2015 at 12:37 AM, John R Pierce wrote:
> On 11/28/2015 6:27 PM, Tom Smith wrote:
>
>> Is there a plan for 9.6 to resolve the issue of very slow query/retrieval
>> of jsonb fields
>> when there are large number (maybe several thousands) of top
Bill Moran writes:
> Tom Smith wrote:
>> Is there a plan for 9.6 to resolve the issue of very slow
>> query/retrieval of jsonb fields when there are large number (maybe
>> several thousands) of top level keys. Currently, if I save a large
>> json document with top
extremely slow.
Thanks
On Sun, Nov 29, 2015 at 12:54 PM, Tom Lane wrote:
> Bill Moran writes:
> > Tom Smith wrote:
> >> Is there a plan for 9.6 to resolve the issue of very slow
> >> query/retrieval of jsonb fields when there are large number (maybe
> >>
y. It's up to you to ensure
that none of those extra threads ever escape to execute any non-Perl
code. I suspect this could easily explain the problems you're seeing.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
that
can change from time to time.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
h the
indexes, which could be painful.
(Having said that, it sure looks to me like JSON's idea of a number is
float/numeric, not merely int. Are you sure you need more capability
in that department, and if so what exactly?)
regards, tom lane
--
Sent via pgsql-general mail
no idea.
The minute you start fooling with a backend's signal behavior, we're
going to politely refuse to support whatever breakage you run into.
We aren't sending those signals just for amusement's sake.
regards, tom lane
--
Sent via pgsql-general
le.php','/([^/]*)$','&file=\1')
or you could use a lookahead constraint:
regexp_replace('http://test.com/test/testfile.php','/(?=[^/]*$)','&file=')
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
anywhere in Postgres, and never has been AFAIK.
I'd speculate that the root of your problem is a version mismatch between
BOOST and SOCI, but it's only speculation.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes
atement = all which you've already rejected.
It'd be possible to write a C-code extension that did something like
that, and some work in that direction has already gone on; the pg_audit
extension that didn't quite get into 9.5 might come close to your
requirements.
ing less crude than 0.5. But again, it's hard
to say what to use instead.
The first of these ideas might be something that would be sane to
back-patch, but I'd be pretty hesitant about back-patching anything
along the lines of #2; the scope of the effects is hard to predict.
bers you show above prove that
it is almost out of free swap already.
Also, while that 20G of "inactive" pages may be candidates for reuse,
they probably can't actually be reused without swapping them out ...
and there's noplace for that data to go.
r
y quite a few patches that would now need to be
documented as "new in 9.5" and are more significant than this.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
han btree indexes for
any real-world purpose. I'm curious why you chose this index type in
the first place.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
ion of the project policy about using COSTS OFF in regression
explain commands. That's causing some though not all of your diffs,
and might lead to pseudo-failures in other environments that we do
consider supported. I'll go fix that ...
regards, tom lane
--
gorithms, or anything of that sort)?
I don't think Postgres even has any concept that matches what you seem
to think a Session ID is.
If you're looking for communication security/integrity checking, that's
something we leave to other software such as SSL.
r
d try again till the REINDEX
succeeds.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
reasons
for that are partly historical no doubt (the listserv used to be a lot
less reliable/prompt than it is now), but the custom is established.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription
postgres;
DROP DATABASE
# create database postgres with template template0;
CREATE DATABASE
If you don't have any custom objects in the postgres database, this would
be by far the easiest way out.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-genera
installation, you could
manually unset the datistemplate flag for either, drop it, and clone it
from the other one.
In short, there's less magic here than meets the eye.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
, but
that's still a large net savings of time.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
erator? And what sort of index are
you using now, that can accept it? Are the rowcount estimates in
the EXPLAIN output accurate? (If they are, it's hardly surprising
that the query takes a long time.)
regards, tom lane
--
Sent via pgsql-general mailing list
Andreas Kretschmer writes:
>> Tom Lane hat am 27. Dezember 2015 um 19:11 geschrieben:
>> What in the world is this @~ operator? And what sort of index are
>> you using now, that can accept it? Are the rowcount estimates in
>> the EXPLAIN output accurate? (If they are
ilities for finding out what the
DDL command had done; 9.5 will provide more info.)
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
m indexes (ie,
contrib/pg_trgm and a GIST or GIN index). See
http://www.postgresql.org/docs/9.4/static/pgtrgm.html
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
Hiroyuki Sato writes:
> I re-created index with pg_trgm.
> Execution time is 210sec.
> Yes It is faster than btree index. But still slow.
> It is possible to improve this query speed?
> Should I use another query or idex?
Did you try a GIN index?
re
table in array the_tables
loop
raise notice 'schema = %; table = %', the_table.t[1], the_table.t[2];
end loop BIGLOOP;
end;
$BODY$
LANGUAGE plpgsql;
select create_table('mike', 'test', true);
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
mns of
the array to be interchangeable at all, so really he would be better
off modeling the data as you suggest.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
-
Bitmap Heap Scan on search (cost=44.00..48.01 rows=1 width=21)
Recheck Cond: (search_vec @@ '''213'' & ''e'' & ''13'' & '&#
using this would probably be eaten by the
overhead of calling a SQL or PL function for each pair of array elements.
You'd probably end up in the same ballpark performance-wise as the UNNEST
solution given earlier.
regards, tom lane
--
Sent via pgsql-general mailing
Andy Colson writes:
> Here are my results, if there are any others you'd like to see please
> let me know. Thanks Tom.
For comparison, could we see the results for the non-partial case, ie
explain analyze
select *
from search
where search_vec @@ to_tsquery('213 &
actually is significantly more expensive than
the non-partial case: 4 msec vs .025 msec. Still, that's about a 200x
penalty, not the 1x penalty the planner is ascribing to it.
Thanks for the data! I'll go moan about this on -hackers.
regards, tom lane
--
Cond: (search_vec @@ to_tsquery('213 & E & 13 & ST &
> N'::text))
This says there's only about a 25% runtime penalty for the partial match,
at least on your example, compared to the planner's estimate of 2700x
penalty :-(. Definitely need to fix th
not: the estimates seem to track the actual cost reasonably well. So
it seems like you've got some weird data statistics that are causing a
misestimate. Could we see the pg_stats row for that tsvector column?
Or maybe even the actual data?
regards, tom lane
--
Sent v
cts the cost
of checking uncommitted tuples to see if they've become committed yet.
If so, there may be little you can do about it except break the insertion
into smaller transactions ... which might or might not be all right from
a data consistency standpoint.
regard
Andy Colson writes:
> On 12/30/2015 1:07 PM, Tom Lane wrote:
>> it seems like you've got some weird data statistics that are causing a
>> misestimate. Could we see the pg_stats row for that tsvector column?
>> Or maybe even the actual data?
> The table exists in
Andy Colson writes:
> On 12/30/2015 1:55 PM, Tom Lane wrote:
>> Are you using any nondefault planner settings? Anything else
>> unusual about your installation?
> There are others, but I'll bet its:
> random_page_cost = 1
Nope...
Maybe something weird about the buil
Andy Colson writes:
> On 12/30/2015 2:18 PM, Tom Lane wrote:
>> Maybe something weird about the build you're using? What does
>> pg_config print?
> [ output ]
No smoking gun there either.
It might be worthwhile to update to 9.3.10, just in case there is
something wonk
UUM I see
(gdb) p *metadata
$2 = {head = 4294967295, tail = 4294967295, tailFreeSize = 0,
nPendingPages = 0, nPendingHeapTuples = 0, nTotalPages = 685,
nEntryPages = 410, nDataPages = 16, nEntries = 44125, ginVersion = 2}
and the cost estimate is far saner.
regards
e what to_timestamp() returns is timestamp WITH time
zone, converting its result to timestamp WITHOUT time zone will cause a
timezone rotation which is what is messing you up. If you feel you really
must do things this way, set the timezone parameter to "UTC" so there's no
zone conve
?xyz) (where xyz is
> one or more alphabetic characters) specifies options affecting the rest of
> the RE.
Right. It says "begin with" and it means "begin with".
We are not Perl and are not attempting to be bug-compatible with its regex
engine. If you want bug-compatibili
e code.
That particular chunk of code is quite MSVC version dependent; read the
comments for it. It's annoying but not especially surprising that they
broke it in an upgrade. Somebody will have to research how one is
supposed to get the appropriate locale name now.
s I made for 9.5 were to no longer set row_security to 'force'
> in postgresql.conf
What did you set it to instead?
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
Ted Toth writes:
> On Mon, Jan 4, 2016 at 4:54 PM, Tom Lane wrote:
>> Are you perhaps testing this as a superuser? Superusers bypass RLS
>> even with FORCE ROW LEVEL SECURITY.
> Yes I was a Superuser but without 'Bypass RLS'. So there's no way to
> enforce
index,
but not vice versa.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
Steve Rogerson writes:
> On 05/01/16 19:47, Tom Lane wrote:
>> That's operating as designed. A unique constraint needs an index,
>> but not vice versa.
> I can see that might be plausible , hence the question but as a "unique index"
> imposes as constra
answer, which might serve as long as your application only
cares about a small number of prefix lengths, is functional indexes.
If you create a functional index on "left(foo,3)" you're all set.
This won't scale well to a whole bunch of different lengths, though.
stgresql.org/docs/devel/static/xoper-optimization.html
Again, that's something that could be improved in principle, but
the amount of work involved seems disproportionate to the likely
benefit.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general
Ted Toth writes:
> This happens on simple INSERTs no RETURNING.
You're going to need to show a concrete example.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgr
h internally uses a
> dump/restore cycle rather than calling pg_upgrade. That
> failed due to ordering problems with table data vs table
> constraints.)
That seems like an independent bug. Can you provide specifics?
regards, tom lane
--
Sent via pgsql-general
Karsten Hilbert writes:
> On Fri, Jan 08, 2016 at 10:45:27AM -0500, Tom Lane wrote:
>> Just for completeness, can you tell us which pg_trgm version (1.0
>> or 1.1) is installed in the 9.4 database?
> Sure:
> (pg_trgm,1.1,"text similarity measurement and index sear
Karsten Hilbert writes:
> On Fri, Jan 08, 2016 at 11:12:09AM -0500, Tom Lane wrote:
>> Hm. I just tried running a pg_upgrade here on a 9.4 database containing
>> pg_trgm 1.1, and didn't see any particular problem, so there's some
>> additional factor needed to c
p to dump things in an unexpected order, which
> could possibly explain the message we're seeing. But that's just a
> guess.
BTW, there will also be .log files, which might contain useful information
as well, especially if any of it is bleats from pg_dump about being unable
to b
Karsten Hilbert writes:
> On Fri, Jan 08, 2016 at 11:23:21AM -0500, Tom Lane wrote:
>> A suggestion is to run the pg_upgrade with -r switch, which will leave a
>> litter of files in your working directory. Some of them will be named
>> like pg_upgrade_dump_NNN.custom and sh
ou can make the modified_by column be a foreign
key referencing a table of users (it probably couldn't be defined
quite like "staff", but you get the idea). The presence of the foreign
key would be enough to cue pg_dump about load order.
regards, tom
Karsten Hilbert writes:
> On Fri, Jan 08, 2016 at 12:38:47PM -0500, Tom Lane wrote:
>> After digging through this, I figured out the problem: you'd installed
>> pg_trgm into the pg_catalog schema, whereas when I was testing I'd just
>> dropped it into the public
Karsten Hilbert writes:
> On Fri, Jan 08, 2016 at 04:03:51PM -0500, Tom Lane wrote:
>> BTW, the one-liner fix that I'd had in mind when I wrote that does indeed
>> fix this particular problem, but after studying the code I realized that
>> there's a whole bunch of r
Adrian Klaver writes:
> On 01/08/2016 01:26 PM, Tom Lane wrote:
>> No, it's just a bug. Although apparently not many people do that, or
>> we'd have heard complaints before.
> That dredged up a memory from way back:
> http://www.postgresql.org/message-id/2004112
601 - 700 of 14353 matches
Mail list logo
