On Wed, 2008-11-12 at 10:48 -0500, Jonah H. Harris wrote:
> > Anyway, I think this is worth fixing before release but it clearly isn't
> > worth attempting to rush a patch in the next few hours. I don't think
> > we'll find anyone who is happy with making it a restart-required option.
>
> I could
Hi, Pgsql-hackers.
> what he's looking for is to somehow
> use XML in lieu of, um, either SQL, PHP, libpq, or something like
> that. (And the fact that those are 4 rather different things reveals
> how confused the matter is.)
http://lists.xml.org/archives/xml-dev/200802/msg00213.html
Dmitry
Hello lists,
I am trying to run Slony on a Master Postgres 8.1.11 replicating to a
Slave same version and 2nd Slave Postgres 8.3.4.
The purpose is to update Postgres in production by steps, first slaves
then switchover to upgrade the master that will not be master when
upgraded.
I am getti
Simon Riggs wrote:
> The only remaining problem for me now is the size of the security
> context column added to each row. I can accept a fixed length 4 byte
> value, but anything longer just seems that it will render this unusable.
> Normal apps should be able to benefit from row level security, a
They're all barfing along this line:
dlltool --export-all --output-def libpg_trgmdll.def trgm_op.o trgm_gist.o
trgm_gin.o
dllwrap -o pg_trgm.dll --dllname pg_trgm.dll --def libpg_trgmdll.def
trgm_op.o trgm_gist.o trgm_gin.o -L../../src/backend -lpostgres
-L../../src/port -L/mingw/lib
Info
I wrote:
>> 2. Put some arbitrary limit on the number of subconditions in an AND or
>> OR clause before we give up and don't attempt to prove anything about
>> it.
> So option #2 with a cutoff of 100 items or so is looking like the
> best response.
I've applied a patch along this line to 8.2 and
On Wed, 2008-11-12 at 16:25 -0500, Tom Lane wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
> > On Tue, 2008-11-11 at 21:57 -0500, Tom Lane wrote:
> >> I was imagining that the heap_inplace_update operation would release the
> >> lock. Is there some problem with the concept?
>
> > Not the conc
Tom Lane wrote:
Ron Mayer <[EMAIL PROTECTED]> writes:
Once this settles I suppose I should post a ECPG patch that's based
off of these Decode/Encode interval functions too?
Yeah, if you want. I think you'll find that the datetime code has
drifted far enough since ecpg forked it that you'll be
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> The other thing that maybe you didn't notice is that lp_flags are 2
> bits, not a full byte. A byte-at-a-time CRC calculation is no help
> there.
I think we're talking past each other. Martin and I are talking about doing
something like:
for (...)
Simon Riggs <[EMAIL PROTECTED]> writes:
> On Tue, 2008-11-11 at 21:57 -0500, Tom Lane wrote:
>> I was imagining that the heap_inplace_update operation would release the
>> lock. Is there some problem with the concept?
> Not the concept, just the mechanism.
> Current tuple lock requestors do Xac
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> Which brings to mind an interesting customer case. They are running
> queries like "WHERE id IN (...)", where ... is a *very* long list of
> keys, against a table that's partitioned by ranges of id. The query was
> running slow, because while cons
Martijn van Oosterhout wrote:
> On Wed, Nov 12, 2008 at 11:08:13AM -0300, Alvaro Herrera wrote:
> > However, your idea suggests something else that we could do to improve
> > the patch: skip the ItemId->lp_flags during the CRC calculation. This
> > would mean we wouldn't need to WAL-log those. T
On Wed, Nov 12, 2008 at 11:08:13AM -0300, Alvaro Herrera wrote:
> For this to work, we would have to create two (or more) versions of the
> calculate checksum macro, one for heap pages and other for other pages.
> I'm not sure how bad is that. The bit that's worse is that we'd need to
> have exter
Hmm, I can get around the btree problem by not summing the "special
space". This loses a bit of reliability because some of the most
critical bits of the page would not be protected by the CRC, but the
bulk of the data would be. And this allows me to get away from page
type specific tricks (like
On Tue, 2008-11-11 at 21:57 -0500, Tom Lane wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
> > On Mon, 2008-11-10 at 19:15 -0500, Tom Lane wrote:
> >> The reason I was thinking about heap_lock_tuple is that it might provide
> >> a suitable defense against that case.
>
> > OK. Lock tuple works
On Fri, 2008-11-07 at 16:52 -0500, Bruce Momjian wrote:
> Simon, would you read the chapter on "covert channels"? You might
> understand it better than I do and it might give you some ideas:
>
> http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.33.5950
OK, read that now.
Looks
I wrote:
> We could respond to this in a number of ways:
> 1. "Tough, don't do that."
> 2. Put some arbitrary limit on the number of subconditions in an AND or
> OR clause before we give up and don't attempt to prove anything about
> it.
> 3. Put in a narrow hack that will get us out of this spe
On Thu, Nov 13, 2008 at 5:16 AM, Tom Lane <[EMAIL PROTECTED]> wrote:
> "Brendan Jurd" <[EMAIL PROTECTED]> writes:
>> I guess my question is, what's the real benefit of going to all this
>> trouble trying to prove that clauses are false?
>
> Not having to scan gigabytes of data in an excluded partit
Brendan Jurd wrote:
On Thu, Nov 13, 2008 at 4:52 AM, Tom Lane <[EMAIL PROTECTED]> wrote:
Yeah. An example of a closely related expression that it *would* be
able to prove self-contradictory is
WHERE x = ALL (ARRAY[1, 2, ...])
or perhaps slightly more realistically
WHERE x = ANY (A
"Brendan Jurd" <[EMAIL PROTECTED]> writes:
> I guess my question is, what's the real benefit of going to all this
> trouble trying to prove that clauses are false?
Not having to scan gigabytes of data in an excluded partition, for
instance.
Now the docs do say
Currently, constraint_exclu
On Thu, Nov 13, 2008 at 4:52 AM, Tom Lane <[EMAIL PROTECTED]> wrote:
> Yeah. An example of a closely related expression that it *would* be
> able to prove self-contradictory is
>WHERE x = ALL (ARRAY[1, 2, ...])
> or perhaps slightly more realistically
>WHERE x = ANY (ARRAY[1, 2, 3]
TODO/issues
- add support of other data types to btree_gin
done, now btree_gin supports int2, int4, int8, float4, float8, money, oid,
timestamp, timestamptz, time, timetz, date, interval, macaddr, inet, cidr, text,
varchar, char, bytea, bit and varbit types
--
Teodor Sigaev
Richard Huxton <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Hmph. It's trying to see if the NOT IN condition is self-contradictory,
>> which of course it isn't, but the predicate_refuted_by machinery isn't
>> smart enough to determine that except by running through all N^2
>> combinations of t
>> I think it's actually more correct to say that {} has an undefined
>> number of dimensions.
>
> That is your opinion, but not my argument above.
I'm aware of that. I believe that the semantics of array operations
should carry more weight than a count of curly braces, but certainly
you don't ha
Tom Lane wrote:
Andrew Chernow <[EMAIL PROTECTED]> writes:
Just noticed that the last libpqtypes release was broken on windows when
dynamically linking. The problem is that windows has two addresses for
functions, the import library uses a stub "ordinal" address while the
DLL itself is using
Tom Lane wrote:
"Robert Haas" <[EMAIL PROTECTED]> writes:
Incidentally, I noticed while looking at this that "\h with" also
fails, even though WITH can now be the first word of a valid SQL
statement. I think we ought to patch psql to return the same help for
WITH as it does for SELECT.
Hmm.
Tom Lane wrote:
> "Sergey Konoplev" <[EMAIL PROTECTED]> writes:
>> You are right. I've found the odd thing (that completely drives me
>> mad) in postgresql.conf.
>
>> You are able to reproduce slow-not-in queries by switching
>> constraint_exclusion to on in your postgresql.conf and running my tes
Chuck McDevitt wrote:
What if the block of text is split in the middle of a multibyte character?
I don't think it is safe to assume raw blocks always end on a character
boundary.
Yeah, it's not. I realized myself after submitting. The generic approach
is to loop with pg_mblen() to find out th
Andrew Chernow <[EMAIL PROTECTED]> writes:
> Just noticed that the last libpqtypes release was broken on windows when
> dynamically linking. The problem is that windows has two addresses for
> functions, the import library uses a stub "ordinal" address while the
> DLL itself is using the real a
OK now that im using the right env var everything seems to work as
described. FYI I also tried to exercise the various new error paths
and everything seems good so as far as i'm concerned this looks good
to me. Ill go mark it as "ready for commiter" on the wiki. (whatever
that means you being a
Robert Haas wrote:
It was pointed out to me today that a zero-dimensional matrix is a scalar.
This makes a bit of sense, if you say that
'{{56}}' is of type int[][], 2 dimensions
'{56}' is of type int[], 1 dimension
'56' is of type int, 0 dimensions
Notice that the number of brace pairs in the
Robert Haas wrote:
Hmm, ISTM that cardinality() is implemented here in the manner
previously rejected for array_length()...
The objection was that basic functionality should not be implemented in
SQL. If we want to disallow all compatibility functions implemented in
SQL as well, we have more
Thank you for your reviewing my code.
2008/11/12 Heikki Linnakangas <[EMAIL PROTECTED]>:
> I've been slicing and dicing this patch for the last few days. There's a lot
> of code in there, but here's some initial comments:
>
> The code to initialize, advance, and finalize an aggregate should be sha
On Wed, Nov 12, 2008 at 09:46:09AM -0500, Robert Haas wrote:
> The || operator is valid only if the dimensions
> of the two arrays are equal (in which case it appends them) or if the
> dimension of one of the arrays is one less than the other (in which
> case, if legal, it treats the array of lesse
> Anyway, I think this is worth fixing before release but it clearly isn't
> worth attempting to rush a patch in the next few hours. I don't think
> we'll find anyone who is happy with making it a restart-required option.
I couldn't find a patch/commit for this and was just wondering whether
someo
"Sergey Konoplev" <[EMAIL PROTECTED]> writes:
> You are right. I've found the odd thing (that completely drives me
> mad) in postgresql.conf.
> You are able to reproduce slow-not-in queries by switching
> constraint_exclusion to on in your postgresql.conf and running my test
> (which is attached t
On Wed, Nov 12, 2008 at 02:12:19PM +0200, Peter Eisentraut wrote:
> Tom Lane wrote:
> >Seems like we ought to clean this up. I'm not sure which way to jump
> >though: should we decree that arrays of no elements must always have
> >zero dimensions, or should we get rid of that and standardize on, s
> It was pointed out to me today that a zero-dimensional matrix is a scalar.
> This makes a bit of sense, if you say that
>
> '{{56}}' is of type int[][], 2 dimensions
> '{56}' is of type int[], 1 dimension
> '56' is of type int, 0 dimensions
>
> Notice that the number of brace pairs in the litera
Just noticed that the last libpqtypes release was broken on windows when
dynamically linking. The problem is that windows has two addresses for
functions, the import library uses a stub "ordinal" address while the
DLL itself is using the real address; yet another m$ annoyance. This
breaks t
Hmm, ISTM that cardinality() is implemented here in the manner
previously rejected for array_length()...
...Robert
On Wed, Nov 12, 2008 at 8:13 AM, Peter Eisentraut <[EMAIL PROTECTED]> wrote:
> Robert Haas wrote:
>>
>> Updated version attached, this time without the compiler warning.
>
> I have c
Tom Lane wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > However, your idea suggests something else that we could do to improve
> > the patch: skip the ItemId->lp_flags during the CRC calculation. This
> > would mean we wouldn't need to WAL-log those.
>
> What!? In most cases those bits
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> However, your idea suggests something else that we could do to improve
> the patch: skip the ItemId->lp_flags during the CRC calculation. This
> would mean we wouldn't need to WAL-log those.
What!? In most cases those bits are critical data, not hints
I've been slicing and dicing this patch for the last few days. There's a
lot of code in there, but here's some initial comments:
The code to initialize, advance, and finalize an aggregate should be
shared between Agg and Window nodes.
I'm a bit disappointed that we need so much code to suppor
Martijn van Oosterhout wrote:
> If you're going to look at the line pointers anyway, couldn't you just
> do it in one pass, like:
>
> n = 0
> next = &tuple[n].hintbits
> pos = 0
> while pos < BLOCK_SIZE:
> if pos == next:
> CRC_ADD( block[pos] & mask )
> n++
> next = &tuple[n].hint
Tom Lane wrote:
That's an artifact of the fact that the patch tries to piggyback on
the DOMAIN infrastructure instead of implementing its own statement
type etc.
This piggybacking is intentional in some way. If you read the
commentary on the SQL99 standard, distinct types were specifically
i
Robert Haas wrote:
Updated version attached, this time without the compiler warning.
I have committed something based on this. The issue of empty arrays
will need a separate solution.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
Tom Lane wrote:
Seems like we ought to clean this up. I'm not sure which way to jump
though: should we decree that arrays of no elements must always have
zero dimensions, or should we get rid of that and standardize on, say,
1-D array with lower bound 1 and upper bound 0?
It was pointed out to
47 matches
Mail list logo
