Bugfix patches in the next CF, was: Re: [BUGS] pg_ctl -D "/absolute/path" -m fast restart - doesn't work in some cases
2013-05-16 23:55 keltezéssel, Alvaro Herrera írta: Josh Kupershmidt escribió: On Thu, May 16, 2013 at 4:34 PM, hubert depesz lubaczewski wrote: only when Pg is started with relative path, and restarted with absolute, the problem shows. It has been a nuisance for me too. Possible patch for pg_ctl is in the next CF: http://www.postgresql.org/message-id/cak3ujrfk8-izau1smpnzr5muc+6crwbk0_7byjnwuoapj3e...@mail.gmail.com Um, if this is a bug introduced during the 9.3 timeframe surely we ought to fix it now instead of waiting for the CF. Sorry for diverting the thread but if bugfixes are urgent, you can also look at http://www.postgresql.org/message-id/cabuevewx2dqt45x1phhdzd_khy8hz5a9xo95xvghou2ztyn...@mail.gmail.com and the fix at https://commitfest.postgresql.org/action/patch_view?id=1085 The CF in progress at the time was already closed for new patches. There are other patches marked as a bugfix, like: https://commitfest.postgresql.org/action/patch_view?id=1087 https://commitfest.postgresql.org/action/patch_view?id=1076 https://commitfest.postgresql.org/action/patch_view?id=1081 Best regards, Zoltán Böszörményi -- -- Zoltán Böszörményi Cybertec Schönig & Schönig GmbH Gröhrmühlgasse 26 A-2700 Wiener Neustadt, Austria Web: http://www.postgresql-support.de http://www.postgresql.at/ -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #6572: The example of SPI_execute is bogus
2012-04-14 18:15 keltezéssel, Peter Eisentraut írta: On lör, 2012-04-14 at 08:23 -0400, Robert Haas wrote: On Sat, Apr 14, 2012 at 3:27 AM, Pavel Stehule wrote: It has a lot of sense. Without it, it's very difficult to do logical replication on a table with no primary key. (Whether or not people should create such tables in the first place is, of course, beside the point.) I am not against to functionality - I am against just to syntax DELETE FROM tab LIMIT x because is it ambiguous what means: DELETE FROM tab RETURNING * LIMIT x What's ambiguous about that? I suppose one could wonder whether the LIMIT applies to the deleting or just the returning. Ambigous only in this order. LIMIT x RETURNING * wouldn't be. -- -- Zoltán Böszörményi Cybertec Schönig& Schönig GmbH Gröhrmühlgasse 26 A-2700 Wiener Neustadt, Austria Web: http://www.postgresql-support.de http://www.postgresql.at/ -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #6461: "-t" deletes primary key
2012-02-19 09:30 keltezéssel, Peter Eisentraut írta: > On fre, 2012-02-17 at 12:01 -0500, Tom Lane wrote: >> lenka.piy...@gmail.com writes: >>> when i restore a particular table using pg_restore (using option "-t") it >>> doesn't restore my primary key... >> This is not a bug. -t selects the table only, not associated indexes. The associated sequence != indexes on the same table, but yes, it's a little annoying sometimes. > But from a user's perspective, that behavior seems kind of useless. > > -- -- Zoltán Böszörményi Cybertec Schönig & Schönig GmbH Gröhrmühlgasse 26 A-2700 Wiener Neustadt, Austria Web: http://www.postgresql-support.de http://www.postgresql.at/ -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #6315: FETCH NEXT :next ROWS ONLY fails
2011-12-01 20:09 keltezéssel, rep.dot@gmail.com írta: > The following bug has been logged on the website: > > Bug reference: 6315 > Logged by: Bernhard Reutner-Fischer > Email address: rep.dot@gmail.com > PostgreSQL version: 9.1.1 > Operating system: linux > Description: > > Binding for "OFFSET :offset" works fine but binding for a > "FETCH NEXT :next > ROWS ONLY" raises: > syntax error at or near "$2" > SELECT * FROM foo OFFSET $1 ROWS FETCH NEXT $2 ROWS ONLY This is not a supported syntax. Consider using SELECT * FROM foo OFFSET $1 LIMIT $2 instead. -- -- Zoltán Böszörményi Cybertec Schönig & Schönig GmbH Gröhrmühlgasse 26 A-2700 Wiener Neustadt, Austria Web: http://www.postgresql-support.de http://www.postgresql.at/ -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] char(0)
2011-10-17 14:28 keltezéssel, Susanne Ebrecht írta: On 17.10.2011 10:30, Simon Riggs wrote: On Mon, Oct 17, 2011 at 8:31 AM, Susanne Ebrecht wrote: PostgreSQL isn't supporting CHAR(0). What does the SQL Standard say? Document: 02-Foundation Section: 4.2.1 Introduction to character strings Begin quoting A character string is a sequence of characters. All the characters in a character string are taken from a single character set. A character string has a length, which is the number of characters in the sequence. The length is 0 (zero) or a positive integer. End quoting I am looking at 6WD2_02_Foundation_2007-12.pdf. Search for "" that is used in section "6.1 ": := [ ] Section 6.1 doesn't talk about limiting the definition to > 0 values But in page 157, section "5.3 ": 17) The declared type of a is fixed-length character string. The length of a string literal> is the number of s that it contains. Each symbol> contained in represents a single in both the value and the length of the string literal>. The two s contained in a shall not be separated by any . NOTE 92 — s are allowed to be zero-length strings (i.e., to contain no characters) even though it is not permitted to declare a that is CHARACTER with 0 (zero). So, a table column is not allowed to be char(0) or varchar(0). It's explicit in NOTE 92. Best regards, Zoltán Böszörményi -- -- Zoltán Böszörményi Cybertec Schönig& Schönig GmbH Gröhrmühlgasse 26 A-2700 Wiener Neustadt, Austria Web: http://www.postgresql-support.de http://www.postgresql.at/ -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] Cache lookup failure for index during pg_dump
Tom Lane írta: > Bob Lunney writes: > >> I have a job that summarizes some data from a table, truncates the table, >> drops the indexes, writes the summarized data back into the table, then >> recreates the indexes. The operations above are not in a single >> transaction, but separate statements executed by a script. Easy, runs >> great, has for years. >> Recently the job takes a little longer to run and is still going when the >> database dump starts. That's when I started getting this: >> > > >> ERROR: cache lookup failed for index 70424 >> > > >> My questions are: can making DDL changes during a dump cause this error? >> Are the queries used by pg_dump transactionally consistent, i.e. do they run >> in a transaction and get a single view of the database system catalogs? >> Other than finer coordination of jobs, how can this situation be avoided? >> > > It's a bit messy. pg_dump runs in a serializable transaction, so it > sees a consistent snapshot of the database including system catalogs. > However, it relies in part on various specialized backend functions like > pg_get_indexdef(), and those things tend to run on SnapshotNow time, ie > they look at the currently committed state. So it is possible to get > this type of error if someone performs DDL changes while a dump is > happening: pg_dump sees index 70424 still listed in the catalogs, > so it asks about it, and the backend says "there is no such index", > which there isn't anymore because somebody dropped it since pg_dump's > transaction started. > I looked at ruleutils.c and now I am a little confused. I mean different functions use different subsystems to get their info. E.g.: syscache is used by e.g.: pg_get_indexdef pg_get_constraintdef pg_get_userbyid pg_get_functiondef direct systable_beginscan(SnapshotNow) is used by: pg_get_triggerdef pg_get_serial_sequence SPI is used by: pg_get_ruledef pg_get_viewdef SPI uses the same snapshot as the calling query, right? So, a serializable transaction gets all their info properly. Syscache doesn't contain old info, only the latest according to committed transactions, this is where the "cache lookup failed for index" problem comes from but some others, e.g. dropped functions or usernames may show a similar error message. Looking at the tqual.c and snapmgr.c, using systable_beginscan(GetTransactionSnapshot()) instead of SearchSysCache() would solve the problem for pg_dump. Why would we have to duplicate these functions? It seems (at least for pg_get_ruledef and pg_get_indexdef) that these functions are only used by pg_dump and psql's \something macros. We would lose a little performance by not using the syscache but gain a lot of correctness. Am I missing something? Best regards, Zoltán Böszörményi -- Bible has answers for everything. Proof: "But let your communication be, Yea, yea; Nay, nay: for whatsoever is more than these cometh of evil." (Matthew 5:37) - basics of digital technology. "May your kingdom come" - superficial description of plate tectonics -- Zoltán Böszörményi Cybertec Schönig & Schönig GmbH http://www.postgresql.at/ -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] dividing money by money
John R Pierce írta: > Boszormenyi Zoltan wrote: >> Loading this dump into another database that happens >> to have a different locale than hu_HU fails. >> >> But then any operator between two money values would >> only work if both values have the same currency. >> > > indeed, its all a big tarpit. next, you'll want currency conversion > tables. and, are there still any currenccies like old style UK where > the subunits aren't 100ths? schillings or whatever Yeah, and we could also switch PG numeric type to base 12 to count in dozens or base 60 to deal with the mayan calendar... ;-) -- Bible has answers for everything. Proof: "But let your communication be, Yea, yea; Nay, nay: for whatsoever is more than these cometh of evil." (Matthew 5:37) - basics of digital technology. "May your kingdom come" - superficial description of plate tectonics -- Zoltán Böszörményi Cybertec Schönig & Schönig GmbH http://www.postgresql.at/ -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] dividing money by money
Kevin Grittner írta:
> Andy Balholm wrote:
>
>
>> The ability to divide money by money would be useful for finding
>> what percent one money value is of another.
>>
>
> That certainly sounds useful and natural to me. I don't think it
> rises to the level of a *bug*, but it's a reasonable request for
> enhancement. If there are no objections I'll add it to the TODO
> list.
>
How about improving the money type so it can store
values in different currencies?
=# create table money1 (x money);
CREATE TABLE
=# insert into money1 values ('1');
INSERT 0 1
=# select * from money1;
x
Ft1,00
(1 sor)
=# insert into money1 values ('$1');
ERROR: invalid input syntax for type money: "$1"
pg_dump -t money1:
==
Ft1,00
\.
==
Loading this dump into another database that happens
to have a different locale than hu_HU fails.
But then any operator between two money values would
only work if both values have the same currency.
Best regards,
Zoltán Böszörményi
--
Bible has answers for everything. Proof:
"But let your communication be, Yea, yea; Nay, nay: for whatsoever is more
than these cometh of evil." (Matthew 5:37) - basics of digital technology.
"May your kingdom come" - superficial description of plate tectonics
--
Zoltán Böszörményi
Cybertec Schönig & Schönig GmbH
http://www.postgresql.at/
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
